Operating System The TI-99/4A Operating System

[Asmusr]

 

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

 

You’re most welcome.

 

...lee

 

I'm obviously becoming more forgetful.

[kl99]

This is a great project and effort Lee!

I tried my ways once to recreate a commented version of the console rom / groms for the 99/4a by starting from the 99/8 console source files, which were released.

The "official" comments by TI are a great ressource. The 99/8 console rom can be considered to be identical over many parts, so the comments can be "moved" over to a disassembled 99/4a rom/grom file.

Diff Tools like WinMerge [www.winmerge.org] are essential for such a comparison project.

I also tried to align the sourcecode with Intern to include his comments.

This is another source i discovered already on whtech:

ftp://ftp.whtech.com/source/console.src

The 99/8 source files are in the same ftp-directory.

 

I also discovered another ressource for commented source files inside the Genie.

Here is all what I have so far. I got sidetracked by some other "interesting" thing.

TI-99#8-wip.zip

System-Software-Lee.zip

 

Maybe its of help.

[kl99]

In the last days I have tried to prepare a merge of these two files by adding comment lines to the file if the other had a code or comment line to achieve a better diff comparison. It's not finished yet, but once it is, the extensive original comments from the 99/8 source code [intsim.txt] can be moved over to your work file [ROM-4A-a.a99] quite easily.

Unless I made a mistake, the ROM-4A-a-comments.a99 file should still generate the same binary output.

 

Whenever I added a line, i did it with "****".

 

ROM-4A-a-comments.a99

intsim.txt

[kl99]

Hi Guys,

I am currently working on something in the direction of this thread.

My tool tries to read in all kinds of assembler source code files and automatically identifies the label, opcode, operands and comment fields of each line. So far it is doing a good job I assume.

It even validates the used opcodes already, currently trying my ways with validating the allowed operands for each opcode.

I already tried my ways generating an html out of it with all parts of the syntaxes in another color to easy up reading. When a Label Reference is used as Operand you can click on it and it goes to the Label Definition.

What I am really trying to achieve is auto-combining the comments next to statements from all available Comments Ressources:

- 99/4A Rom0 Commented Source

- Heiner Martin Rom0 Comments

- 99/8 Rom Commented Source

- XB Rom0 and Rom1 Commented Source (thx to Rich RXB).

 

The comments should be auto-addable not only to the 99/4A ROM but to any passages of matching disassembled code (like 99/5 rom or Tomy Tutor rom).

 

I am troubling finding documentation on the following instructions of assembler source code files:

"SPIN", occurs without any operands (occurs several times in the file ROM-4A_B.a99 and seems to match an instruction in Heiner Martin Disassembly of the ROM to ">13F0 10FF JMP >13F0 Wait for interrupt"

"SCRNOP" occurs as opcode with one operand in the 99/8 assembler source code files.

 

Is it common to use "SET0" [Zero Number] instead of the correct "SETO", like happening in the 99/8 source disk files?

 

Is there some editor that marks your line "MOV R1" as red/error as long as the second operand is missing? If not, such an editor might become a nice side-product of the project.

[+Lee Stewart]

I am troubling finding documentation on the following instructions of assembler source code files:

"SPIN", occurs without any operands (occurs several times in the file ROM-4A_B.a99 and seems to match an instruction in Heiner Martin Disassembly of the ROM to ">13F0 10FF JMP >13F0 Wait for interrupt"

 

“SPIN” is not a TMS9900 Assembler instruction. It is a comment, which is an abbreviation for “spin our wheels”—a reference to a vehicle stuck in a spot and going nowhere because it has lost traction. The TI programmers used “LABEL JMP LABEL” to set up an infinite loop until a timer interrupt forced a return to the instruction following the loop. This code assembles to >10FF and is used in four places in the tape-cassette routine in console ROM0. After an interrupt, the following code increments the return address to the instruction following the infinite loop:

*
* TIMER INTERRUPT ROUTINE
*
TIMER  SBZ  0                MAKE SURE WE'RE IN INTPT MODE
       SBO  3                CLEAR DECREMENTER INTPT
       MOV  R1,R1            TEST FLAG REGISTER
       JLT  TIMER1           FLAG SET -> ERROR EXIT
       LWPI WKSC             BACK TO REGULAR WORKSPACE
 
       C    *R14,@HXSPIN     DOING A SPIN?
 
       JNE  TIMER1           NO, DON'T INC ADR.
       INCT R14              BYPASS SPIN        <----Increments return address past “SPIN”
TIMER2 RTWP                  AND RETURN
TIMER1 LWPI WKSC
 
       MOV  @WKSE+R6+R6,R14  GET EXIT ADDRESS
 
       JMP  TIMER2           AND EXIT

...lee

[FSword7]

On 3/15/2016 at 1:13 AM, InsaneMultitasker said:

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

There is ti990 emulator on the Internet.  Google it.

[+FarmerPotato]

On 12/12/2022 at 10:44 AM, FSword7 said:Yes.

 

It is Dave Pitts' asm990, which he provides   with sim990. It's a C-source package. It can  assemble all instructions for 9900 cpu types up to 990/12. There is also a link editor and some macro support.  The output is regular tagged object format as used in the 4A too. 

The native assemblers in DX10 are SDSMAC and TXMIRA. SDSMAC has a big macro language. Some 4A programs  turn out to have the SDSMAC identifier at the bottom...

 

Asm990 runs on any Unix-y system. The accompanying lnk990 has facilities for making the libraries, overlays and segments used in DX10. Don't use those 🙂 

 

Ralphb's xdt99 package has xas99, which is a 4A assembler with specific features for binary images. And you need it's xdm99 to copy files into a DSK image for use in a 4A emulator or TIF files for transfer. 
 

[+Lee Stewart]

On 3/16/2016 at 1:19 PM, Lee Stewart 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

 

In all of my searching, I was never able to get any traction on NUD as a programming term until a private message thread with @InsaneMultitasker¹. I know I am not the only one here who gets seriously frustrated with search engines like Google handing me everything except what I am seeking.

 

It turns out that NUD and LED (both used extensively in the TI Basic and TI Extended Basic parsers) are terms that are tied to a particular kind of computer language parsing called “Top Down Operator Precedence” by its author, Vaughan R. Pratt, in 1973 while he was at MIT and, hence, often termed “Pratt Parsing”. The two terms stand for NUll Denotation and LEft Denotation and refer to head (NUD) and tail (LED) handler functions in Pratt parsing and their position in language parsing trees. To quote Pratt’s paper (expanded version of original):

 

“We will call the code denoted by a token with a preceding expression its left denotation or LED and without a preceding expression its null denotation or NUD.”

 

Also, p. 134, Chapter 9 “Top Down Operator Precedence” by Douglas Crockford in Beautiful Code: Leading Programmers Explain How They Think, O’Reilly Media, Inc., 2007, Andy Oram, Greg Wilson, eds.:

 

“A NUD does not care about the tokens to the left. A LED does. A NUD method is used by values (such as variables and literals) and by prefix operators. A LED method is used by infix operators and suffix operators. A token may have both a NUD method and a LED method.”

 

Though I have not read the above references in any kind of detail, I fully intend to do so and believe they are well worth your while to do the same.

 

Considering that Pratt published his well-received parsing method in 1973, it is no wonder that the TI developers of TI Basic and TI Extended Basic likely were well-versed in its use and fully incorporated it in the respective Basic language parsers. The use of the NUD and LED terms, as well as the commented code, particularly that of the console ROM and GROMs, would seem to verify that conclusion.

 

...lee

____________________

1 Many thanks to @InsaneMultitasker for all his research that netted the above sources as well as the additional sources below:

• https://people.csail.mit.edu/jaffer/slib/Nud-and-Led-Definition.html
• https://pythonhosted.org/PrattParse/tutorial.html
• https://abarker.github.io/typped/pratt_parsing_intro.html

Edited May 2 by Lee Stewart
corrections

[+InsaneMultitasker]

As I think I mentioned to @Lee Stewart during our exchanges at the time, I recalled reading references to (and perhaps explanations for) NUD and/or LED in some of the documentation that members here have preserved from various estates and auctions.  I could not, however, find the right documents and searching the forums wasn't fruitful.  I was interested in knowing how the terms fit into the Geneve's Advanced BASIC source code (which is derived from XB and Myarc XB) since many labels and some comments reference these then- and still-peculiar terms that Lee asked about.   Neat stuff though a bit more advanced than I am able to fully parse myself.   

 

[+FarmerPotato]

@Lee Stewart @InsaneMultitasker

Well worth reading, indeed!

 

I read the Crockford chapter from Beautiful Code, which seemed the most accessible (but it gets really deep by the time it completes Simplified JavaScript). 
 

Thanks to TI's old books,  I've been reading computer science from this era (1970s Wirth, Dijkstra, Hoare).

 

The statement of Pratt's that struck me most was about hand-crafted parsers falling out of favor, behind BNF-style grammars, automata theory, and recursive descent.

 

While the top-down operator precedence algorithm is 1) effective, and 2) uses only concepts that are familiar from everyday programming (compiler writers excepted.)  

It just happens that I've been maintaining some hand-crafted parser code. Yesterday, I rewrote it with a much better algorithm. Fortunate timing!

 

Thanks for chasing this (NUD LED comment)  down and bringing the computer science!

update: I've discarded the "better algorithm" for a straightforward Pratt parser. 

Edited June 2 by FarmerPotato
Update

[+Lee Stewart]

1 hour ago, FarmerPotato said:

The statement of Pratt's that struck me most was about hand-crafted parsers falling out of favor, behind BNF-style grammars, automata theory, and recursive descent.

 

Yeah—me too.

 

1 hour ago, FarmerPotato said:

Thanks for chasing this (NUD LED comment)  down and bringing the computer science!

 

Happy to have been a part of it!

 

...lee