MAXI09 PCB ordered and yet more prototyping

      No Comments on MAXI09 PCB ordered and yet more prototyping

Two more bits of prototyping work have been completed recently.

The first is the keyboard controller portion. Since the MAXI09 now includes a new Amiga 600 keyboard, and because this keyboard has many more connections then the old C64 one, I have mocked up the controller on breadboard.

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.

The format of a scancode byte is naturally different to the one used for the C64 controller:
  • 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.

Prototyping first required a DIP adapter for the A600 keyboard’s 30 way flex cable. This turned out to be a nice trivial project for KiCAD and showed that it can be useful for home made PCBs as well as those professionally made. Here’s a picture of the little adapter board (well three of them on a single piece of copper clad) prior to drilling and soldering:

I was quite pleased with this little adapter board.

Here is a picture of the keyboard and controller in its prototyping state:
It’s a bit of a jungle, with the following parts squeezed onto one breadboard:
  • 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.

The sequence in my little mockup, then, is as follows:
  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.

For completeness here is a schematic of the updated FPGA section:

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

Also, for the last couple of weeks I have been working away at laying out the MAXI09 PCB. For the most part, laying boards out with KiCAD is miles ahead of gEDA pcb. There are a few negatives, but the continuous enforcement of the Design Rules more then makes up for them. This makes it impossible to route a track to the wrong pad, cross an existing track, or place a via too close to a track or pad. This is a far ahead of the “after the fact” DRC report from gEDA. Another of my favourite features is how the rats nest for a part is shown as it is dragged about. This makes it easy to place parts close to other related parts, in the initial stages of laying out a board. There are a couple of annoying behaviours, of course.
  • 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.

Here’s a picture of the signal and silkscreen layers:
Only the top and bottom signal traces are shown. The internal layers, used for ground and the two 5V Vcc (digital and analogue) rails are not very interesting so are hidden from the above picture. But, for completeness, here is the ground layer:
And the Vcc layers:

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.

Here’s a picture of the MAXI09 board, in glorious 3D:

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.

After a lengthy (re)check of both the schematic and the board and its footprints, it has now been ordered for manufacturer from Botech Circuits. Total cost for 5 boards is about £150, so obviously I really hope it works!While waiting for the board, I will crack on with working on the VHDL for the MuDdy and DISCo FPGAs. Initially I will write only the address decoder, and other core logic. The MMU and DMAC will come later…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.