Emax

I think the solution here really depends on the actual cause of the problem. It may even be just some simple thing like the cable wiring or a driver 
setting for the PC RS422 hardware. It would be helpful if you could provide some more detail on the hardware you are using. For a start, the exact 
brand and model number of the RS422 interfaces and cables plus the wiring diagrams of the cables.

The best case would be if you could get an existing PC RS422 interface to work with the Emax with no hardware modification. Otherwise the solutions 
start to get more complicated, such as modifying circuits, building an interface board or even having a microcontroller sitting between the PC and the 
Emax doing protocol translation. But now you have the Emax protocols worked out I believe a solution can be achieved. 

If you don't have the tools to measure what is going on in the interface circuits then you will have difficulty sorting this out. I would suggest using a 
digital oscilloscope to measure the TX and RX data signals plus the 500kHz clock at the Emax 6850 UART chip when the Emax is actually communicating 
with both the Mac and the PC. You will need at least two oscilloscope channels to see the clock and the data simultaneously. More channels would be 
nice, but the TX data and clock together and RX data and clock together are the first things to look at. You could also use a logic analyzer but I think an 
oscilloscope is better because it will show the actual waveforms, not just the logic transitions.

Unfortunately the Emax and Mac RS422 interfaces are products of their times, and times move on. No doubt it was a reasonable decision to implement 
the interface to the host computer this way back in the 1980s.

The sysex timeout is related to the dumping protocol and has no real bearing on what happens with the clocking at the data tranfer layer. But you could 
always experiment with it to see if it makes any difference to the problem you are seeing. At this stage we do not know for sure that the problem is at 
the low level.

I am not sure how much experience you have with hardware and communications troubleshooting but I am happy to help or provide further if you 
would like to pursue this. As I said in a previous email, I would like to see a general solution that would allow any of the Emu RS422 equipped samplers 
to be connected to a modern PC for sample dumping and/or bank transfer (where applicable). You have done fabulous work with the EMXP program and 
seem to have the software and Emu formats and protocols worked out. So I think getting this happening should not be too hard :)

/Tristan

Saturday, November 22, 2008, 12:00:21 AM, you wrote:

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