[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: where can i download the various OS's for my GS?



BluPhoenyx wrote:
 To: Michael J. Mahon
Michael J. Mahon wrote:

aiiadict@gmail.com wrote:

On Apr 23, 8:52 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:

Yes, but I'd like it as an extension of BASIC.SYSTEM, since
my fingers have already memorized its commands, and my
Applesoft programs depend on it.  ;-)

I'm guessing that such an extension could fit in just one
page of high memory...



So catch command line input with your command processor,
if it doesn't match any of YOUR available commands, run
it through the basic.system processor (basic.system will
RTS back to your pre-processor, which then RTS back to
prodos command line blinker...

if it is a match to one of YOUR commands:

1)check if it is already resident in RAM.  If it is, execute it
2)if not in RAM, load from disk, keep a flag that says
YOURcommand#x is loaded,  and execute...

that would be nice...  if you weren't using 5.25 disks,
you could put the command processor + loaded commands
into the disk II driver space at $d000


It would also be good to automatically *unload* a command
if there is a demand for RAM.

Since there's no good hook for determining when, say, an
Applesoft program wants to use high memory, it's probably
best to write the handler to deal with all commands as
"overlays" with no continuing claim on RAM.


Or, a small kernel which can adjust himem: and load the utility, which must be relocatable, wherever. This could actually work fairly quickly if the 'modules' were in /ram or a very fast disk.

There are already such commands, such as those in ProCMD, that
allocate space and relocate themselves, then install themselves
into the BASIC.SYSTEM command chain.  (The only downside is that
they load at a predetermined spot, usually right in the middle
of any program you have in memory, so they generally have to be
installed at the beginning of a session.)

The problem with resident commands is that the more commands you
use, the less RAM you have to play with.

What I was talking about was a general external command handler
that would run *non-resident* commands, perhaps out of a ProDOS
buffer, to keep the impact on available RAM minimal and predictable.

Of course, this would require putting a size limit on commands,
but that would probably work fine.

The notion of non-resident commands was probably dismissed in the
early days because a floppy access would be quite slow, and all
commands you might want would have to be on a mounted floppy at
all times.  Now that hard disks are common, non-resident commands
make perfect sense.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."