Saturday, 11 May 2013

The 6809 computer is now self-updateable

I can now update the contents of the EEPROM without removing the chip! This marks a minor milestone in this little project.

The flow of the update process is a little different then previously described, but has quite a bit in common with the process used by the AVR EEPROM programmer:
  1. At startup a greeting prompts the user to either type 'f' (for flash) or hit any other key
  2. If they type anything but 'f' normal startup continues.
  3. The first thing the flash code does is copy the whole of the EEPROM (16 KByte) into the top half of RAM.
  4. The flashing code, now in RAM, is jumped to by calculating a jump address from the location of the code in EEPROM and working out where it now is in RAM.
  5. It outputs a marker (+++) which the sending side uses to know it can start the upload.
  6. The uploader sends 64 bytes (a page for the AT28C256) which the 6809 writes to a RAM buffer.
  7. The 6809 acknowledges the page by sending back a hash character. But before acknowledging the page, the 6809 writes the copy of it into EEPROM and waits about 10ms, as per the AVR code.
  8. After all pages have been uploaded and written out, the 6809 sends the new EEPROM content back to the uploader so it can check it. Nothing can be done if there was a write error, but at least it will be known.
  9. At the end of the upload process a reset is performed so the new code is run.
The uploader side of the process is a Linux program (flasher) somewhat similar to upload.c written for the AVR EEPROM programmer.

The process works well although it would be better if the flash code in the 6809 and the actual monitor were two distinct programs and only the monitor was updated. This would mean if the upload failed the "core" update system would still be available so the upload could be retried. Doing this is a fair amount of work though, so I think I will skip it for now. I do, of course, still have the AVR programmer so I can always recover the system.

Both the updated monitor code and Linux flasher program are in git, if anyone is interested.

This week I also had a problem with the MAX232 level shsifter. In the end I gave up with that part of the circuit and now have a USB TTL serial interface plugged into the 6850 in the breadboard. It has the side benefit of breaking out +5V and GND from the USB so a single connector onto the breadboard for both serial and power is all that is needed. At some point I will figure out why the MAX232 no longer works as it once did.

Below is the latest pic of the breadboard. The USB port looks weird but actually works quite well.  The circuit, except for the removal of the MAX232, is near enough identical to the previous circuit.  The only change is that /WE on the EEPROM is now connected in the way as the RAM /WE pin.  Previously it was tied high, ie. writes were impossible.


Finally, a screen shot of two terminal windows. One shows a session with the monitor, the other a run of the flasher program.

As a break from working on the 6809 my next task will be to learn more about I2C and how I might use it to connect up some I2C peripherals including sensors, real time clocks, and the like to the 6809 computer.

The easiest way to learn about these "modern" serial busses is to use a microcontroller. The AVR comes with both an SPI interface (it is used for flashing the internal EEPEOM) and an I2C interface, which AVR terms TWI (two wire interface). I hope to interface a serial EEPROM to an ATMega8 as a learning excersise. Once I've figured this out, there are a number of options for interfacing a 6809 to a I2C bus...

2 comments:

  1. Nice work.
    I am working on an sbc combining an HD6309 cpu with a V9990 VDP and I would like to interface with modern devices as well.
    Thanks for the inspiration.

    ReplyDelete
    Replies
    1. Thanks! I assume you've seen my latest board? The V9990 sounds amazing! I have a SMT phobia though :) What UART are you using? Do you have a blog somewhere?

      Delete