Emax

I hope you can create a device which is not restricted to the Emax ! 
If we could use the same device with the EII that would be awesome.

From a software developer's point of view, it would be really nice to 
have a device which can be instructed by software to:
- run with any supported internal clock rate (at least 31.25 kbaud 
which we really need)
- run with external clocking
- use X databits, Y stopbits and Z parity.
- (perhaps) use some timing parameters, like "max time between two 
bytes" (but I'm not sure we really need this)

That's all I want :-) and it would be the most flexible solution, 
capable of communicating with any Emu sampler supporting the RS422 
interface.

I hope I'm not dreaming ?
Crossing my fingers...
Good luck !

///E-Synthesist 

--- In emax@yahoogroups.com, mr julian <jujulilianan@...> 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.....
>