Emax

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