You can see the fix for the MEMRDY and /DMAREQ pins, which sour the otherwise error-free board.

The other piece of construction I’ve done is to, albeit temporarily, mount the PCB and keyboard on a piece of acrylic. I hope to eventually redo this in a more permanent way, but for now I can at least type on the keyboard. MAXI09 now resembles a real computer!

This picture, if you look closely, shows a Compact Flash attached to the IDE port. I was pleased that this works nicely, as before, though thus far the CF is operating only in 8 bit mode, and without the help of the DMA Controller.

• Attaches to a TV/RGB monitor
• Keyboard
• Joystick ports
• Sound
• Mass storage

The Snake game was loaded from the Compact Flash, with the keyboard used for operating the computer.

The computers’s main limitations are down to the software. My Monitor is not a proper operating environment. Eventually I hope to write a simple multitasking Operating System, but in the mean time the Monitor can be used to test the hardware, including the parts implemented in programmable logic, and to try out ideas for the OS I hope to write, investigate interrupts, etc.

Another thing I have been working on is a boot loader. The main purpose of this is to allow the EEPROM to be reprogrammed regardless of its content. One of the flaws with the previously implemented in-system EEPROM reprogramming is that the code to reprogram the device is stored in the EEPROM. If the reprogramming fails, maybe because of a power interruption, then the computer is un-bootable, necessitating a pull of the EEPROM and a reprogram on my home made EEPROM programmer. The solution to this problem is to put the reprogramming code somewhere else. In the case of the MAXI09 there is one interesting possibility: the MuDdy FPGA. The Flex10K (PDF) are interesting because as well as the programmable logic, they also have RAM bits. These can be used for anything including data logging or lookup tables for maths functions, but a simpler use is to expose the memory on external pins. It is also possible to pre-load the memory with content set at configuration time. And removing the memory array’s write line makes it behave as a ROM.

The EPF10K10 has 3 lots of 2048 bits, or 3 by 256 bytes of RAM, called EAB (PDF) by Altera. 256 bytes is enough to implement a flash routine in 6809 machine code. This leaves 2 by 256 bytes for other purposes, like the MMU functionality when I get round to implementing it. It might also be possible to implement a boot loader which reads the OS code from blocks in the IDE device, or receives the image via XMODEM.

One further complication in my boot loader is that it needs to overlay the top most page of EEPROM at 0xFF00 to 0xFFFF. This is necessary because after the boot loader has switched to the runtime system (the OS, or as it currently stands the Monitor), that image and not the loader needs to occupy the top page so that the interrupt vectors are in place.

This is accomplished by having another register in MuDdy which controls what is presented at the top page. A zero, the default, puts the loader FPGA ROM there and a one puts the EEPROM at that page. For completeness it is also possible, via another bit in the same register, to write project the EEPROM. This is in addition to write protection hardware jumper.

This register is called MUDDYSTATE, although this is probably a bad name for it. Bit 0, when 1, write enables the EEPROM. Bit 1, when 1, maps the EEPROM onto the top most page. All other bits are currently unused and will be ignored here.

A simplified description of the new MAXI09 boot process is as follows:

1. MUDDYSTATE is set to 0b00 after MuDdy has been configured.
2. 6809 resets into the loader code
3. Loader outputs start-up banner saying: press f to flash
4. Two second, approximately, wait for input
5. If no input, jump to the last step
6. If we got an f then the operator wants to reprogram the EEPROM
7. Copy the loader image, 256 bytes, to a scratch area of RAM
8. Calculate the new position for the programming routine and jump to it
9. Enable writing to the EEPROM, and map it into the top page by writing 0b11 into MUDDYSTATE
10. Copy 16 KByte of 64 byte pages from the serial port to the EEPROM, much as done previously
11. Disable writing to the EEPROM by writing 0b10 to MUDDYSTATE
12. Send the new content of the EEPROM back to host computer so it can verify the content, much as before
13. Jump to the top of EEPROM, at 0xC000, which will start the OS or Monitor

Inside the OS, almost the very first thing it needs to do to is write 0b10 into MUDDYSTATE, in case the EEPROM was not just flashed. This will ensure the loader ROM is not at the top page regardless of wether it was previously reprogrammed, and that writing to the EEPROM is disabled.

The loader code is cobbled together from various bits of Monitor code, including serial routines and the reprogramming code itself. Even after I finally implement it fully, serial IO inside the loader program will always be polled and not interrupt driven. This is both to reduce the size of the code and to keep it as simple as possible. Currently the loader program is about 220 bytes in length, so not much more room is available.

Actually getting the loader code into the MuDdy FPGA is an interesting process. After producing the 256 loader binary via the ASxxxx assembler, it needs to be converted into a format that the Altera tools require. Two file formats are supported: Intel HEX and Altera’s own Memory Image File (MIF). After trying and failing to get the ASxxxx linker, aslink, to produce compatible Intel HEX  files, I eventually settled on writing a simple Perl script that converts a binary file into the MIF format. This file is then associated with a RAM array VHDL component which in turn is instantiated by a wizard within the Quartus tool.

The summary of all this is that the loader works very well. Regardless of the state of the EEPROM, I can always recover the system. It is even possible to start the computer without the EEPROM socketed; albeit all you see at the serial console is the prompt to start the reprogramming process.

• Whilst the IDE interface works fine in 8 bit mode, I want to get 16 bit transfers implemented. This will involve implementing a latch in DISCo to hold the high byte of the 16 bit IDE data bus, as I’ve described previously.
• Also, now that I have a, albeit 8 bit IDE interface, it would be nice to modify my, somewhat ropey, low level IDE routines to make use of the DMA Controller implemented in MuDdy.
• Although the Amiga 600 keyboard is functional, the work needs finishing. Scan-codes need to be interpreted for the cursor and other non alpha-numeric keys, commands need to be added to twiddle with the RGB LED and caps lock LED, a keyboard-activated reset is needed, etc.
• Now that the SPI peripheral ICs have been attached to the board, I have no excuse not to implement an SPI bus controller inside DISCo. It will permit access to to DS1305 (PDF) Real Time Clock, analogue joystick pots, and the 32KB SPI EEPROM.

I paid a good price, and it is complete with a manual and even the C64 interface module. This was the first printer I ever owned; I used one with my Amiga 1200 in the 90s. I’d like to test that the parallel port on the MAXI09 board works properly by sending the printer data from memory, using a Monitor command specially written for this purpose.