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

[jefbla@bconnex.net (Jeff Blakeney)]

nparker@cie-2.uoregon.edu (Neil Parker) wrote:

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

Yes, this is the first, and probably easiest, method that I came up
with for catching all the special stuff.  Unfortunately, this is
probably the slowest method so I am trying to avoid it if at all
possible.

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

This is approximately what I described in another message.  The
difference being that I would decode instructions until I reached a
branch, jump or an instruction that dealt with a special area then
execute that entire section of code then deal with the branch, jump or
special instruction.

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

No matter what I do, it will always run slower than letting the IIgs
run it as it normally would.  I planned on making it as fast as I
could but I still think that the convenience of running stuff under
GS/OS will outweigh the loss in speed as long as the loss in speed
isn't too drastic.

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

I mentioned this in another message that I was thinking of using a
heart beat routine to continually update the real display or window
from the emulator video memory.

[stuff about 5.25" drive controllers snipped]

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

This sounds promising.  I could even add a routine to the emulator to
allow making disk images on the fly.  Something like DOS 3.3 Launcher
copy program but integrated into the emulator rather than as a
separate application.

Another thought that just occurred to me, which is kind of a take off
of you caching a track of the disk, is to cache the entire disk.  The
are only 140K after all and the disk image could be made when you
start the emulator and remade whenever you click a button or press a
key combination after you have changed disks.

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

Braver or dumber?  Anyways, there are lots of options as is evidenced
by our ideas above.

This just might work if I keep getting advice like this.  I do believe
I will sit down this evening and start some planning.