Hi Ted, yes, the Emax documents mention synchronous communication,
while the EII documents mention asynchronous communication.
Anyway it's clear that we need synchronous communication from the
perspective that the host should be clocked by the slave (strange
world we're living in :-) so they shouldn't clock independent from
each other.
Of course the Emax and EII provide a clock signal to the Mac. That's
clearly described in all documents. Moreover the internal clock of
the Mac is not capable of generating 500 kbaud by itself, so this
speed was only possible by providing a clock to the Mac.
The homepages of the devices I mentioned provide the (limited)
information which accompanies these devices. I have no technical
inside information.
The Meilhaus is the only one I can open, and the main IC is labeled
FTDI FT2328L 729-1.
The other 3 ICs are labeled:
- MAX3089E CSD0706 (two ICs)
- NXP 74HCT02D L7C1C303 Un60723D
and an oscillator (?) labeled 6.00F7PN
There's also a 4th small 8-pin IC but that one is too small to read
its label :-)
The board is labeled KENT 2 94V-0.
But the main problem is that the "contact" with the "outside world"
is provided by a DB9M connector only and some jumpers.
And in all of my devices this DB9M connector complies with
the 'typical' RS422 pin layout. This means:
- 1 pin for the ground
- 4 pins for the data transmission (+ and -, send and receive)
- 4 pins for the handshaking (+ and -, RTS and CTS)
No pins are left, so no additional pins of the internal chips can be
reached, unless one would solder direcly on them (and they are very
small !). This is true for almost all RS422 ports out there, except
for the minidin8 of the Mac.
It would be interesting to know if there are RS422 devices which have
additional pins for things like external clocking.
Any device based on the chip used in the Mac should do the job (they
told me it's something like a Philips SCN2651, I have the datasheet
but no device using this IC)...
///E-Synthesist
--- In emax@yahoogroups.com, Ted Summers <djtbs1@...> wrote:
>
> From the emax service manual.....
>
>
> This paragraph to me indicates a Synchronous clock at 500Khz. What
I
> can see from the schematic is that the signal from pin 7 connects
to
> the 9638 pin 6. The 9638 pin 6 is an output signal confirmed from
the
> parts datasheet. So the Emax is supplying the clock to the host
> computer for timing.
>
> So what you are saying is that none of these RS422 ports or
converters
> have a clock line input?
>
> Do you have any links to the documentation for these RS422 devices
> that we can review or are there any schematics for them or are you
> able to determine any IC's used in them we could look at the
> datasheets for?
>
> Regards,
> Ted
>
>
> On Nov 22, 2008, at 9:14 AM, esynthesist wrote:
>
> OK. If I was able to connect the clock of the Emax with the RS422
> port I would have done so from the very beginning of course :-)
>
> But that's the whole problem: I haven't found a new PC RS422 port
yet
> which is capable of being externally clocked. Also the specs
provided
> on many vendor's websites are pretty vague.
> Perhaps some high end RS422 automation ports can be clocked, but
> these devices tend to be quite expensive (and still seem not to have
> this feature; the higher price is due to additional protection,
> better hardcases, breakout boxes, multiple ports, etc).
>
> So: if anyone knows where to buy an affordable RS422 port (USB or PC
> Card/Express Card) which is externally clockable, I love to hear
it !!
>
> (Note: as far as I know the EII has the same serial communication
> setup as the Emax. Does this mean that the statement in the Emu
> document saying that the RS422 communication is "asynchronous" is a
> type/wrong ?)
>
> ///E-Synthesist
>
> --- In emax@yahoogroups.com, tu@ wrote:
> >
> > Ok, this explains why you are seeing errors in the data coming
from
> the PC but not with data going to the PC. You are running the PC
> RS422 interfaces
> > asynchronously when they need to synchronous with the Emax clock.
> Your cable also does not have the 500kHz clock from the Emax
> connected!
> >
> > When your PC RS422 interface is set to 500k baud with its
internal
> clock the PC RS422 interface can receive the data from the Emax
> perfectly because
> > the data is transmitted in the same format as a standard
> asynchronous UART transmission. However, the 6850 UART in the Emax
is
> running in x1
> > synchronous mode, where it needs one correctly aligned clock
pulse
> for each start, stop and data bit received. As the Emax UART RX
clock
> is fed from
> > the same 500kHz clock that appears on its RS422 port, the
received
> data needs to be properly synchronized with that clock edge.
> >
> > With your currect interfaces the PC UART will be happily
> transmitting data in sync with its internal clock but the
> asynchronous bit transitions will not
> > always be in sync with the Emax 500kHz clock. Because of this the
> Emax will sometimes appear to work correctly but then the clock to
> data relationship
> > will drift and there will be corruption in the received data.
> >
> > The best solution for this would be to get another RS422 card
that
> allows operation from an external clock in x1 mode. The 500kHz x1
> UART clock is
> > transmitted from pin 7 of the Emax RS422 connector and needs to
be
> connected to the PC RS422 external clock input. Note that the
CTS/RTS
> pins on
> > serial ports are for hardware handshaking and not normally used
as
> clock inputs. The Mac serial interface uses its HSKi pin as its
> external clock input
> > but how this is implemented in another RS422 may be different.
> >
> > /Tristan
> >
> > Saturday, November 22, 2008, 9:03:23 PM, you wrote:
> >
> > >
> > About the hardware I have used until now:
> >
> > Serial ports:
> > - Meilhaus Redcom USB-COMI RS422 USB port. Also sold with other
> brand
> > names such as Easysync; very popular one. --> This is the one I
> have
> > best results with. Internal clockable at 500kbaud.
> > - Moxa Uport 1150 RS422/RS232 USB port. This device does not
> support
> > RTS/CTS handshaking for RS422 and is not internally clockable at
> 500
> > kbaud. So it's useless :-)
> > - Exsys EX-1362 double RS422 PCMCIA card. This one has the same
> > features as the Meilhaus but the results where less reliable.
> > - Ednet RS232 USB adapter 84204. A cheap RS232 device, just to
see
> if
> > this wouldn't work. It didn't.
> >
> > Cable/wiring:
> > Until now I only used the GND and DATA signals, so I connected 5
> pins
> > of the Emax/Emulator II to the PC RS422 as follows:
> > - Emax PIN 3 (GND) to RS422 PIN 5 (GND)
> > - Emax PIN 4 (RXD+) to RS422 PIN 2 (TXD+)
> > - Emax PIN 5 (RXD-) to RS422 PIN 1 (TXD-)
> > - Emax PIN 8 (TXD+) to RS422 PIN 3 (RXD+)
> > - Emax PIN 9 (TXD-) to RS422 PIN 4 (RXD-)
> > The cable is a 10-wire shielded cable of 1.5 meters long.
> >
> > (I already spent 300 EUR on serial devices, so I'm not planning
to
> > buy additional ones anymore :-)
> >
> > Final note: before I started this project with the EII/Emax, I
had
> > never programmed/monitored a serial device before, so let's say
> that
> > my hardware/RS422 experience is low but increasing ...
> >
> > ///E-Synthesist
> >
> > --- In emax@yahoogroups.com, tu@ wrote:
> > >
> > > 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
Show quoted textHide quoted text
> > > could
> > > > > > > > actually
> > > > > > > > > take
> > > > > > > > > > >
> > > > > > > > > > > longer.
> > > > > > > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>