Emax

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....
>