At this stage I am still operating my new ETA-3400X as a standalone machine with a clone serial terminal and cassette port. I have a serial monitor (Fantom II) and Tiny BASIC as my tools. The ROM dump is on my PC and there is probably an easier way to get the ROM dump onto the ETA-3400X using the monitors SREC file transfer method IF I had a serial cable to my PC which I probably do, but somewhere hard to get to.
Even if I did that, the interpreter cannot run as it stands. That's because of several reasons:
- It loads from $0000 upward to about $1C00 overwriting the zero-page space and potentially crashing the monitor. That shouldn't be a big issue as a RESET on the ET-3400 hex keypad, then restart the monitor with a call to $F400 where it now resides should still keep the majority of the interpreter in RAM other than perhaps part of zero-page.
- The ALTAIR 680 BASIC was designed to work with the much smaller 256 byte ALTAIR PROM and not the 2KB Fantom II so there would be patches required so that the two do not corrupt each other, especially in the zero-page space.
- The ALTAIR 680 uses a 6850 ACIA, and the ETA-3400X uses a 6821 PIA, both are mapped in different memory locations and have different service routines.
- You can't just patch code without knowing a bit about what it's actually doing. A commented disassembly would be nice but for the ALTAIR 680 BASIC there isn't one available.
So to start this off I really need a disassembled listing of any description. And I also need to try and find some of the I/O routines.
I searched for and downloaded a couple of free disassemblers for my PC in order to try them out and see what was the most suitable.
- VASM was first and it sounded good because it could also work with different CPUs. Unfortunately, once I read some of the documentation I realised that it seemed to be only an assembler, so that was off the list.
- DASM was next, and it turns out to be another assembler only, so that's out too.
- DASMx turned out to be a disassembler that worked for different CPUs including the 6800, 6502, 8080/8085 and Z80, all of which I use in different machines. It was also a symbolic disassembler which I thought might come in handy, even though I've never used one before.
DASMx is a DOS based program, so you have to run it at the command prompt, or in a command prompt window, which is how I used it. The documentation is pretty good and I had to read some of it to get it to do the hard work.
DASM needs a binary file, so I put a copy of MITS-RAW.BIN into the DASMx directory. The I go into a DOS window and navigate to DASMx. If I had realised how it was going to install in a subdirectory of a subdirectory I would have done it differently as I had to navigate multiple levels down and that's a pain in the butt in DOS.
When you first look at the disassembled file it's a mess and without any predefined symbols it's even harder. For example this is a short subroutine in the listing:
0612 : DE 7A " z" ldx X007A
0614 : 09 " " dex
0615 L0615:
0615 : DF 96 " " stx X0096
0617 L0617:
0617 : 39 "9" rts
;
Now after I have added some labels and comments it's a bit easier to work out what's happening:
; perform RESTORE:
0612 : DE 7A ldx ProgramBase ;or Written By message start ?
0614 : 09 dex ;-1
0615 : DF 96 L0615: stx DataProgramPtr
0617 : 39 L0617: rts ;(5uS)
;**********************************************************************
However in order to get the labels on there you have to create a symbol file that includes all the symbols. The symbol filename must be the same filename as the .BIN file but with a .SYM file type. In my symbol file I have these lines as well as a lot more:
word 0x007A ProgramBase ;program Base
symbol 0x007C FACCUM ;Floating Point Accumulator
symbol 0x007D FACCUM+1
symbol 0x007E FACCUM+2
symbol 0x007F FACCUM+3
word 0x0096 DataProgramPtr ;Program Data pointer
vector 0x011F USRptr ;BASIC pointer to USR routine
Note the symbol for ProgramBase and DataProgramPtr are defined here, as well as a lot of others.
But where do you find the symbol names (I hear you ask) ?
The simple answer is that I have to guess every single label by reading partial disassembly listings of other similar versions of ALTAIR BASIC and deducing it's name and location in RAM. Alternately I make up my own symbol names if I can work out what it does. The disassembler assigns it's own sequential names if it needs one.
For example, starting at the www.altairbasic.org web site I found this info. for the 4K 8080 version of BASIC even though it's a completely different CPU, a smaller version of BASIC, it was written around the same time and other versions are probably similar (I hope), since they were all from MicroSoft:
Rather than re-invent the names I started off trying to use names that others had used in their disassembled listings for other versions. I hoped that this would make it easier for me and others later on in understanding what is happening and get more of the disassembly completed.
But the address of those symbols is different !
Hang on, I have used $7A instead of $0165 and $96 instead of $016D!!!. Yes they are different addresses and that was one of the hardest parts of this whole conversion. That's where the guessing became an art, or just good luck. I originally had about 3 possible addresses for those symbols, but as I got more and more of the disassembly completed it then became obvious which ones were correct.
I didn't know all the symbols at first and even after completing the project I still don't have symbol names for the majority of it.
Eventually updating the symbol file, then running the disassembler became unproductive because I was also patching a copy of the disassembled code, and adding comments. That's something that the disassembler loses if it's working from a binary source file and recreating the disassembled listing over and over.
How did I get the code onto the ET-3400 ?
Manually..., the hard way..., one byte at a time!. Lots of late nights and early mornings and coffee. That is, sometimes I was up until 5am getting it done if I was on a roll. All $1B00 (6912) bytes! using the Fantom II monitor. I first printed out a hexadecimal dump of the ROM onto 13 pages of A4. Then as I typed in some blocks in random order, I'd rule them off as entered. I'm sure you would think that typing in all this manually is crazy, and you would be correct. Remember, I didn't initially plan to port this interpreter across by myself. It was only going to be just enough as a proof of concept. I expected I'd only need about a tenth of the code as proof of concept.
The Fantom II monitor does make it a bit easier to enter the code, using the M (Modify) command. For example you can type M 0100 <Enter> when you get a prompt for new data (in hexadecimal) on that address or hit <Enter> to skip to the next address.
Every now and again, say every 30 mins of data entry I would make another backup onto cassette tape, just in case the power failed or I crashed the program, and later on I did this religiously before I ever tested a new section of code.
Saving to tape on the ETA-3400 is quite fast if it's a binary file. To save or load an entire 8K of RAM only took about 100 seconds at the fastest tape speed option. That's under 2 minutes for 8K. Compare that to loading a 14K Star Trek program using LOAD in Tiny BASIC at about 23 minutes! There is no comparison, and it means I can save it a lot without losing too much time.
The save command is:
<ctrl>T1:0000,1C00 <Enter>
Make sure to start the tape recording before you hit the <Enter> key. And also make sure to stop the recording after it's finished and you get a monitor prompt.
The load command was simply:
L1
In this case make sure to start the tape playing after you hit <Enter>
The #1 after the L or T designates the fastest tape R/W speed. I never had to use a slower speed as it almost always worked. The few times it didn't work was usually because I was moving things around and bumped the wires in the middle of a Load or Save. (I'm still running this on prototype board and breadboard).
One of the nice features of the Fantom II monitor is that while it is reading a file in, one of the 7-segment decimal points flashes, so you know it's actually doing something and hasn't crashed.
Next I cover more of the disassembly process...
No comments:
Post a Comment