Emax

That cable would actually be a serial cable. I have a couple of these
myself.
Parallel ports by definition are not serial.

Parallel has a datawire for each of the 8 bits, serial has one datawire that
tranfers all the bits for a single byte.
Just because the plug fits, doesn't mean that the two devices talk, the
protocol is right or even that the pinout is compatible.

Many a person has plugged a cable into a port on a PC and blown up one or
the other or both due to signal pinout differences.

Since everything is builtin on modern PC motherboards, it is no longer as
simple as swapping an interface board. You can blow up the IC that controls
all I/O that interface to the PCI bus. That can become the time to buy a new
motherboard.

YMMV



On Thu, Nov 5, 2009 at 1:04 PM, gadgetfiddler <gadgetfiddler@...>wrote:

>
>
> have you considered utulizing the printer port on a pc to make the data
> transfer into the rs-422 port on the emaxII?
> I've got a cord with a male printer port plug on one side and a female
> serial port plug on the other.
>
> --- In emax@yahoogroups.com <emax%40yahoogroups.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?
> >
> > 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 <emax%40yahoogroups.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]
> >
>
> 
>


[Non-text portions of this message have been removed]