A few weeks ago I designed a PCB for 68 Katy, and yesterday the boards arrived in the mail. While I had originally imagined the PCB version of 68 Katy would include all sorts of new and exciting features, what I designed was almost a straight copy of the breadboard version of 68 Katy. I knew I couldn’t keep that breadboard prototype intact forever, because sooner or later I’d need the breadboard for something else, or my cat would jump on the desk and knock something loose. The PCB became mainly a way to preserve the existing 68 Katy design in a more permanent form. The only significant change from the breadboard version was the replacement of the PAL and all the 7400 glue logic with a single Xilinx XC9572XL CPLD.

When the PCB arrived, I took one look at it and realized it wouldn’t work. Check out the rendered image above, and see if you can guess why. Hint: I forgot to include a component that wasn’t needed in the breadboard version, but is needed here.

This is a 5V design, intended to be powered by an externally regulated 5V supply. The CPLD that I selected has 5V tolerant I/O, but it needs a 3.3V supply voltage. So where’s the 3.3V power source? Oops, there isn’t one. I connected the CPLD supply pins to 5V, which will toast the chip.

I can add a 3.3V regulator to the board, and fix up the few traces that are affected, but I’m annoyed with myself for wasting three weeks and $40 to discover a problem I could have caught just by looking at my schematic. I wonder what other errors I made?

This PCB was made with KiCad, and it was my first time using that program to create a real board. Looking at the finished PCB, it appears that many of the footprints I used have what I’d consider to be abnormally small plated rings around the drill holes for through-hole components. They should still work, but it will be more difficult to hand-solder the components and get a good solder contact with the board, so I’ll probably resize all those too when I make the board revisions.

I wish there were more things I could test on this PCB, to help catch other hidden problems, but unfortunately it will be completely non-functional without a CPLD. I think my goof with the power supply for the CPLD is beyond anything I can fix with some cutting and jumper wires, since it needs a 3.3V supply, but there isn’t one anywhere on the board.

Stuffing new technology into old hardware is fun. How about a bootable, rewritable ROM disk for a Macintosh Plus, using modern flash memory? Dream no more, the reality is here. 🙂 Using a small adapter board, the original ROM chips on the Mac’s logic board are replaced with 1 MB of flash ROM. The flash ROM contains a modified copy of the original Apple ROM data plus a special disk driver, and a disk image occupies the remainder of the 1 MB of flash. When powered on, the Mac can be booted from the built-in ROM disk with a single key press. When necessary, the contents of the ROM disk image can be rewritten from within the running system, using a custom-made flash updater program. You can fill the ROM disk with system software and a couple of games, or whatever you want to show off without needing a disk. The same thing should be possible for the Mac 128K and Mac 512K too.

This project is a combination of three smaller projects, two of which were developed by other people.

 
1. ROM Adapter Board

Swapping the stock ROMs for larger 1 MB flash ROMs requires a physical adapter, because the flash ROMs have more pins and have some signal pins in different locations than the stock ROM chips. Rob Braun designed an adapter board that fits in the stock ROM sockets of a Mac Plus, and accepts modern (well, less ancient) 29F040B flash ROM chips. In order to take advantage of the entire 1 MB, two extra wires must be connected to address pins on the CPU. This can be done using IC test clips, or by soldering wires directly to pins on the 68000 CPU.

 
2. ROM Disk Driver

Apple provided the Macintosh Classic with a built-in ROM disk: hold Command-Option-X-O during startup, and the Classic will boot from the built-in disk image. Rob and Doug Brown studied how the Classic’s ROM disk driver works, and developed a stand-alone ROM disk driver for vintage Macintosh computers. Originally designed for custom ROMs in Mac II-series machines, Rob updated the ROM disk driver to work with the modified Mac Plus ROM as well. It even has a custom “pirate Mac” icon at the boot screen, to remind you that you’ve got a modified ROM installed. But the disk image is fixed in ROM – to change it, you need to open up the Mac and put the flash ROM chips in an external EPROM programmer.

 
3. Rewritable Flash ROM

In a discussion on the mac68k.info forum, I proposed connecting the CPU’s R/W pin to the flash ROMs, to make in-system reprogramming of the disk image possible. By coincidence, I had just finished my 68 Katy breadboard computer, which also used a 29F040B flash ROM and a 68000-family CPU. So I knew in-system modification of the flash ROM data was possible. Writing to a ROM is a strange concept, and with the 29F040B, it will ignore standard attempts at writing. That’s a good thing – you wouldn’t want a software bug to go modifying your ROM! But if you write a series of magic “unlock” bytes to a series of magic addresses in the ROM, it will enter a special command mode. From this mode, it’s possible to query the chip parameters, erase blocks of flash memory, and write new values to the flash.

To make this happen, I needed to write a flash updater program that could run on a vintage Mac. It’s not rocket science, but it had been 20 years since I last did any real classic Macintosh programming, so it took me a while to dig up Metrowerks Codewarrior and remember how to create a “hello world” type program. The resulting tool isn’t pretty, but it gets the job done, and now the contents of the ROM disk can be modified from within the running system, or even the ROM code itself can be modified.

 
Build

Want to build one of these? You’ll need soldering equipment, and an EPROM programmer to write the initial image to the flash chips.

PCB Gerber files for the adapter board – plusrom5
Flash Tool for in-system ROM updating – Flash Tool 1.1
Modified ROM image (concatenate your ROM disk image to this to make a bootable ROM disk) – modplus.bin

Firmware 0.7A-F14 improves write performance for HD20 emulation. With the old firmware, if you wrote a 1 MB file to the disk, it would do 2000 separate 512 byte writes to the SD card. SD cards really don’t like this! With the new firmware, the Emu hardware uses an internal 10K RAM buffer, and does 100 separate 10K writes to the SD card. Read behavior is unchanged, so read performance will be the same as before.

Combo Firmware 0.7A-F14

The performance gain vs the old firmware for HD20 writes depends on the model of Macintosh, and the size and type of SD card used. Faster Macs like the IIci will see more benefit than a Mac Plus, since I/O in the faster Macs is less constrained by CPU speed and more directly tied to the actual disk throughput. SD cards with a larger erase page size will also see more benefit from this new firmware. The erase page size is the native block size of the SD card, and typically is something like 4K. When performing a small 512 byte write, the SD card must read an entire 4K block from flash memory into an internal RAM buffer, erase the whole block of flash, update the 512 bytes of the buffer that are being modified, then write the whole 4K buffer back to flash memory. The larger the erase page size, the more inefficient this process is for small writes, and the more this new firmware will help. Unfortunately erase page sizes aren’t normally advertised, but larger SD cards usually have a larger erase page size than smaller cards. For this reason, the best Emu performance in both HD20 and floppy modes will typically be achieved with a small capacity SD card. Use a card of 2 GB or smaller if you can find one.

On a Mac IIsi with an 8 GB SD card, this new firmware provided a 40% improvement in HD20 write speeds in my testing. With a 2 GB card, the improvement was 8%, but it was still faster in absolute terms than the 8 GB card. Interestingly, the 2 GB card with old firmware had the same performance as the 8 GB card with new firmware, so erase page size really matters! On a Mac Plus with the 8 GB card, the new firmware resulted in about a 36% improvement in HD20 write speeds. With the 2 GB card there was no measurable write speed improvement on the Mac Plus. Bottom line: use a small capacity card in combination with this new firmware for the best HD20 write speeds.

Four and a half years ago, I wrote a mini-review of Eagle vs. KiCad, two of the most popular software tools for hobbyists creating custom circuit boards. I concluded that while KiCad had lots of promise, it was too full of quirks and bugs to recommend, and Eagle was the better choice for most people.

This week I had an opportunity to try KiCad again. Although nothing had fundamentally changed, I found that my overall impression of the program was much more favorable. KiCad still has lots of annoying issues, but frankly so does Eagle. And with 4 1/2 years more design experience, I can now appreciate how some of what I originally saw as flaws in KiCad were actually just different design decisions, whose value I can now appreciate.

 
The Software

If you’re not familiar with either of these tools, Eagle is a commercial program created by the German company CadSoft, and according to Wikipedia it’s been in continuous development since 1988. There are several versions of Eagle, but the majority of hobbyists use Eagle Light. This version is free (as in beer), but is limited to a maximum board area of 100 x 80 mm, and may only be used for non-commercial purposes. There’s also a separate non-profit license available, and an inexpensive commercial light license. Eagle is presently the “standard” for open source hardware and hobby projects found on the web, although this is changing.

KiCad is a free program (as in freedom, and beer), developed by a team of volunteers, and more recently with help from CERN. Wikipedia says KiCad has been around since 1992, although I only first heard of it a few years ago. While Eagle is a single monolithic program, KiCad is a loose collection of several different cooperating programs for schematic editing, board layout, and other tasks.

This is not a debate over free software. The nice folks at CadSoft are great for offering the very capable Eagle Light for free, and I have nothing against people charging money for software, since that’s how I’ve employed myself most of my life. 🙂 My interest is solely in which tool is better for the job.

I tested KiCad build 2014-10-27 and Eagle 6.3.0, both running on Windows 7. This is an older version of Eagle, which isn’t quite fair, but the test was more about how KiCad has changed since I last looked at it.

So which tool is better for hobbyists? I’m going to score them roughly even, but each has its strengths. Most open source hardware projects come with Eagle design files, so if you’re extending an existing project the choice may already be made for you. Eagle is also more scriptable, and may have an easier transition path to professional-level EDA software. But KiCad’s user interface is more intuitive, its board layout tool has some nice extra features, and it can create boards of any size. If forced to pick a favorite, I would say KiCad just edges ahead for the win.

 
KiCad Gripes

In my original review, my biggest complaint with KiCad was the way footprint selection was divorced from component selection. In Eagle you can place a 555 timer in your schematic, switch to the board view, and place it. In KiCad, you can place a 555 timer in your schematic, then you need to run another tool to select which footprint to associate with it. Only then can you place the chip on the board and route its connections. To a beginner this is a turn-off, feeling confusing and cumbersome. But once you’ve been around the block a few times, you’ll appreciate the flexibility this approach offers. This is one feature that grew on me after a while.

The earlier review complained about graphical “droppies” on the screen, and unfortunately this hasn’t gotten better. In the layout tool especially, virtually every time you do anything, you’ll be left with half-redrawn garbage on the screen, broken lines, or other visual artifacts. But as annoying as this problem is, I found I quickly developed the habit to refresh the view or change the zoom level after every operation, restoring the screen to normal.

Other problems from my original review seemed at least partially fixed: flawed footprints (didn’t notice any this time), random pieces of text in French or German (still happens), rat’s nest wire drawing problems (seems OK now).

KiCad doesn’t automatically add a board outline. This confused me before, and it confused me again this time. It’s just a minor gripe, though. By making me draw my own board outline, it may even force me to think harder about exactly what shape the board should be, or defer the board outline decisions until the main components have already been placed.

Creating new libraries of schematic symbols and footprints was pretty challenging to understand the first time, and I had to search out web tutorials. The process is just as bad with Eagle, though. Once I had my new library created in KiCad, the process of copying, modifying, and creating new symbols and footprints felt substantially easier than with Eagle.

Modifying tracks that have already been placed still seems cumbersome with KiCad. Once a board gets crowded, you often need to introduce extra little bends and angles in already-placed tracks, in order to make room for new tracks. KiCad can do this, but it seemed like 90% of the time it complained about “two collinear segments”, or just moved sections of track in a way other than what I wanted. I found I had to resort to deleting the track and routing it over again more often than I’d like.

One spot where KiCad still lags is the integration between its various sub-tools. With Eagle, changes made in the schematic are automatically reflected in the board layout, and vice versa. With KiCad you have to export a netlist file from the schematic editor, and import it to the board layout editor, every time you make a change.

 
KiCad Likes

The more I used it, the more I appreciated KiCad’s “Google Maps” board layout view, where high zoom levels show each track and pin labeled with a signal name like a street map. Very handy.

In the last review I complained about problems with the design rule checker, the tool that verifies clearance between tracks and neighboring tracks, pads, and vias. This time I had no trouble with the design rules, because they’re automatically enforced as you route the tracks. If a particular track placement would violate a design rule, it just won’t let you put the track there. If routing worked this way before, I don’t remember it. It’s a very nice feature.

I also griped about the autorouter last time. Since then, KiCad has added integration with FreeRouting, an external Java-based autorouter. There seems to be some legal dispute surrounding FreeRouting, and the web-based version of the tool that KiCad links to no longer exists. However, I was able to download a precompiled Window executable of FreeRouting, which worked fine with the file I exported from KiCad. It successfully routed what I thought was a difficult section of board in only a few seconds, and the result was easy to import back into KiCad. The result did have a few crazy tracks that spanned half the board, but if I’d been doing that part myself manually, I probably would have given up before I ever finished it.

 
Final Cut

The reality is that KiCad, Eagle, or any other circuit layout tool has a fairly steep learning curve, and you’ll have to invest many hours of time learning to use it effectively. With the current version of KiCad, I believe it’s worth that investment of time. Those who are already happy with Eagle will probably find little compelling reason to switch, but for new hobbyist engineers, KiCad certainly deserves a close look.

Firmware 0.6A-F14 now supports formatting the emulated HD20 disk from the Finder. This is handy for creating new hard disk images without the aid of programs like Mini vMac or Basilisk II. Just grab any random file of 100 MB or so (or create a new one using DD under Linux), name it HD20.dsk, and put it on the SD card. If you boot the Mac from another disk, it will see the HD20 disk image, but won’t recognize it as a valid Macintosh disk. The Finder will ask if you want to initialize the disk – answer yes. Be aware that formatting large disk images can take several minutes, during which there’s no on-screen feedback that anything is happening.

While working on this firmware, I encountered more mysterious errors and spontaneous reboots of the sort I described with firmware 0.5A-F14 on my original purple prototype board. But this time it was happening on another board. I rearranged some code, and the problems mysteriously went away, and even the balky purple prototype board started working fine again. I can’t explain what was causing those errors originally though, so maybe I fixed them, or maybe I just papered over them and there’s still a problem lurking somewhere. Please let me know if you experience any of these issues with this firmware 0.6A-F14:

• Emu consistently says there’s no SD card, when there is. Even after reboot, reset, reinsert card.
• Emu in floppy emulation mode says “no image files found”, even though there are disk images on the SD card
• Emu resets to the smiley face screen in the middle of disk I/O, as if you had pressed the reset button

Combo Firmware 0.6A-F14

Once again, if you try this firmware, I would appreciate feedback on what systems you tried it with and what the results were. Thanks!

Ta dah! I thought it couldn’t be done, but I used my hammer and tongs to smash HD20 emulation and floppy emulation into a single firmware version. No more re-flashing the board when you want to switch between emulation types; now you can make your choice from a config menu during start-up. Your default choice is saved in EEPROM, so you only need to access the config menu if you want to choose a different emulation mode than you did last time. Unfortunately this combo firmware was born on the grave of the self-testing logic, which is now gone. That means I can’t use this to replace the regular production firmware. Maybe I’ll look into using JTAG boundary scan for a future firmware update, and re-implement the self-test using that method instead of with CPLD logic.

This firmware is a major change from version 0.4. The code for both floppy and HD20 emulation underwent significant changes, and the CPLD logic was altered substantially too. That means there’s an excellent chance I broke stuff. If you see any strange behavior during floppy or HD20 emulation that wasn’t present with the previous firmware, please let me know.

The scariest and most perplexing issue with this new firmware is that it doesn’t work on my original purple Floppy Emu board, the very first one I ever built back in April 2012. With this firmware, the purple board experiences constant SD card errors, or even spontaneously reboots during disk I/O! The behavior is similar to what I found on the first production boards, before I discovered that they needed more capacitance on the output of their voltage regulators. The purple board lacks that capacitor, and also has a few other small differences from the production boards. So I’d be prepared to believe the problems are all due to the purple board’s hardware, except that it worked fine with every previous firmware version, including Sunday’s version 0.4A-F66. So… yeah. There’s that.

I’ve tested this new firmware in both floppy and HD20 modes, on a Mac 512K, Plus, and IIsi, with one of the current batch of production boards as well as the first (hand-soldered) production board with serial #0001. No problems anywhere.

• Merged the firmware, with a menu-selectable HD20 or floppy mode. Default choice is stored in EEPROM.
• Changed the default HD20 disk icon to a standard Apple hard drive icon.
• LED now blinks during HD20 disk activity.
• Fixed a bunch of little bugs.
• Disabled self-tests. 🙁

Combo Firmware 0.5A-F14

Notes on which Macintosh models you’ve confirmed to work with the latest firmware are always welcome.