Asmusr Posted February 14, 2018 Share Posted February 14, 2018 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. 5 Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 14, 2018 Author Share Posted February 14, 2018 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. Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 14, 2018 Author Share Posted February 14, 2018 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 14, 2018 Share Posted February 14, 2018 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). 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 14, 2018 Share Posted February 14, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted February 14, 2018 Share Posted February 14, 2018 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 14, 2018 Author Share Posted February 14, 2018 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted February 14, 2018 Share Posted February 14, 2018 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 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted February 14, 2018 Share Posted February 14, 2018 ... 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 1 Quote Link to comment Share on other sites More sharing options...
PeteE Posted February 14, 2018 Share Posted February 14, 2018 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 14, 2018 Share Posted February 14, 2018 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. Quote Link to comment Share on other sites More sharing options...
PeteE Posted February 14, 2018 Share Posted February 14, 2018 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. Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 15, 2018 Author Share Posted February 15, 2018 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. Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 15, 2018 Author Share Posted February 15, 2018 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. Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 16, 2018 Author Share Posted February 16, 2018 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 codeversus03B0 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 tableversus0970 D7E0 MOVB @>83F1,*R15 Write address motion tableissue in- Cyc pdf[3].0A9E D820 MOVB R@>83D9,@>8C02 Load VDP registerversus0A9E D820 MOVB @>83D9,@>8C02 Load VDP registerissue in- Cyc pdf[4].111C 0604 DEC R3versus111C 0604 DEC R4issue in- Cyc pdf[5].17BC 835C DATA >83C5 Pointer address VDPversus17BC 835C DATA >835C Pointer address VDPissue 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. Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 16, 2018 Author Share Posted February 16, 2018 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 16, 2018 Share Posted February 16, 2018 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. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted February 17, 2018 Share Posted February 17, 2018 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 17, 2018 Share Posted February 17, 2018 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. Quote Link to comment Share on other sites More sharing options...
apersson850 Posted February 19, 2018 Share Posted February 19, 2018 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 19, 2018 Author Share Posted February 19, 2018 (edited) 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 Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 20, 2018 Author Share Posted February 20, 2018 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted February 20, 2018 Share Posted February 20, 2018 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. Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 20, 2018 Author Share Posted February 20, 2018 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." Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.