Emax

Hi Emu artists
 
I've been following the thread concerning pc to Emax bank transfer with much interest. 
 
I fully support what Tristian say. I think to, that it will be worthwhile for Emu-users to be able to transfer banks from the pc to the whole Emu line of samplers (Emax, Emax II, EII, EIII & EIIIx) via the RS422 port.
 
I was just hoping that the interface could be an USB to RS422 since I have no more room for a PCI card. :-| But as I read the posts of the impressive guy E-synthesist, this doesn't seem possible. That's a bummer for me.
 
I hope you'll find a solution and keep up the good work :-)
 
Best regards
 
Brian
Denmark
 


--- Den man 17/11/08 skrev tu@... <tu@....au>:

Fra: tu@... <tu@...>
Emne: Re: [emax] Re: RS422 fun
Til: "esynthesist" <emax@yahoogroups.com>
Dato: mandag 17. november 2008 13.24






I am not sure about the Mac circuitry but the RS422 interface on the Emax should just be standard 
9637 and 9638 RS422 buffers. The input threshold on the 9637 receiver is specified to be +/- 
200mV so it should work with voltages higher than that. Do you have an oscilloscope that you can 
use to probe the 9637 while it is receiving data? If so, you could compare when receiving data 
from the Mac and the PC via RS422.

Its not a priority, but I think it would be worthwhile to have an RS422 interface that would allow 
any PC to be used for sample dumping to the Emax I, Emax II, EII, EIII and EIIIx as well as bank 
transfer with the EII and Emax. Even if an interface box cost some money I feel there would be a 
demand given the numbers of these samplers still in use. The Emu world cannot live on old Macs 
alone :)

/Tristan

Monday, November 17, 2008, 3:24:57 AM, you wrote:

>
After some additional testing I'm pretty sure the problems are not 
caused by timing differences, but by voltage levels. 
I received a PCMCIA RS422 port this week, and this thing has even 
more problems with communicating with the EII and the Emax than my 
USB/RS422 converter device. And again the communication problem is to 
be found in the PC->Emax transmit part, not in the receive part.
I mentioned before that the Mac RS422 is sending very high signal 
levels (higher than "officially" allowed by the RS422 standard). The 
Emu samplers seem to rely on these high signals.
Conclusion: I give up the current experiments. Perhaps some time in 
the future I'll try to make a device based on Mac circuits...

--- In emax@yahoogroups. com, tu@... wrote:
>
> Ok, that is interesting.
> 
> An alternative to direct connection of the RS422 to the PC would be 
a microcontroller sitting 
> between the PC and sampler. I think someone suggested that before. 
It could respond to the 
> sampler with tight timing but handle the loose timing over the PC 
connection. I guess the PC side 
> could be implemented with either RS-232 or USB. But obviously USB 
would require a lot more 
> coding than simply translating RS422 and RS232 port protocols with 
a bit of buffering in between.
> 
> /Tristan
> 
> Wednesday, November 12, 2008, 1:15:37 AM, you wrote:
> 
> >
> Yes it's about the same concept as on the EII: taking an exact dump 
> of the internal Emax memory at 500 kbaud in both directions. Or in 
> other words... transferring an EMX file across the serial line 
> (except for the EMX 39 byte header string of course).
> 
> But there are two major drawbacks compared with the EII: 
> 1/ the Emax uses the MMA standard to accomplish this dump, meaning 
> that the data is sent in packets of 120 bytes instead of 256 bytes, 
> which is slower.
> 2/ it's not possible to dump specific memory segments, the whole 
> thing must be dumped in one sequential loop from the very beginning 
> (position 0) to the very end (position 552959). 
> 
> The second one is a BIG problem: it means that if something goes 
> wrong (like a bad packet) the whole dump must be restarted.
> And... since the PC RS422 communication line with the Emax is not 
> optimal, this kind of error will for sure occur during a bank 
> transfer. On the EII, this means simply re-asking for the 
particular 
> bad data packet, but on the Emax you have to start all over again.
> 
> In practice this means that a full load/unload is simply not 
possible 
> with my current hardware (USB-RS422 and USB-RS232 converters of all 
> kinds) because the loop is restarted endlessly. At the end of the 
> week I'll try an non-USB port device, I hope that one will work.
> If not, a custom RS422 PC port must be built for the Emax/EII, 
based 
> on the RS422 circuits & ICs of the Mac.
> 
> ///E-Synthesist
> 
> --- In emax@yahoogroups. com, tu@ wrote:
> >
> > Fantastic! So, is it the same method that the EII uses for bank 
> transfer or something else? Is there 
> > any chance you could document the protocol? 
> > 
> > I think 25-30 seconds should be acceptable for Emax I bank loads. 
> At least it provides an option 
> > for those who can't or don't want to add SCSI. 
> > 
> > The Emax II load time does sound a bit slow. But it might still 
be 
> of use if someone had a working 
> > Emax II with a dead SCSI chip.
> > 
> > Out of interest, can the Emax II directly load an Emax I bank 
(with 
> compressed 8 bit samples) in 
> > this way? 
> > 
> > /Tristan
> > 
> > Tuesday, November 11, 2008, 3:04:25 AM, you wrote:
> > 
> > >
> > After some experiments during the weekend, the current status of 
my 
> > little RS422 project is that I know how to do *fast* bank 
> > loads/unloads on the Emax via RS422. 
> > This should reduce the total data transfer time to 25-30 seconds 
on 
> > the Emax-I instead of the 2-3 minutes of Alchemy. Most probably 
> this 
> > was also the total load time of the OMI CDS3 system, which is - 
> let's 
> > say - "acceptable" ... 
> > That's about the same speed as loading from a floppy :-) but the 
> > biggest advantage would be that one would have immediate access 
to 
> > hundreds of banks on the PC harddrive instead of having to copy 
> > individual banks to floppy disks first... 
> > Still SCSI is a much better alternative. .. for those having a 
rev2 
> or 
> > rev3 board, and for those using the Emax-II. BTW at RS422 speed, 
> the 
> > data transfer time on a fully loaded Emax-II Turbo 8M would be 
> about 
> > 7 minutes :-). Fortunately every Emax-II is equipped with SCSI.
> > 
> > I have to write some decent software now which supports the full 
> Emax 
> > handshaking protocol. But I'm pretty sure that the USB<-->RS422 
> > converters will not be the best solution for this communication - 
> > just like with the EII the communication seems to be quite 
> unreliable 
> > when transmitting data from the PC to the Emax, as a consequence 
> the 
> > total transfer time increases dramatically due to handshaking 
> > overhead. 
> > At the end of the week I will have a PCCard RS422 port on my 
> laptop. 
> > This piece of hardware does not suffer from USB latency, so I 
hope 
> it 
> > will work better...
> > 
> > ///E-Synthesist
> > 
> > --- In emax@yahoogroups. com, "esynthesist" <esynthesist@ > wrote:
> > >
> > > Yes, I was also thinking there must be some dedicated command 
> (set) 
> > > for fast load/unload. But the fact that John remembered a load 
> time 
> > > of 5 minutes for the OMI cdroms made me doubt again... On the 
> other 
> > > hand it is true that OMI cdroms could only be used after the 
> > release 
> > > of OS 3.2, so this is indeed an indication that additional 
> commands 
> > > have been added, or at least some changes have been applied. I 
> also 
> > > observed that the v 3.2 MIDI protocol is not 100% behaving as 
> > > described in the v 3.0 document, e.g. the timeout handling is 
> > > different. So there are also changes in the 'normal' SYSEX/MMA 
> > > protocol.
> > > By the way: the OMI drive also required a firmware update in 
> order 
> > to 
> > > be compatible with the Emax. Question is of course whether this 
> was 
> > > just a small firmware update (to support the newly added 
commands 
> > in 
> > > the Emax OS) or a huge piece of Emax-specific code (to 
implement 
> > the 
> > > full SYSEX/MMA command set - which is indeed quite unlikely) ...
> > > 
> > > The Emax-II and EIII indeed have a filesystem which is 
optimized 
> > for 
> > > handling different banksizes; I have the specs here because I 
> > needed 
> > > them for EMXP. The EII and Emax are using filesystems with 
fixed 
> > > filesizes in a sequential order.
> > > 
> > > Since I don't have any Emax OMI cdrom disk I'm not even sure 
> > whether 
> > > the banks on these disks are "EMX-like" 8-bit images or 
expanded 
> 12 
> > > bit images. It makes sense that they are 8-bit, because this 
> > allowed 
> > > OMI to put more banks on a CD, to transfer them faster to the 
> Emax 
> > > (if EII-like commands have been implemented in the Emax OS of 
> > course) 
> > > and to use the same bank layout as on the Emax floppy and Emax 
> > > harddisk banks.
> > > 
> > > So despite the "5 minutes load time" note from John, I think we 
> can 
> > > still assume that there is some specific command set in V3.2 
> which 
> > > enables fast bank loads. I will try to find them out during the 
> > > weekend, either by experimenting or by looking into the OS 
> > > binary/disassembled code...
> > > 
> > > ///E-Synthesist
> > > 
> > > 
> > > 
> > > --- In emax@yahoogroups. com, tu@ wrote:
> > > >
> > > > 
> > > > Thursday, November 6, 2008, 4:23:43 AM, you wrote:
> > > > 
> > > > >
> > > > But the 5 minutes load time may have been reality...
> > > > 
> > > > This can explain why I don't know anyone and find no 
reference 
> at 
> > > all 
> > > > of anyone who actually used this CD-ROM drive with the Emax. 
If 
> > > this 
> > > > 5 minutes load time is true, this must have resulted in a 
> > > commercial 
> > > > failure for OMI when they launched the Emax OMI cd disks... 
but 
> > > they 
> > > > probably released these disks also in Mac/SD format ?
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Yes, such a slow load time would have been a major marketing 
> > > problem. I find it difficult to imagine that Emu would not have 
> > added 
> > > the small amount of 
> > > > extra code required to load in a bank quickly via RS422. If 
> they 
> > > wanted to sell Emaxes then surely there was a strong incentive 
to 
> > > make the sound 
> > > > library efficient to use. I suspect the OMI CDROM system for 
> the 
> > > Emax was not a major market success because of the cost. The 
OMI 
> > > CDROM drive, or 
> > > > even a Mac with a CDROM drive, would have cost a significant 
> > > proportion of the cost of an Emax. The average musician 
probably 
> > > would not have been 
> > > > able to justify that additional expense. Particularly so 
given 
> > that 
> > > early CDROM drives were rather fragile.
> > > > 
> > > > >
> > > > 
> > > > And yes, Emu has done strange things. E.g. the EII cdrom kit 
> > > > supported a "folder" or "category" system: the banks on a 
disk 
> > > could 
> > > > be put in folders (like bank "piano" in folder "acoustic 
> > > keyboards") 
> > > > to make navigation much easier. This feature was not 
available 
> on 
> > > the 
> > > > Emax and EIII harddisks. Maybe Emu considered this to be a 
> > feature 
> > > of 
> > > > OMI and not of Emu themselves, but they could have learned 
from 
> > > > that...
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Surely the category organisation was only a feature of the 
OMI 
> > > CDROM system, as the EII had no control over it. So it was 
OMI's 
> > > CDROM format, not 
> > > > Emu's format. But this also gave OMI the flexibility to put 
as 
> > many 
> > > banks on the disk as they wanted and to organise them as they 
> > wanted. 
> > > There was 
> > > > no restriction on how OMI could do this as long as they could 
> > serve 
> > > up the full memory image of each bank to the EII via the RS422 
> port 
> > > when required.
> > > > 
> > > > Don't the Emax and the EII hard disk formats allocate a fixed 
> > > number of banks for the disk? I believe you cannot fit any more 
> > banks 
> > > on the disk even if 
> > > > the existing banks are only half full of samples. Presumably 
> this 
> > > is because the Emax and EII use a fixed memory size for each 
bank 
> > and 
> > > the complete 
> > > > data for the bank is copied directly between memory and disk 
> when 
> > > you load or save a bank. Each hard disk bank is a the 
equivalent 
> of 
> > > one floppy disk 
> > > > image minus the OS data. I believe the Emax II and EIII use 
> > > variable sized banks. Therefore the number of banks stored on a 
> > hard 
> > > disk or CDROM 
> > > > depends on how much data is contained in each bank. But I 
> believe 
> > > there is still a limit of 100 banks per disk. 
> > > > 
> > > > >
> > > > 
> > > > 
> > > > 
> > > > RS422 Communication with the Emulator was designed based on 
> > > following 
> > > > key principles:
> > > > - all communication, including request/reply for parameter 
> > changes, 
> > > > occurs at 500 Kbaud
> > > > - a whole bank can be downloaded/loaded with one special 
> designed 
> > > > type of command (a command which actually directly 
reads/writes 
> > the 
> > > > RAM memory segments in which the bank data is residing)
> > > > - bulk data load/unload occurs with data packets sized 256 
> bytes, 
> > > of 
> > > > which each byte represents 1 sample point (data is 
transferred 
> in 
> > > > compressed format)
> > > > 
> > > > On the Emax, they seem to have decided that choosing for a 
> > > *standard* 
> > > > medium speed protocol was more important than choosing for a 
> > > > *proprietary* high speed protocol. So they went for the MIDI 
> > > > SYSES/MMA approach:
> > > > - all basic communication, including all 
commands/instructio ns, 
> > > > occurs at 31.25 Kbaud, no matter if the DIN5 MIDI sockets or 
> the 
> > > DB9 
> > > > RS422 port are being used.
> > > > - loading/unloading banks requires the full set of SYSEX 
> > commands. 
> > > > Hence to simply download the parameters of just one voice of 
> just 
> > > one 
> > > > preset, already multiple commands must be exchanged with the 
> > Emax. 
> > > > This is due to the fact that in general only one parameter 
can 
> be 
> > > > transferred per command. And this must be done at the slow 
> 31.25 
> > > > Kbaud speed...mmmm. ..
> > > > - bulk data (sample) load/unload occurs with data packets 
sized 
> > > only 
> > > > 120 bytes (MMA standard). Moreover each sample point requires 
> 12 
> > > bits 
> > > > now instead of 8 bits on the EII since data is transferred in 
> > > linear 
> > > > format instead of compressed format.
> > > > As a consequence, loading/unloading banks is much slower than 
> on 
> > > the 
> > > > EII. Of course, once they released the Emax-II, they would 
have 
> > > faced 
> > > > problems anyway. This machine could have up to 8MB banks and 
> > > doesn't 
> > > > use compression, so even at full 500 kbaud speed and using 
only 
> > one 
> > > > command - which is impossible in reality - the Emax-II would 
> > > require 
> > > > at least 2.7 minutes for loading/unloading banks. Fortunately 
> > there 
> > > > was something invented called SCSI :-)
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Have a look at the MIDI spec for the Emax V3.0 software. The 
> fast 
> > > (RS422) dumps use a protocol based on the MIDI SDS but slightly 
> > > modified. The 
> > > > sample data is dumped as 12 bit linear but the samples are 
> packed 
> > > so that two 12 bit samples are transferred in three 8 bit 
bytes. 
> It 
> > > is also of note that 
> > > > sending 8 bit wide data in this way violates the MIDI 
standard, 
> > as 
> > > bit7 is always reserved as an indicator of a status byte. Of 
> course 
> > > this is not really an 
> > > > issue here as the 500k baud RS422 data is only being 
> transferred 
> > > to/from the Emax so no other MIDI devices will ever see this 
> > > violation of the 
> > > > standard. But the outcome is that dumping samples as 12 bit 
> only 
> > > takes 50% longer than dumping as 8 bit compressed. Doing a 
proper 
> > > MIDI SDS dump 
> > > > of 8 bit or 12 bit data actually takes the same amount of 
time 
> as 
> > > only 7 data bits can be transferred for each byte in the 
message. 
> > So 
> > > an 8 bit dump 
> > > > takes two bytes per sample (7 + 1) while a 12 bit dump also 
> > > requires two bytes per sample (7 + 5). 16 bit dumps are even 
> slower 
> > > as they require three 
> > > > bytes per sample (7 + 7 + 2).
> > > > 
> > > > As you have said, the failure to provide a means of directly 
> > > transferring banks into memory via RS422 seems to be the 
problem 
> in 
> > > the Emax, at least as 
> > > > documented in the V3.0 MIDI spec. But if the V3.0 spec 
already 
> > > provides all the functions required to load banks from the 
CDROM 
> > > drive using MIDI 
> > > > SYSEX and RS422, then why is V3.2 or the SE software claimed 
to 
> > add 
> > > OMI CDROM support? It still seems likely to me that some extra 
> > > functions were 
> > > > added in those versions to support fast bank loading via 
RS422. 
> > If 
> > > not, then the OMI CDROM drive would have to be converting the 8 
> bit 
> > > compressed 
> > > > sample data on the CDROM to 12 bit linear in order to dump 
the 
> > > samples into the Emax. The Emax would then have to convert the 
12 
> > bit 
> > > linear samples 
> > > > back to compressed 8 bit samples. The transfer of samples 
would 
> > > also take 50% longer for 12 bit linear compared to 8 bit 
> > compressed. 
> > > And of course 
> > > > there would be no way for sequencer data included in the bank 
> to 
> > be 
> > > loaded into the Emax. I could be wrong, but it just seems 
> unlikely 
> > > Emu would have 
> > > > made it so difficult when a small software update to the Emax 
> > could 
> > > make bank dumping work in much the same way as the EII.
> > > > 
> > > > >
> > > > 
> > > > Nevertheless I will still do some experiments to find out if 
> the 
> > > Emax 
> > > > OS doesn't have any "fast bank load" commands... 
> > > > By the way: does anyone know whether the binary code of the 
> Emax 
> > OS 
> > > > can easily be de-compiled/ disassembled in some way in order 
to 
> > get 
> > > > some kind of source code ? Is a simple Z80 disassembler 
> > sufficient ?
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Unfortunately it seems the only way is to experiment and see 
> what 
> > > can be uncovered. The Emax NS32000 main CPU code can be 
> > disassembled 
> > > but it is 
> > > > not a common processor. The hard part of analyzing the 
> > disassembled 
> > > code is working out where the program and data begins and ends 
as 
> > > well as what 
> > > > interrupt routines are being handled at runtime and how they 
> > > interact. You would need to combine together the code from the 
> disk 
> > > OS image and the 
> > > > EPROM into a processor memory map. Various hardware 
peripherals 
> > > will also probably exist at certain addresses in the memory 
map. 
> To 
> > > pull it all 
> > > > together you will ideally have the circuit schematics, the 
> memory 
> > > map, CPU/chip documentation plus a detailed design description 
of 
> > how 
> > > the system 
> > > > works. Often much of this data can be found in the product 
> > service 
> > > manual. Then you need to determine which routines are called 
when 
> > > MIDI/RS422 
> > > > interrupts are handled. Testing with a logic analyzer probing 
> the 
> > > CPU would certainly make that easier.
> > > > 
> > > > /Tristan
> > > > 
> > > > >
> > > > 
> > > > 
> > > > ///E-Synthesist 
> > > > 
> > > > --- In emax@yahoogroups. com, tu@ wrote:
> > > > >
> > > > > That seems excessively slow, as the EII could load a 
similar 
> > > sized 
> > > > bank from the same CDROM 
> > > > > drive in 12 seconds. Its hard to imagine Emu would not have 
> > > > implemented a similar load time on 
> > > > > the Emax if all it took was adding a software routine. But 
> then 
> > > > again, stranger things have 
> > > > > happened...
> > > > > 
> > > > > /Tristan
> > > > > 
> > > > > Quoting John Silveria II <john@>:
> > > > > 
> > > > > > Somewhere, and I can't remember where, I read that the CD-
> Rom 
> > > > drive
> > > > > > took 
> > > > > > up to 5 minutes to load a bank. I wish I could remember 
> > where. 
> > > So
> > > > > > indeed 
> > > > > > it was not only as slow as typical SYSEX load, it could 
> > > actually 
> > > > take
> > > > > > 
> > > > > > longer.
> > > > > > 

 














      ___________________________________________________________ 
Skal du købe ny bil? Sammenlign priser på brugte biler med Kelkoo og find et godt tilbud! - Se mere her http://dk.yahoo.com/r/pat/mmb

[Non-text portions of this message have been removed]