Re: Disk ][ Launcher (was: Late night musings...)

[jefbla@bconnex.net (Jeff Blakeney)]

nathan@visi.com (Nathan Mates) wrote:

>In article <50b1ll$bh6@news.bconnex.net>,
>Jeff Blakeney <jefbla@bconnex.net> wrote:

>>I hadn't thought of that.  Mind you I'm still in the design phase.

>   "No batle plan survives contact with the enemy." (Apparently, Sun
>Tzu, the Art of War). Programming isn't that bad, but until you're
>real good (especially with quirks like emulation), expect a lot of
>surprises when your code runs against real world stuff.

Yes, there is a lot of stuff to deal with but I figure if I don't try,
I'll never know whether it is possible or not.  I know that one of the
first things that I thought of that might mess up the entire idea is
interrupts.  If a program disables interrupts, an emulator will have
to emulate that disabling because to actually disable interrupts would
cause the emulator to lose the ability to step in an handle the things
it needs to (ie. screen updates, disk access).  If I remember
correctly, early versions of ProDOS left interrupts disabled all the
time which stopped IIgs users from being able to access the Control
Panel CDA.  I'm still not sure just how badly programs will react to
not having interrupts disabled the way they expect.

>>I have been trying to come up with ways to allow execution of the 8
>>bit programs to be performed by the 65816 at full speed.  By caching
>>small sections of code and checking them for anything special and then
>>executing any code I'm not concerned about at full speed or by putting
>>COP instructions in those special locations but I can't really think
>>of a way to find the places to put the COPs easily.

>   Doubtful this can be done easily or well. The main problem is that
>the 6502/65C02 has variable instruction lengths, and no easy way to
>determine if an arbitrary section of bytes is code, data, a mix, or
>what. Your next problem is that if something is to run under GS/OS, it
>must have a real light footprint on bank 0. That means pretty much
>anything that hits I/O or video can't be run at full speed without some
>major hackery. (Setting the B register to 00/01/e0/e1 could let you
>do that, but would prevent any other writes to your program space if
>your program is not in those banks).

You are correct, this wouldn't be easy.  I was thinking that the only
way to determine the actual code would be to trace it.  Basically, you
would have to write a dissassembler that knows what certain memory
address and registers contain so that it knows where to continue
dissassembling after any branch or jump instructions.  Mind you, if
you only checked the code up to any branch instructions then execute
it, you could then easily determine where that branch is going to go
and start checking that code up to the next branch instruction.

This probably doesn't make much sense the way I have written it but it
makes a lot a sense in my mind.  I'm just having trouble expressing it
at present.

>   If you can come up with a way of determining _well_ (90% solutions
>are easy, and won't work with everything) which code hits video and
>which doesn't, so much the better. About the only 'reliable' way to do
>so is to manually emulate all code in a given range (say one page),
>and verify that it has no writes to video or i/o. Then, until
>something writes to that page or dp locations used by that page, you
>can run it at full speed. Now when there are lots of pages with
>interlocking dependencies, this gets real ugly real fast.

Actually, I figured that the video would be the easiest.  You just
have to keep flags of the video softswitches so that you know what is
currently being displayed (40 or 80 column text, lo-res, hi-res, etc.)
and have a heart beat routine running that will copy the video memory
from wherever it is stored to actual screen memory or convert it to a
bitmap or string of text to be displayed in a window.

It is the trapping of the softswitches and accesses to the slots that
I am most concerned about.

>   You may be satisfied with something that runs a program or
>two. Those of us who do programming for a living have learned to hate
>90% solutions-- they're guaranteed to stand up and bite you later.
>Doing it right the first time will save you a LOT of trouble later on.

Too true.  I have run into so many programs that could have been
fantastic but the authors just never added the little extra to make it
a much more useful program.

I do strive for excellence with my programs which is one of the
reasons I have only released one program so far.  I don't think I have
written anything of good enough quality or that is needed to release.
The only reason that I even released Selector v1.0 was because there
were a few people that needed it and even then, I improved the program
about 300% before actually releasing it.