Floating Point tests
Within a couple of days of my historical 'PRINT 2+2' replication I had enough code in to write this small program and RUN it. For me this was the icing on the cake. I could now see the potential of having a real floating point BASIC on the ETA-3400X.
A more impressive floating point test.
Debugging
The majority of the time I was able to fix bugs by using the Fantom II monitor and stepping through the section of code for a specific instruction until it started to do something unexpected or branch off to a section of code that I hadn't entered.
Most of the time it was some access to a zero-page address that had been relocated that I missed.
Sometimes I wasn't sure if I had a bug or not, because the result seemed to work but it didn't match what the BASIC Reference manual had in it. On a couple of occasions I contacted one of the ET-3400 group members for confirmation of the bug.
I have to thank two people in particular who helped check some bugs or discrepancies for me since I didn't have an original or clone ALTAIR 680 to test things on.
Mike Douglas of deramp.com helped me with PEEK and POKE instruction where we found that the manual was incorrect. According to the manual you could only use 0 to 32767 PEEK and POKE range, however I was able to PEEK and POKE from 0 to 65535. He also confirmed the FRE(0) memory results. He also confirmed I had an error with the leading zero's in the program LIST command and the BYTES FREE statement after boot up, which I was slightly disappointed with as I thought the leading zero's looked cool and made the listings neater.
Jeff Tranter went to great lengths and helped me with memory dumps using his home built 6800 based SBC with a 6850 ACIA which can emulate an ALTAIR 680.
Also I got a lot of tips, theories and encouragement from members of the ET-3400 group as I progressed.
An appropriate cartoon posted by one of the ET-3400 group members was closer to the truth than he realised.
Memory mapping decisions
Up until near the end of the port I was working on a limited amount of BASIC program memory and this was because I had to add a few small subroutines to patch some of the code and there wasn't anywhere within the existing space to do that. Also I wasn't sure where in zero-page that the pointers for BASIC Variables, Arrays, Strings or the BASIC Stack was stored, partly because those addresses were seemingly replicated in a couple of places.
I added the patches after $1AB8 for the Random seed value, the VT100 7-bit patch, a POLCAT routine, a COLD start routine, a non-destructive Find-Top-of-RAM routine and the Baudot buffer (which I've misnamed throughout). As it turns out the apparent unused #$00 bytes between $0100 and $010C that I repurposed for relocated zero-page code were actually needed as a scratchpad to convert binary to decimal (as far as I can tell) and possibly other uses, so I had to reinstate it in a new location.
In the original version of the 8K BASIC the user is asked whether they require SIN-COS-TAN-ATN? and this determines where in the RAM that BASIC stores it's user BASIC programs. It actually overwrites itself from $18F3 or lower overwriting code that it no longer needs once BASIC starts. This can include floating-point data for trigonometric functions and all of the startup strings for MEMORY SIZE? and the startup message. Microsoft did this to give the user more RAM on an already small memory size because the cost of RAM was prohibitive and every byte counted.
I wasn't able to keep all that RAM for the user because I had to squeeze in the patches somewhere, however I did have the advantage of having about 48K of user RAM for BASIC interpreter and it's programs, so losing about 800 bytes was a reasonable trade off. Instead I have the start of BASIC program space etc starting from $1C00 regardless of what the user types in response to WANT SIN-COS-TAN-ATN ?
The last difficult bug I had was with the READ and DATA statements. This took about 3 weeks to find, where other bugs were typically found within a day. First I had to try and nail down what the bug actually was and be able to replicate it reliably. This is typically what would happen for this bug:
When I first entered the program and ran it I got:
?SN ERROR
If I then typed certain commands such as PRINT "ABCDEFGHI" in immediate mode, then ran the program it would work and display:
1 2
I even analysed the tokenised program in memory and it did not change. This one had me stumped and I got a lot of suggestion on what to try, but nothing worked.
I tried my typical trace method I had used successfully on most of the other bugs, but this time that method didn't work because of the way that the Stack Pointer was used. If I used the Step command in the Fantom II monitor it would normally execute a single instruction, however in doing so it also dumped the registers at whatever the Stack pointer address was at the time, and this unfortunately overwrote data or code. Then when the code continued for the next instruction it would restore the registers from the Stack pointer location and continue execution.
This bug was really annoying me because it was the one bug that stood in the way of completing this project to 99% or better. If a user typed in a program, about 20% of programs I tested would encounter this bug. To me this was unacceptable.
In the end I had to try and trap the bug by putting breakpoints at the other end of the code that ran and gradually moved that breakpoint backward. Each time I could examine the registers and know if it had hit the bug or not. The disadvantage of this method was that in some cases the program could jump to a subroutine from several locations, so I had to eliminate one at a time.
The cause of the bug turned out to be one more of those zero-page patches that I had typed wrong and I have no explanation of how it ran at all with that bug in it because it was jumping into the wrong zero page address. For me it was a one in a million chance that the bug still allowed the program to run and not crash, just produce weird results.
There's only one more thing to do now that all the bugs have been squashed...
No comments:
Post a Comment