Re: A86: Re: New operating system...


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

Re: A86: Re: New operating system...




Ah, that's making more sense now :)  I was actually thinking along these
lines for the TI-86+ (as a suggestion to TI).  It seems to me to be really
wasteful to have the system vars at $c000, right in the middle of the 32k
free ram (assuming you don't use the float stuff, but how many game
programmers do?).

This is actually a good idea, assuming all you want to use your calculator
for is games.  If you were willing to sacrifice a 16k ram page, you could
even (I think) still use your calc as a calculator (what an idea!).

For the OS, the calculator would be reset, then the OS program loaded on to
it.  The OS would easily fit in an 8k program (at least it better!).  When
run, it would wipe the VAT and other info from the ram pages.  It would
setup ram page 0 into $4000 and leave ram page 1 at $8000.  It would then
copy the kernal portion of itself to $4000, leaving the 48k that it didn't
use free.  If the calc were still to be used as a calculator, then the
program loader could be copied to page 6, along with the system vars
(leaving the VAT intact).  On exit, it would be swapped back to page 0 and
everything would be left intact.  Actually, now that I think about it, two
pages would be required, because the OS uses the fps stack on page 1--how'd
the 85 get around that???

Now, once the OS is loaded, you have almost 48k of free, contiguous ram.
Pages 2-6 would be free, giving 80k for programs.  All linking and other
program management (renaming, deleting) would handled by the OS, as it would
use it's own VAT (which would be stored _cleanly_ inside the OS's memory).
It would also handle power on/off along with APD (while inside the shell),
as using the normal methods for power off would disrupt the shell.

The stack should start at $ffff and video memory would start somewhere like
$f000.  This would place the stack at the most convient location, and where
video memory goes isn't important, because it will probably be moved later
(what, you're going to waste 48k on black and white programs?! :)

The OS should include certain things like block write-back, where a program
would set a flag and set two address for the start and ending write back
locations.  With this method, a program could have a block with high scores
and other settings, and only that block would be written back (thus not
forcing write-back, allowing most of the program's code to be self modified,
yet very easily allowing high scores).  It could also be made a call instead
of a feature used on program exit.

>
>>That IS a good idea, and I have _thought_ about it.  But since the OS
>is
>>contained in ROM, how do you propose to put a new OS on the calculator?
>
>Well sure the OS is in rom, but it also eats up a lot of space in ram
>with system variables, VAT, and whatever else that it does, that I as a
>programmer simply am tired of having to skirt around.  Particularly,
>this last 16Kbyte block that is located permanently at $c000..  the
>first ~5K is used by the system right? I mean I don't know all the
>details, but there must be some reason that the TI-os loads asm programs
>at $d748.  so I'm assuming $c000-$d748 is used by the system.
>
>Anyway, you write a "bootloader" that loads the kernal into ram
>somewhere and this becomes the new operating system.  The prorgam never
>gives control back to the rom, so it therefor uses the ram how it wants
>to.  Now I am still not sure how I want this new OS to use the ram...
>but I had got an idea yesterday:
>
>Instead of having a "ram-disk" or variable-disk or whatever you want to
>call it that stors "programs" and "data" why don't we create an
>operating system that simply has one type of memory.  This memory will
>contain "segments" that can either be data or program.  If it is program
>then it has the ability to be "run".  So instead of "loading" programs
>to be run, we can simply ahve our operating system load the appropriate
>"pages" of ram and then call this segment.  Every time you load a
>program you are making an extra "unecessary" copy of it.  If we want to
>run multiple programs on a 128K platform, this program copying is
>wastefull.  And under this paradigm, running another program would be as
>simple as adding this segment's address to the task-schedualer.
>
>Now this paredigm might be at first seem to wild and different to even
>think about.  But give it some thought.  Now I know that there are
>several things that must be done in preperation to even think about
>making such a system work.  Some subtle, and some pure out blatent, but
>I think you will find that these preperotory task are all "doable" and
>not only that.  The bulk of this stuff can be done by the OS without the
>programmer having to worry about it.
>
>Later,
>
>David E. West
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>
>