Re: Mockingboard emulator (was: Late night musings...)

[nparker@cie-2.uoregon.edu (Neil Parker)]

In article <50b1lc$bh6@news.bconnex.net> jefbla@bconnex.net (Jeff Blakeney)
writes:
>[...]
>Basically, when the emulator sees an access in the "virtual slot" that
>we wish to make into a "Mockingboard" we check to see what the 8 bit
>program is telling the Mockingboard to do and reproduce the same
>effect using the Ensoniq.  This same technique can be applied to
>emulating a 5.25" disk controller which will allow access to a real
>5.25" drive or to a disk image file on a hard drive.

In order to do this reliably, you'd have to find some way to intercept
each opcode as it executes, and check to see if it references the virtual
hardware.  Some computers provide easy ways to do this, but not the Apple
II--if you want to do it with any reliability, you're stuck single-stepping
the code.

There are a couple of ways to do this.  One is to build a complete virtual
6502, like the PC and Mac A2 emulators do.  The emulator fetches each
opcode itself, decodes it, and performs the appropriate operation on the
simulated registers or simulated memory.  The code running under the
emulator's control never actually executes directly on the host CPU.

The other way is to do it like the very first Apple II ROM does for the
monitor Step and Trace commands.  It decodes each instruction only far
enough to figure out how many bytes long the instruction is, and to
recognize a few instructions that it has to handle as special cases.
Then it copies the instruction to a three-byte buffer on page zero (if the
instruction isn't thee bytes long, the buffer is padded with NOPs), and
jumps to it.  At the end of the buffer is a jump back to the step/trace
code.  (I recommend reading the monitor ROM listings in the original Apple
II hardware reference manual.)

Either method is going to be a lot slower than a real Apple II.  The former
method would probably be faster, while the later would probably result in a
smaller emulator program (since it doesn't have to include code to simulate
every instruction).

Unless your emulated code is running in the same memory locations that it
would occupy if it were running on a "real" Apple II, you'll have to
emulate a lot more hardware than just the stuff in pages $C0-$CF.
Remember, there's also the text display and the hires graphics display.

Some hardware could prove particulary difficult to emulate.  The 5.25-inch
disk controller is the most obvious example--most of its functions have
*very* strict timing requirements (for example, writes have to happen at
exact 32-microsecond intervals, and if a read operation takes longer than
32 microseconds, data will be lost).  There's no way code running at
emulator speed can hope to keep up with the timing requirements, so giving
the emulated code access to the real disk drive hardware isn't the solution.
The only schemes I've been able to come up with for a fully-emulated disk
drive controller (which is the only way you could do it) involve the emulator
reading a whole track from the "real" drive and doling out pieces of it 
to the emulated code on demand.  To get it right, the emulator would
probably have to count emulated CPU cycles very carefully, and it would
probably fail miserably with copy-protected disks.

You might want to consider not allowing direct access to the real drive at
all--force the user to use disk images instead.  The disk drive problem
is much easier to solve if the emulated hardware doesn't have to worry
about staying synchronized with a real device.

If you want to try writing the code to make an emulated disk controller
work with a real disk drive, good luck!  You're a braver person than I.

              - Neil Parker
-- 
Neil Parker                       | No cute quote, no cute ASCII art, no cute
nparker@cie-2.uoregon.edu         | disclaimer, no deposit, no return....
nparker@cie.uoregon.edu           | (This space intentionally left blank:
http://cie-2.uoregon.edu/~nparker |                                           )