Tuesday, 29 December 2015

MAXI09 initial bring up

After a wait of only about a week and a half, I have now received five MAXI09 PCBs from Botech. Here they are in the wallet:

I was surprised at how much they all weigh! And the bottom:

As you can see, they look great. Especially noticeable is the silk screen which is beautifully crisp and clear.

After doing some basic continuity checks, the first step was to attach the power related parts. 

Unfortunately the SR10S05 (PDF) regulator refused to play, and I measured exactly same voltage at the output side as the input side. This was a bit of a puzzle until I looked again at the datasheet and realised that the footprint was backwards. The regulator was one of the few parts of the computer which I didn't prototype. Had I done so this mistake would have been spotted. In any case, it was a trivial job to re-solder the part around the correct way, upon doing so a healthy 5V was observed at the Vcc points. So the only damage from that error was the fact that the silk screen didn't match the installed part.

Next I soldered the configuration flash, JTAG header and FPGAs; the point being to verify that the JTAG chain was intact and that I could program the EPC2 configuration flash with the board powered up. After fixing an error, I inadvertently soldered a PLCC socket in the wrong orientation, I received an error about an unreliable connection in the JTAG chain. This turned out to be caused by a faulty EPC2 configuration flash. Swapping it out for a known good one removed the error and I was able to program the configuration flash. So far so good.

At this point the VHDL for MuDdy and DISCo was, and still is, very minimal; just very basic glue logic. DISCo has a single register for turning on and off the attached LED. To keep things as simple as possible the value cannot be read back by the MPU, yet.

The next step was to attach the CPU, oscillator can, and memory. I hacked together a 4 pin socket for the 8Mhz oscillator can by pulling half the contacts from a 8 pin DIP socket. It seems to work quite well.

Next, the first grand switch on: would the LED flash? No chance. The first obvious issue was with the BA and BS LEDs. They were flashing randomly, indicating that the MPU wasn't owning the busses properly. It was clear that something was very wrong. Next I attached my logic analyser to the E clock pin. Nothing. Things weren't looking good at all.

After a few days, and relaxing over Christmas, I had a closer look at the problem. The first job was to figure out what was wrong with the E clock. I decided that, better late then never, I would prototype using a can oscillator with a 6809. All my previous computers had used a resonator, and though the datasheet clearly stated that the EXTAL and XTAL pins could be fed a TTL clock signal, I had not seen it done before. So I breadboarded the minimal parts: MPU, oscillator can and some wires.

Initially I had the same problem, wether I used a can oscillator or a crystal: no E clock. After a little while I realised that the E clock was in fact running, but only for a few hundred milliseconds after applying power to the breadboard. This was encouraging in some ways, confusing in others. As it turned out the breadboard had a problem the MAXI09 had, some missing connections.

It seems that in the switch to KiCAD I managed to forget to connect two vital pins, /DMAREQ and MRDY to Vcc. Therefore these inputs were floating, and hence the MPU was not properly owning the busses, since this is exactly what these two pins are used for: bus mastering control. Unfortunately the only solution to this problem was to attach some jumper wires from a convenient Vcc point (I chose the power pin on the 6809 itself since it was near) to the requisite pins.

After this, and fixing some problems with the MuDdy VHDL: success, a blinking LED! In the end I went back to how I bought up the first 6809 computer on breadboard. First I drove the LED using only code in the EEPROM, then I made things more interesting by using RAM to hold a delay value, and changed this delay through the run of the program. It was a big relief to see this work, since at one point I thought MAXI09 was dead on arrival.

The next step was the UART, or rather QUART, in the form of the SC16C654 (PDF). This, too, was never prototyped. As it turns out this part is quite different from the XR88C681 (PDF) used on my previous board. One of the differences is that the QUART has two bus modes: one for Intel (called 16 in the datasheet) and one for Motorola (called 68). The bus mode is hard configured through a pin. Low for 68 and high for 16.  I naturally chose 68 mode; I'm using a Motorola 6809 after all. Also in 68 mode there is only one interrupt and chip select line. They are shared across all four UARTs. In Intel mode there is one select and interrupt per port. This would have required many more precious FPGA pins.

However, there was a vital extra difference in the form of bus timings. I hadn't paid enough attention to the fact that the 68 mode is actually for 68000 MPUs not 680x MPUs. There is a vital difference between the two. In the 68000, the chip selects are always asserted after read/write. In the 8 bit Motorola parts it is the other way around. So in summary, the UART didn't work, at least initially. After struggling with the problem for a little while I came up with a fairly simple fix by delaying the QUART's chip select to a point after the R/W signal is asserted. There were probably multiple ways to do this, but the way I went for was to only select the QUART when the MPU's Q clock was high. Q goes high about a quarter of a machine cycle later then the QUART's address appears on the address bus. See page 3 of the 6809 datasheet for more info on the machine 6809's machine cycle.

After this small change to MuDdy's VHDL I was finally able to communicate with MAXI09. This was a big milestone. Using the old monitor which I wrote a few years ago I will be able to test out the peripheral ICs on the MAXI09 board, as well as use it to test out things like the DMA controller and MMU, when they are eventually implemented.

I'm now in the process of soldering up the peripheral ICs and testing each one with the monitor. So far I have attached the 6522 (PDF) VIA, and one of the joystick ports, and I'm happy to report that both appear to be working fine.

Here's a picture of the board as it currently stands:

There's obviously quite a bit more to do, construction wise, before I start on the implementations for things like the MMU, DMAC, disk interface, and SPI controller.

While the MAXI09 board is not, of course, fully made up yet I thought it would be interesting to list a few of the things I would improve upon, and list the mistakes I've thus far found:

  • Obviously the previously mentioned problems with the /DMAREQ and MRDY pins and the switching regulator.
  • The keyboard flex connector is not quite central, horizontally, on the board. This means that the keyboard will not be centred across the board, at least not without folding the flex cable.
  • If I had more time I would have done more to reduce the size of the board. There is quite a bit of "dead space", particularly around the bottom left section, and this could be "squashed out". It would not be a massive saving, perhaps 500-700mils, for a large amount of work though.
  • There are not enough screw holes in the board. The board is quite large and so flexes fairly easily. More evenly spaced holes, and perhaps a screw hole in the centre of the board, would remedy this.
  • I hadn't appreciated at the time that whilst all the ICs in a horizontal or vertical direction are orientated in the same way (generally a good idea in PCB layout) the horizontal ones are, nonetheless, all upside down. It's not a big problem, and no doubt the orientation makes for a better layout of the traces, it's just not very aesthetically pleasing seeing all those IC markings upside down.
Anyway, I'm very pleased with how MAXI09 has worked out so far. Time will tell wether all the peripherals, like the OPL2 and the V9958, will function correctly. But I'm hopefully they will, so that I can get on with the really interesting parts, the DMAC and MMU implementations...

Wednesday, 9 December 2015

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...

Friday, 23 October 2015

Prototyping and tweaks to the MAXI09

I have been busy the last few weeks prototyping up the remaining untested parts of MAXI09.

The first thing I wanted to do was to confirm the functioning of the AD8013 (PDF) video amplifiers. This did not go well at all. After attaching one to a SOIC-14 breakout adapter and plugging it into the circuit on the breadboard, I was unable to get a picture on the TV. Unfortunately I still do not own an oscilloscope so have no way to track this problem down. Also analogue electronics remains mostly a mystery to me, so it was very difficult for me to figure out the issue.

I have had success from a transistor-based amplifier circuit however. My circuit is shamelessly borrowed from the MSX-2 and was supplied by lordbubsy of the 6502.org forums. Whilst the picture is not a great deal better then the, already good enough, picture obtained by directly attaching the VDC to the SCART pins as used in the previous IO board incarnation, having an amplifier stage isolates the television from the IC.

But, unfortunately, I have given up with getting a decent picture from the AD724 (PDF) composite video generator IC so will omit that section. No matter what I try I cannot get a stable picture. This is a bit of a blow as it means that it will not be possible to hook up the MAXI09 to a TV capture card, since all those that I have found have only composite or S-Video input. But it will at least save some board space on what, I suspect, will turn out to be a very large PCB.

Here is the updated schematic of the video section:
After pondering my IDE plans some more, I have come to the conclusion that I can achieve what I want, to present a 16 bit IDE drive "transparently" as an 8 bit peripheral, a lot simpler then I initially thought. I do not need to completely isolate the IDE drive from the MPU busses. Only the high byte half of the IDE databus and the Chip Select lines need be attached to DISCo. The rest of the pins can be attached directly to the MPU, as per the CPLD-based board. To read the 16 bits of IDE data from the 8 bit databus the following steps will be required:
  1. On system reset a 1 bit flag, within DISCo, is cleared.
  2. If the flag bit is clear, this is an odd numbered read. On this read to the drives address in DISCo's address range, select the IDE device by asserting the IDE Chip Selects.
  3. The IDE drive is thus active on the bus so it's low byte, will be returned to the MPU.
  4. At the same time store the high byte, which the IDE device also put out, in a temporary register in DISCo.
  5. Toggle the flag bit.
  6. If the flag bit is set this is an even numbered read. On this read, to the same address, DISCo will this time not assert the IDE Chip Selects and will instead put out the high byte, as stored in the temporary register over the databus.
  7. Toggle the flag bit again.
The process will be similar for writes, but reversed.

I believe the above should work. It's much simpler then my original plan of implementing a proper IDE host controller. One additional consideration is that bytes will have to be swapped by either the CPU, or the DMA controller, when writing. This will complicate the DMA controller implementation a little.

Here is the updated FPGA section:
A further advantage in this approach is that it frees up a large number of pins on DISCo. So many pins in fact that I can dispense with a dedicated SPI controller and instead move the SPI bus controller to DISCo. This also frees up more board space. It does mean, though, that I will have to implement an SPI bus controller myself, or perhaps adapt an existing one.

Here is the updated, and vastly simplified, SPI schematic section:
There's another, relatively minor, change here. The RTC is now a DS1305 (PDF), previously used two years ago now when I was first learning about SPI, instead of a DS3234. The reason for this change is cosmetic: the old RTC was the only SMT part in the whole computer, now that the composite and S-Video IC, and related parts, have been removed. Whilst the DS1305 requires an external crystal, and lacks a temperature sensor, it is at least a through-hole part like every other IC in the computer.

In a further effort to save board space I have decided to forgo the dedicated analogue joystick port and have combined the digital and analog inputs onto the 9 pin port usually used only for digital joysticks. A standard, four direction and one fire button joystick requires six pins. This leaves three pins free: one for the 5V side of the potentiometers, and two for the X and Y axis inputs. In theory I could build a combined five digital inputs and two axis analogue joystick, but to keep it simple I will continue to use the five input Cruiser joystick, and will make a separate two axis, one fire button, analog joystick.

After making the decision to cut down the number of digital joystick inputs by eliminating the analog joystick's fire buttons, the presence of a dedicated VIA for dealing only with ten joystick inputs started to look a bit strange. The 6522 VIA (PDF) is a complex part and relatively expensive (bought new or not) and its use simply as a joystick interface would not be good engineering. So instead the new joystick interface uses two octal D-Type latches, with tri-stating outputs, in the form of two 74HC574 (PDF). Actually the simplest solution of all would have been to use two sets of 5 pins on the DISCo FPGA but that would probably not be the best use of that resource.

Here is the updated digital IO action:

The two joystick Chip Selects (/JOY1 and /JOY2) are generated by MuDdy and are normal Selects but are gated with /READ. This unfortunately adds another pin to MuDdy (two joystick selects instead of a single VIA select), but on the other hand a pin is saved on DISCo since there will be one less interrupt line.

Finally it was time to prototype the YM3812, AKA the OPL2. Fortunately everything worked first time. I breadboarded up the circuit and managed to get a tone after programming the registers following a guide I found. The MAXI09 circuit uses a 14.318 MHz crystal oscillator can whose output will be divided down by a counter in DISCo. For completeness I have replicated this circuit but using an 8 bit counter (74HC590 (PDF)) to divide it down by four to generate the 3.574MHz NTSC colour burst frequency.

Here's a photo of the breadboard rig, showing the YM3812 section and a mock up of the joystick section consisting of some 8 way DIP switches substituting for joysticks:

Also I have received an Amiga 600 from an eBay auction I won. It was sold for spares but appears to be in a reasonable condition. Certainly the bit I care about most, the keyboard, appears to be fine. I just need to find out what connector the ribbon flex cable requires so I can prototype up a modified keyboard controller. Unfortunately, it seems the prototyping isn't quite over yet, but at least it looks like MAXI09 will have a lovely keyboard.

But because I'm so keen to get started, I'm also now in the process of laying out the PCB. It's going to be an interesting challenge, since I will be learning KiCAD's PCB tool as I go...

Thursday, 24 September 2015

Switching to KiCAD and the MAXI09 schematic

Pretty much since I first started using it, about two years ago now, I have been struggling to "like" gEDA.

To be fair, it has many positives. The schematic capture tool is not terrible to use. It is certainly quirky. The totally non standard keyboard shortcuts being just one example of this quirkiness. But it has, in my view, significant problems. In particular, making custom symbols is very laborious. Using named nets, instead of having a dedicated "linkage symbol" is painful. Multi page schematics are possible but strange to work with.

But the worst part of the suite (ignoring simulation and other things I've not touched) is PCB design. The gEDA pcb program traces its routes back to 1990 when it was first written to run on the Atari ST. It's impressive that this code base has been extended and kept alive for a quarter of a century, but it shows. Problems I've had with this software are too numerous to mention, but the main one is that multi-segmented traces are not linked together, they are simply a chain of traces that happen to start and end at overlapping points ie. you cannot simply drag a point about. This essentially doubles the effort to move traces. There are other problems, but the point is I've finally decided to take the plunge and switch ECAD tools away from gEDA.

There are basically two choices - at least if your not spending any money: Eagle and KiCAD.

Eagle is proprietary software, but zero cost provided your boards are not greater then 10 by 8 cm. Also it only supports 2 layer boards with the free version. To overcome these restrictions you need to pay for the software, even for non commercial use. So the free version is basically not suitable for making up the MAXI09 board for both of these reasons.

So my next choice was KiCAD.

KiCAD is GPL software. It's not been around for as long as gEDA, but it has some serious backers, including CERN, and has made rapid progress in just a few years. It should be noted that it is not a true ECAD suite, since it lacks simulation and other tools. It is squarely aimed at people producing their own boards layouts.

The biggest obstacle to switching ECAD suite is the fairly large array of custom schematic symbols, and to a lesser extent PCB footprints, that I've built up over the years of using gEDA. Because I'm working mostly with obsolete, or at least uncommon, parts I've had to make up these symbols and footprints myself. Also, as I've discovered, gEDA is actually blessed with many more exotic symbols then most other suites. Therefore switching tools presented a big challenge because not only has new software got to be learned but all my custom parts remade.

Fortunately I had some help, in the form of lenzjo on the 6502.org forum. He graciously made up nearly all of my custom symbols for me, which was a great starting point for performing the switch since the biggest obstacle was taken care of for me.

So far I'm not quite at a position to say I'm in love with KiCAD, but its certainly a big improvement on gEDA. I've only really looked at the schematic capture portion, but just some of the reasons why I prefer KiCAD are:
  • Repeat last command. This is my favourite feature of KiCAD. Drawing busses is a breeze when the last command can be repeated and iterated such that a wire can be drawn again but shifted down the page, or a label added again but the next the one in a sequence such as D0, D1, D2 etc.
  • A label symbol which combines a net label with a tag, which indicates signal direction. This is much easier to use then having named nets with a basically pointless label symbol.
  • An Electric Rule Check (ERC) which acts like a Design Rule Check but on a schematic level. Since symbol pins, and label symbols, have direction properties it is possible to check for unconnected inputs and multiple outputs connected together, and other errors. While it, of course, can't be used to prove that the circuit will work, it should at least show up many common error types, as well as net link typos, before the design goes to the PCB stage.

Generally the schematics made feel more complete, since the ERC forces you to set the pin types on symbols and the mode on wire links.

There are, naturally, some things I don't like about it:
  • The OS X build is generally the least reliable and the least tested of the three OSs that KiCAD supports. Frequent crashes and redraw problems are the main issues. Consequently I'm running KiCAD inside the same VirtualBox Windows instance as I do my Altera PLD work in. A minor inconvenience.
  • You can't just drag symbols about with the mouse. Instead you have to mouse over them and enter a Move or Grab mode with the keyboard. Move takes only the component whereas Grab moves attached wires as well. It kind of makes sense, but I don't know why it doesn't enter Grab mode with a single click.
  • There is no write image function. This was great for making the images for this blog. Instead I will have to jump through hoops exporting a SVG file, and then converting that to PNG.
  • Multi page schematic support assumes you want to create a hirechecal design structure. This is great for some cases, eg. an audio amplifier consisting of discrete modules (PSU, preamp, power amp) parts. But it makes almost no sense for a project like the MAXI09 which needs common bus signals across all "sections". Whilst there is a workaround to this limitation, it is fairly horrible. My "solution" to this problem is to use a single large page for the entire computer's schematic.

Anyway, I'm very pleased with the switch. The other good news is that the MAXI09 schematic is very nearly complete.

The design is pretty much as I've previously described, save for the sound output and some other details. I settled on a YM3812 (PDF) (AKA OPL2) in the end. Parts have been ordered, and I'm waiting to receive them so I can prototype before finalising that part of the circuit. I still plan to look at incorporating a DAC in my computer, but will do so with an expansion board. The OPL2 was a popular FM synthesizer in its day, being used on early Adlib and SoundBlaster PC sound cards and other places. Whilst I could easily have used the AY sound IC again, I wanted something new to learn and play with.

One other "system wide" change is that the JTAG chain will span the Altera configuration flash, the two Altera FPGAs, and the Xilnx XC9572 65SPI/B. This is possible because, at least in theory, the programming software from one vendor is supposed to ignore the devices on a chain from other vendors. I intend to prove this in practice with my breadboard rig, including a XC9572, and will verify that both manufacturers parts can be programmed from the correct manufacturers' software. Whilst being able to program the CPLD in circuit isn't that useful - the design of the SPI interface isn't one I intend d to change - this is how JTAG chains are supposed to be constructed, and it could still be useful.

Each of these schematic sections is still in draft form but, short of problems encountered prototyping the few remaining parts, it will be the final design that I will layout the PCB against.

First up is the CPU and memory section. No real surprises here, it is mostly identical to previous designs. A jumper has been added to the /WRITE line on the EEPROM. After the problems I had with corruption occurring whilst the CPLD was being programmed on the previous board, I have added a jumper so that in the EEPROM can't be modified unless the jumper is in the "write enabled" position.

Also note the PAn and VAn signals. VA is the "virtual" page address, generated by the top four bits of address from the MPU, and PA is the "physical" address generated by the MMU inside MuDdy.

Though BA and BS are now captured signals, which are attached to the DMAC inside MuDdy, I have retained the LEDs driven from these signals. They make nice indicators for showing system health (for example, stuck interrupts) and could even be useful for indicating, in a very crude way, how much DMA activity there is in the system.

Also note that the MPU clock is now generated by a can oscillator can instead of a crystal resonator. This has been done mainly to save board space; the AVR keyboard controller uses the same 8MHz clock signal. But it should also, in theory, provide a more reliable clock. The oscillator will be socketted so I can try alternative ratings. This will allow me to experiment with using a 12MHz 6309, for instance.

Next up is the FPGA (and IDE) section. No real surprises here, except that the wire linkage symbols make the schematic much clearer now that they show signal direction. Also note the resistor arrays used to pull up the FPGA generated signals, as described in the previous post. 4.7k is the value I've settled on.  It seems there are few rules about the value. Too high and the maximum useable transition frequently will be impaired. Too low and the current drawn when the signal is a logical zero is too great. 4.7k seems to be a reasonable compromise between those two.

Note that back annotations, produced when the PCB is laid out, might mean that the pin assignments at the two FPGAs change.

The next section is the QUART portion. No surprises here at all. It is almost identical to the one presented previously, except that the wiring for the RS232 on RJ45 has been settled. After beeping out the serial cable I had in my parts drawer, I determined that it used the Cisco "standard" pin out. I have therefore copied that for my micro.

Next up is the keyboard microcontroller. Note that the RGB LED is now shown on the schematic as a four way header since this is what will appear on the PCB.

One thing I am still considering here is an alternative keyboard. Whilst the C64 has a nice keyboard, a few things bug me about it:
  • It has no proper cursor keys.
  • The caps lock key is a simple latched button.
  • It's just never felt that nice to type on.

One keyboard that would be great to use instead is the Amiga 600 keyboard:

As a previous user of Amigas, and one of its biggest fans, this would be a great keyboard to use. Its nice and compact, but mostly complete by modern standards, save for the missing numeric keypad. It has a full array of function keys and modifiers. Like the A1200, but unlike the A500, the A600 has an onboard keyboard controller. Thus the actual keyboard component is a key matrix with a 30 pin flex cable. The ATMega8515 (PDF) has just enough free IO pins to be directly attached to the key matrix.

I have yet to make a final decision as to which keyboard I will go with. One thing that may keep me on the C64 keyboard is the simple fact that I have all the parts already. Sourcing the A600 keyboard would not be that cheap. But we shall see.

A signal, /KBDREQ, has been added as an output from the keyboard controller. This will replace the NMI button signal, which was originally going to be routed to DISCo. The intention here is to make the NMI signal generate-able from the keyboard itself, via a "magic" keyboard sequence like Shift with Escape or similar.

Next, the SPI section. As you can see, the 65SPI/B is used to connect up two two way analogue to digital converters, MCP3002 (PDF), used for the two analogue joystick ports. It also has the RTC, a DS3234 (PDF) as used previously, attached. The IRQ line from the RTC is cascaded through the SPI controller. The final SPI channel is attached to an EEPROM, a CAT25256 (PDF). This will be used for storing system configuration settings.

MAXI09 will include two VIAs. One will be attached to the digital signals on all four joysticks, and one will be attached to both a standard 25 pin parallel port and a dual 8 bit IO header. I don't currently own a printer that I could connect to the parallel port, but hopefully this will change. The IO header will be used for hooking the board to breadboards etc. Obviously the parallel printer port and the header won't be useable at the same time.

Next, video. The digital portion of this is identical to what appeared on the IO board. The analogue part is more interesting. The AD724 (PDF) is driven from the three way AD8013 video amp. I managed to find a combined S-Video and composite RCA PCB mountable socket. This should prove to be a space saver. Parts of this section have been prototyped: the AD724 part, without feeding amplifiers, was run up on breadboard. The result was a little disappointing but probably acceptable bearing in mind the fact the circuit was on breadboard. Here the un-amplified RGB signals was converted to composite:

Actually the quality was worse in real life compared to the picture, but partly this poor quality picture may be down to the use of breadboard, flying leads, and insufficient power supply conditioning. I am still waiting to recieve the amplifier ICs, after which I will breadboard up the entire analogue portion, including amplified RGB connected up to SCART.

The third to last portion of the schematic is the new YM3812. This is an interesting IC. The output is not an analogue signal, as per the GI AY sound IC used previously, but a serial digital audio stream. A second IC, specialised to the purpose of producing a useful analogue output is required. This is essentially a serial input DAC. Some op-amps complete this portion, and terminate the sound output at a jack socket. Unfortunately unlike the GI AY sound IC, sound output will be mono. Hopefully the parts for this section will arrive soon so I can prototype it up. Note that this sound IC is independently clocked. Whilst I could have used the MPU E clock, I wanted to use the same frequency as was used in PC sound cards, and the like. This was the NTSC colour burst at 3.579 MHz. Since it was pretty much impossible to obtain a can oscillator at this frequency, I have to settle with a 14.3 MHz can and divide it down by four using two pins (in and out) in DISCo.
Next is the expansion connector. There are two main differences to the 40 way expansion connector used previously. First of all, all signals originating at the MPU are buffered through some 74HC245 (PDF) bidirectional buffers. This is probably not essential, but since the drive abilities on NMOS parts are not as strong as on modern CMOS parts, it is a good idea, especially when signals cross between boards. The second change is the sheer number of pins, 60 in all, including extra Vcc and GND pins. The full physical address bus will be available on the connector, as will  most of the CPU control signals. In addition six signals generated by MuDdy, nominally chip selects, will also be present on the expansion connector. A further two pins are wired to the connector from DISCo. These will likely be IRQ lines, but again their purpose is not fixed by the schematic. The general idea with these connections is that, for simple expansion boards at least, no glue logic should be needed on the expansion board.

There are limits to what the expansion board could implement, however. For example it will not be possible to master the busses from the expansion. This is because of various reasons, including the fact that the address bus drivers are not bidirectional. None the less some pretty cool things should be possible.

The last section is the power rails and decoupling capacitors. KiCAD is a little interesting in the way it deals with power supplies. The MAXI09 has two power busses, one for digital parts (+5VD and GNDD) and one for analogue parts (+5VA and GNDA). Extra conditioning, in the form of a ferrite bead, is used for the analogue components.

The external power connector is a barrel plug as preciously mentioned. But a regulator will take the input 7V or so and convert it to 5V. Though initially I considered using a 7805, the inherent inefficiency of linear regulators led me to look at using an on PCB switch-mode solution. Initially I was going to go with a buck DCDC converter IC, which would have used a few passive parts such as an inductor. This solution is much more efficient then a linear regulator, but obviously requires more board space. Generally speaking these parts require manual tuning to set the required output potential. Then I found something even better: a complete 5V switching regulator circuit with a 7805 style footprint. They are even available rated up to an amp, for instance the SR10S05 (PDF).

The entire circuit, as an A1 sized PDF, is also available for download. Eventually I will also include the custom symbols and footprints in my github account.

I am now in the process of prototyping up the last remaining sections of the circuit. After which the exciting process of laying out the PCB can begin. I just hope it wont have to be too large..

Wednesday, 12 August 2015

MuDdy and DISCo progress, and system reset generation

I have finally solved the issue with holding multiple FPGA designs inside a single configuration flash. It seems there is a special tool just for the purpose of creating complex program files (.pof files). The details are buried in this document. So this is great news, though since I only have one PLCC84 adapter made up I won't be able to test the theory until I have the MAXI09 board in my hands.

Another mystery I've solved this past week is how to handle system resets. Since these FPGAs must receive their design from the flashes at start-up, it is not possible for the MPU to simply be bought out of reset by a reset generator, as was done when the glue logic was handled by a CPLD. If this was done there would be a race at start-up between the reset generator and the FPGA configuration process. If the reset generator took the MPU out of reset before the FPGA was programmed, the computer would not start because vital pins, like memory chip selects, would not yet be operating. Whilst it's likely that the FPGA would win this race and be programmed in time, it isn't good practice to leave any uncertainty in circuit design.

The solution I've come up with for this problem is to use the FPGA itself to generate a system reset signal and dispense with the old DS1813 (PDF) reset generator entirely. The FLEX 10K has two useful signals for this task:
  • CONF_DONE: This signal is principally used to control the configuration flash. It indicates, by going high, that the configuration step is complete, that is to say it has received the design from the flash. By itself this can't be used to generate a system reset because after the configuration phase, the FPGA must then initialise, which takes a few more microseconds.
  • INIT_DONE: This is an optional signal, meaning the same pin can also be used for IO, that indicates, by tristating, that the FPGA has entered the running phase and is now implementing the design. Because it is also an IO pin, and the FPGA receives the instruction for how to use the pin as part of the configuration data, this pin is, as all the IO pins are, tristated at start-up, before any configuration data has been received.
These two signals can be combined, by ANDing them, to form a useful /RESET signal, as the following screenshot from the logic analyser shows:

In this screenshot, the system was first powered up from cold, and then immediately after the MPU came out of reset, it was reset again by pressing the nCONFIG button (described below). Whilst it looks like CONF_DONE and INIT_DONE rise at the same time, zooming in shows CONF_DONE falls about half a uS seconds before INIT_DONE. The result of ANDing the two signals results in a signal that remains low until the point where initialisation is complete. To be fair, I suspect my 6809 is slow enough that simply using CONF_DONE as /RESET would do the trick. But I am trying to do a good job here, not just something that works.

One further consideration is how to reset the computer without cycling the power. Reading the FPGA documents once more shows a nice simple solution to this: shorting the nCONFIG pin to ground, and then letting the pin float high via its pullup, causes the programming process to be restarted. A simplified schematic of the programming lines, reset logic, and button is as follows:

In this diagram the JTAG chain has been omitted for clarity. I have jury-rigged this setup by performing some surgery on the existing CPLD board, removing the reset generator and tieing the /RESET line to a quad, two input AND gate 74HC08 (PDF). The inputs of this AND gate, at the top of the breadboards, is attached to the CONF_ and INIT_DONE signals. A button for nCONFIG completes the new reset handling:

It is difficult to see in the picture the red wire snaking it's way to the 6809 board is the /RESET signal. The nCONFIG push button is at the bottom left of the breadboard.

This seems to work very nicely, though I am slightly disappointed that I will need to use some discreet logic. Pressing the reset button causes the FPGA to obtain its configuration again, with the MPU resetting a few uS later. And of course the MPU is held in reset whilst the FPGA starts up at power-on too.

One additional bit of surgery was performed: the sliding switch which is used to halt the processor was removed and the /HALT pin connected to a pin on the FPGA. This is the pink wire leading to the 6809 board in the in the picture above. This allowed me to verify, at least somewhat, that my ideas for halting the MPU during DMA transfers were viable.

Since only a handful of the required signals were available to the FPGA I was not able to actually implemented a DMA controller. But borrowing the VHDL implemented for the time-limited buzzer output I was able to pause the processor for a variable amount of time by writing to the buzzer registers from the monitor. The previously internal signal, SOUNDPLAYING, was inverted and routed externally to the /HALT pin on the 6809. By watching the BA and BS LEDs I was able to verify that the processor was halted, and then un-halted. This does not fully confirm that the DMAC is certain to work, but it is a major source of encouragement.

The last major issue regarding use of an FPGA to perform glue logic functions relates to the fact that, at least with the FLEX 10K, all of the IO pins are tristated whilst the FPGA is being programmed. This a problem because these pins are used to drive pins like Chip Selects and Output Enables on the various memory and peripheral ICs. This leaves these pins to float for a brief time during start-up. This is a problem for two reasons.

The biggest problem is that if /CS and /OE pins float low, then the data busses on these ICs will be in the read state, which will cause the bus to come out of tristate and be driven. This could happen to multiple ICs at the same time, causing bus contention. Whilst the MPU is not running at this time, it's possible that the multiple busses being driven against each other will cause excessive current draw.

Likewise, whilst floating, a CMOS input's voltage level can sit between the high and low thresholds. A CMOS input shunts current from Vcc to ground at the moment of transition between high and low. On a square edge this is inconsequential. But an input sitting around the cross over window, which could happen with a floating input, can also cause excessive current.

The solution in both cases is to connect these FPGA outputs to a pullup resistor. That way when the FPGA has tristated the output pin during start-up the memory Output Enable (or other) will see a voltage very close to Vcc, which for an /OE will force the memory IC off the data bus regardless of the other control pins.

After consulting the folks on the 6502 forum I have concluded that the problem of excessive current draw caused by inputs floating around the grey zone between high and low is less of a problem then I first feared. None the less, since some peripheral ICs do not have a read line generated from the FPGA (eg. the 6522, which uses the MPU's R/W line) I will put pull-ups on all the Chip Select lines. This is the only way to guarantee that these IC won't start to drive the data bus.

I have to say that these pull-ups are a little annoying, and the computer may well work without them. But none the less I would rather do things properly.

I'm now at a point where I can draw up a schematic for the FPGA section of the MAXI09:

This is still very much a draft since at a minimum I need to allocate component numbers to each part. Also, the pullups on the /CSn pins, and other critical pins have not yet been added. There will likely be other changes as well. There are a few differences to what I described previously.

Obviously the /RESET handling is different, since it is generated by the FPGAs control signals not as an output pin. I have also discovered that the SC16C654 QUART, in 68 mode, has an ordinary active low reset pin, which means an active high reset does not need to be generated. This puts me two pins up, and one pin down (for INIT_DONE) on the previous MuDdy allocation, giving me another Chip Select. DISCo makes use of the DEV_CLRn pin to implement a /RESET signal, which will clear all registered flip-flops to 0 when asserted

I have decided to use a DAC attached to the MPU bus, instead of it being attached to DISCo. In its place will be the buzzer output. I can still experiment with sound generation from an FPGA using an expansion board. This frees up 7 pins, allowing me to route /NMI as a regular interrupt, with a push button input pin as well. Since I need INIT_DONE from DISCo as well as MuDdy, this leaves me with four currently unused IO pins. Curiously this is just enough pins to hook up an SD card via SPI, such that I could implement a sort of SD card host controller (as opposed to a simple SPI bus interface which the 65SPI/B provides). This would require a great deal of logic resources though. Plus it leaves me with the feeling that SD cards are not very retro. We will see.

On the Configuration Flash IC two pullups are not required since I have found out that the EPC2 (PDF) can be configured to use it's own internal pullups.

I'm currently in the middle of making up the breadboard for the AD724 (PDF) (not 725, oops) RGB to composite converter. I also have yet to order the AD8013 video amplifier ICs. These will be needed soon so I can confirm the function of the analogue portion of the video output. After that, the only remaining task, schematic wise at least, is to settle on a DAC, and its audio amplifier.

Talking of things analogue, another thing I'm in the middle of is choosing which Digital Storage Osciliscope to purchase. So much choice, not made any easier by me not knowing what it is I really need..

Thursday, 30 July 2015

Fleshing out the MAXI09

My last post was full of text, and therefore not very approachable. This post will hopefully explain some of my thoughts in a clearer way, with the diagrams and schematics (hopefully) doing most of the talking.

First up here is the current, work in progress, system overview:

(I tried looking for some nice online tools for making these kinds of diagrams, but in the end settled with using the schematic capture program from the gEDA suite, the same one I use for my schematics. All the online tools I found sucked in one way or another.)

Common busses, notably the data bus, run around the edge.

The MuDdy FPGA is the system core, and glues the whole computer together. It generates the physical address (seen by the RAM and EEPROM) and the various chip selects, one for each device. Only key select lines are shown. Likewise most read and write lines are hidden in this diagram. This FPGA is also connected to the HALT line on the CPU, so it can stop it whilst performing DMA operations. MuDdy also receives bus status information from the CPU. A buzzer is also attached, and will be used, as before, principally to indicate boot progress and boot errors.

DISCo is pure peripheral, though it also has the job of routing interrupts. Again, only some interrupt lines are shown. DISCo is also connected to a DAC, and through the DAC to a 3.5mm mono jack. It is also connected to the IDE header.

Moving along, the SPI controller is the 65SPI/B, a variant on the regular 65SPI used previously. It has some advantages, the main one (for me) is that it can route interrupts. This means the DS3234 (PDF) interrupt output, very useful for generating a precise system tick, does not need to be attached to MuDdy, and instead the 65SPI/B can pick up the interrupt and forward it along by generating an interrupt on its own interrupt line. In addition to this, it can also generate its own interrupts at the end of a transferred byte, etc. Also attached to the SPI master is an ADC. This is used for a new addition to the MAXI09 plan: an analogue joystick. Writing pong should be reasonably easy, and is much nicer to play with an analogue joystick.

As a side project I will build my own joystick out of an old X Box controller stick and some push buttons. It won't be pretty but it should work well. It will connect to the computer using a six pin mini-DIN. This is the same connector as a PS/2 keyboard or mouse, and has the advantage over a DB9 because it is smaller, saving precious board space.

A VIA will be used for a single 9 pin Atari joystick port. It will handle the six digital joystick inputs, plus two buttons from the analogue joystick. The other half of the VIA will be useable for general IO, but won't be bought out into an external connector.

Video will be provided by a V9958, equipped with 128+64KB of RAM. Unlike the old IO board, RGB video will be amplified by an AD8073 (PDF) IC, which should provide a better quality picture. Composite and S-VIDEO will be provided by appropriate connectors, driven from an AD724 (PDF).

The keyboard and controller will be similar to the one used previously, expect it will be attached to a UART channel instead of a VIA port. This will allow bidirectional communications between the MPU and the keyboard controller, allowing things like key repeat rate to be set. The keyboard MCU will also have an RGB LED attached, that will be used to show keyboard and system health. For instance, if the MPU does not acknowledge scan code bytes in a reasonable time, it will enter an error mode and flash the LED. For fun, it will be possible to change the colour of the LED from the MPU. This LED will be attached using a flying lead and a header, such that it will be visible outside the computer's case, when one is eventually made. In this way it will double up as the systems power indicator.

Below is a draft schematic for the keyboard controller portion:

I have chosen to continue using the PLCC44 version of the ATMega8 on the MAXI09, even though a version in DIP28 has just enough IO pins now that the UART is used instead of a full 8 bit port with handshake lines to talk to the MPU. But I have chosen to stick with the PLCC44 footprint with four 8 bit ports since it will be easier to program as it won't require port accesses to be spliced together when scanning the keyboard.

This takes us on to the UART. Or rather QUART, since this computer will have four UART channels. Perhaps it is excessive, but they could all be used one day. As mentioned, one will be used for the keyboard. A further two will be presented at EIA-232 signal levels, but to save board space RJ45 connectors will be used instead of DB9s. Unlike in the previous board hardware handshaking lines, RTS and CTS will be available. An eight line driver, in the form of the MAX238 (PDF), will be used as a level shifter for the two externally presented UART channels. The final channel will be headered out on a simple 3 pin header and will be useable via a USB FTDI lead.

Here is the preliminary schematic for the UART section:

The QUART used is a Philips/NXP SC16C654 (PDF) in PLCC68. I have not used this part before but it appears fairly similar the the XR88C681 (PDF), used in my previous micro. Slightly irritatingly, this UART does not have a timer. Therefore the main system timer will have to come from another source. Luckily there are still several others to choose from.

The main reason this schematic is a draft is because I have not figured out which pinout to use for the RJ45s. Unlike with DB9s, there is no standard pinout. Each equipment vendor (Cisco, etc) have their own standards. Therefore I will base the pinout on the RJ45 to DB9 leads I already have access to, but I have yet to determine the pinout they use. (I do appreciate that I am using the wrong terms here. The DB9 used on serial ports is correctly referred to as the DE9; the RJ45 used on Ethernet (and some serial console ports) is actually an 8P8C connector. I choose to use the terms that most people know these things as, even if they are wrong.)

This pretty much finishes up the current thinking behind the hardware. There's a few details related to the PCB which I have also decided.

As I mentioned in my previous post it will be a four layer board. Vcc and ground will be on internal layers, with the outer layers used for signals. This should hopefully simplify the laying out process, at the expense of a more costly board. Power will be presented on a 5V barrel connector instead of my usual USB-B socket. This will mean an ordinary wall-wart type PSU could be used. Alternatively, USB-A to barrel leads are available. The one disadvantage with this idea is that it's possible someone might plug a higher Voltage barrel plug into the computer by accident, blowing up components. This generally wouldn't happen with a USB socket since all USB devices are rated at 5V. This makes it a bit of dilemma, but I think the advantages of a barrel connector outweigh the disadvantages.

I have yet to figure out how, precisely, to utilise a single configuration flash to store the design for two FPGAs. The data sheets (PDF) explain how to wire up the parts to achieve this; what is not clear is how to construct the "program file" which needs to be loaded into the Flash such that it will then program multiple FPGAs at startup. This is quite frustrating, since I really don't want to use a configuration flash with each FPGA. If I cannot figure it out soon I will have to consult the experts on the Altera forums.

I have also yet to settle on a choice of DAC, nor am I entirely satisfied that I wouldn't be better off attaching one to the MPU buses instead of the DISCo FPGA. This would save at least 8 pins on DISCo and still let me play with 8 bit PCM via DMA. The only thing not possible would be wave table generation from the FPGA. A possible choice of device that can be attached to an MPU bus is the TLC7226 (PDF), a four output DAC with an MPU compatible write/select pin. One advantage of a multi output DAC is it would allow the computer to generate stereo sound. Of course this IC could also be used with DISCo, though more then 8 pins would be required.

I am slightly concerned that I am under using the generally rather useful 6522 VIA by relegating it to only being used for reading joysticks. The VIA can do much more, as my previous usage of it to interface to a keyboard controller shows. One idea that would be great to do, since it would add to the retro feel, is to add a parallel printer port to my computer. This would require a full VIA all to itself though. But I'm considering it. It would allow me to attach the computer to an old Centronics printer, which could be fun. It mostly comes down to the size of the PCB. At a minimum I will add a header for the unused half of the VIA, so at least it will be usable for breadboard-type experiments. Another idea is to include a second pair of analogue and digital joysticks. This would only require the addition of a second two channel ADC, using the other half of the VIA for the digital inputs for both joysticks, but of course more board space, especially for the DB9, would be needed.

My next task will be to prototype up the RGB to composite circuit. I will need to dust off the IO board with the V9958 for this. I already have a couple of AD725s (PDF), and some suitable SOIC breadboard adapters. I need to buy the amplifier ICs (AD8073 (PDF)) though, and will verify their function when I have them.

So, MAXI09 is coming along well, though that multiple FPGA mystery needs solving. Once the last few decisions have been made I will start to finalise the circuit before, at long last, I can start on the PCB design...