Emax

I think a DSO is a better option here as this investigation will most likely involve looking at the signal waveforms. A logic analyzer will usually have 
more channels and a deeper memory than a DSO but it will just show logic transitions. A DSO with a combined logic analyzer pod would probably be 
ideal, but more expensive.

/Tristan

Saturday, November 22, 2008, 5:39:23 AM, you wrote:

>
so the non-USB port didn't work?

That link I sent the other week was to a 422 adapter card that was able 
to run synchronous.... is the issue that this card can only be clock 
master, or something???

PS, you do NOT need a digital storage oscilloscope. A logic analyser 
will tell you way more here.

esynthesist wrote:

>Thanks Tristan.
>
>I'm wondering though: even if we find the actual cause of the problem 
>(timing or signal level), I guess there's not much we can do to solve 
>the problem. Besides making a custom communication board of course.
>Because I don't think characteristics such as "clock to data 
>relationship" can be configured on any normal commercial RS422 port 
>device for PCs, right ?
>That's in fact the only reason why I didn't invest in a scope yet: 
>exactly knowing the problem would be nice, but not being able to 
>solve it would be frustrating :-)
>Man ! I would love the standard PC RS422 ports to be externally 
>clockable ! Why is this (once again) one of those "Mac"-only 
>features !
>
>Question: the RS422 communication "timeout period" on the Emax can be 
>configured with a SYSEX command (from 1 to 127 seconds). But I guess 
>this is not something that can help on the lowel level data 
>syncronization problem we are dealing with here, right ? I 
>guess "our" problem is more related to the speed at which a stream of 
>bits (as a whole) is entering the Emax port ?
>
>///E-Synthesist 
>
>
> 
>
> 
>

hey Tristian.

sorry, but you think wrong.

I have a DSO at work that costs more than an EII, an EIII, an emax, an 
emax II, and old mac, and a PC with a proper synchronious RS422 port 
combined... and it won't help with debugging a serial comms protocol, 
beyond the most basic of issues.

Any old 10MHz+ cro will show you in about 20 seconds if you have a 
voltage problem with your serial interface at 500khz.... After that 
there can be all sorts of issues, relating to subtle timing problems, 
and a simple USB connected logic analyser will be the tool to 
investigate and quantify any problems there.... (once you actually have 
the PC running an externally clocked synchronous RS422 interface....)


tu@... wrote:

>I think a DSO is a better option here as this investigation will most likely involve looking at the signal waveforms. A logic analyzer will usually have 
>more channels and a deeper memory than a DSO but it will just show logic transitions. A DSO with a combined logic analyzer pod would probably be 
>ideal, but more expensive.
>
>/Tristan
>
>  
>

Sorry, maybe there was some confusion. I was referring to using the DSO for investigating the 
waveforms of the RS422 signal, not for analysing the protocol. Obviously a logic analyzer would be 
better for that.

/Tristan

Sunday, November 23, 2008, 10:07:46 AM, you wrote:

>
hey Tristian.

sorry, but you think wrong.

I have a DSO at work that costs more than an EII, an EIII, an emax, an 
emax II, and old mac, and a PC with a proper synchronious RS422 port 
combined... and it won't help with debugging a serial comms protocol, 
beyond the most basic of issues.

Any old 10MHz+ cro will show you in about 20 seconds if you have a 
voltage problem with your serial interface at 500khz.... After that 
there can be all sorts of issues, relating to subtle timing problems, 
and a simple USB connected logic analyser will be the tool to 
investigate and quantify any problems there.... (once you actually have 
the PC running an externally clocked synchronous RS422 interface....)

tu@... wrote:

>I think a DSO is a better option here as this investigation will most likely involve looking at the 
signal waveforms. A logic analyzer will usually have 
>more channels and a deeper memory than a DSO but it will just show logic transitions. A DSO 
with a combined logic analyzer pod would probably be 

>ideal, but more expensive.
>
>/Tristan
>
> 
>

If the Emax bank dump protocol uses the same format as the MMA SDS data packet then each 
packet only requires 127 bytes. That should not be too difficult to buffer.

If each packet requires a Ack/Nak reply then there is a built in flow control mechanism and no 
RTS/CTS hardware flow control is required. 

Esynthesist, would it be possible for you to reveal a bit more detail about the bank dump protocol? 
What goes in the headers etc?

/Tristan

Sunday, November 23, 2008, 9:01:15 PM, you wrote:

>

esynthesist wrote:

> Oops. I'm getting depressed finding out that my s/h USD50 old Mac is
>
>equipped with two (!) serial ports capable of what one (!) new USD399 
>one can do. And for that 50 dollars the Mac package also includes a 
>computer with screen, keyboard, harddisk and floppy drive :-)
>(ok, the Quatech will have more *serial* features, but still...)
> 
>
yeah.... modern computers move on from old tech, but then when you need 
the simple old features of the old tech, they're no longer a standard 
item, and you pay $$

>So I guess the next step is custom building one, e.g. with 
>experimental/evaluation boards or from scratch. 
>Not my piece of cake...
> 
>
Well, I did some investigating, and got the basic RS232 adapter test 
code up and working with serial loopback on my dev board, and read 
through the manual about setting up the avr USART for synchronous 
communication, which looks really simple... (though will have to build 
some buffer circuits, and then do more testing running it in loopback, 
while being externally clocked form the emax, before I can say it'll 
even be approaching being a possibly being useful solution)

note: this will never work as well as a proper US$399 synchronous 
interface, because it will be limited by whatever buffer size that can 
be made in the AVR(which has only 8k of ram), after the USB stack and 
the basic code takes everything it needs, but it's possible that maybe 
with a bit of tweaking, it can be made to work well enough to send and 
receive packets for the emax... as long as it's allowed to spend a bit 
of time shuffling data to/from the PC between packets....

so - how big are the packets that the emax sends and receives, anyway??

>I guess experimenting with the CTS/RTS signals also does not make 
>sense anymore, right ? I thought it could be a way to keep the 
>drifting under control... I guess not... 
> 
>
nope... sorry... it's the mechanism for either side of the comms pair to 
say "hold up! I've had enough!!" to the other side, instead of just 
overflowing and crapping out...

looking at my service manual again, I don't see CTS or RTS here 
either.... just tx, rx, and clock. so I guess that's all we need, to 
talk to the emax from a PC?

>And I'm still a bit afraid that it could damage my PC RS422 port 
>since the RTS/CTS pins are expecting either positive or negative 
>voltages but not a mixture of them. Or are those ports typically 
>protected against this "abuse" ?
> 
>
They are protected, to some degree.

btw, "+" and "-" do not refer to the voltage polarity of a balanced 
signal, they refer to the logical polarity. in this case, I think you'll 
find RS422 + and - parts of a signal are both always in the range of 0V 
to 5V, but the "+" is 5V when the "-" is 0v, and the "-" is 5V when the 
"+ is 0v....

O yes, the protocol.
It's really simple in fact. It's based on MMA as it has been 
described in the MIDI SYSEX v3.0 docs of Emu.
It's just that the "Get Bank" and "Send Bank" SYSEX commands were 
missing in that document. Here they are:

1/ To send a bank from Emax to Host Computer:
  - the host should send F0 18 02 09 F7 at 31.25kbaud to the Emax 
(Request to Send Bank Fast)
  - the Emax will respond with F0 18 02 0F F7 at 31.25kbaud (Accept 
Bank Fast)
  - then Emax switches to 500kbaud, and the host computer should do 
so too.
  - from that point on the communication is exactly the same as the 
one described for Send Sample Fast: the host should send an initial 
ACK (F0 7E 0C 7F 00 F7) and then the data dump starts. The Emax sends 
MMA data packets (127 bytes containing 120 data bytes), and each 
packet should be ACKed by the host (F0 7E 0C 7F pp F7 with pp = 
packet number looping from 0x00 to 0xFF, then back to 0x00 again and 
so on).
  - in total 4609 of these packet transmissions + ACKs should be done.

2/ To send a bank from Host Computer to Emax:
  - the host should send F0 18 02 0F F7 at 31.25kbaud to the Emax 
(Accept Bank Fast)
  - the Emax will immediately switch to 500kbaud and the host 
computer should do so too
  - the Emax will send an ACK (if everything goes well) i.e. F0 7E 0C 
7F 00 F7
  - then the host should start sending MMA packets, which will be 
ACKed by the Emax one after another (packets 00=0x00 to 127=0xFF and 
then again from 0x00)

That's about it.
To find this out, I simply tried the first undocumented SYSEX code 
(09) and I immediately had luck ! It seemed to be the command I was 
looking for.
Sniffing the communication between my Mac (Sound Designer for Emax) 
and the Emax confirms that this is the protocol that should be used.

Of course I want to add the RS422 load/unload features to EMXP, and 
was hoping to be able to use the standard Windows C serial 
communication library of Microsoft.
If some of you succeed in creating hardware for the RS422 it would be 
great that this library can be used. If some special hardware 
specific library must be used I can get in trouble with freeware 
licensing for EMXP... unless that library would be completely free 
also.

PS: the fact that the host must initiate the communication at 31.25 
kbaud and then has to switch to 500kbaud is something to think about 
when using external clocking. I suppose and hope that even this 31.25 
kbaud is clocked by the Emax to the Mac, so that the host doesn't 
have to change from internal clocking to external clocking all the 
time.

///E-Synthesist
--- In emax@yahoogroups.com, tu@... wrote:
>
> If the Emax bank dump protocol uses the same format as the MMA SDS 
data packet then each 
> packet only requires 127 bytes. That should not be too difficult to 
buffer.
> 
> If each packet requires a Ack/Nak reply then there is a built in 
flow control mechanism and no 
> RTS/CTS hardware flow control is required. 
> 
> Esynthesist, would it be possible for you to reveal a bit more 
detail about the bank dump protocol? 
> What goes in the headers etc?
> 
> /Tristan
> 
> Sunday, November 23, 2008, 9:01:15 PM, you wrote:
> 
> >
> 
> esynthesist wrote:
> 
> > Oops. I'm getting depressed finding out that my s/h USD50 old Mac 
is
> >
> >equipped with two (!) serial ports capable of what one (!) new 
USD399 
> >one can do. And for that 50 dollars the Mac package also includes 
a 
> >computer with screen, keyboard, harddisk and floppy drive :-)
> >(ok, the Quatech will have more *serial* features, but still...)
> > 
> >
> yeah.... modern computers move on from old tech, but then when you 
need 
> the simple old features of the old tech, they're no longer a 
standard 
> item, and you pay $$
> 
> >So I guess the next step is custom building one, e.g. with 
> >experimental/evaluation boards or from scratch. 
> >Not my piece of cake...
> > 
> >
> Well, I did some investigating, and got the basic RS232 adapter 
test 
> code up and working with serial loopback on my dev board, and read 
> through the manual about setting up the avr USART for synchronous 
> communication, which looks really simple... (though will have to 
build 
> some buffer circuits, and then do more testing running it in 
loopback, 
> while being externally clocked form the emax, before I can say 
it'll 
> even be approaching being a possibly being useful solution)
> 
> note: this will never work as well as a proper US$399 synchronous 
> interface, because it will be limited by whatever buffer size that 
can 
> be made in the AVR(which has only 8k of ram), after the USB stack 
and 
> the basic code takes everything it needs, but it's possible that 
maybe 
> with a bit of tweaking, it can be made to work well enough to send 
and 
> receive packets for the emax... as long as it's allowed to spend a 
bit 
> of time shuffling data to/from the PC between packets....
> 
> so - how big are the packets that the emax sends and receives, 
anyway??
> 
> >I guess experimenting with the CTS/RTS signals also does not make 
> >sense anymore, right ? I thought it could be a way to keep the 
> >drifting under control... I guess not... 
> > 
> >
> nope... sorry... it's the mechanism for either side of the comms 
pair to 
> say "hold up! I've had enough!!" to the other side, instead of just 
> overflowing and crapping out...
> 
> looking at my service manual again, I don't see CTS or RTS here 
> either.... just tx, rx, and clock. so I guess that's all we need, 
to 
> talk to the emax from a PC?
> 
> >And I'm still a bit afraid that it could damage my PC RS422 port 
> >since the RTS/CTS pins are expecting either positive or negative 
> >voltages but not a mixture of them. Or are those ports typically 
> >protected against this "abuse" ?
> > 
> >
> They are protected, to some degree.
> 
> btw, "+" and "-" do not refer to the voltage polarity of a balanced 
> signal, they refer to the logical polarity. in this case, I think 
you'll 
> find RS422 + and - parts of a signal are both always in the range 
of 0V 
> to 5V, but the "+" is 5V when the "-" is 0v, and the "-" is 5V when 
the 
> "+ is 0v....
>

Something I forgot in the communication specs:
- The 31.25 kbaud communication is 1 startbit, 8 databits, 1 stopbit, 
no parity
- The 500 kbaud communication is 1 startbit, 8 databits, 1 stopbit, 
odd parity

///E-Synthesist

--- In emax@yahoogroups.com, "esynthesist" <esynthesist@...> wrote:
>
> O yes, the protocol.
> It's really simple in fact. It's based on MMA as it has been 
> described in the MIDI SYSEX v3.0 docs of Emu.
> It's just that the "Get Bank" and "Send Bank" SYSEX commands were 
> missing in that document. Here they are:
> 
> 1/ To send a bank from Emax to Host Computer:
>   - the host should send F0 18 02 09 F7 at 31.25kbaud to the Emax 
> (Request to Send Bank Fast)
>   - the Emax will respond with F0 18 02 0F F7 at 31.25kbaud (Accept 
> Bank Fast)
>   - then Emax switches to 500kbaud, and the host computer should do 
> so too.
>   - from that point on the communication is exactly the same as the 
> one described for Send Sample Fast: the host should send an initial 
> ACK (F0 7E 0C 7F 00 F7) and then the data dump starts. The Emax 
sends 
> MMA data packets (127 bytes containing 120 data bytes), and each 
> packet should be ACKed by the host (F0 7E 0C 7F pp F7 with pp = 
> packet number looping from 0x00 to 0xFF, then back to 0x00 again 
and 
> so on).
>   - in total 4609 of these packet transmissions + ACKs should be 
done.
> 
> 2/ To send a bank from Host Computer to Emax:
>   - the host should send F0 18 02 0F F7 at 31.25kbaud to the Emax 
> (Accept Bank Fast)
>   - the Emax will immediately switch to 500kbaud and the host 
> computer should do so too
>   - the Emax will send an ACK (if everything goes well) i.e. F0 7E 
0C 
> 7F 00 F7
>   - then the host should start sending MMA packets, which will be 
> ACKed by the Emax one after another (packets 00=0x00 to 127=0xFF 
and 
> then again from 0x00)
> 
> That's about it.
> To find this out, I simply tried the first undocumented SYSEX code 
> (09) and I immediately had luck ! It seemed to be the command I was 
> looking for.
> Sniffing the communication between my Mac (Sound Designer for Emax) 
> and the Emax confirms that this is the protocol that should be used.
> 
> Of course I want to add the RS422 load/unload features to EMXP, and 
> was hoping to be able to use the standard Windows C serial 
> communication library of Microsoft.
> If some of you succeed in creating hardware for the RS422 it would 
be 
> great that this library can be used. If some special hardware 
> specific library must be used I can get in trouble with freeware 
> licensing for EMXP... unless that library would be completely free 
> also.
> 
> PS: the fact that the host must initiate the communication at 31.25 
> kbaud and then has to switch to 500kbaud is something to think 
about 
> when using external clocking. I suppose and hope that even this 
31.25 
> kbaud is clocked by the Emax to the Mac, so that the host doesn't 
> have to change from internal clocking to external clocking all the 
> time.
> 
> ///E-Synthesist
> --- In emax@yahoogroups.com, tu@ wrote:
> >
> > If the Emax bank dump protocol uses the same format as the MMA 
SDS 
> data packet then each 
> > packet only requires 127 bytes. That should not be too difficult 
to 
> buffer.
> > 
> > If each packet requires a Ack/Nak reply then there is a built in 
> flow control mechanism and no 
> > RTS/CTS hardware flow control is required. 
> > 
> > Esynthesist, would it be possible for you to reveal a bit more 
> detail about the bank dump protocol? 
> > What goes in the headers etc?
> > 
> > /Tristan
> > 
> > Sunday, November 23, 2008, 9:01:15 PM, you wrote:
> > 
> > >
> > 
> > esynthesist wrote:
> > 
> > > Oops. I'm getting depressed finding out that my s/h USD50 old 
Mac 
> is
> > >
> > >equipped with two (!) serial ports capable of what one (!) new 
> USD399 
> > >one can do. And for that 50 dollars the Mac package also 
includes 
> a 
> > >computer with screen, keyboard, harddisk and floppy drive :-)
> > >(ok, the Quatech will have more *serial* features, but still...)
> > > 
> > >
> > yeah.... modern computers move on from old tech, but then when 
you 
> need 
> > the simple old features of the old tech, they're no longer a 
> standard 
> > item, and you pay $$
> > 
> > >So I guess the next step is custom building one, e.g. with 
> > >experimental/evaluation boards or from scratch. 
> > >Not my piece of cake...
> > > 
> > >
> > Well, I did some investigating, and got the basic RS232 adapter 
> test 
> > code up and working with serial loopback on my dev board, and 
read 
> > through the manual about setting up the avr USART for synchronous 
> > communication, which looks really simple... (though will have to 
> build 
> > some buffer circuits, and then do more testing running it in 
> loopback, 
> > while being externally clocked form the emax, before I can say 
> it'll 
> > even be approaching being a possibly being useful solution)
> > 
> > note: this will never work as well as a proper US$399 synchronous 
> > interface, because it will be limited by whatever buffer size 
that 
> can 
> > be made in the AVR(which has only 8k of ram), after the USB stack 
> and 
> > the basic code takes everything it needs, but it's possible that 
> maybe 
> > with a bit of tweaking, it can be made to work well enough to 
send 
> and 
> > receive packets for the emax... as long as it's allowed to spend 
a 
> bit 
> > of time shuffling data to/from the PC between packets....
> > 
> > so - how big are the packets that the emax sends and receives, 
> anyway??
> > 
> > >I guess experimenting with the CTS/RTS signals also does not 
make 
> > >sense anymore, right ? I thought it could be a way to keep the 
> > >drifting under control... I guess not... 
> > > 
> > >
> > nope... sorry... it's the mechanism for either side of the comms 
> pair to 
> > say "hold up! I've had enough!!" to the other side, instead of 
just 
> > overflowing and crapping out...
> > 
> > looking at my service manual again, I don't see CTS or RTS here 
> > either.... just tx, rx, and clock. so I guess that's all we need, 
> to 
> > talk to the emax from a PC?
> > 
> > >And I'm still a bit afraid that it could damage my PC RS422 port 
> > >since the RTS/CTS pins are expecting either positive or negative 
> > >voltages but not a mixture of them. Or are those ports typically 
> > >protected against this "abuse" ?
> > > 
> > >
> > They are protected, to some degree.
> > 
> > btw, "+" and "-" do not refer to the voltage polarity of a 
balanced 
> > signal, they refer to the logical polarity. in this case, I think 
> you'll 
> > find RS422 + and - parts of a signal are both always in the range 
> of 0V 
> > to 5V, but the "+" is 5V when the "-" is 0v, and the "-" is 5V 
when 

> the 
> > "+ is 0v....
> >
>

esynthesist wrote:

>If some of you succeed in creating hardware for the RS422 it would be 
>great that this library can be used. If some special hardware 
>specific library must be used I can get in trouble with freeware 
>licensing for EMXP... unless that library would be completely free 
>also.
>  
>
it's just using a standard windows USB serial port driver so far. in 
this case, you'll see it just as a normal USB serial port... if it needs 
something more than that, I could be slowed down a lot, as I have no 
windows driver experience.... will have to look more into it if need arises.
:-)

anyway - I ordered RS422 chips yesterday. should have them in a few 
days, I hope. then will experiment with the emax, and see what i can see.

>PS: the fact that the host must initiate the communication at 31.25 
>kbaud and then has to switch to 500kbaud is something to think about 
>when using external clocking.
>
hmmm... of course standard RS232 ports don't do 31.25 or synchronous.....
possibly the simplest thing to do is to tell the serial interface to run 
at 19.2k, and i can make that value actually set the interface to 31.25 
similarly, tell the interface to run at 115k, and I can make it run as a 
synchronous slave. I don't think that will cause problems in the driver 
side.

speaking of 31.25 - how did you select that? was it one of the standard 
baud options with your RS422 ports?

> I suppose and hope that even this 31.25 
>kbaud is clocked by the Emax to the Mac, so that the host doesn't 
>have to change from internal clocking to external clocking all the 
>time.
>  
>
naah... it probably does change.
but that's OK.
very simple to do on the AVR side. just need to change a bit in a 
register, and flush serial port buffers.....
:-)

Sounds great that standard USB serial comms is being used.

I don't know about the clocking part of your hardware experiment, but 
from a signal perspective I was thinking that RS232 can be used too, 
as long as you can clock at 31.25 internally and clock externally for 
the 500kbaud. The Emulator II document states explicitly that its 
port is both RS422 and RS232 compliant (using the EII TXD-/RXD- only 
towards the RS232 TXD/RXD pins), but that the 500kbaud speed must be 
supported in both cases and that "this is typically not supported by 
RS232 chips". I guess the same principle holds for the Emax ?

To answer your question about the 31.25kbaud speed: with my USB<--
>RS422 adapter it is possible to clock internally at ANY speed 
between 200 bps and about 1 Mbps; the chipset seems not to use the 
standard "divider" approach, but another "new" thing in a "new" IC :-
) So I could clock at 31.25 and 500 kbaud simply by instructing the 
port to do so.

///E-Synthesist

--- In emax@yahoogroups.com, mr julian <jujulilianan@...> wrote:
>
> 
> 
> esynthesist wrote:
> 
> >If some of you succeed in creating hardware for the RS422 it would 
be 
> >great that this library can be used. If some special hardware 
> >specific library must be used I can get in trouble with freeware 
> >licensing for EMXP... unless that library would be completely free 
> >also.
> >  
> >
> it's just using a standard windows USB serial port driver so far. 
in 
> this case, you'll see it just as a normal USB serial port... if it 
needs 
> something more than that, I could be slowed down a lot, as I have 
no 
> windows driver experience.... will have to look more into it if 
need arises.
> :-)
> 
> anyway - I ordered RS422 chips yesterday. should have them in a few 
> days, I hope. then will experiment with the emax, and see what i 
can see.
> 
> >PS: the fact that the host must initiate the communication at 
31.25 
> >kbaud and then has to switch to 500kbaud is something to think 
about 
> >when using external clocking.
> >
> hmmm... of course standard RS232 ports don't do 31.25 or 
synchronous.....
> possibly the simplest thing to do is to tell the serial interface 
to run 
> at 19.2k, and i can make that value actually set the interface to 
31.25 
> similarly, tell the interface to run at 115k, and I can make it run 
as a 
> synchronous slave. I don't think that will cause problems in the 
driver 
> side.
> 
> speaking of 31.25 - how did you select that? was it one of the 
standard 

> baud options with your RS422 ports?
> 
> > I suppose and hope that even this 31.25 
> >kbaud is clocked by the Emax to the Mac, so that the host doesn't 
> >have to change from internal clocking to external clocking all the 
> >time.
> >  
> >
> naah... it probably does change.
> but that's OK.
> very simple to do on the AVR side. just need to change a bit in a 
> register, and flush serial port buffers.....
> :-)
>

I agree, your USB to RS422 adapter is probably the best option here. It has the specific 
advantages that the PC software can command the baud rate and parity detection to change in 
accordance with the protocol and it is a once piece solution. 

Still, I might put together a serial baud rate converter just to try it out. I will of course have to get 
the microcontroller to monitor the comms and modify the RS422 UART baud rate and parity as 
required. I looked around and it seems most UARTs do not support the synchronous mode. That is 
probably why most USB to RSXXX adapters don't support it either. I will probably just use the 
microcontroller's internal UART to talk to the PC and a 6850 UART to talk to the RS422 interface. At 
least I know it will be compatible with the Emax!

By my calculation, if the PC UART runs at 460.8k baud (4 x 115.2k) with no parity then the data 
rate will be extremely close to that of the Emax UART with odd parity. 460.8k/10 = 46.08kB/s vs 
500k/11 = 45.454kB/s. I think this is probably the optimal rate to minimise the load on the buffers. 

I think I already have all the parts needed to build it except for the 6850. But I do not have much 
time right now so it might have to wait until the Christmas break. Maybe you will have the USB 
solution working by then anyway.

/Tristan

Tuesday, November 25, 2008, 5:12:51 AM, you wrote:

>


tu@... wrote:

>Thanks, this protocol makes sense. No doubt Emu did it this way so they could reuse the SDS 
sample dump code. Can you confirm that the Emax 
>always waits for an Ack/Nak before sending the next packet? This is important to know, as the 
buffering requirement is much lower if we can be sure a 
>new packet will not arrive until after the last packet has been handled.
> 
>
yeah..... that would make things really simple.
:-)

>A side effect of this is that when operating at 31.25k baud the Emax UART is actually working in 
asynchronous mode. Synchronous operation 
>only happens when the x1 clock divider is used. Therefore the Mac is presumably doing the same 
thing at its end when switching between the baud 
>rates.
> 
>
I'm pretty sure the mac would have to have it's own clock for 
asynchronous communication.

in asynchronous mode, the UART runs at much faster than baudrate speeds 
(say 500k for 31.25k data ??which is why the emax works fine at asynch 
31.25k with this as it's clock, still... ;-) and continually samples the 
serial data for the start bit. then when it's got a valid start bit, 
having detected the falling edge at the beginning, it samples the rest 
of the bits in the middle, and confirms the final edge of the stop bit. 
all being good, the received byte is latched to the output.

>The easiest solution from your software perspective would be if you could have a USB serial port 
that supports synchronous RS422 connection to the 
>Emax (or other Emu sampler). Then you handle the protocol, baud rate switching etc and you can 
use standard Windows drivers. This is presumably 
>what the expensive commercial interfaces are offering and I presume this is what Julian is 
working on a low cost alternative to. 
>
yep!
:-)

basic solution if this works will be one $30 dev board, wired to a 
separate board with a couple of ICs. I will just veroboard the custom 
stuff for now, but if it works and a few people want one, can always get 
a batch of small PCBs made up for a few $.

if I can get away with a simple unchanged serial adapter, that would be 
amazing - otherwise I might have to put some smarts into my buffer that 
will make it only work with the emax (ie look for header info and 
deliberately hold off a packet retransmission to the emax until it has a 
whole one, etc etc - basically make it run off the actual data that 
comes through it...)

>Another option would be 
>to have a microcontroller with a large buffer memory that the PC can read from and write to 
using whatever protocol and the microcontroller would 
>handle the Emu sampler synchronous RS422 interface and protocols. Obviously this would be 
more work to develop the software for the microcontroller 
>and possibly the drivers. 
> 
>
yeah - would be best not to have to do that if at all possible.
also, half a MB of fast access RAM for buffering would be annoying to 
deal with hooking up on an 8 bit micro.

>Another possibility would be to have a micro controller with two serial interfaces, one to the PC 
(asynchronous RS422 or RS232) and one to the Emu 
>sampler (synchronous RS422). The micro controller would just buffer and pass data between the 
two UARTs and switch baud rates (31.25k/500k) 
>toward the Emu sampler if required. The PC host could connect via any off the shelf USB to 
RS232/RS422 adapter or use a built in or PCI serial port. 
>Because of the flow control provided by the Ack/Nak messages, the PC serial connection could 
also use any baud rate the PC port supports. Although 
>dumps would be slower at PC baud rates lower than 500kHz, this would make it widely 
compatible with any old PC you might happen to have lying 
>around. Both the microcontroller software and hardware would be fairly simple for this option and 
no special drivers would be required. The Emax serial 
>port even provides +5V that could be used to power the small interface board.
> 
>

A serial rate converter would be even simpler, but it would be nice to 
be able to have PC side running fast enough that there was no gaps 
between bytes in a packet, as seen by the emax.....