Emax

Thanks Tristan.

I'm wondering though: even if we find the actual cause of the problem 
(timing or signal level), I guess there's not much we can do to solve 
the problem. Besides making a custom communication board of course.
Because I don't think characteristics such as "clock to data 
relationship" can be configured on any normal commercial RS422 port 
device for PCs, right ?
That's in fact the only reason why I didn't invest in a scope yet: 
exactly knowing the problem would be nice, but not being able to 
solve it would be frustrating :-)
Man ! I would love the standard PC RS422 ports to be externally 
clockable ! Why is this (once again) one of those "Mac"-only 
features !

Question: the RS422 communication "timeout period" on the Emax can be 
configured with a SYSEX command (from 1 to 127 seconds). But I guess 
this is not something that can help on the lowel level data 
syncronization problem we are dealing with here, right ? I 
guess "our" problem is more related to the speed at which a stream of 
bits (as a whole) is entering the Emax port ?

///E-Synthesist 

--- In emax@yahoogroups.com, tu@... wrote:
>
> Yes, an oscilloscope is what you need. I suggest getting a digital 
model as it should allow you to capture and store the signals you are 
measuring. Some 
> high end multimeters also have oscilloscope functions, but check 
the bandwidth is well above the highest frequencies you will need to 
measure. An audio 
> card is not suitable for this task.
> 
> I did a search on the Mac serial port and it seems that while the 
output voltage levels are slightly non standard they should not 
present any problems for 
> the Emax 9637 RS422 receiver chip. I only have the Emax II 
schematics but I believe the RS422 interface should be the same as 
the Emax. The 9637 
> circuit doesn't appear to have any EMI supression or termination 
other than a pullup to +5V on the noninverting input. So the Emax is 
relying on the 
> sending circuit to ensure a reasonably clean signal arrives. The 
Mac has an EMI filter on its RS422 port but I am not sure what your 
PC RS422 port may 
> have.
> 
> Another thing to look at is the relationship between the 500kHz 
clock the Emax sends out and the data that is sent back to the Emax 
from the PC. The 
> 6850 UART in the Emax relies on a this being within a certain 
timing range. If the clock to data relationship from the PC RS422 
port is not the same as 
> from the Mac then this could cause problems. The same would also 
occur if the PC RS422 transmit clock is drifting because is not 
locked to the same 
> clock that it is receiving from the Emax. Of course the data being 
sent from the Emax to the PC will be ok because the clock and data 
are transmitted 
> together with the correct timing relationship.
> 
> /Tristan
> 
> Tuesday, November 18, 2008, 3:58:48 AM, you wrote:
> 
> >
> 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.
> > > > > > > >
> >
>