Emax

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