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

[geoff@seeker.the-hermes.net (Geoff Weiss)]

Jeff Blakeney <jefbla@bconnex.net> wrote:
>nparker@cie-2.uoregon.edu (Neil Parker) wrote:
>
>>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
>
>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

I would have to disagree with you.  This seems like the fastest way to
do it to guarantee 100% compatibility.

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

Lets see what is wrong with this logic (Nathan gave a half-dozen
reasons a few posts back).  First of all, you want this code to run in bank 0,
right?  How many bytes will you allocate in bank 0 to run this code?  What
happens if there is a chunk of code (before getting to a branch or jump)
larger than those number of bytes? Assuming you solve that problem, how would
you know if there is any soft switch access in this code?  If you this
project is to work based on your outline, you can't access the softswitch
areas, but emulate them ($00/2000 - $00/3fff, space for hires pages 1 and 2
can't be accessed in bank 0).  This means you have to check the code 
before letting the machine run it.  What happens if the code has 
LDA ($06),Y ?  Is this a hires page access or data access?  You will need
to keep track of what is in $06, $07, and Y and see if it is a soft
switch or graphics or text pages access.  There is even more work making
sure an Absolute Indexed instruction is accessing a "safe" location.
By the time you do all this checking, you have written a 6502 emulator,
plus the need to copy any data to the execution area, plus the time
to execute it.

A close analogy to what you want to do is sort of like writing an
optimizer--searching through the code to optimize the best way to
execute it.  Anybody who knows anything about optimizers can tell
you that there is no perfect way to write an optimizer and is slows
down compiling by an extreme amount.  If you can make something
work 100% of the time at a reasonable speed, immediately copyright
your work since you would be the best in the field.  If you have
no idea the concepts of writing an optimizer, there is alot of
reading for you to do.

>>Either method is going to be a lot slower than a real Apple II.  The former
>
>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.

For me, a 5.25" drive and Proboot is convenient enough.  I can have a
hard drive in slot 6 and still boot DOS 3.3 games from GS/OS.  And
they will run at the proper speed of 1 Mhz.

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

I think I explained to you why you still have to check for soft switches
and text/graphics pages.

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

I would suggest makeing completely disk image based.  If you are
going to emulate the entire 5.25" firmware (which you will have to
do since the emulator won't be fast enough to access a real 5.25"
drive), you might as well get the speed advantage of a having the
disk image in memory.

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

Hopefully that was a rhetorical question!

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

I haven't written any code, but I started thinking about how one would
write a 6502 emulator (I am not crazy enough to really do it).  The
minimum number of cycles for an instruction to take would be about 100
cycles.  This is just a guess on my part to code the main instruction-
read loop and to perform a PHA in an emulated stack.  A standard 3-byte
JMP or JSR instruction could be done in around 170 cycles.  Would you
add a wait state to these JMP or JSR instructions to make them as equal
timing as possible to the PHA?

Remember, _every_ memory access instruction that isn't a direct page
access would be needed to check for access in bank $C0.

Geoff
-- 
-------------------------------------------------------------------------------
e-mail: geoff@the-hermes.net   System Administrator for Hermes Internet Service
WWW: <a href=http://www.the-hermes.net/~geoff>Geoff's Home Page</a>
The report of my death was greatly exaggerated. -- Mark Twain