Operating System The TI-99/4A Operating System

[+Lee Stewart]

This project to augment and enhance the Assembly Language Code (ALC) listing of TI-99/4A’s Console ROM Operating System is largely obviated by the DX-10 Assembler ALC source code discussed below the second separator bar further down. It appears to be the original source code.

 

———————————————————

Startup Message for this Thread—

 

I am in the process of attempting to enhance the annotation and instruction labelling of the ALC of the TI-99/4A’s console ROM so that I can better wend my way through the code. My starting point is @Tursi’s TI994A_CPU.asm, which he ported from Heiner Martin’s TI99/4A INTERN. Right now, I am calling it TI994A_CPU.a99. I will maintain an up-to-date version, serialized by date, in this post of this thread. Please, feel free to suggest modifications, including the file name (perhaps, with only a different extension, it is too close to @Tursi’s file’s name), the name of this thread and its tags—I’m flexible.

I have barely begun this effort with the file below; but, it should give you an idea of what I am trying to do:

• I would like clarification of lines where I have the comment, “???LES???”, because I have not yet discovered why the lines are there. [Now known from ROM-4A files below]

• Labels and comments thus far: Lines 1 – 111, 464, 669, 1101, 1116, 1186 – 1356, 1499, 2446 (I will not continue itemizing the changes going forward. This is just to give you ideas.)

• More spacing around comment lines—especially, section headings.

• Page-number lines include the book referenced.

TI994A_CPU_20160313.a99

Eventually, I want to extend this effort to the console GROMs; but, for now, I am limiting it to the console ROM.

...lee

 

———————————————————

Original(?) Commented Assembly Language Code (ALC)—

 

The following code has been modified by Yours Truly to be successfully assembled by Corey Burr’s ASM994A assembler. My changes are marked with “*==LES==*”. Items I have questions about are marked with at least “???”:

ROM-4A_20160317.zip

...lee

Edited March 18, 2016 by Lee Stewart

[+Ksarul]

How about TI994A-CROM (for Console ROM) and then you can add files later called CGROM0, CGROM1, and CGROM2. . .

[Tursi]

Filename looks fine to me

 

The DATA >0008 is used in the ROM in two places for keyboard scanning (the FCTN part of FCTN-4 and FCTN-=) and as part of the VDP address setup in GPL MOVE.

 

The question marks for the >001E at >0014 and >001A I couldn't find a use for.

[+InsaneMultitasker]

The question marks for the >001E at >0014 and >001A I couldn't find a use for.

Pretty sure >1E00 is "SBZ 0". I think I have some files that may help in this endeavor.

 

Edit: from the file below - debugging entry points?

 

SCNKEY B @KSCAN

*

HX0008 DATA >0008 USED IN COC & LDCR

* ENTRY NOT KNOWN

C014 SBZ 0 DEBUG BOARD INSTRUCTIONS

B @>007A

*ENTRY NOT KNOWN

C01A SBZ 0 DEBUG BOARD INSTRUCTIONS

B @>0078

Edited March 13, 2016 by InsaneMultitasker

[+InsaneMultitasker]

The disk containing these source files is labeled with the following hand-written info:

 

TI-intern (ROMS-source code in DX10 Assm)

 

I do not recall whether I have ever posted these files before nor do I recall how I obtained the disk. The handwriting is not my own. I've had it in my library since the early-to-mid 90s.

 

TI994a ROMS source DX10 assm.DSK

[+Lee Stewart]

The disk containing these source files is labeled with the following hand-written info:

 

TI-intern (ROMS-source code in DX10 Assm)

 

I do not recall whether I have ever posted these files before nor do I recall how I obtained the disk. The handwriting is not my own. I've had it in my library since the early-to-mid 90s.

 

Thanks for this, Tim! I have my work cut out for me, now. I will work on assembling these to see that they produce the same binary as TI99/4A INTERN and then, I guess, I will attempt a consolidation of comments and labelling.

 

...lee

[+InsaneMultitasker]

Thanks for this, Tim! I have my work cut out for me, now. I will work on assembling these to see that they produce the same binary as TI99/4A INTERN and then, I guess, I will attempt a consolidation of comments and labelling.

 

...lee

Have fun! There are some comments, including a few that look like TIs storage paths, that lead me to wonder if this came from TI. In fact, it reminded me of the ti writer source code. Want another project? .

[+Lee Stewart]

Have fun! There are some comments, including a few that look like TIs storage paths, that lead me to wonder if this came from TI. In fact, it reminded me of the ti writer source code. Want another project? .

 

Hah! I think my next project will be TI Logo II in fbForth 2.0 or, possibly, an fbForth 2.0 DBMS. Before those, I should probably update the fbForth 2.0 Manual.

 

...lee

[+Ksarul]

I had fun turning the ROM-A files into a PDF tonight. I'll get to the others tomorrow.

CROM-TI994A-A.pdf

Edited March 14, 2016 by Ksarul

[+Lee Stewart]

Well—I attempted to assemble the code Tim posted in post #5 above, but ASM994A just threw up! I am not sure why; but, I have already found some code that needs to be changed for a successful assembly with ASM994A:

• There are a handful of “SPIN” instructions in the casette I/O routines, which must be for a macro-assembler. They will need to be changed to “<label> JMP <label>”
• There are some labels that are the same as the conditional-assembly directives used by ASM994A, such as IF, ELSE, .... (I had trouble with those assembling fbForth.)
• There are multiply-defined EQUates that ought to be identical, but may not be so because of some assembly error. The assembler ought to be OK with them.
• I need to check the RORG and AORG directives because ASM994A is a little hinky where they are concerned.

Anybody wanting to look over my shoulder, feel free.

 

...lee

[+InsaneMultitasker]

Is there such a beast as a dx-10 assembler? I find references to the ti-990 when I look up dx10.

[+Ksarul]

I have the manuals for the DX-10 Assembler from a recent purchase. . .they are also available in the TI-990 portion of Bitsavers.

[+Lee Stewart]

I’m getting there. It appears that TI (if that is where the DX10 source files are from) assembled these in 3 separate operations to produce an object file for each major segment of the ROM:

1. T.I. 99/4A GRAPHICS LANGUAGE INTERPRETER (program identifier: GPLINT)
2. T.I. 99/4A FLOATING POINT & CASSETTE (program identifier: FLTPT)
3. T.I. 99/4A BASIC INTERPRETER (program identifier: BASICI)

Unfortunately, during this process, they reused about 7 labels that cause conflict when the source code is all assembled to a single object file. At least, now, I have a listing that shows most of what I need to fix. My first attempt had left me guessing because the assembler had aborted without producing a listing! It shouldn’t be long, now.

 

...lee

[Willsy]

I’m getting there. It appears that TI (if that is where the DX10 source files are from) assembled these in 3 separate operations to produce an object file for each major segment of the ROM:

1. T.I. 99/4A GRAPHICS LANGUAGE INTERPRETER (program identifier: GPLINT)
2. T.I. 99/4A FLOATING POINT & CASSETTE (program identifier: FLTPT)
3. T.I. 99/4A BASIC INTERPRETER (program identifier: BASICI)

Unfortunately, during this process, they reused about 7 labels that cause conflict when the source code is all assembled to a single object file. At least, now, I have a listing that shows most of what I need to fix. My first attempt had left me guessing because the assembler had aborted without producing a listing! It shouldn’t be long, now.

 

...lee

Is there any reason why you have to assemble it as a single file? Why not leave it as three files, as TI did?

[+Lee Stewart]

Success!! —

 

All of my mods are marked with “*==LES==*”. I combined the fourteen, numbered, source-code files into three ‘A’, ‘B’ and ‘C’ files. I may eventually consolidate them into a single source file, as with the TI99/4A-INTERN-derived source file.

 

I will probably remove the cross-module-reference EQUates just as I did the DEFs because they are superfluous when assembled as a single object file. I am not sure what I should do with the other duplicate EQUates. They do serve to show which module (GPL Interpreter, Floating Point & Casette or Basic Interpreter) requires them. I am inclined to put all EQUates at the beginning of the first file regardless of which module uses them.

 

The following ZIP file contains ROM-4A-a.a99, ROM-4A-b.a99, ROM-4A-c.a99 and ROM-4A.lst:

 

ROM-4A_20160316.zip

 

...lee

[+Lee Stewart]

There are many references to “NUD” in the TI source code for the Basic Interpreter portion of the ROM. Heiner Martin (“Add NUD table address”) and Thierry Nouspikel (“NUD table for assembly language routines”) use the term, as well. Does anyone know what it stands for? [Edit: Solved! See this later post for details.]

 

...lee

Edited May 6, 2023 by Lee Stewart
Update

[Stuart]

Lee Stewart, on 16 Mar 2016 - 5:19 PM, said:

There are many references to “NUD” in the TI source code for the Basic Interpreter portion of the ROM. Heiner Martin (“Add NUD table address”) and Thierry Nouspikel (“NUD table for assembly language routines”) use the term, as well. Does anyone know what it stands for?

 

...lee

 

"Not usually dangerous"

[+InsaneMultitasker]

I’m getting there. It appears that TI (if that is where the DX10 source files are from) assembled these in 3 separate operations to produce an object file for each major segment of the ROM:

1. T.I. 99/4A GRAPHICS LANGUAGE INTERPRETER (program identifier: GPLINT)
2. T.I. 99/4A FLOATING POINT & CASSETTE (program identifier: FLTPT)
3. T.I. 99/4A BASIC INTERPRETER (program identifier: BASICI)

Unfortunately, during this process, they reused about 7 labels that cause conflict when the source code is all assembled to a single object file. At least, now, I have a listing that shows most of what I need to fix. My first attempt had left me guessing because the assembler had aborted without producing a listing! It shouldn’t be long, now.

 

...lee

Perhaps the segments were worked on concurrently by different teams. Have you noticed any differences between this and the TI Intern compiled sources?

[+Lee Stewart]

Perhaps the segments were worked on concurrently by different teams. Have you noticed any differences between this and the TI Intern compiled sources?

 

The binaries are identical. The ALC has register references that use the ‘R’ designation, which is always easier to follow than just register numbers. It is also rich with labels and comments that appear to be by the original programmers, which makes this code much easier to wade through. Heiner Martin did a remarkable job of commenting the disassembled code, but the lack of mnemonic labels and comments from divining the ALC’s function, along with number-only register references, are necessarily less desirable.

 

...lee

[+Lee Stewart]

Eventually, the files in ROM-4A_20160316.zip of post #15 above will find their way to post #1 because they assemble to the same code as the file that is currently there, but are easier to follow.

 

Right now, I just wanted to give a few interesting tidbits gleaned from my perusal of the ROM-4A files. Though many of us know that there are odd references to the console ROM that harvest values from code that is actually part of instruction code, it is kind of cool to see it documented in the comments of the original(?) programmers. There may be more labelled some other way, but I have found five such locations commented with “NASTY”. They are

• C025
• C030
• HX20
• HX06
• HX0300

I should also note that I found one and only one mistake in the code. It is the EQUate for SAVVDP in the code for the Basic Interpreter (currently, ROM-4A-c.a99). It evaluates to >83D8 rather than the correct >83D4 from the code for the GPL Interpreter (currently, ROM-4A-a.a99). I guess the two different calculations support the notion that different programming teams may have worked on the ALC. The first instance has it as

 

SAVVDP EQU PAD+>D4 <---PAD + >D4 = >8300 + >D4 = >83D4

and the second, as

 

SAVVDP EQU WKSC+R12+R12 <---WKSC + R12 + R12 = >83C0 + >0C + >0C = >83D8

 

which, of course, conflicts with the previous value. The following would correct it:

 

SAVVDP EQU WKSC+R10+R10 <---WKSC + R10 + R10 = >83C0 + >0A + >0A = >83D4

 

...lee

[+Lee Stewart]

To avoid unnecessary clutter (at least, for now), I decided to remove all of my changes to the ROM ALC except for those that are absolutely necessary

• for successfully assembling the three “modules” to a single object file,
• to avoid conflicts with the ASM994A assembler,
• to inline the SPIN macro (because I don't know how to define macros for ASM994A or if it is even possible—for that I would need to start using @ralphb’s xas99) and
• to remove the single error in the third module (mentioned in my last post)

Here is the current set of files:

 

ROM-4A_20160317.zip

 

...lee

[Asmusr]

Which tool do you use to turn the object file into a binary file?

[+Lee Stewart]

Which tool do you use to turn the object file into a binary file?

 

I use @Tursi’s tiobj2bin, which, I’m guessing, you already have and probably know it will only convert absolute code with no external references.

 

...lee

 

[Edits in this color]

Edited March 17, 2016 by Lee Stewart

[Asmusr]

 

I use @Tursi’s tiobj2bin, which, I’m guessing, you already have and probably know it will only convert absolute code with no external references.

 

...lee

 

[Edits in this color]

 

No I wasn't aware of that. Thank you.

[+Lee Stewart]

No I wasn't aware of that.

 

Oops! Here’s the context that led me astray: post #928 of “Classic99 Updates”.

Thank you.

 

You’re most welcome.

 

...lee