Re: A86: Re: Replacement OS

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

Re: A86: Re: Replacement OS


Im going to continue to refine this idea over the next couple weeks. I have a
bunch of other coding to do in the interrim, mostly having to do with a
complete linux solution to the z80 IDE department.
I'll keep the list posted on progress...

Kirk Meyer wrote:

> See inside =) Also, see at the very bottom for the memory layout of Katydid,
> copied from the "official" doc files =)
>
> On a side note, you want to be certain that the contents of RAM page 2 never
> change with a new OS (as they do in your implementation). If you can fulfill
> this requirement, the new OS won't go bye-bye when they pop the batteries in
> case of crash...

I didnt mean to do that...the second page is supposed to be page 7 instead, so
that 2-6 can contain all the variable data as normal.

>
>
> > Programming/Gaming Interface for the TI-86
> >
> > This is a replacement operation system for the TI-86, which would attempt
> to give the
> > programmer more space for standard programs, as well at a ton of data
> space. Math would
> > be pretty much extinguished, so don't count on it being easy to get used
> to...
>
> Um where's the data space? I'm assuming that you're counting the unused
> parts of pages 1 & 2 as data space, but what if the program is 32kb? Then
> what?
>
> > Some basic information (proposed):
> >
> > [RAM page 0]
> > Operating System Data     = $C000 - $C7FF (2kb for ops, shadow regs and
> things of that nature)
> > Operating System Calls    = $C800 - $E7FF (~8kb for os calls (findpixel,
> putsprite, _puts etc)
> > Variable Table = $E800 - Stack End (approx 4kb for 256 variables)
> > Stack          = $FBFF (going up)   (approx 1kb)
> > Video memory 1 = $FC00 - $FFFF
>
> If it's an OS replacement you better allocate room for an IM2 interrupt that
> reads the keyboard, etc. Also, what about greyscale?!? Double buffering?!?
>
> > [RAM page 1] (to be loaded into port 5)
> > _asm_exec_ram (place of execution) = $4000 - $7FFF
> >
> > [RAM page 2] (to be loaded into port 6)
> > extended execution area if needed  = $8000 - $BFFF (16kb)
>
> Why? Why not just relocate the variables, then you could have 112kb of user
> memory...

A very good point, except that i would like not to have to jack with the
variables at all, other than the VAT itself, since it wastes so much space on
page 7.

>
>
>

Should be 2-6 here

> > [RAM page 3 - 7]
> > Standard variable data
> >
> > Total of 96kb user available memory (same as current TI-86 memory).
> > ~6 - 12kb of this could be used to save the current system into a string,
> so the new OS could
> > be exited back to the TI-OS.
>
> Um, I might be seeing things, but I believe you meant only 80kb user memory
> the way you had it set up. A more efficient way to allow switching between
> TI-OS & "your OS" is to do something similar to chmasc. Put a restore
> program someplace that just reinitializes "your OS" (this program would only
> take maybe a hundred bytes). This is the method Katydid uses to allow you to
> easily switch to and from TI-OS. Note that Katydid also creates the program
> for the user so they don't have to remember the short asm program (C3xxxx).
>
> > This takes the execution area to 32kb of continuous usable space at one
> time w/o
> > any page swapping.
>
> Right now we have 24kb without page swapping, is this worth 8kb?
>

I dont rightly know, but it could be...

>
> > ROM calls that would need to be replaced are numerous:
> > (obviously only a partial list)
> >
> > _putx and _vputx
> > _clrScrn and _clrLCD (could be same call actually)
> > _HtimesL (_MUL_HL)
> > _OPx moving routines
> > _FindSym
> > _load_ram_ahl
> > _disp_ahl
> > _get_free_mem
> > _get_word_de (there's anoter name for this i think)
> > _createstring
> > _createprgm
> > all abs address data moving routines (or at least the usefull ones)
>
> Why replace the first 3 on your list? They would work just as well on your
> new OS the way you have it set up... the only reason is if you were trying
> for an "orthodox" OS replacement. Heh.
>

I dont want to have to use the ROM at all, so that i wouldnt have to be
switching port 5 all the time.

>
> Katydid is an OS replacement, but it makes sense because it does math, and
> it does math better than the TI-OS... yours doesn't seem to have all that
> many advantages over TI-OS anyway...
>

The advantage is that its a programming environment that would be completely
documented. Even after 2 1/2 years, we still dont know how to do tons of stuff
with the 86...I want to know everything about an OS when im programming for it,
so that when a problem occurs, i can fix it at the source...(hrm maybe thats a
pun...then again maybe i need more sleep...)

>
> ;
> ; *****************************
> ; *                           *
> ; * Documentation for Katydid *
> ; *                           *
> ; *****************************
> ;
> ; I. RAM Layout
> ; =============
> ;
> ; The RAM is layed out as follows:
> ; Page 0: interrupt routine, common functions, video buffers, and more.
> ; Page 1: User memory (16kb total -- plenty for math only)
> ; Page 2: Miscellaneous items (graphing, linking, possibly jump table)
> ; Page 3: Numeric functions -- numeric algorithms (variable precision)
> ; Page 4: Symbolic functions -- simplification, factoring, solving, etc.
> ; Page 5: Advanced Symbolic -- integration, derivatives, etc.
> ; Page 6: Plugin (only ONE plugin at a time, accessible via PRGM)
> ; Page 7: Katydid core routines (equation entry, keyboard logic, etc.)
> ;
> ; II. RAM Page 0
> ; ==============
> ;
> ; NOTE: Bit fields are described by the notation {7 6 5 4 3 2 1 0} with any
> ;       information following the appropriate number.
> ;
> ; Start  End  Lngth Description
> ; ===== ===== =====
> =========================================================
> ; $C000 $C100   257 Interrupt vector table (all contains value $C1)
> ; $C101 $C140    64 Keyboard buffer, also (IY - $40) through (IY - $01)
> ; $C141 $C1C0   128 IY Flag Area, (IY + $00) through (IY + $7F)
> ; $C1C1 $????  ???? Interrupt routine, primary ROM functions, numbers
> ; $CE00 $CFFF   512 Variable pointers (256 of them, 64 for each slate)
> ; $D000 $EFFF  8192 A really big temporary area
> ; $F000 $F3FF  1024 A really big stack
> ; $F400 $F7FF  1024 Tertiary LCD memory (used for double buffering)
> ; $F800 $FBFF  1024 Secondary LCD memory (used for grayscale)
> ; $FC00 $FFFF  1024 Primary LCD memory (sprites may only be drawn here)
> ;
> *snip* =)

I like the way the screens and stack are setup...thats probably how it would be
in my OS.
Follow-Ups: References: