TI-99 OS Development

[Gip-Gip]

I think I have a good layout for the PAD ram so-far. I'll most-likely be programming in assembler (not what I was hoping for) due to the lack of room for a stack.

 

>8000->800F: Registers

>8010->801E: Memory device map

>801F->802D: Process callpoints

>802E->807F: Memory map

Memory-device map entry-layout

Word 1 - Start Address

Word 2 - End Address

Word 3 - Read/Write Call

Memory map entry-layout

Word 1 - Start Addr

Word 2 - End Addr

Process callpoint entry-layout

Word 1 - Program Counter (See notes)

Word 2 - Accumulator

Word 3 - Flags

NOTES

• The program counter is not immediate, in that it is only used when the task is first accessed, and changes to it will not be recognized until the task gives up control
• You can only run up to 5 programs at a time, have 41 memory allocations, and 5 memory devices, due to the limitations of the PAD ram.
• Memory allocations have a fix-length (4-byte) string preceding their start-address. This is their ID

Edited May 25, 2017 by Gip-Gip

[Gip-Gip]

Right now I'm working on the font and graphical things (took a while to get the dev environment set up). Should I stay with the standard TI-99 typeface or base it off something else?

 

I'm planning on doing a MikeOS-styled memory/task manager in favor over a console. Tell me what you think.

----------------------------------------
|        WEMYT I.I.MMXVII Rev 0        |
|                                      |
|  E to toggle exec flag | D to delete |
|    N for new | ESC to resume exec    |
|--------------------------------------|
| |FLAGS|START|END  |I.D. |NAME        |
|--------------------------------------|
|>|     |>0004|>000F|>0000|foo         |
| |E    |>0014|>0399|>0010|edit        |
| |E    |>040C|>09FF|>0400|file manager|
| |     |>1009|>10FF|>1000|file list   |
| |     |>1110|>11FF|>1100|I'm a lon...|
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
----------------------------------------

Side note; I'm thinking the memory allocations should be I.D.ed by a pointer to their name

Edited May 28, 2017 by Gip-Gip

[+TheBF]

Right now I'm working on the font and graphical things (took a while to get the dev environment set up). Should I stay with the standard TI-99 typeface or base it off something else?

 

I'm planning on doing a MikeOS-styled memory/task manager in favor over a console. Tell me what you think.

----------------------------------------
|        WEMYT I.I.MMXVII Rev 0        |
|                                      |
|  E to toggle exec flag | D to delete |
|    N for new | ESC to resume exec    |
|--------------------------------------|
| |FLAGS|START|END  |I.D. |NAME        |
|--------------------------------------|
|>|     |>0004|>000F|>0000|foo         |
| |E    |>0014|>0399|>0010|edit        |
| |E    |>040C|>09FF|>0400|file manager|
| |     |>1009|>10FF|>1000|file list   |
| |     |>1110|>11FF|>1100|I'm a lon...|
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
| |     |     |     |     |            |
----------------------------------------

Side note; I'm thinking the memory allocations should be I.D.ed by a pointer to their name

 

I don't know MikeOS, but from what you describe I think you need to consider the following.

 

1. You can create the table shown above as a finite size table with fields laid out in memory

 

* flags start end I.D>. name

* --------------------------------------------------------

DATA 0 , 0, 0 , 0 'name#1'

" " " " "

" " " " "

" " " " "

* etc....

 

 

-OR- you create the table as a linked list so you can add a new entry any time.

For that you will need a link field in the record

 

 

 

* Link flags start end I.D name

* --------------------------------------------------------------------------

 

​RECRD1 DATA 0, xxxx, yyyy, zzzz , qqqq , 'name#1' * first entry links to nothing (0)

 

<memory>

<memory>

<memory>

 

 

RECRD2 DATA RECRD1, xxxx, yyyy, zzzz , qqqq , 'name#1' * next record links to the previous record

 

 

 

Also the pointer that is used to find a table RECORD contains the address of the first number of the table record

In the link-list case it would be the LINK field.

 

In the first case it would be the FLAGS field.

 

But in both cases, you could remove the I.D field because each record has a unique address and that can be the ID #

if you want to use it for that purpose.

 

My 2 cents

 

BF

[Gip-Gip]

 

I don't know MikeOS

 

I was trying to relate the U.I. to something and Mike O.S. is the closest match

 

 

 

1. You can create the table shown above as a finite size table with fields laid out in memory

 

* flags start end I.D>. name

* --------------------------------------------------------

DATA 0 , 0, 0 , 0 'name#1'

" " " " "

" " " " "

" " " " "

* etc....

 

 

-OR- you create the table as a linked list so you can add a new entry any time.

For that you will need a link field in the record

 

 

 

* Link flags start end I.D name

* --------------------------------------------------------------------------

 

​RECRD1 DATA 0, xxxx, yyyy, zzzz , qqqq , 'name#1' * first entry links to nothing (0)

 

<memory>

<memory>

<memory>

 

 

RECRD2 DATA RECRD1, xxxx, yyyy, zzzz , qqqq , 'name#1' * next record links to the previous record

 

That's another option. The table could hold allocations that need to be more-quickly accessed, such as libraries, and those entries can have child allocations in RAM.

 

The I.D. field will probably be removed, and instead a NULL-terminated string will be expected at the start of the allocation to provide the name

 

Thanks for the suggestions!

[Gip-Gip]

I plan to have my code on GitHub by wednesday and a U.I. out by the end of the week. I finally have the dev. environment figured out and my progress should speed up; just keep in mind I am a complete newbie to the TI and it may take some getting use to.

[apersson850]

P-code systems work this way, but the TI-99 version that interpreted P-code bytes with GPL byte code was a bad decision.

No, it didn't work like that. The PME (P-Machine Emulator) was written in 9900 assembly code. The bulk of it running from the 12 K ROM on the p-code card, some loaded into CPU RAM and the most critical part of the inner interpreter running from CPU RAM at >8300. It was then interpreting p-code stored bytewise (it is an 8-bit code) in either CPU RAM, VDP RAM or the 48 K p-code card GROM. Part of these GROMs stored the OS:, i.e. the ROM disk where the main part of the operating system was stored.

But reading a byte from VDP RAM or GROM isn't slow, once the address has been set up.

 

Some of the PME had to run from CPU RAM, so that it could still function when the p-code card had to be disabled to access other cards in the PE box.

Edited May 30, 2017 by apersson850

[+TheBF]

Thanks for the explanation. I had read it was GPL here somewhere else.

[apersson850]

Maybe that comes from that they used GROM chips to store the code. The same kind of chips used to store GPL. But on the p-code card for a different purpose.

[Gip-Gip]

A few core things and the semi-original font are finished. At this rate the code will be available by the end of the day.

 

I personally prefer the actual lowercase characters over the original T.I. lowercase but if you don't like the change feel free to tell me.

 

[apersson850]

I used to lift them all one pixel, so I could get true descenders. They do hit a "tall" letter on the line below, but I live with that.

[Gip-Gip]

Uploaded the test code. Doesn't do much except print stuff to the screen. I plan to document it a little more + add some input code within the next two days.

 

You can visit the GitHub here.

[Gip-Gip]

If it wasn't obvious, development on the OS project has essentially been nonexistent. This is due to the fact I've taken an interest in electrical engineering and will continue to work on EE projects until my FinalGROM arrives. From there I will **attempt** to work on EE projects and programming projects simultaneously since I have the free time.

 

I will also more-than-likely re-write the source to be cleaner and more efficient.

 

P.S.

 

Now would be a great time to discuss O.S. concept ideas

[+9640News]

On 5/19/2017 at 5:12 PM, mizapf said:

For you Amiga fans out there (yes, I had one, too (is that a confession?)).

 

The attached pictures show the "Guru meditation" that I implemented on the Geneve. You can see on the first picture that the program is loaded; then I load the word 0000 to address A000, then I poke the A000 address into the interrupt hook so that this location is executed on the next interrupt.

 

This is my original text that - if I remember correctly - was published in one issue of Micropendium.

 

The GURU MEDITATION

Author: Michael Zapf

Suppose you want to write some machine language programs. Normally, it takes several passes until the program finally assembles - after having found the last syntax error. After the first "0000 ERRORS" you load and run it with great expectations ... and nothing happens, at least not what you wanted the program to do. Now, if you are lucky, you can press QUIT (or CTRL-ALT-DEL) for a "warm" boot, and maybe the program is still standing in the RAM so that you can PEEK it via TI BASIC. Otherwise you have to turn your computer off and back on, losing your program in memory.

If you are using a Geneve, there is another threat not experienced by the standard TI user: System kernel RAM locations can be affected so that you cannot reset your computer any more, let alone debug your program. The reason for this is that the program counter is loaded with an unexpected address, and the execution is transferred to a part of memory which probably does not contain executable code. This happens when - subprograms are not terminated correctly (RTWP instead of RT or vice versa)

• subprograms are not called correctly (BLWP instead of BL or v.v.)
• array bounds are exceeded (especially with a list of addresses)
• return adresses are lost or incorrect (forgotten DATA after BL)
• and many more.

One of the TMS9995 processor's most powerful features is the MID flag which is not used, however, by the operating system. Whenever the processor encounters a word that is to be executed but does not represent a valid command, it generates an interrupt of level 2 which is not maskable by LIMI. The interrupt service routine can check the CRU flag 1FDA: It is set when an illegal command has been encountered. The abbrevation MID means "macro instruction detect" which reveals another usage for this feature. Currently, the MID flag is simply cleared by the interrupt service routine.

The following program is intended for the Geneve in GPL mode with standard Editor/Assembler and standard GPL interpreter. Newer versions may require changing of the absolute addresses in GROM or RAM. Assemble this program and load it via LOAD AND RUN once; it remains installed until you clear the memory completely or reload the GPL interpreter. Now take the source code of one of your programs and put a DATA >0000 right into the program text. If you run this bugged program the execution will halt right at this position and the computer will inform you that an error has occured, giving you the values of the WP, PC and ST registers. Press the left mouse button to return to the master title screen; your program remains unchanged. This early execution break can prevent your computer from totally disturbing the memory, but there is surely no guaranty that the computer will not hang. This program was inspired by the "Guru meditation" message of the Commodore Amiga which is more detailed, however.

 

 

***     GURU MEDITATION        ***
*     on Geneve 9640 in GPL Mode
*     Version 1.1
*     March 14, 1991
*     Michael Zapf
* Put this utility in an unused RAM space
       AORG >8100
TEXT1  TEXT 'Software failure.   Press'
       TEXT ' left mouse button to continue.'
TEXT2  TEXT 'Guru meditation  #'
HEXD   TEXT '0123456789ABCDEF'
POINT  TEXT '..'
* VDP register settings
VDPREG DATA >8004,>8170,>8203,>8347
       DATA >8401,>8506,>8600,>8761
       DATA >8888,>8900,>8A00,>8B00
       DATA >8C06,>8D66,>8E00,>8F00
* Check MID flag. If not active, return.
START  LI   R12,>1FDA
       TB   0
       JEQ  START1
       B    @>035E
START1 SBZ  0          * Clear flag
       LWPI >8300
* Set VDP registers to defined values
       LI   R1,VDPREG
LOOP1  MOV  *R1+,R0
       BL   @SETADR
       CI   R1,START
       JL   LOOP1
* Clear the screen
       LI   R5,>8C00
       LI   R0,>4000
       BL   @SETADR
       LI   R2,1920
       LI   R1,>2000
LOOP   MOVB R1,*R5
       DEC  R2
       JNE  LOOP
* Load upper and lower case character set
* from GROM to VDP (R5 is VDPWD)
* (to repair probably destroyed character definitions)
* Note: The characters are stored by seven bytes in GROM
* so that a 00 must be inserted before each definition.
       LI   R0,>06B4        * GROM position
       MOVB R0,@>9C02
       SWPB R0
       MOVB R0,@>9C02
       LI   R0,>4900        * VDP position
       BL   @SETADR
       LI   R3,96           * No. of characters
       CLR  R1
JL     MOVB R1,*R5          * Insert 00
       LI   R2,7
IL     MOVB @>9800,*R5      * Copy seven bytes
       DEC  R2
       JNE  IL
       DEC  R3
       JNE  JL
* Write texts on screen
       BL   @WRITE
       DATA >40AC,TEXT1,56
       BL   @WRITE
       DATA >4158,TEXT2,18
* Write values of R13,R14,R15 on screen.
* R3 will be used as a pointer to the RAM location
* of these registers (starting at >83DA).
* R5 is still >8C00 (VDPWD).
* Use the character list HEXD to transfer the nybbles
* (half bytes) to the corresponding ascii char.
       DECT @>83DC
       LI   R3,>83DA
       LI   R6,3
DISP   MOV  *R3+,R4
       LI   R2,4        * four nybbles per word
LD     SRC  R4,12       * shift to rightmost nybble
       MOV  R4,R1
       ANDI R1,>000F        * mask it
       MOVB @HEXD(R1),*R5   * Write char to VDP
       DEC  R2
       JNE  LD
       DEC  R6          * next register
       JEQ  FRAME
       MOVB @POINT,*R5  * Print a "."
       JMP  DISP
FRAME  BL   @CLRBLK    *  Clear blink attributes
       LI   R2,6       *  Six rows
       LI   R0,>5009   *  Step forward to columns 72+
* Set blink attribute of columns 0 and 79
* of six consecutive rows
       LI   R1,>0180
F1     BL   @SETADR
       MOVB R1,*R5      * column 79
       SWPB R1
       MOVB R1,*R5      * column 0
       SWPB R1
       AI   R0,10       * next row
       DEC  R2
       JNE  F1
* Set blink attribute of every column in the first row
       LI   R2,10
       LI   R0,>5000
       SETO R1
       BL   @SETADR
F2     MOVB R1,*R5
       DEC  R2
       JNE  F2
* Set blink attribute of every column in row 6
       LI   R2,10
       LI   R0,>503C
       BL   @SETADR
F3     MOVB R1,*R5
       DEC  R2
       JNE  F3
* Check the left mouse button. If depressed, stop blinking
* and return to the master title screen.
MLOOP  LI   R12,>0038
       TB   0
       JEQ  MLOOP
       BL   @CLRBLK
       LI   R0,>8D0F
       BL   @SETADR
       BLWP @>0000
* Standard routine to set a VDP address.
* Note: Add >4000 for writing to the address
SETADR SWPB R0
       MOVB R0,@>8C02
       SWPB R0
       MOVB R0,@>8C02
       RT
* Write the text on screen defined by the following three words:
* DATA screen pos, RAM pos, length
WRITE  MOV  *R11+,R0
       MOV  *R11+,R1
       MOV  *R11+,R2
       MOV  R11,R10
       BL   @SETADR
WL     MOVB *R1+,*R5
       DEC  R2
       JNE  WL
       B    *R10
* Initialize the blink attribute table (VDP >1000)
* by writing 00 in all positions
CLRBLK MOV  R11,R10
       LI   R0,>5000
       BL   @SETADR
       LI   R2,270
       CLR  R1
       MOVB R1,*R5
       DEC  R2
       JNE  $-4
       B    *R10
* Paste the B @START into the interrupt routine
* of the console ROM (which is RAM on the Geneve)
* replacing the clearing of the MID flag.
* Normal execution will resume at >035E (see above).
       AORG >035A
       B    @START
       END

@InsaneMultitasker I found the Guru meditation code @mizapf referenced.  Looking at the code, it is significant in size.  We could likely add the code into the CLI\NEWCMDS with modifications to the task page 0 and ospage 0 where if a MID is hit, it pages the CLI in and then executes the code.  As is, I do not think we could embed the code into task page 0 or os page 0 due to the size.

 

Beery

[+mizapf]

I'd rather not have it included in the OS, but maybe get a chance to link to this or some other code that I install at MDOS startup (in whatever way this has to be done actually).

[RXB]

Just wondering if you took took GROM 0 and turned into Pure Assembly how much speed increase would you get for that work?

 

For shts and giggles say put it in Cart ROM at >6000  for a test run?

 

I have been doing this for RXB in that taking GPL and turning it into ROM/RAM run from Fast RAM.

Edited February 19 by RXB

[+acadiel]

Looking at things like this makes me wonder how easily we can use something like MESS to make a Z80 "Ranger" TI-99/3B if we were able to translate the ROM and GROM0, 1, and 2 into something compatible with Z80.  

 

(Yeah, I know stuff would need to be recompiled, but am really curious if we could reproduce the "great experiment" )