Emax

Tristan,

Actually I only tried the Emax-->PC bank transfer, so I can't say 
anything about the other direction yet.
So concerning the Emax->PC transfer: in fact the Emax can live with 
the fact that no ACKs are being sent by the host. If no ACK (or data 
in general) is transmitted for about 55 msec, Emax seems to decide to 
send the next packet. Sounds great, but note that a bank transfer 
takes a lot of time this way (waiting for these ACKs will already 
take more than 4 minutes in total :-). But I was able to download 
banks this way, yes...
So why doesn't the Emax re-send the packet for max. 5 times ?
Because after initially sending the packet, the PC sends an ACK to 
the Emax which fails to arrive correctly on the Emax. The Emax 
replies immediately with a "Cancel Dump" message and on the Emax 
display the error "Aborted - Bad ACK received for packet XXXX".

You're right about the 31.25kbaud communication: this is indeed 
asynchronous, so it's relying on the internal clock. That means 
switching from internal to external clock for unloading/loading banks.

About your request to send/receive wavs between EMXP and the Emax: no 
problem, that can be done once we succeed in getting the hardware 
comms up and running ! 

///E-Synthesist



--- In emax@yahoogroups.com, 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.
> 
> Its interesting you should mention the 31.25k/500k baud rate 
switching. The Emax UART must do this by selecting x1 or x16 clock 
divider mode in the 
> UART. According to the schemtics, the 500kHz clock being sent out 
of the RS422 port and driving the Emax UART TX & RX does not change 
in 
> frequency. 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.
> 
> You earlier reported that the Emax bank dump must be continuous 
with no resent packets. But I notice the MIDI SDS implementation in 
the Emax allows 
> for up to 5 resends if a Nak is received for a particular packet. 
When your bank dump failed was this because of the RS422 clock 
synchronization 
> problem? If so, it is likely any subsequent resends of the packet 
would also have failed and received a Nak. This leads me to suspect 
that with a working 
> synchronous RS422 connection you probably could continue the dump 
by resending packets that returned a Nak from the Emax.
> 
> 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. 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. 
> 
> 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.
> 
> I would be very interested to have the option in EMXP to dump 
samples to and from the Emax (or other Emu RS422 equiped sampler) 
directly from wav 
> files. Then it would be easy to take a sample, transfer it to the 
PC, edit on any PC editor that supports wav and then dump back to the 
sampler again. 
> Do you have any plan to implement something like this in addition 
to bank transfers?
> 
> /Tristan
> 
> Monday, November 24, 2008, 2:30:34 AM, you 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....
> >
>