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