Two more bits of prototyping work have been completed recently.

I was able to establish the pining on the 30 way flex connector for this keyboard by examining the schematic of the A600 (PDF). The following lines are used:

• 5 Key rows
• 15 Ordinary key columns
• 7 “Shifting” key columns
• 1 Ground for the shifting row
• 2 Caps Lock LED connections (cathode and anode)

The shift row is interesting. Ordinary key matrix keyboards surfer from phantom key presses. This is especially a problem for shift keys, where pressing, say, left shift with control and one other letter will, quite possibly, introduce a fourth key press. This problem can be reduced if shifting keys are tested outside of ordinary keys, so the A600 has the shift, control, alt, and Amiga keys on dedicated lines.

• bit 7 – 1 -> up, 0 -> down
• bit 6 – row bit 2
• bit 5 – row bit 1
• bit 4 – row bit 0
• bit 3 – 0 -> low half of columns, 1-> high half of columns
• bit 2 – column bit 2
• bit 1 – column bit 1
• bit 0 – column bit 0

Here is the updated keyboard controller schematic section:

You can see that nearly every pin on the AVR is used. As well as the keyboard flex connector and UART lines, the AVR is also attached to an RGB LED. This will be used as both a power indicator and a system error indicator. Another output, marked /KBDREQ is used to generate a signal for the DISCo FPGA, as will be described later.

I was quite pleased with this little adapter board.

• The afore-mentioned 30 way flex adapter
• ATmega8515 (PDF) on a 44 way DIP adapter
• An RGB LED
• UART cable
• ISP header

The purpose of the prototype was to verify that I knew how to scan the keyboard, and to test out a few other things including the RGB LED and the Caps Lock LED.

After modifying the C64 keyboard controller code, I could successfully see the generated scancodes across the UART. I also verified the function of the Caps Lock LED by, in AVR code, toggling it on and off when the button was pressed. A similar thing was done for the RGB LED, using the R, G and B keys. Note that in the finished MAXI09 commands from the 6809 MPU will control these LEDs, based on system, and keyboard, activity.

At this point I was pretty pleased. Through the prototyping phase the keyboard controller code for MAXI09 was mostly written. But then I had another idea: instead of generating the system /RESET when the FPGAs have been configured, how about having the AVR generate it instead? This would allow the system to be reset under keyboard control. But because the AVR also needs to be reset its not possible to simply tie an AVR’s output back to its /RESET pin because it would never come out of reset the moment it went low.

The solution to this feedback loop is to instead only hold the /RESET signal low for a few milliseconds, before raising it again, so that the AVR and the rest of the system will start running. This can be done using various ways, including a 555 timer, configured in monostable mode but I have settled on using the DISCo FPGA and the system E clock to hold the /RESET line low for a few ticks just after /KEYREQ goes low.

The final part of this puzzle is FPGA config time. Since /RESET is now an FPGA output it will be tristated whilst the FPGA is configured. This would be a big problem but it is easily solved with a pull down resistor, which serves to lock the system in reset whilst the FPGA receives its config from the configuration flash.

Having the system reset signal being generated by logic in this way introduces some fun ideas. It would be possible, for instance, to implement a watchdog mechanism whereby if a special IO port wasn’t written to for a certain number of ticks, say every five seconds, a system reset would be generated. Thus a system crash would be recovered.

Since /RESET handling is a critical system action, I decided to prototype this new idea. Thus here is a picture of probably the worst bit of hacking I have so far done:

Despite appearances the actual key events are not routed to the MPU via the DUART. All of these parts are just for prototyping the system reset action! I’m perhaps naively assuming that this part of the computer won’t pose any problems.

The reset generator has once again been removed from the old CPLD SBC board, and /RESET is generated from the FPGA breadboard. This signal is also routed to the AVR keyboard controller which also generates the keyboard request signal when a random key (I used the Help key, just for fun) is pressed.

1. At power up /RESET is pulled low by a resistor
2. After FPGA config /RESET goes high
3. FPGA, keyboard controller and MPU are now running
4. Help key pressed
5. /KBDREQ lowered by AVR code
6. FPGA lowers /RESET
7. Clock ticks pass
8. FPGA raises /RESET

Amazingly, and despite the 30cm or more runs of multiple wires, this all worked first time.

This should be the last of the prototyping for the MAXI09.

• The multiple rendering modes is odd. The OpenGL mode has push routing abilities, which I’ve yet to properly explore. These aren’t available in the “normal” rendering mode, for some reason.
• In normal rendering mode, multiple select is not possible except by drawing a box. This is strange, but surprisingly only a small problem.
• I would still love the ability to easily “squash” empty board space, which comes apparent only after routing traces, but this can be worked around by rerouting and reworking, at least if the problem of empty space is noticed quickly enough.

Push routing does look amazingly useful, as this video shows, and is surely something I will need on my first SMT board. But for this through hole board the same basic feature sizes, only slightly reduced from the last SBC board made with gEDA, have sufficed: 8 mil signal traces, 12 mil via holes and 8 mil clearances. Everything is, almost exclusively, laid out on a 25 mil grid. The slightly smaller trace and via dimensions have permitted some more flexible via placements then before, which has proven useful because the MAXI09 board contains A LOT more components and thus lots more vias.

At the bottom left is the analogue power plane. It’s irregular shape catches the transistor RGB amplifiers, the OPL2 sound amplifier, and the analogue power pins on the V9958. The final board dimensions are 264mm x 194mm which is only a little bigger then I hoped at the outset of the MAXI09 project. It’s still enormous though, and only a few cm from an A4 page.

Whilst I am quite sure that my board could have been routed with gEDA, it would have definitely taken a lot longer and I doubt the result would have been quite as good. The MAXI09 board is easily the most complex I have ever designed; it has at least twice the parts, and connections, as the previous board and is of course my first 4 layer board.

One of the other nice, though probably not particularly useful, features of KiCAD’s PCB layout program is the ability to present a 3D view of the board. In theory this can help with determining if a part will physically fit where it’s been placed, but mostly I think it’s there just because it looks really cool.

As you can see, a number of components don’t have a 3D model. This is because I can’t find them online and don’t yet know how to make them myself, something I plan to fix when I get a chance.

Incidentally, whilst KiCAD ships with a good number of models many, including the lovely looking DIP ICs sitting in their sockets, were downloaded from this website. I have to thank Walter for his enormous efforts in making these KiCAD models.