Saturday, 27 April 2013

Monitor progress

So far the monitor can do four things:
  1. Dump memory contents in hex and ASCII (d command)
  2. Write memory contents in hex (w command)
  3. Exit the monitor and run arbitrary code (e command)
  4. Show the registers as they were just before the monitor was reentered (r command)
For ease of parsing each command is a single character.

Monitors are generally implemented as a big software interrupt handler. When external code needs to be run, a "rti" (return from interrupt) is performed, directly after modifying the return address ie. the Program Counter as it was just before the monitor was entered is modified to point at the external code. To return to the monitor, external code should do a "swi" (software interrupt).  This will cause the entire CPU state to be saved to the stack.

Probably the most complicated code written so far is for the ASCII to byte conversion. Each time a memory address or other data needs to be displayed, or read in, it needs to be converted. This would be trivial in C. I'm slowly gaining profficency in 6809 asm though and am enjoying the change of pace from languages a million miles away like Perl and C which I'm more used to using.

The parser, while not good at spotting every user error, is fairly flexible and will parse a stream of ASCII space-separated hex into a list of bytes and words with markers to indicate wether a byte or word, or the end of the list, was found. On the downside I'm still to implement backspace key handling.

The following screenshot shows how a trivial program is input, in machine code, at memory location $2000, dumped back out to check it was loaded successfully and ran. Finally the registers are displayed, showing what they were when the trivial program is finished and the monitor is reentered:

The program is as follows:

2000   lda #$40    86 40
       ora #$02    8a 02
       swi         4f

As you can see, the A register has the value $42 ($40 OR'd with $02) when the monitor is re-entered, and the progam counter has moved on to location $2005. Other registers will have fairly random values.

As it currently stands the monitor is not terribly useful, but it's getting there.

The next stage, after finally implementing backspace handling, is to implement EEPROM programming in the monitor. The rough plan for the uploading command is:
  1. Copy the whole monitor code to RAM
  2. Jump to the upload subroutine in RAM
  3. Read from the serial port 16Kbytes for the EEPROM image and write it to RAM
  4. Send the image back to the uploader machine so it can check it
  5. If the uploader isn't happy with what it received, it will output an N
  6. If its ok the uploader will send a Y and the monitor will copy the RAM image into the EEPROM
  7. Either way a reset will be performed
The reason for the convoluted copying is twofold.

First the monitor shouldn't be overwritten while its running. That way leads to madness. Second the upload should be validated before being made active, and overwriting the current EEPROM code. The idea is that if the upload was corrupt for some reason, the current monitor won't be lost. Luckily there is 32KByte of RAM available to hold the whole EEPROM image (which is 16Kbyte). Of course a plain old bug in the monitor could still cause me to reach for the EEPROM programmer, but generally this approach should mean I can improve the monitor more quickly.

Other approaches to solving this problem are possible. One way would involve using a loader program which is protected from the main program and never normally overwritten. Even if junk was uploaded it would still be available, and this loader "mini program" would always be run on reset instead of the actual monitor. This is probably more complicated then the plan outlined above, so I will choose the simpler option.

No comments:

Post a Comment