Emax

To have 100% certainty about the actual problem I should indeed do 
some measurements with an oscilloscope... but I don't have one.
I was (and still) am thinking about buying one, either analog or 
digital. Until now I only did some measurements with an external 
audio card acting as a wave recorder, but its sampling frequency and 
bandwith are - of course - insufficient to do proper measurements on 
500kbaud signals. What I do see however - even with this method - is 
that the amplitude level of the Mac signal is much higher than the PC 
signal.
On the other hand, if the RS422 of the Emax is standard, then I 
shouldn't have any problem. Mmmm... 
Yes, the best solution would consist of a custom RS422 port for the 
PC which can even be externally clocked. But I'm not an electronics 
specialist so it will take a looooonnnnng time before I will end up 
with a working set :-)

///E-Synthesist

--- In emax@yahoogroups.com, tu@... wrote:
>
> 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/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.
> > > > > > >
>