Jump to content

Photo

TI-99 OS Development


36 replies to this topic

#26 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • Topic Starter
  • 209 posts
  • Location:Georgia, US

Posted Wed May 24, 2017 6:43 PM

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 by Gip-Gip, Wed May 24, 2017 7:59 PM.


#27 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • Topic Starter
  • 209 posts
  • Location:Georgia, US

Posted Sat May 27, 2017 8:01 PM

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 by Gip-Gip, Sat May 27, 2017 8:17 PM.


#28 TheBF OFFLINE  

TheBF

    Moonsweeper

  • 316 posts
  • Location:The Great White North

Posted Sun May 28, 2017 7:02 AM

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



#29 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • Topic Starter
  • 209 posts
  • Location:Georgia, US

Posted Sun May 28, 2017 8:29 AM

 

I don't know MikeOS

 

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

 

shot-1.png

 

 

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!



#30 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • Topic Starter
  • 209 posts
  • Location:Georgia, US

Posted Mon May 29, 2017 10:05 PM

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.



#31 apersson850 OFFLINE  

apersson850

    Moonsweeper

  • 421 posts

Posted Tue May 30, 2017 7:18 AM

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 by apersson850, Tue May 30, 2017 7:21 AM.


#32 TheBF OFFLINE  

TheBF

    Moonsweeper

  • 316 posts
  • Location:The Great White North

Posted Tue May 30, 2017 9:07 AM

Thanks for the explanation. I had read it was GPL here somewhere else.
  • RXB likes this

#33 apersson850 OFFLINE  

apersson850

    Moonsweeper

  • 421 posts

Posted Tue May 30, 2017 10:25 AM

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.



#34 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • Topic Starter
  • 209 posts
  • Location:Georgia, US

Posted Tue May 30, 2017 2:31 PM

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.

 

Attached File  Screen shot 2017-05-30 at 04.15.26 PM.png   7.14KB   1 downloadsAttached File  Screen shot 2017-05-30 at 04.18.23 PM.png   6.53KB   1 downloads



#35 apersson850 OFFLINE  

apersson850

    Moonsweeper

  • 421 posts

Posted Tue May 30, 2017 3:44 PM

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.



#36 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • Topic Starter
  • 209 posts
  • Location:Georgia, US

Posted Tue May 30, 2017 8:04 PM

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.



#37 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • Topic Starter
  • 209 posts
  • Location:Georgia, US

Posted Wed Jul 12, 2017 7:00 PM

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






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users