Emax

--- In emax@yahoogroups.com, Ted Summers <djtbs1@...> wrote:
>
> Well, for the person who is going to build the interface board- what  
> about using the clock out from the emax as input into the clock  
> circuit of the UART on the interface board to be built?
> 
> Would that make it synchronized?

Yep. But does the X1 and X16 modes need to be both clocked?
If not there needs to be some software (PC side) to tell the board to
change to and from synchronous/asynchronous.

I have very little Mac knowledge...
Some brief research from interweb has revealed that the 8-pin port is
not really RS-422 on the Mac but Appletalk/localtalk?
So I see for USB MAC owners solutions are 
http://www.geethree.com/stealth/index.html
- card that replaces the modem card.
and
http://www.keyspan.com/products/usa28xg/homepage.spml
- But apparently not on OSX.

Cheers,
Ed.

 
> Regards,
> Ted
> 
> 
> On Nov 26, 2008, at 1:41 PM, esynthesist wrote:
> 
>  >>>>One thing - you already have EII comms working with a standard
> off the shelf USB connector, don't you???
> <<<<
> Yes I have, but it works only for sending banks from the EII to the
> PC, not the other way around, due to the synchronization loss...
> which was the reason why I posted this RS422 questions to Emu
> groups :-)
> 
> I you'd like to have the example C code I used for this and/or for
> the Emax bank unload, I can send them to you.
> The Emax code "works" but as I mentoned before the communication gets
> out of sync after receiving about 40 datapackets, due to the lack of
> sync comm.
> The code contains basically the port configurations (baudrate,
> parity, ...) and the open/read/write/close instructions to perform
> the actual communication. It uses the standard serial communication
> library of Microsoft (Visual C), based on things like DCB
> configuration. In these communication libraries I haven't found any
> structure/function yet which allows to set the baudrate to "external
> clocking" instead of a "number" (internal clocking).
> But perhaps the provided software with your device can be driven in
> another way, allowing for other parameters sent accross the USB
> serial class.
> 
> ...So we stay "on" topic in this board with the Q&A about RS422 and
> the experiments to get the thing working for Emax ?
> 
> ///E-Synthesist
> 
> --- In emax@yahoogroups.com, mr julian <jujulilianan@> wrote:
>  >
>  > first up, I know NOTHING about the windows driver side of this... I
> just
>  > installed a driver that was supplied with the firmware, and I can
> see
>  > that in windows system, it's come up as a generic serial port, with
>  > settings for:
>  >
>  > Bits per second: (75-128000)
>  > data bits: (4-8)
>  > parity: (odd, even, none, mark, space)
>  > stop bits: (1, 1.5, 2)
>  > flow control: (Xon/Xoff, hardware, none)
>  >
>  > Also, I can open and close this port in hyperterminal, and adjust
> the
>  > settings in hyperterminal....
>  >
>  > Now, I imagine that wheen it is connected to my PC, this port gets
>  > listed somewhere inside windows in an appropriate place, and
>  > applications looking for serial ports find its information, and can
> then
>  > request to connect/disconnect, and and send config information -
> just
>  > like any other serial port.... but if I needed to add extra
>  > functionality, like a synchronous BPS setting, I have no idea where
> to
>  > put that... but maybe I could find out?
>  >
>  > I'm still waiting for the 422 chips, so will start seeing what I
> can
>  > find out about the driver, and the application-driver interface,
> plus
>  > the driver-board interface. and see what would need to be modified
> to
>  > make this do exactly what we want.
>  >
>  > But yeah. my ideal finished product would be a USB connected board
> that
>  > connects to a PC, and windows sees it as a standard serial
> interface
>  > with standard interface parameters including synch/asynch control
>  > (whatever standard for that is!) and your program could therefore
>  > connect to it just like it would connect to any other serial
> interface,
>  > and work with it the same way for any sampler....
>  >
>  > Also, I'm not interested in holding any kind of IP here - I'm
> really
>  > just mucking about with configuration and possibly making small
>  > adjustments to existing open-source code...... if I create a
> solution,
>  > I'll provide all assembly instructions/code completely open for
> anyone
>  > who wants to use it however they wat.
>  >
>  > One thing - you already have EII comms working with a standard off
> the
>  > shelf USB connector, don't you???
>  >
>  >
>  >
>  > anyway - we should probably take this discussion off-list. it's
> getting
>  > a bit OT for the emax community in general I think.
>  > :-)
>  >
>  >
>  >
>  > esynthesist wrote:
>  >
>  > >OK :-)
>  > >What are the parameters that *can* be changed with the standard
>  > >driver ? Nothing ??? Isn't it possible to define parity, or
> clocking
>  > >by software? If this is true, how can you change these parameters
>  > >then ? I'm not sure I understand.
>  > >
>  > >I mean: as soon as I can write a piece of C-code (based on sample
>  > >code provided by you of course ;-), which uses the standard USB
>  > >driver library, but which contains specific Emax code, that's fine
>  > >for me; then it's just a matter of writing another piece of code
> for
>  > >each Emu sampler we want to support. I was not hoping for more.
>  > >But if the *hardware itself* is built in such a way that it only
>  > >supports the Emax, then we would need another piece of hardware
> for
>  > >the Emulator II, and that would be a shame...
>  > >
>  > >But I guess it will all be software-driven, right ?
>  > >
>  > >///E-Synthesist
>  > >
>  > >
>  > >
>  > >
>  > >
>  >
> 
> 
> 
> 
> 
> [Non-text portions of this message have been removed]
>