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

[jefbla@bconnex.net (Jeff Blakeney)]

geoff@seeker.the-hermes.net (Geoff Weiss) wrote:

>Jeff Blakeney <jefbla@bconnex.net> wrote:
>>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.

Yes, it would be the fastest way to DEVELOP the emulator while making
it 100% compatible, but it isn't necessarily the method that will
produce the fastest execution of emulated code.

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

Nope.  I don't care where the actual code or the code in my
"execution" buffer is.

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

I will pick an arbitrary size for the execution buffer and when it is
filled, I will then execute it, clear it and start checking code from
where I left off.

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

I could always treat them as special cases just like branches, jumps
and direct accesses to special locations.  Otherwise, I could always
scan through the code in the execution buffer again to see if any of
it modifies the address or register in question.  If nothing does,
then I just check the address or register in question and figure out
whether the resulting address of the instruction is in a special area
or not.

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

Actually, I'm not trying to optimize it, I'm just trying to execute
what is already there in a controlled way.

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

Except that you can't use programs like AppleWorks v5 or PublishIt
while still having access to NDAs, CDEVs or possibly even other GS/OS
or ProDOS 8 applications while running under SwitchIt, MultiGS or the
Manager.

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

Yes I do still have to check for them and update flags for my heart
beat routine to know what display mode is currently in use.  (ie. 40
or 80 column text, lo-res, hi-res, etc.)

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

Yes, I think this is the method that I will use.  It will make this
portion of the coding that much easier.

>>Braver or dumber?

>Hopefully that was a rhetorical question!

That's for readers of these articles to decide.  :-)

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

I'm not sure how critical the relative execution times of instructions
is going to be.  At present I have no intention of a PHA (4 cycles)
instruction takes 25% more time to execute than a 3 byte JMP (3
cycles).  If this turns out to be a problem then I might just have to
pad out instructions to take the proper relative amount of time.