Part 2i: Patching method

Getting back to the disassembly and patching, I still only had about 10-20% of the ROM dump entered at this stage. Not enough to execute any commands or RUN any programs. Since BASIC is an interpreter language there is a program mode and an immediate mode. I have the program mode partly working, although somewhat limited to very short programs. For the immediate mode you only need to be able to enter a one-liner and it will try and execute it after tokenising the line.

I needed to concentrate on entering just the parts of the hex ROM dump and patching that I needed to test, rather than typing in the whole 8K of the original dump.

How I managed that was to print out the full hex dump on thirteen A4 sized pages in landscape mode, leaving a bit of room on the side for patch notes. Because this was done in a purely random sequence depending on which code block I wanted to enter, I marked off each block in pencil, ticking it off once entered and saved.

This is where the BASIC token pointers came in handy as it gave me the entry points into many of the BASIC commands, such as LET, PRINT, LIST, CLEAR, NULL etc.

Page 3 of 13 showing blocks of code marked off in pencil and side notes. Patches required to orange highlighted bytes. 

Page 4 of 13 showing a few more BASIC command entry points and typical number of patches highlighted in orange.

Having the entry point to one of the BASIC commands allowed me to set a breakpoint at the start of that command, and if I didn't have a breakpoint set already I could use the one I set up for the NULL command (as described earlier), then drop into the monitor and add a breakpoint for the new command to be patched. For example if I want to test the LET command I would place a breakpoint at $0791, then return to BASIC to test it.

I could then enter LET A = 1 for example, and hit <Enter>. At that point it would  tokenise the the command string and working out what command it was doing, then jump to that command entry point. That's when it would hit the breakpoint at $0791 and dump the registers.

This was also an excellent way for me to confirm that I had the correct entry points. If it didn't stop where I was expecting it to, I would have to recheck where it was actually jumping to.

STEPPING through the code.

Using the disassembly listing on my PC screen, I could read through the code and simultaneously step through the code on the ETA-3400X using the Fantom II monitor's Step command. This gave me the advantage of seeing what the registers were doing and also where the program was going during execution. If I saw that a zero-page location was being altered I would have to patch it to match any amendments I had made. If it headed off to a block of BASIC code that I had not entered yet, I would stop stepping through the code, and instead I would then enter another block of code. Usually blocks of code would end in a RTS instruction (hex $39) or a JMP instruction to another section of code.

After I had added all of the code related to a specific BASIC command I would usually save the file, then test it out to see if it had worked or not using the immediate mode in BASIC.

If the command didn't work as expected, I could then step through the instruction again and see where it took me, or if I could see anything obvious that I may have missed initially, however most of the time the new command would work.

I maintained a status sheet which also was a bug list of commands that I had added and tested, or if I wasn't able to get it to work I'd just try and put in a description of the bug.

This is just a snapshot of some of the entries

.

.

- added NEW function and tested.
- added LIST function and tested. LIST X also tested.
- fixed bug with leading zero's in #### BYTES FREE and program LISTing.
- added NULL function and tested. NULL 0 .. NULL 78 tested (ie <= terminal width - 2).

  Larger numbers produce "?FC ERROR".
  NULL with no parameters produces '?SN ERROR'.
- added CLEAR function. tested CLEAR and CLEAR 50 and both seemed to work. CLEAR with too large of a number causes an '?OM ERROR'

.

.

Unresolved issues arising:

- Establish correct RAM locations for:

  BASIC program code, currently overwrites $18F3... if all trig functions selected ('Y').*

  Variables = *just after the '00 00 00' at the end of the BASIC program*

  Arrays = *TBA - seem to be placed directly after variables.

Strings = variable name, size and and a pointer is above BASIC with other floating point variables, actual string data is stored downward near the top of RAM.

  Stack = *TBA - BASIC runtime stack

* partially resolved.

- Using <Enter> after 'Memory Size?' causes Fantom II breakpoints to be overwritten at top of RAM. Entries of ~48000 or lower works fine for now.

.

.

Besides the tests I made up, I was also testing each command with the examples shown in the BASIC Reference Manual in their exact syntax and making sure I had the correct output. If they worked I'd mark them off, but if they were different, then I'd make a note. I used a copy of the .pdf reference manual and added comments and highlights to the test.

Highlighted commands in the .pdf that did not work and comments on the side bar. On this page INP(adrs) is not a supported on the ALTAIR 680 for hardware reasons.

Although the reference manual was written for the ALTAIR 8800 (4K and 8K versions), the ALTAIR 680 was supposedly the same, however some commands like INP and OUT are not supported because of hardware differences between the 8080 CPU and the 6800 CPU.

Next I reach an historical moment...