Chris Stemple has finished the first custom build of a BMOW project by a reader, with a great-looking build of the Backcountry Logger Mini. Using some spare room on a panel from InternationalCircuits.com, Chris added and removed a few things from the original layout. His board features solder points for additional microcontroller pins, as well as a power switch and LED, while eliminating the external EEPROM chip. The build went smoothly except for some difficulty soldering the BMP085 sensor, which took the application of a heat gun to snap into place. Awesome work!

If you’re interesting in building a BMOW project, you’ll find all the design files and schematics on the summary page, listed under the Project Summaries header in the left margin.

Ugh, I’ve been going around in circles trying to settle on the best way to add a floppy disk replica to Plus Too. I’ve been thinking about this way too much, and now I’ve got visions of sync bytes dancing in my head. Here are the two main options:

Replacement Disk Driver

I could create a new disk driver that replaces the one in the Mac’s ROM. The great thing about this approach is that the driver API is very straightforward: it receives requests to read/write X bytes from offset Y on the disk. This could be almost trivially mapped to a disk image in a separate ROM or on a SD card, without ever having to worry about the IWM, disk heads, tracks, sectors, encodings, sync bytes, or anything else. A custom driver would also make it possible to have more disk drives, and larger disk sizes that don’t correspond to any real floppy disk.

The big drawback of this approach is that writing a custom device driver isn’t easy! Unfortunately it’s not as simple as just processing those read/write requests. The driver must correctly handle synchronous and asynchronous calls, hook into the interrupt manager, and handle all manner of control and status requests in the same way as the original Sony floppy driver.  I’ve spent a substantial amount of time digging through the internals of the Sony driver, and it’s pretty complicated. I don’t think I’m really up for the challenge of writing a new driver in 68000 assembly, using MPW. Even if I did get something that mostly worked, it’s likely the kind of thing that would have subtle bugs that would cause all kinds of hard-to-find problems.

A secondary concern is how to actually replace the original disk driver. I could modify the ROM image before programming it to the ROM chip, but that seems a little heavy-handed, and would make it more difficult to support a multi-Mac replica that handles more than one original ROM type. It would be nicer if the replacement driver were overlaid onto the Mac’s memory map without physically modifying the original ROM. But where would the replacement driver code be stored– in some other ROM? Or in internal memory of the FPGA? This could be solved, but it feels yucky.

IWM and Floppy Replication

The alternative approach is to use the original ROM floppy driver, and make hardware to replicate the behavior of the IWM and floppy drive. This was my original plan, and after a detour to examine the replacement driver idea, I think I’m going to return to this one. The big advtange of this approach is that success or failure will be binary: it won’t work at all, until it works 100%. That’s a lot more appealing than endless chasing bugs in a custom driver. This approach doesn’t require any ROM patching, and would also be a good foundation for later building the external floppy emulator for real Macs that I’ve been talking about.

This method does have several drawbacks. Replicating all the behaviors of the IWM and the floppy won’t be easy, especially the floppy behaviors. I’ve more or less mapped out everything I need to know to do it, but it’s still going to be a large task. This method also limits Plus Too to two* 800K disks, just like a real Mac Plus. I’m also concerned about implementing disk writes with this method: when the IWM starts spitting random bytes at the disk interface, it will take some processing to work backwards and figure out what sectors the Mac was actually trying to update.

Neither approach really seems great, and both would be a substantial amount of work. My gut tells me that IWM and floppy replication is a big task I can succeed at, whereas a replacement disk driver is a big task with a high potential to veer off into a ditch and fail, but maybe I’m overly pessimistic. Here’s hoping I can get at least one of these approaches to work!

* all three homonyms of “to”, consecutively in a sentence… English is crazy!

While I’ve been working on the Plus Too Macintosh replica,  I’ve also collected a few real vintage Macs in the past couple of weeks. Too many, in fact, so it’s getting hard to even walk through my office due to the Mac paraphenalia everywhere. The trouble is that once your friends hear you’re collecting vintage Macs, they’ll start giving you perfectly good systems for free! Here’s the current inventory:

Mac Plus – aka “Lonely” – I bought this Plus from a Craigslist ad with the photo shown above. It’s in nice working condition, and has only moderate yellowing of the plastic. I’ve paired it with an older Apple M0110 keyboard, which actually predates the Plus. After an upgrade to 4MB of RAM and the addition of a 100 MB external Zip drive, Lonely is in business! The Plus is running System 6.0.7 and has a 68000 CPU running at 8 MHz.

Mac 512Ke – aka “Smelly” – This was another Craigslist purchase, acquired from a guy who was once a Mac repair tech in Japan. He threw a whole box of spare Apple ICs into the deal for free. This machine earned its nickname from the horrible burning smell it gave off when I first turned it on. In an attempt to pinpoint the problem, I later ran it outside with the rear cover off, but the smell never returned and Smelly has worked fine ever since. It’s paired with an Apple M0110A keyboard (the one with the numeric keypad) with a couple of broken keys. The 512Ke is basically a Plus with no SCSI and only 512K RAM, but the CPU specs are the same.

Macintosh Classic – I was given this machine for free, which is good because it has lots of problems. It does mostly work, but there’s no sound, and it sometimes fails to boot up and shows a checkboard pattern on the screen. I believe both of those problems are due to aging capacitors on the motherboard, which could be replaced if I were motivated enough. The floppy drive doesn’t work, and seemingly half the keyboard keys are broken. It’s got a 40 MB internal hard drive and 4 MB RAM, and the same CPU as the Plus and 512Ke. I’ll probably cannibalize the HD and RAM, and recycle the rest.

Macintosh LC II – I bought this pizza box machine cheaply from a vintage Mac web site. The specs are good: 68030 at 16 MHz, 12 MB RAM, 1 GB hard drive, and ethernet card. Unfortunately it’s a real dog running System 7.5. I used to own an LC myself, and I don’t remember it being this slow. It can take nearly a second for the computer to respond to mouse clicks on the tool strip! I haven’t been able to get the ethernet card working, although I haven’t tried very hard. I plan to install System 7.1, and see if that helps improve performance at all. If not, I’ll probably swap out the 1 GB HD for the Classic’s 40 MB one, and re-sell or donate this machine.

Powerbook Duo 230 – This was another freebie. The Duo 230 sports System 7.1, 12 MB RAM, a 120 MB hard drive, and 16 glorious grays. The 33 MHz 68030 CPU feels relatively snappy. Unfortunately without a Duo dock or mini-dock, the only way to get data on and off the Duo is with a LocalTalk network connection. Even if I had a dock, though, the flakey keyboard makes it challenging to use. All of the keys work, but many of them have to be pressed very hard to register a keypress. This is a common problem with Duo keyboards, and I followed the instructions to disassemble the keyboard and clean the contacts on the mylar membranes, but it didn’t seem to help much. I’ll probably donate this machine.

Power Mac 8500 – This Mac is awesome, and I got it for free! There’s something about the vintage tower Macs that’s just irresistable. With a 120 MHz Power PC 604 CPU, 160 MB RAM, and System 9, it’s actually capable of running semi-recent software. It’s only problem is that it’s as loud as an airplane. I think the hard drive mount may be vibrating, which should be simple to fix. If one of the fans is failing, it may be more difficult to find a replacement.

I was able to get online and browse the web using the 8500, although no recent web browser will run on this machine, and the browsers that do run on it (Internet Explorer 5… ahem) have trouble rendering many web pages from 2011. Even when the pages do render correctly, it is S…L…O…W… These days, even a simple web page is likely to involve downloading dozens of individual image and style sheet files and running a bunch of JavaScript. I plan to keep this machine for general Mac nostalgia use, and as a file server for the Plus and 512Ke.

Piles of Peripherals

I’ve got external Zip drives, assorted RAM, system saver fans, SCSI cables and terminators, serial cables, LocalTalk cables, and a bunch of other stuff that I can’t even identify. I need to learn to say no to donations, even when they’re free!

I’m making slow progress on Plus Too, unraveling the mysteries of the Mac’s operation little by little. I haven’t really worked on the IWM and floppy components yet, because I’ve been consumed with chasing down other details, and trying to learn how to create FPGA timing constraints. There has been some visible progress, though: you can now move the mouse cursor around the question-mark disk screen, and the question mark flashes on and off. Woo-hoo!

In order to learn why my hardware doesn’t work as expected, I usually have to disassemble and examine the portions of the Toolbox ROM routines that access the hardware, so I can understand how it’s supposed to work. This has been a slow and painful task, one I’d compare to swimming through mud. Certain parts of the ROM routines are beginning to make sense to me now, though, and I’ve discovered several “mysteries” in the routines that are either vintage Apple bugs, or else places where my understanding is flawed.

Broken Timers

The Macintosh VIA’s Timer 2 is configured as a one-shot 16-bit countdown timer. When the countdown reaches zero, the VIA triggers an interrupt. Because the VIA runs at 783.36 kHz, the maximum possible timeout delay = 65536 / 783360, or 84 milliseconds. To implement delays longer than that, the ROM routines repeatedly schedule T2 for successive 84 millisecond delays. Here’s a portion of the relevant code from the Toolbox ROM:

P700:
           Tst.L     D1               ; D1 is a pointer to the timer parameters
           BEQ       L3640
           Move.L    D1, A1
           Move.L    $A(A1), D1       ; get the desired timeout delay (in milliseconds)
           MoveQ.L   $54, D0
           Cmp.L     D0, D1
           BLE       L3639            ; if the desired delay is more than 84 ms, then just do 84 ms
           Move.L    D0, D1
L3639:     Move.L    (TimeVars), A1
           Move.L    D1, (A1)         ; save the actual delay value
           MulU      $30C, D1         ; convert milliseconds to VIA clock cycles
           Move.L    (VIA), A1
           ROR       $8, D1
           Move.B    D1, $1200(A1)    ; store high byte of delay in T2C-H
           ROR       $8, D1
           Move.B    D1, $1000(A1)    ; store low byte of delay in T2C-L
           Move.B    $-60, $1C00(A1)  ; enable the timer 2 timeout interrupt
           Lea.L     P_VIAInt5_Timer2, A0
           Move.L    A0, (Lvl1DT.5)   ; install the interrupt handler
L3640:     Rts

The important thing to notice here is that the high byte of the timer is loaded before the low byte. According to the VIA 6522 datasheet, this is wrong, and will generate incorrect timeouts. The datasheet explains that T2C-L (the low byte of the T2 counter) can not be directly written. Instead, a write to that register will write to a latch called T2L-L. Then when T2C-H is written, the VIA will simultaneously load T2C-L from T2L-L, and arm the timer. By writing the timer bytes in the opposite of the expected order, this ROM routine will end up using whatever low byte was intended for the previous invocation of T2, resulting in a timing error of up to 0.33 milliseconds. Probably no one attempts to use the timer for sub-millisecond timing, so the bug isn’t noticed in practice.

Question Mark Flash Rate

The question mark at the boot screen flashes on and off. I would have guessed that the flashing rate was governed by a timer, but apparently it’s just a hard-coded delay loop.

      MoveQ.L   $4, D0
      Swap      D0
L70:  SubQ      $1, D0
      BNE       L70

Because my TG68 soft-CPU requires fewer clock cycles per instruction than a real 68000, this loop runs faster, and the question mark flashes about 2-3 times the normal rate. It makes Plus Too look a little hyperactive. This could cause different behaviors on real Mac hardware as well. I’m not sure if this same ROM routine is used on the Mac II, but if it is, I would expect the question mark to flash faster than on a Plus, due to the faster CPU.

There’s another point about this code snippet that I don’t understand: D0 is initialzed to the long value $00000004, then the lower and upper halves are swapped, which changes the value to $00040000. But the loop performs a SubQ, not a SubQ.L, so only the lower 16 bits of D0 are used in the subtraction. That means the initial value of 4 is irrelevant, and the loop will execute 2^16 or 65536 times.

Mouse Button at the Question Mark Screen

Apparently if you hold down the mouse button while the Mac is at the question mark disk screen, it does… something. I discovered this by accident, because at first my mouse adapter behaved as if the button were always pressed. Try this on a real Mac Plus! It makes some seeking noises from the floppy drive, about once every second, as long as you hold down the mouse button. From a look at the ROM routines, it seems like it tries to force the Mac to read the disk, even if it doesn’t think there’s a disk inserted. Anyone know for sure what this feature is for?

Flickering Mouse Cursor

After I got the mouse movement working, one of the first things I noticed was that the cursor flickers when it’s in the bottom third of the screen. I assumed this was a problem with my hardware design, and spent quite a while trying to discover the root cause. After a lot of digging, I found that every time the question mark flashes on and off, the ROM routines call PlotDisk to draw and erase it, whose code looks like this:

P_mPlotDisk:
      _HideCursor
      Move.L    (Ticks), D0
L72:  Cmp.L     (Ticks), D0
      BEQ       L72	; wait until Ticks has changed
      ; ... disk icon drawing code is here
L73:  _ShowCursor
      Rts

First it hides the cursor, then it waits until Ticks has changed, which indicates that the VBlank interrupt routine has run. This looks like an attempt to ensure the disk icon drawing code happens during VBlank to avoid flicker, but it’s flawed. It could take up to a full 1/60th of a second for Ticks to change. During the time the routine is waiting for the change, the cursor has already been hidden. If the screen area containing the mouse is repainted during this time, the user will see cursor flicker. To fix the bug, the call to _HideCursor should be moved to after the wait loop, and just before the actual disk icon drawing code.

My moment of triumph came when I tried this on a real Mac 512Ke, and observed the same cursor flickering behavior. If the cursor is moved to the bottom portion of the screen, it will flicker every time the question mark flashes on and off. I’ve managed to reproduce the exact behavior of an obscure, timing dependent bug from the real Mac hardware. Try that, software emulators!

Now I’m really getting somewhere with Plus Too: it’s the “question mark disk” screen! If you ever owned a Macintosh with no hard drive, you’ll be very familiar with this screen, because it was shown whenever the computer was turned on. It’s the Mac’s way of saying “please insert a system disk.” It means everything is OK, ready to go, but it needs an operating system disk to proceed further. Here’s another photo, this time showing the entire screen:

The mouse pointer appears in the upper-left. With a bit more work, I should be able to move the mouse around while on this screen.

The green text at the bottom of the screen is my primitive on-screen debug interface. Because the pixel-doubled 512 x 342 Mac desktop is only 684 pixels tall, there’s some extra space above and below it when running at 1024 x 768 SVGA resolution, and it’s the perfect place to show debug data. The green text isn’t drawn by the Mac (which after all can only do black and white), but by the video output circuit in the FPGA. There are effectively two video sources which it combines: one from the Mac screen buffer, and one from the debug interface. The debug text shows the current CPU address, data in, data out, address strobe, data strobes, previous address, and breakpoint address. The breakpoint address can be modified by setting the positions of switches on the Altera DE1 board, and pressing a button to load the low, middle, or high byte of the address. Crude, but it’s better than nothing.

Thus far I’ve actually implemented very little Mac-specific hardware behavior, so it’s suprising that it gets to the question mark disk screen. The implemented hardware is:

• 68000 CPU (synthetic soft-CPU in the FPGA)
• 128 KB ROM from Mac Plus (in external Flash ROM)
• 512 KB RAM (in external SRAM)
• address decoder maps ROM to $400000 and RAM to $000000
• IWM floppy controller always returns $1F when read, and otherwise does nothing
• Reads from address $FFFFFx return 24 + x. This makes interrupt vectors work correctly.
• VIA is partially implemented: vblank and one second interrupts work, the interrupt enable and flags registers work, and the memory overlay bit works.
• Video circuit reads from a hard-coded frame buffer address of $3FA700, which wraps around to the correct address in the 512 KB RAM space.

That’s it. There’s nothing whatsoever for the keyboard, mouse, disk, sound, or SCC, and the VIA is only about 25% implemented. I did have to cheat a little to reach the question mark disk screen: there’s still something wrong with my interrupt flags, and I had to flip a switch a few times to manually enable and disable interrupts. Without my intervention, it stalls indefinitely on a black screen. Hopefully the interrupt problem will be simple to fix.

Reaching the question mark disk screen is great, but it’s sobering to realize that getting further will probably require an order of magnitude more work than I’ve done so far. That’s because it will require implementing the IWM behavior, as well as the behavior of the floppy drive itself, and the lowest-level bit-by-bit data representation on a floppy disk. On the other hand, once I do get past this screen, I should be most of the way to having a working Mac clone.

I used to believe that Altera’s FPGA tools were much more hobbyist-friendly than the comparable Xilinx tools, and I frequently bashed the Xilinx tools whenever the topic came up. But after giving them a head-to-head comparison recently, I think I may have to eat my words. The truth is they’re both pretty rough and clunky, and difficult for a beginner to get the hang of, but the Xilinx tools are definitely superior in some important areas.

My FPGA apprenticeship started out poorly with Xilinx in 2009. Over the couple of years I’ve owned a Xilinx Spartan 3A FPGA starter kit, I’ve learned to really hate it and the confusing Xilinx tools and documentation. Trying to get the DDR2 DRAM working on the Xilinx board was an exercise in futility that occupied several months of my time, and I eventually just gave up, as I couldn’t even get the reference design to work. The Spartan 3A starter kit hardware also seems needlessly complex, like they threw one of every possible component on there just to serve as an example. That makes it a confusing mass of jumpers, options, and shared pins that obscures whatever you’re trying to create. Too often I also found the Xilinx documentation and examples incomprehensible, and their online support poor to none. Eventually I gave up on them, and vowed to only use parts from their competitor Altera in the future.

A year or so later, the opportunity to try Altera hardware and tools came, during the development of Tiny CPU. It was a mostly positive experience, although I didn’t really attempt anything very complex. When I needed it, I found the Altera documentation to be decent, and the project went forward without ever hitting any Altera-specific snags. I viewed the result as promising, but not really conclusively better than Xilinx.

During the recent development of Plus Too, I’ve finally had an opportunity to try both Xilinx and Altera tools for the same project, and make a direct comparison. I first spent about a week gettings things set up on the Xilinx board, which culminated in the “Sad Mac” I wrote about yesterday. Then for the past two days, I’ve been translating the existing design to get it working on the Altera board. I love the Altera DE1 hardware– it’s uncluttered, has SRAM *and* SDRAM, and comes with a nice program that can be used to interactively control the hardware or read/write the on-board memory. When it comes to the tools, however, moving from Xilinx to Altera definitely felt like taking a step backward.

Windows 3.1 called. It wants its interface back.

My first complaint about the Altera tools is the interface, which is a UI gem straight out of 1993. Yes I know it’s a petty complaint, but it reinforces the feeling of cruftiness that permeates everything else in the Altera tools. Check out a couple of screen shots:

Those message tabs remind me of MSVC 6.0. And the navbar icons use about nine unique colors across the whole set. And what’s with the balloon help menu?

Here are the corresponding sections of the Xilinx interface for comparison:

That feature is not licensed and has been disabled

Another gripe about the Altera tools is that so many features have been locked out of the free edition. I understand they need to hold something back for the professional edition of their tool, but some of the things they lock just seem petty. After a full compilation run, the output window will be full of warnings about all these tantalizing features you’re not getting. For example if you synthesize your Altera model on a computer with a multi-core CPU (pretty much any CPU these days), you’ll get this warning:

WARNING: Parallel compilation is not licensed and has been disabled

Thanks for nothing, Altera. The Xilinx tools happily spins off multiple threads for each of my CPU cores, and tells me it’s doing it too.

What simulation?

An essential part of FPGA development is simulating the design, because it’s generally much easier to find mistakes in simulation than in the real hardware. You can view every waveform, step through time, set breakpoints, and other sorts of things like you’d do in a functional programming language like C. With the Xilinx tools, I was able to simulate the Plus Too design by switching to the Simulation view, and double-clicking Simulate Behavioral Model. The built-in simulation tool ISim started right up, and within moments I was debugging the design, watching the simulated CPU talk to simulated RAM, ROM, and video. Professionals might need something more powerful than ISim, but it was great for my needs.

The Altera simulation experience was a nightmare in comparison. It took me some time to realize that the Altera Quartus II software doesn’t include any built-in simulator, so I wasted quite a while assuming I was doing something wrong when simulation didn’t work. Altera recommends that you use Modelsim Altera Edition, which is a separate product that must be downloaded and installed separately. Once that’s done, you need to go back into the Altera software and tell it to use Modelsim as the simulation tool, which involved more poking around in menus that are doubtless familiar to pros but took me a while to discover.

Once I had Modelsim AE launching with my design, I thought I was home free. Instead, I was greeted by a laundry list of errors like “Unresolved defparam reference to ‘altpll_component’ in altpll_component.port_extclk3.” After some more swearing and poking around, I found that Modelsim was relying on some environment variables that weren’t set. Environment variables… OK. I made the necessary environment settings, but it still didn’t work. It seemed that Modelsim was unable to parse the definitions for any Altera megafunctions (their IP blocks). A few hours of Googling for answers didn’t find any obvious solutions. It seemed that it might somehow be related to instantiating megafunctions with VHDL implementations from inside a Verilog file, but all my megafunctions were created by the Altera wizard, so they should be fine right? Wrong. Eventually I hand-edited the modelsim.ini file to force it to use Verilog implementations of the megafunctions instead of VHDL ones, and that worked. There was probably some simpler way to do it, but I never found it.

You got your VHDL in my Verilog

Once the simulation model finally compiled successfully, I was ready to start debugging, only to be met with the error message “ALTERA version supports only a single HDL”. Huh? The translation is “you can’t simulate designs containing both Verilog and VHDL files unless you buy the commercial version of ModelSim for over a thousand dollars”. Since my design files are Verilog, but the TG68 68000 core is VHDL, that meant I was dead in the water. In contrast, Xilinx’s ISim simulated all this with ease and no complaints.

It’s the software, stupid

For most of us electronics hobbyists who are interested in FPGAs, the choice of what device or board to use isn’t really determined by which has the most 18-bit multipliers or other whiz-bang features. It’s not really determined by the cost, either, since generally we’re only buying one device. Instead, it’s determined by how easy the device is to use, and how quickly we can accomplish our goals with the hardware. The best software tools are like a trusty set of wrenches that let us quickly open things up and tinker with them, focuing our attention on the novel parts of the project. Poor tools force you to spend time thinking about them instead of your project, and I wish there were better FPGA tools options for hobbyists. From the two major FPGA vendors, my nod goes to the Xilinx tools if you care strongly about simulation.