Lots of Assembler Questions

[Asmusr]

Just an idea, not sure if this has already been suggested: since the ROM does not change it should be possible in emulator debuggers to show a fully commented/labelled disassembly when single stepping through the ROM.

[kl99]

Is Mike working on an E/A manual? I'm asking because some time ago I also decided to OCR the E/A manual, and I'm working my way through those pages (already done 50 pages) right now.

 

The Cyc already contains so many documents you only find if you understand the directory structure. It already contains all PHM Manuals. The EA Manual you find on the DVD here:

\vendors\ti\phm\phm3055\phm3055.pdf

 

Afaik it is included in the Cyc for decades already. It includes fixes from all published addendums and reports from magazines or newsletters.

[kl99]

Just an idea, not sure if this has already been suggested: since the ROM does not change it should be possible in emulator debuggers to show a fully commented/labelled disassembly when single stepping through the ROM.

 

That is the whole idea why I started all this. My TI Simulator will not run with the binary Rom but directly execute the source code providing full context to the debugger user.

The ultimate goal is to abstract things away in the simulator by setting a config in the debugger, so the user can say he wants to concentrate only on Gpl or only Assembler or abstract away the Keyboard Scan, Grom Read Routine or the Basic Interpreter.

 

However the first step is still to be completed. Which is a merge of all available source code files, their use of labels over resolved values, their comments together into one "archival" source code version.

It should merge the comments by TI Intern, the comments from the original 99/4A source code files (there are two different ones) and the comments from the 99/8 source code files.

I could have done this manually, but I am a programmer. And the benefit will be that it can be used to generate a commented source code for the 99/5 disassembly, published by Fabrice, and a commented version for shared code parts in the Tomy Tutor Rom disassembly, which I am curious to analyze.

The small tool for reading in one source code file turned out to become that intelligent that I am using the Intermediate Representation in the tool as basis to execute a simulation of the TI-99.

 

I have no insight how all the existing TI-99 emulators are representating the Rom during execution. From the target of MAME I assume, that is working very close to the hardware level.

Simply showing the commented source code line to the debugging user would gain a bit but not much unless the emulator is actually aware of the symbols referenced in that line.

Since the acutal TI is not aware of it, I assume all emulators are like that.

[+mizapf]

Afaik it is included in the Cyc for decades already.

 

Well, if you bought the PC99 emulator, that is.

 

...

 

Thanks for pointing me to that document, leaves more time for other things (although I believe my version looks close to the original, and it has a clickable table of contents; I'm preparing it in LibreOffice and export to PDF too).

[+mizapf]

Just an idea, not sure if this has already been suggested: since the ROM does not change it should be possible in emulator debuggers to show a fully commented/labelled disassembly when single stepping through the ROM.

 

This is generally possible, but no one ever suggested that in MAME to my knowledge. Currently the ROM is disassembled in the debugger; one could envisage to have a source code file, using addresses as keys, and show the lines with comments instead of the pure disassembly.

 

But disassembled and commented listings are rare, I suppose, one would need some agreement about the format, and possibly someone who rewrites the commented listing to abide by that format. Remember, in MAME we are talking about a common debugger frontend for thousands of systems.

[apersson850]

Is there any difference between <gas> and (gas) ?

Somewhere the Manual writes () Indicates “the contents of”.

Does this even refer to the syntax Definitions or to something else?

 

I am currently trying to understand how to resolve all these expressions of operands that use Symbols to their actual value.

It seems sometimes they refer to the memory address who contains the label.

And sometimes the operand refers not to the memory address who contains the label but to the EQU value.

Still lots to learn it seems

<gas> or (gas) in this case is a general address source. Just different typography. The meaning is the same.

The convention that BLAH represents the value of BLAH, but (BLAH) represents the value stored at address BLAH, is used by some assemblers. But the nomenclature in the TI assembler is that BLAH is the address, @BLAH is a reference to the value stored at BLAH.

 

As far as symbols go, you are correct. A symbol may represent a location in memory, or may represent a value which is unrelated to any particular memory location.

FACTOR DATA 123
OFFSET EQU   22

MPY  @FACTOR,R4
AI   R5,OFFSET

In the example above, R4 is multiplied with data stored at FACTOR, not by FACTOR itself.

Then the value of OFFSET, not the value stored at OFFSET, is added to the result.

Edited February 19, 2018 by apersson850

[kl99]

In the example above, R4 is multiplied with data stored at FACTOR, not by FACTOR itself.

Then the value of OFFSET, not the value stored at OFFSET, is added to the result.

 

Your detailing helps me a lot, and for sure other interested members. Much appreciated. I am wondering who you are and if we have met in Chicago or at the TI Treffen in Europe? I am Klaus from Vienna.

[+Lee Stewart]

A couple of things in the E/A Manual to check very carefully are the “Status bits tested” and “Status bits affected” sections of each instruction. Those sections use ‘^’ to indicate a tested or affected bit. There may be more, but I know at least one of those is wrong when compared to the TMS9900 Data Manual, viz., the carry bit for the NEGATE (NEG) instruction (p. 94) is affected, but there is no ‘^’ under ‘C’ (bit 3).

 

...lee

[+Lee Stewart]

...

Also I have discovered some mistakes in the TI Intern but once my Comparer is developed, I will have a complete list of its source code mistakes.

 

In the listing for ROM 0 (pp. 11 – 79), I found only one error in Heiner Martin’s listing as compared with the TI listing. At >17BC (p. 62), the machine code is correct, but the source code should be “DATA >835C”.

 

...lee

[PeteE]

Just an idea, not sure if this has already been suggested: since the ROM does not change it should be possible in emulator debuggers to show a fully commented/labelled disassembly when single stepping through the ROM.

 

A great feature to have would be to load an assembly listing into a debugger to allow showing the current line in source code based on the PC address, as well as use labels for breakpoints.

 

 

This is generally possible, but no one ever suggested that in MAME to my knowledge. Currently the ROM is disassembled in the debugger; one could envisage to have a source code file, using addresses as keys, and show the lines with comments instead of the pure disassembly.

 

But disassembled and commented listings are rare, I suppose, one would need some agreement about the format, and possibly someone who rewrites the commented listing to abide by that format. Remember, in MAME we are talking about a common debugger frontend for thousands of systems.

Well, there is the assembler listing format output by the xdt99 xas99 assembler, which claims to be "almost identical to that of the original Editor/Assembler module." I use the listing for all of my assembly language development and the classic99 debugger to cross reference the PC address with the address in the listing to single-step through and debug the program. Having the debugger be able to show the listing directly would be amazing.

 

Here is a sample listing fragment:

0144               * Copy R2 bytes from R1 to VDP address R0
0145 6894 D7A0  46 VDPW   MOVB @R0LB,*R14      ; Send low byte of VDP RAM write address
     6896 8301
0146 6898 0260  22        ORI  R0,VDPWM        ; Set read/write bits 14 and 15 to write (01)
     689A 4000
0147 689C D780  30        MOVB R0,*R14         ; Send high byte of VDP RAM write address
0148 689E D7F1  40 !      MOVB *R1+,*R15       ; Write byte to VDP RAM
0149 68A0 0602  14        DEC  R2              ; Byte counter
0150 68A2 16FD  14        JNE  -!              ; Check if done
0151 68A4 045B  20        RT

The first decimal number is the line number of the original file, followed by the hexadecimal address of the instruction, followed by the hexadecimal encoding of the instruction, followed by the estimated number of clocks taken, followed by the line in the source code optionally starting with label.

[+mizapf]

Well, there is the assembler listing format output by the xdt99 xas99 assembler, which claims to be "almost identical to that of the original Editor/Assembler module."

 

You're thinking too TI-ish .

 

When I'm talking about MAME, this must fit for the PDP-1, for the TI-99, and for the SNES at the same time.

[PeteE]

 

You're thinking too TI-ish .

 

When I'm talking about MAME, this must fit for the PDP-1, for the TI-99, and for the SNES at the same time.

True. But whatever format MAME standardizes on, it should be trivial to convert xas99 listings into whatever symbol/address representation MAME expects. I posted the snippet to give an idea of what kinds of things would be needed in that format.

[kl99]

I was able to finish the festure that resolves the Symbols to their actual address/value.

Current challenge is that the Heiner Martin book TI Intern uses not the pseudo codes for RT and NOP but instead a B *R11 and a JMP to the next line. I have to provide render Options for these in order to Streamline them for an automatic comparison.

 

Also I need to provide options to streamline positioning.

 

The expressions need to be resolved now by doing the actual operation. ">8300+>8E". This is the last big type of difference between the Source code files I am comparing.

 

I have created a source code file for Rom0 from the TI Intern Pdf book which compares quite well already to the other Rom0 sources.

[kl99]

 

A great feature to have would be to load an assembly listing into a debugger to allow showing the current line in source code based on the PC address, as well as use labels for breakpoints.

 

Of course once an emulator would be able to run on source code, it could be doable to debug the actual source code of an User Program and abstract all actions around it (Gpl, Xml calls) away unless wanted by the debugger user.

Let's see how far this project gets. And whether it can inspire other projects.

[kl99]

Rom0 initial comparison done.

 

### TI Intern Rom0 errors ###

they were reported to Mike Wright from the Cyc just now.

[1].
03B0 131A JEQ >03FA Yes, go get old key code
versus
03B0 131A JEQ >03E6
[wrong operand address, original books contain no comment for that line]

issue in
- English printed book (only operand is wrong)
- Cyc pdf

[2].
0970 D7E0 MOVB R@>83F1,*R15 Write address motion table
versus
0970 D7E0 MOVB @>83F1,*R15 Write address motion table

issue in
- Cyc pdf

[3].
0A9E D820 MOVB R@>83D9,@>8C02 Load VDP register
versus
0A9E D820 MOVB @>83D9,@>8C02 Load VDP register

issue in
- Cyc pdf

[4].
111C 0604 DEC R3
versus
111C 0604 DEC R4

issue in
- Cyc pdf

[5].
17BC 835C DATA >83C5 Pointer address VDP
versus
17BC 835C DATA >835C Pointer address VDP

issue in
- English printed book
- German printed book
- Cyc pdf
- Online pdf by Heiner Martin

 

Not checked was:

- compiled binary value (to be done)

- memory address line value (only the regenerated one by the tool was compared)

 

TIcode99 was cheating a bit on the feature implementations, in some cases I only did it as far to make the comparison of the two files work.

 

RenderOptions are currently the following, default options are shown and are in a way set to recreate a perfect copy of the original text file.

 

bool KeepLinesOnlyConsistingOfLabel = true;
bool SkipEmptyOrWhiteSpaceLines = false;
bool TrimWhiteSpaceAtEndOfLine = false;
bool RenderAddress = false;
bool RenderCommentField = true;
bool RenderLabelField = true;
bool RenderCommentLine = true;
bool ResolveSymbolsInExpressions = false;
bool ResolveExpressions = false;
bool RenderAssemblerDirectives = true; [comment: this name will change, it's misleading, purpose is to not render EQU, COPY, IDT, DEF, AORG if set to false]
bool RenderZeroLeadingDigits = true;
PseudoInstructionOptions PseudoInstructions = PseudoInstructionOptions.Original;
NumberRenderOptions RenderNumbers = NumberRenderOptions.Original;
WorkSpaceRenderOptions RenderWorkspaceRegisterPreFix = WorkSpaceRenderOptions.Original;

WorkSpaceRenderOptions

- Original

- AlwaysRenderPreFix

- NeverRenderPreFix

 

NumberRenderOptions

- Original

- AlwaysHexadecimal

- AlwaysDecimal

PseudoInstructionOptions

- Original

- AlwaysUsePseudoInstruction

- AlwaysUseResolvedValue [comment: NOP will become JMP >xxxx with >xxxx being the address of the next line, RT will become B *R11]

 

I did not start streamlining DATA versus BYTE statements.

There were so few occurences left of differences, so for now I did a manual comparison of those, since coding is quite tricky.

 

con4ar0.txt

0000         DATA >83E0,>0024    Reset vector  
0004         DATA >83C0,>0900    Interrupt one (all 9901 interr
0008  INTTIM DATA >83C0,>0A92    Interrupt two
000C  CLOCK  BYTE >30            3 MHz clock   
000D  HAA    BYTE >AA            Valid ROM ID 

Heiner Martin

0000 DATA >83E0          RESET vector
0002 DATA >0024
0004 DATA >83C0          Interrupt Level 1 (9901)
0006 DATA >0900
0008 DATA >83C0          Interrupt Level 2
000A DATA >0A92
000C BYTE >30            3 MHz clock frequency
OOOD BYTE >AA            Header validation byte

Streamlining these would require merging several lines to the selected standard.

Difficult being what to do with comments from the original lines.

So the headache on this has to wait a bit

 

To have yet another source, I will now try to extract a text version from the Heiner Martin Pdf book, he released:
http://ti99ers.org/hof/bios/HeinerMartin/tiintern.pdf

It should mostly match the TI Intern Pdf book of The Cyc, but you never know.

[kl99]

The use of the additional source turned out well:
http://ti99ers.org/h...in/tiintern.pdf

 

Download in case you are interested:

TI-Intern-Rom0-HeinerMartinEdition.a99

 

It revealed two mini-issues in The Cyc edition of TI-Intern, which tried to streamlines some things on their own.

For example The Cyc edition always renders Workspace Registers with R as prefix. The original TI Intern book did not have that.

 

However for this line I don't think it should be happening for the 2nd operand, the ShiftCount

TI-Intern Pdf, Heiner Martin Edition and printed book:
1260 0814 SRA 4,1     Exponent :2, Basis 100!!
TI-Intern Pdf, Cyc Edition:
1260 0814 SRA R4,R1   Exponent :2, Base 100!!

Same here for the 2nd operand, which is the Cru Bit Addressing

TI-Intern Pdf, Heiner Martin Edition and printed book:
0304 3544 STCR 4,5    Fetch CRU
TI-Intern Pdf, Cyc Edition:
0304 3544 STCR R4,R5  Fetch CRU

Also I don't understand the switch/difference for this line, the change seems motivated to reflect the commented source code by TI:

TI-Intern Pdf, Heiner Martin Edition and printed book:
0036 1000        JMP >0038      Turns off GPL extension
TI-Intern Pdf, Cyc Edition:
0036 1000        DATA >1000     Used in CZC
TI commented source code:
0036 1000 HX1000 DATA >1000     USED IN CZC

Would "JMP >0038" really compile to >1000 ? Isn't that rather matching a NOP?

 

Summary of Comparison between

- Rom0, TI-Intern Pdf, Heiner Martin Edition

- Rom0, TI-Intern Pdf, Cyc Edition

 

I already fixed all issues that were published in the last post before running this comparison.

Workspace Register were rendered with Prefix R, since they didn't match originally.

Instructions which can be done via Pseudo Instructions were rendered as Pseudo Instructions, as the two files didn't match.

The comments and the comment lines were blended out, it seems the cyc was changing and adding some comments.

The memory address lines were regenerated by TIcode99 and matching, the original ones were not checked.

The binary values were not compared, this will be done once TIcode99 is able to compile on its own.

Edited February 16, 2018 by kl99

[+mizapf]

NOP is indeed a pseudo-instruction and translates as JMP $+2, machine code >1000.

 

You can actually assemble SRA R4,R1, because R1 is EQUated to 1. However, this makes sense if you want to confuse the reader.

[Asmusr]

SRA R4,R1 doesn't make much sense, but SRA R4,R0 actually would make sense since in this case the shift value is taken from R0.

[+mizapf]

SRA R4,R1 doesn't make much sense, but SRA R4,R0 actually would make sense since in this case the shift value is taken from R0.

But this guarantees utter confusion... Better not.

[apersson850]

NOP is indeed a pseudo-instruction and translates as JMP $+2, machine code >1000.

So yes, when that instruction is stored at >0036, then JMP >0038 is assembled to opcode >1000.

The problem a "dumb" disassembler has here is that it can't know if the source code contained DATA >1000, BYTE >10 followed by EVEN or JMP $+2 (or to an equivalent label). The end result is identical.

 

 

Your detailing helps me a lot, and for sure other interested members. Much appreciated. I am wondering who you are and if we have met in Chicago or at the TI Treffen in Europe? I am Klaus from Vienna.

I doubt we've met. I was quite active in the Swedish user's group Programbiten during 1980-1995. I've visited some gatherings in Sweden and Denmark, but not in recent years. if you look at the scans here, you'll find issues of that newsletter with my articles here and there. My name is Anders Persson.

Edited February 19, 2018 by apersson850

[kl99]

Again, it feels like very good progress, however I didn't come to the video(s) I have planned to show the tool off a bit.

 

- a lot of refactoring to get cleaner code, not have spaghetti code and to better structure the code

- changed some RenderOptions, especially around the rendering of numbers

 

NumberDigitsRenderOptions DecimalNumberDigits = NumberDigitsRenderOptions.Original;

NumberDigitsRenderOptions HexaDecimalNumberDigits = NumberDigitsRenderOptions.Original;

NumberRenderOptions RenderNumbers = NumberRenderOptions.Original;

 

NumberDigitsRenderOptions
- Original
- EnforceZeroLeadingDigits

- TrimZeroLeadingDigits

 

NumberRenderOptions

- Original
- AlwaysHexadecimal

- AlwaysDecimal

 

you can specify different Rendering Options for Hexadecimal Numbers versus Decimal Numbers.

That always you to leave Decimal Numbers in their original format (as in the source code file), but render Hexadecimal Numbers always with leading zeros.

 

A new thing in the inner workings of TIcode99 called MaximumNumber (set by some xml definition file) defines how many digits are used for rendering the operand if somebody runs the option EnforceZeroLeadingDigits.

An operand for Workspace Register Reference should never render as >0009, but only as single Digit in Hexmode like >9, even if EnforceZeroLeadingDigits is active.

An operand for the DATA Statement should render as word, therefore >0009, in case EnforceZeroLeadingDigits is active.

An operand for the BYTE Statement should render as byte, therefore >09, in case EnforceZeroLeadingDigits is active.

 

Here is some background information on how the tools is operating

 

This is the TMS99xx.xml definition file that the tool is reading.

tms99xx.xml

 

It defines the

- TMS9900 opcodes

- TMS9995 opcodes

- TMS9940 opcodes

- TMS990/10 opcodes

- TMS9900 Editor/Assembler - Assembler Directives

- TMS9900 Editor/Assembler - Pseudo Instructions

- TMS990/10 Assembler - Assembler Directives

- TMS990/10 Assembler - Pseudo Instructions

- Operand Type Definitions

 

Basically this defines the language for TIcode99 to work with. I could setup a similar file for TMS7xxx assembler to make it work with that language too.

I already started a GPL xml definition file, but that is not in use yet.

 

The text for various tooltips come from the xml file as well.

Edited February 19, 2018 by kl99

[kl99]

Okay. I can not do the replacement of two BYTE statements by one DATA like I intended it, in case somebody prefers later format-style (or for comparison of two files, where one has the same line as two BYTE and the other has it as DATA).

Let's compare memory address >1158, >1159 from all available source codes:

TI-Intern-Rom0-The-Cyc-Edition:
1158        BYTE 50             Used in rounding
1159        BYTE 03             Integer overflow error code

TI-Intern-Rom0-Heiner-Martin-Edition:
1158        DATA >3203

ROM-4A_B:
1158 HX3203 DATA >3203

con4ar0:
1158 LW50H  BYTE 50
1159 ERRI   BYTE ERRIOV

You could argue that it is a style question. But there are situations where keeping the two BYTE seperate makes much more sense.

con4ar0.a99 defines a label for each of the lines. Both labels are used as references from other codelines.

con4ar0:
1308        CB   *R2+,@LW50H   Is rounding necessary ?
...
1330        MOVB @ERRI,@FAC+10 Error code

I can not change the >1158 and >1159 into one DATA statement without loosing the information and ability to point to them by their original label (which gives much hint on their purpose to the user).

 

 

Even, if no labels are used to refer to >1158 or >1159, it makes much more sense to keep the lines as BYTES if somebody references to one of the bytes directly, especially with byte opcodes (MOVB,...).

In fact they contain two values for two different purposes. And the way how they are referred individually reveals that.

TI-Intern-Rom0-Heiner-Martin-Edition:
1308        CB   *2+,@>1158
...
1330        MOVB @>1159,@>8354 Set error

To sum it up, I can not know all the references to a memory address before I have finished scanning in all the lines.

Therefore the check whether BYTE or DATA can be replaced has to happen after that.

For it to work I will create a List of all References from A to B.

I already have a list for Labels and Assembly Constants but not for direct address references.

 

More when I got to it ...

Edited February 20, 2018 by kl99

[+TheBF]

 

That is the whole idea why I started all this. My TI Simulator will not run with the binary Rom but directly execute the source code providing full context to the debugger user.

The ultimate goal is to abstract things away in the simulator by setting a config in the debugger, so the user can say he wants to concentrate only on Gpl or only Assembler or abstract away the Keyboard Scan, Grom Read Routine or the Basic Interpreter.

 

However the first step is still to be completed. Which is a merge of all available source code files, their use of labels over resolved values, their comments together into one "archival" source code version.

It should merge the comments by TI Intern, the comments from the original 99/4A source code files (there are two different ones) and the comments from the 99/8 source code files.

I could have done this manually, but I am a programmer. And the benefit will be that it can be used to generate a commented source code for the 99/5 disassembly, published by Fabrice, and a commented version for shared code parts in the Tomy Tutor Rom disassembly, which I am curious to analyze.

The small tool for reading in one source code file turned out to become that intelligent that I am using the Intermediate Representation in the tool as basis to execute a simulation of the TI-99.

 

I have no insight how all the existing TI-99 emulators are representating the Rom during execution. From the target of MAME I assume, that is working very close to the hardware level.

Simply showing the commented source code line to the debugging user would gain a bit but not much unless the emulator is actually aware of the symbols referenced in that line.

Since the acutal TI is not aware of it, I assume all emulators are like that.

 

 

As you say the ROM is fixed so could you not just associate each comment/code with a program counter address?

It seems like a big 2D table of address values as index with one or more strings associated with each address.

[kl99]

 

 

As you say the ROM is fixed so could you not just associate each comment/code with a program counter address?

It seems like a big 2D table of address values as index with one or more strings associated with each address.

 

That would end up with the situation like stated earlier:

"Simply showing the commented source code line to the debugging user would gain a bit but not much unless the emulator is actually aware of the symbols referenced in that line."