Emax

OK :-)
What are the parameters that *can* be changed with the standard 
driver ? Nothing ??? Isn't it possible to define parity, or clocking 
by software? If this is true, how can you change these parameters 
then ? I'm not sure I understand.

I mean: as soon as I can write a piece of C-code (based on sample 
code provided by you of course ;-), which uses the standard USB 
driver library, but which contains specific Emax code, that's fine 
for me; then it's just a matter of writing another piece of code for 
each Emu sampler we want to support. I was not hoping for more.
But if the *hardware itself* is built in such a way that it only 
supports the Emax, then we would need another piece of hardware for 
the Emulator II, and that would be a shame...

But I guess it will all be software-driven, right ?

///E-Synthesist 

--- In emax@yahoogroups.com, "Julian" <jujulilianan@...> wrote:
>
> what you want is probably doable. It's definately do-able with the 
AVR,
> but my issue is the PC driver side, and modifying or creating a 
driver
> to send all the extra configuration instructions.
> 
> How about we try and see what we can do with a hard coded emax 
version,
> and then see what we can do for the EII later?
> 
> that would be a great excuse for me to get an Eii......
> :-P
> 
> 
> 
> 
> On Mon, 24 Nov 2008 22:12:14 -0000, "esynthesist"
> <esynthesist@...> said:
> > 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.....
> > >
> > 
> > 
> > 
> > ------------------------------------
> > 
> > Emax and Emax II User's Group Website
> > 
> > http://www.silveriafamily.comYahoo! Groups Links
> > 
> > 
> > 
> -- 
> http://bleepin.com
> 
> -- 
> http://www.fastmail.fm - Same, same, but different...
>