Jump to content

Photo

TI-99 OS Development


36 replies to this topic

#1 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

  • 205 posts
  • Location:Georgia, US

Posted Tue May 16, 2017 3:51 PM

I'm taking a break from VePseu development, and I would like to make an OS named wem/yt (loW rEsource Memory/sYstem inTerface) for the TI I have lying around. The reason being so I can use the computer for something AND learn enough to port it to more systems, say an Intel.

 

The idea is pretty simple in my opinion

  • you have a memory manager which is powered by barebones I/O (keyboard and display)
  • you can save, load, and execute blocks of memory
  • it would implement voluntary multitasking (have programs jump back to a certain point once they're done)
  • Implement a portable compile-when-ready executable format for non-critical executables
  • drivers like disk or tape would be built-in, and would be run as essentially high-priority executables.

 

The OS obviously isn't made for performance, rather to allow the lowest usable level of the system. I see use in programming and debugging, along with basic file editing tasks (I also plan to make an Arduino interface, but that's for later).

 

Here's the thing

 

Looking at the list of programming languages isn't very promising, as C (the best language for the job) lacks documentation (C99) or won't compile properly (GCC). I'll learn new languages if I have to, but I don't want to (learning a language and building an OS at the same time sounds like hell to me). If anyone has any suggestion I would greatly appreciate it

 

Now that I have the manual for C99 I'll be using that


Edited by Gip-Gip, Mon May 29, 2017 10:01 PM.


#2 Sinphaltimus OFFLINE  

Sinphaltimus

    Stargunner

  • 1,920 posts
  • Distracted at the Keyboard
  • Location:Poconos, PA

Posted Tue May 16, 2017 4:42 PM

I can't really help you except that I find it interesting you posted this. Recently a very similar thread popped up here.

http://atariage.com/...n/#entry3759414

#3 Sinphaltimus OFFLINE  

Sinphaltimus

    Stargunner

  • 1,920 posts
  • Distracted at the Keyboard
  • Location:Poconos, PA

Posted Tue May 16, 2017 6:44 PM

In the other thread you asked for compiler documentation. AFAIK, this is the largest repository I have access to for everything TI related. I bet your docs are here someplace. I couldn't find them below but possibly in another folder off the root.

ftp://ftp.whtech.com/programming/c99/


Edited by Sinphaltimus, Tue May 16, 2017 6:48 PM.


#4 chue OFFLINE  

chue

    Chopper Commander

  • 134 posts

Posted Tue May 16, 2017 7:03 PM

What problems did you have with GCC?

 

As for possible tools/ languages/ docs, take a look at the first post in the development resources thread here: http://atariage.com/...rces/?p=1881598


Edited by chue, Tue May 16, 2017 7:04 PM.


#5 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

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

Posted Tue May 16, 2017 7:48 PM

What problems did you have with GCC?

 

Errors while building GCC. Might be because I'm on an oldish mac, but I've personally never been able to build GCC, even when I follow the directions



#6 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

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

Posted Tue May 16, 2017 8:20 PM

In the other thread you asked for compiler documentation. AFAIK, this is the largest repository I have access to for everything TI related. I bet your docs are here someplace. I couldn't find them below but possibly in another folder off the root.

ftp://ftp.whtech.com/programming/c99/

 

Found it!

 

ftp://ftp.whtech.com/programming/c99/C99REL4/c99%20v4%20for%20994a%20manual.pdf

 

I'll also attach the manual to this post incase the site goes down (I don't necessarily trust the FTP server)

Attached Files



#7 Lord Vorkosigan OFFLINE  

Lord Vorkosigan

    Combat Commando

  • 2 posts

Posted Wed May 17, 2017 3:16 AM

Hi,

 

There's also the Fuzix project which can be interesting as starting point:

http://atariage.com/...x-unix-on-ti99/



#8 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

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

Posted Thu May 18, 2017 11:40 AM

Currently I'm getting the dev environment set up, I'll release a version of the OS by at most sunday



#9 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,422 posts
  • Location:Denmark

Posted Thu May 18, 2017 11:49 AM

Are you planning that your memory manager should support paged memory like SAMS? 



#10 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

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

Posted Thu May 18, 2017 12:18 PM

Are you planning that your memory manager should support paged memory like SAMS?


Paged memory would greatly improve the ability of the TI, so I'll find a way(not just yet, however)

#11 TheBF OFFLINE  

TheBF

    Moonsweeper

  • 307 posts
  • Location:The Great White North

Posted Thu May 18, 2017 8:42 PM

It's a daring project.  You might want to consider having programs for your O/S run as byte code rather than machine code, with the ability to call machine code when needed.

Byte code systems can save a lot of space fro your programs if you build an efficient virtual machine.

GPL is an example, although not one I would recommend. No sense constraining yourself to 256 bytes of RAM.

 

Basically you build a virtual machine that is core of everything and it just interprets program bytes very fast.

Your virtual machine can be register based or stack based or 2 stack based like GPL, but generally is made to be simpler than the underlying machine.

 

Any language for your O/S then just has to create byte code. P-code systems work this way, but the TI-99 version that interpreted P-code bytes with GPL byte code was a bad decision.



#12 RXB OFFLINE  

RXB

    River Patroller

  • 2,721 posts
  • Location:Vancouver, Washington, USA

Posted Thu May 18, 2017 9:35 PM

It's a daring project.  You might want to consider having programs for your O/S run as byte code rather than machine code, with the ability to call machine code when needed.

Byte code systems can save a lot of space fro your programs if you build an efficient virtual machine.

GPL is an example, although not one I would recommend. No sense constraining yourself to 256 bytes of RAM.

 

Basically you build a virtual machine that is core of everything and it just interprets program bytes very fast.

Your virtual machine can be register based or stack based or 2 stack based like GPL, but generally is made to be simpler than the underlying machine.

 

Any language for your O/S then just has to create byte code. P-code systems work this way, but the TI-99 version that interpreted P-code bytes with GPL byte code was a bad decision.

True the GROM and VDP chip delays are horrid for running programs.

Nothing worse then a built in HARDWARE DELAY for running Programs in any language.


Edited by RXB, Thu May 18, 2017 9:35 PM.


#13 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

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

Posted Thu May 18, 2017 10:18 PM

It's a daring project. 

 

It isn't as big of a mess as the Intel machines, at least

 

You might want to consider having programs for your O/S run as byte code rather than machine code, with the ability to call machine code when needed.

 

That was sorta my original idea but the speed would be really bad (imagine running your daily programs in Valgrind 24/7). Granted, I wouldn't have to do some voodoo magic with the memory manager to make 32kb (or even worse, the stock 256) work with an OS, just include some large RAM chips on the cart.

 

I needed to come up with an instruction set for the compile-when-ready idea, so I'll get that done and tell everyone about it



#14 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,311 posts
  • Location:Silver Run, Maryland

Posted Fri May 19, 2017 2:47 AM

GPL is an example, although not one I would recommend. No sense constraining yourself to 256 bytes of RAM.

 

How is GPL constrained to 256 bytes of RAM?

 

...lee



#15 chue OFFLINE  

chue

    Chopper Commander

  • 134 posts

Posted Fri May 19, 2017 5:30 AM

Basically you build a virtual machine that is core of everything and it just interprets program bytes very fast.

Your virtual machine can be register based or stack based or 2 stack based like GPL, but generally is made to be simpler than the underlying machine.

 

 

The Forth guys on this thread are too modest!

 

Correct me if I'm wrong but Forth:

 

- is a stack based VM

- interprets byte code fast

- is memory efficient

- supports the TI hardware well

 

I've read that someone ;) has multi-tasking working: http://atariage.com/...king/?p=3763980

 

I've been thinking about a TIOS from a C point of view and it appears daunting.  I'm not a Forth guy, but it "feels" right here.  So what am I missing?


Edited by chue, Fri May 19, 2017 5:34 AM.


#16 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,009 posts
  • Location:Uzbekistan (no, really!)

Posted Fri May 19, 2017 12:44 PM

TurboForth had been my TI OS since 2007. I have block 1 configured to leaf the extensions that I need/need use (just like autoexec on DOS systems). I can read files, print files, catalog disks and load #3 programs without leaving Forth.

Forth is a small OS with the added benefit of having a programming language and scripting language built in. All in 16K.

#17 ti99iuc OFFLINE  

ti99iuc

    Stargunner

  • 1,190 posts
  • Location:Italy

Posted Fri May 19, 2017 12:53 PM

I Remember sometimes99er started a Windows Demo similar to Amiga Workbench :P

Attached File  Windows - 1.png   17.36KB   1 downloads   Attached File  Windows - 2.png   16.49KB   1 downloads

I know it could be impossibe to have as OS but it was a funny dream.


Edited by ti99iuc, Fri May 19, 2017 12:56 PM.


#18 mizapf ONLINE  

mizapf

    River Patroller

  • 2,505 posts
  • Location:Germany

Posted Fri May 19, 2017 3:12 PM

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

Attached Files



#19 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

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

Posted Fri May 19, 2017 9:37 PM

Started on the opcode list over at GitHub. I'm doing a 6502-inspired instruction set, tell me what you think


Edited by Gip-Gip, Fri May 19, 2017 9:38 PM.


#20 TheBF OFFLINE  

TheBF

    Moonsweeper

  • 307 posts
  • Location:The Great White North

Posted Mon May 22, 2017 6:29 AM

 

How is GPL constrained to 256 bytes of RAM?

 

...lee

 

I was thinking about the bare console, and how they engineers had to shoe-horn the language to use the PAD memory.



#21 TheBF OFFLINE  

TheBF

    Moonsweeper

  • 307 posts
  • Location:The Great White North

Posted Mon May 22, 2017 6:33 AM

 

The Forth guys on this thread are too modest!

 

Correct me if I'm wrong but Forth:

 

- is a stack based VM

- interprets byte code fast

- is memory efficient

- supports the TI hardware well

 

I've read that someone ;) has multi-tasking working: http://atariage.com/...king/?p=3763980

 

I've been thinking about a TIOS from a C point of view and it appears daunting.  I'm not a Forth guy, but it "feels" right here.  So what am I missing?

- is a stack based VM  -  2 stack VM but who's counting

 

- interprets byte code fast - The implementations you see here are running "address" lists rather than byte codes and some Assembler at the lowest level.

                                            There are byte-code Forths. Open-firmware which boots Sun machines is one such system.

 

- is memory efficient        -  Evidence points to smaller final program sizes yes. Some of that can be to small routines, easily re-used and re-combined to make higher level functions.

                                           rather than the system itself.  But that is disputed sometimes.

 

 

- supports the TI hardware well   -  Sure.  You write assembler code to get the real work done and the point to them on demand.


Edited by TheBF, Mon May 22, 2017 6:34 AM.


#22 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

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

Posted Mon May 22, 2017 7:41 AM

- is a stack based VM  -  2 stack VM but who's counting

 

- interprets byte code fast - The implementations you see here are running "address" lists rather than byte codes and some Assembler at the lowest level.

                                            There are byte-code Forths. Open-firmware which boots Sun machines is one such system.

 

- is memory efficient        -  Evidence points to smaller final program sizes yes. Some of that can be to small routines, easily re-used and re-combined to make higher level functions.

                                           rather than the system itself.  But that is disputed sometimes.

 

 

- supports the TI hardware well   -  Sure.  You write assembler code to get the real work done and the point to them on demand.

I'm still working on the compiler situation, so I haven't implemented anything yet. I may ask, when I do implement the VM should it be stack based or register based? I'm already working on a register based system, just wanted to know if there are any advantages before I finalize it



#23 TheBF OFFLINE  

TheBF

    Moonsweeper

  • 307 posts
  • Location:The Great White North

Posted Mon May 22, 2017 5:59 PM

I'm already working on a register based system, just wanted to know if there are any advantages before I finalize it

 Excellent question!

 

There are divergent opinions on the matter.  The rumors say a stack based VM can created smaller code.

The Java VM is one of the best modern ones.  Once you add all the classes and methods the code is probably not any smaller

when you write in Java, but you should be able to do any language on top of JVM.

 

The Parrot VM which is used by a bunch of languages now is a register VM and I have read it outperforms stack VMs for speed.

https://en.wikipedia...virtual_machine

 

You should probably get familiar with a all three. Byte code Forth VM, JVM and Parrot VM and then make a decision. :-)

 

B



#24 TheBF OFFLINE  

TheBF

    Moonsweeper

  • 307 posts
  • Location:The Great White North

Posted Mon May 22, 2017 6:06 PM

As I think about it a little bit more, a register based VM could take direct advantage of the 9900's memory to memory architecture.

 

Your byte codes can add,subtract, mpy etc directly to memory and use hardware registers only when needed.

Just a thought

 

And taking a page from Parrot...

 

create some Virtual registers in memory

 

myregs     BSS  32*2        * now you have 32 16 bit registers.

 

myfloats   BSS  8* 8          * and 8 floating point registers

 

... how many more and what kind would you like? :-)



#25 Gip-Gip OFFLINE  

Gip-Gip

    Chopper Commander

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

Posted Mon May 22, 2017 9:03 PM

As I think about it a little bit more, a register based VM could take direct advantage of the 9900's memory to memory architecture.

 

Your byte codes can add,subtract, mpy etc directly to memory and use hardware registers only when needed.

Just a thought

 

And taking a page from Parrot...

 

create some Virtual registers in memory

 

myregs     BSS  32*2        * now you have 32 16 bit registers.

 

myfloats   BSS  8* 8          * and 8 floating point registers

 

... how many more and what kind would you like? :-)

I was thinking the advantage to a register-based VM would be I wouldn't have to deal with the lack of a built-in stack, and I could use the workspace to my advantage (change it for each task). I'll look at all of them tomorrow; I have plenty of time to kill now exams are over.

 

I'm considering only programming a few core utilities like the memory mapper/task manager in ASM or C, while doing the rest in the VM's language (with calls to native code when needed). This would be slow, but it would also negate the need for a separate native-code multitasker (not like the TI's gonna be much faster anyways)






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users