Emax

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/instructions, 
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.
> > 
> > -- 
> > Yahoo! Messenger: EmaxJS
> > The Silveria Family Website and Emax and Emax II User's Group
> > http://www.silveriafamily.com
> > 
> >
>