The Mac ROM-inator kit is back in stock! The ROM-inator replaces the stock ROM with 1MB of re-writable flash ROM in a Macintosh Plus, 512Ke, 512K, or 128K – making it possible to do all sorts of crazy customizations! The new kit has an updated default ROM image, with a new boot chime, modified Happy Mac icon, and System 6 ROM disk with a small collection of built-in apps and games. All these defaults can be changed by updating the flash memory. Personalize that old compact Mac, and make it fun again!

For a while I’ve been struggling with occasional mystery bugs when making changes to the Floppy Emu AVR microcontroller firmware. I’ll make some seemingly innocuous code changes, and completely unrelated things will break. Frequently I’ll change something in a menu or other user-facing code, and suddenly the Emu will lose the ability to read the SD card, and insist there’s no card present. Needless to say, this makes development a real pain in the butt.

Today I found a perfect example of this behavior, where changing the max loop count in some code that’s not even executed would cause the Emu to lose access to the SD card. Buried in the code that simulates reading a floppy disk image is this:

#define INTER_SECTOR_GAP_SIZE 55
// lots of stuff omitted
for (uint16_t i=0; i<INTER_SECTOR_GAP_SIZE; i++)
{
  SendByteAndCheckRestart(0xFF);
}

What I found is that if I changed 55 to 56 or 65 or pretty much any other number, the Emu would suddenly become unable to read the SD card. What’s strange is that this for loop isn’t even executed during Emu startup, where the SD problem occurs. And just changing a single constant from 55 to 56 shouldn’t change the size or location of the compiled code, or anything else that might reveal previously hidden memory-related bugs. But it was extremely reliable: 55 always worked fine, 56 could never read the SD card.

Determined to find an explanation, I grabbed the binary diff tool VBinDiff and used it to compare the two compiled .hex files. I fully expected the files to be identical, save for a single byte that was 0x47 in one version and 0x48 in another version. But I was stunned to find the two files differ in hundreds of places! There are at least a hundred single-byte differences, as well as whole blocks that are different between the two. Thinking maybe I was getting different compile results from one compile to the next, due to a compiled-in timestamp or something weird, I tried compiling the same source code twice and comparing the results. They were identical. But if I changed the loop count, I got a hugely different result. And somehow that result was causing an SD card problem.

At the moment I don’t have any explanation for this, except maybe for some kind of compiler optimization that kicks in after 55 something-or-others. If you’re curious, you can compare the two .hex files yourself: floppyemu-55.hex, floppyemu-56.hex. The hex files show exactly what will be programmed into the ATMEGA1284’s flash memory.

I always operate my computer on a mahogany desk, while wearing a suit and tie. Don’t you?

There’s been no progress on the Lisa disk emulation itself since my last update, but I’ve spent some time getting the Lisa into a state where I can collect better floppy diagnostic information. The BLU Basic Lisa Utility seems to be the best tool available for this.

 
BLU Setup

BLU isn’t an application, but is a “bare metal” program that loads instead of the operating system. As I mentioned previously, the tricky part with BLU is that it needs to be loaded from a real floppy disk, but I also need to connect the Floppy Emu in order to run tests on it. The Lisa only has one floppy port, and I don’t want to hot-swap the drives.

I finally decided to install BLU to the Lisa’s hard drive. I’d been resisting that solution, since a BLU hard drive install wipes out anything else on the HD, which makes it impossible for me to run further Macworks tests. That’s not great, but because it would enable me to run BLU from the HD while testing a Floppy Emu on the floppy port, I decided it was the best option available. After reading the BLU documentation, I learned that the HD install option is in the “miscellaneous” sub-menu, accessed by pressing M from the main menu. But wait a second – the M key on the Lisa’s keyboard is broken! Argh! No HD install for me.

So instead of installing BLU to the hard drive, I switched to my backup plan and built a two port floppy drive adapter with an external enable switch. This adapter connects power and the computer’s floppy outputs to both drives, with a manual switch to control whether the computer’s enable output is connected to drive 1 or drive 2. The read lines from the floppy drives are connected together, but that should be OK since only one drive will be enabled at a time. That’s similar to how the external and internal floppy drives are connected on a Mac.

Not wanting to risk damaging the Lisa if the adapter was flawed, I tested the adapter on a Mac SE, with one 400K drive and one Floppy Emu. It mostly worked, and I could use the switch, and the computer would only see the drive that was enabled with the switch. But there were some weird problems too, like disks sometimes becoming unreadable or failing to eject. I had almost given up on the adapter, when I realized the problem was that I’d combined a real 400K drive with a Floppy Emu that acted like an 800K drive. So from the computer’s point of view, the type of drive would magically change when I flipped the switch, causing badness. After changing the Floppy Emu firmware to identify itself as a 400K drive, it worked fine.

Now I can use the adapter to connect both a 400K drive and a Floppy Emu to the Lisa, though only one drive can be used at a time. I can boot BLU from a real floppy disk, then switch over to the Floppy Emu to run tests. Great! Unfortunately I can’t actually see the results of BLU’s floppy tests. It sends the test results to the serial port, not the screen. I’ve ordered a DB-25 to USB serial cable, but it’ll be a couple of days before it arrives.

 
Binary Hacking

Meanwhile, about that broken M key… it turns out that I still need access to BLU’s (M)iscellanous menu in order to turn on verbose output from the floppy tests. And short of getting a new Lisa keyboard, the only solution was to patch BLU to use a different keyboard shortcut to access the menu.

BLU is distributed as a DiskCopy 4.2 image file. I opened the file in a hex editor under Windows, and found where the menu options were stored, and the table of keypress values for each option. I hacked the code to use B for the miscellaneous menu, instead of M, and saved my work. Success! Except now the checksum on the image file was wrong, and DiskCopy 4.2 refused to load it.

Undaunted, I searched the web for some existing tool that could fix DC42 checksums, or ignore the checksums, or at least tell me the values of the stored and computed checksums. I found nothing. I couldn’t even find a good explanation of the checksum algorithm, the only reference being a one-sentence description on the DiskFerret wiki. I finally gave up on finding an existing tool, and wrote my own program to compute DC42 checksums, experimenting with it until the values it computed matched the stored checksums in some known-good DC42 image files. I used my new program to manually fix the stored checksum in my patched version of the BLU image file, and all was well. There must have been an easier way to work around a broken M key!

 
Floppy Tester Tool

In addition to BLU, the other weapon in my arsenal is a Macintosh program I wrote during Floppy Emu’s original development, and which I described in my previous post. This testing program has a few problems on the Lisa, when running under Macworks. After some experiments, I learned that it doesn’t work on Macs with a 64K ROM (the Mac 128K or Mac 512K), nor on the Lisa with an emulated 64K Mac ROM using Macworks XL. The program opens, then immediately closes again, with no error message reported. More experiments showed that it worked fine with a 128K ROM (Mac Plus). When the Lisa was updated to use Macworks Plus with an emulated 128K ROM, the testing program worked. However, I suspect that the combination of Macworks Plus and 400K IO ROMs in the Lisa I’m using is causing some problems of its own. A much better solution would be to understand why the program doesn’t work with 64K ROMs, and fix it.

So why doesn’t it work? My best guess is that it’s some glue code being automatically inserted by the Metrowerks Codewarrior 6 compiler I used to build the program. I don’t remember exactly when Codewarrior 6 was current, but it’s probably 10-15 years newer than those early Macs with the 64K ROM, and so it’s easy to imagine it would assume the target machine had at least a 128K ROM. In fact I know of one example of this already, where Codewarrior automatically includes calls to the StripAddress() trap, which is supposed to make sure addresses are 32-bit clean. But this trap doesn’t exist on old ROMs and old system versions, so programs built with CW6 will mysteriously crash. StripAddress() isn’t even needed on those systems, because they always run in 24-bit mode. The solution I’ve found is to open the compiled program in ResEdit, open the CODE resource, and replace instances of 0xA055 (StripAddress) with 0x4E71 (NOP instruction).

A better solution would be to rebuild the test program with an older compiler that’s more likely to be 64K ROM friendly. Keith Kaisershot kindly did this using Think C 5.0. I haven’t yet had a chance to try his new version, but I hope to give it a shot after I finish up this progress report.

 
BLU Testing

I’ve also been mulling over possible explanations for the BLU test results reported by my remote Lisa pen-pal. It looks like the Lisa is finding the start of the sector’s data section OK, but runs into errors at the data checksum or the data end signature, so something is going wrong midway through the sector data. Possible causes I can think of:

1. It picked up a false data start signature in the middle of some other data, while the floppy controller was out of sync. This might happen occasionally, but it should be rare. I doubt this is the problem.

2. The bit rate sent by the Floppy Emu doesn’t match the bit rate expected by the Lisa. The Emu sends at exactly one bit per 2.0 microseconds. On a real Macintosh and floppy drive, it would be 2.04 microseconds, but this discrepancy never caused a problem. I doubt this is the problem on the Lisa, but it might be.

3. The Lisa is getting confused because the Emu doesn’t provide proper 10-bit bitslips. I don’t think this can be the answer, because it wouldn’t explain how the Lisa could so often read the start of a data section OK, but run into problems somewhere before reaching the end. The bitslip is something that happens before a sector, or between the sector’s address and data sections, but not in the middle of the data.

4. Electrical noise, reflections, ringing, or cross-coupling are screwing up the digital signal from the Floppy Emu to the Lisa, causing read errors. I tend to doubt this, since if it were a problem, it should be a problem on the Mac too. But maybe the Mac is more tolerant of noise, has different voltage thresholds or hysteresis on the inputs, so electrical noise simply doesn’t affect it as much. The scope should reveal this.

5. The structure of a single bit is not what the Lisa expects. When simulating a read, a 0 bit is sent by keeping the signal at whatever level it was previously, and a 1 bit is sent by a high-to-low transition. Some time after the high-to-low transition, but before the next bit window, there must be a low-to-high transition to prepare for a possible high-to-low transition on the next bit. The time delay between these two transitions is undefined, as far as I know, as long as it’s less than a bit window. I believe Floppy Emu does it half-way through the bit window, so a sequence of all 1 bits would be transmitted as a 50% duty cycle square wave. Maybe the Lisa hardware expects a different duty cycle? Comparing the Floppy Emu signal to a real drive on the scope might shed some light on this.

6. Something is interrupting the AVR microcontroller during its transmission of a sector, so it hiccups midway through and introduces an error into the data. I think this is the most likely explanation for the problems observed. But if it were a problem, it should be affecting the Mac too. Possible things that could interrupt or stall the AVR and cause a hiccup:

• It thinks the computer just switched to reading the opposite side of the disk.
• It thinks the computer just stepped to a different track.
• It thinks the computer just began a write operation.
• There is a code path where it takes longer to compute and prepare the next byte than the 16 microseconds it takes to send a byte.

That seems like plenty to think about for tonight.

Floppy Emu for Lisa progress report: I now have a firmware version that sort-of-works on the Lisa, when using Macintosh disk images, and running Macworks Plus on the Lisa. I can read from an emulated 400K Macintosh disk as well as write to it. From the limited testing I’ve done so far, it looks like the data is read and written correctly. But it’s not really usable as-is, and there are still some significant problems to overcome.

 
Bit Slip

The reason it wasn’t working yesterday appears to have been a problem with the way Floppy Emu generates something called bitslip markers. The data on a floppy disk is just one long string of bits, with no framing information to show where one byte ends and the next begins. The floppy controller only knows that disk bytes always have 1 as the MSB, so if it reads a byte where the MSB is 0, it means the framing must be wrong. It slips one bit, and tries again. To assist the floppy controller, disks normally contain a series of special 10-bit markers called bitslip markers, with the binary value 1111111100. After five consecutive bitslip markers, it turns out that the floppy controller will always end up with the correct framing, regardless of what framing it started with in the bit stream.

The trouble was that Floppy Emu wasn’t generating 10-bit 1111111100 markers, it was generating 8-bit 11111111 markers. This is one of those cases where you scratch your head and wonder how it ever worked at all, even on the Macintosh. Once I fixed the bitslip generation (I hope), Macintosh disk images started working on the Lisa under Macworks Plus. Woot!

 
Slowness

The biggest problem is that it’s slow. S… L…. O….. W…… After inserting a disk image through the Floppy Emu interface, it takes about 20-30 seconds before the disk icon appears on the desktop. And file copy operations take so long, you may as well go eat a sandwich while you’re waiting, even for files in the 10K size range. I’m guessing it’s still encountering a ton of low-level errors, causing the floppy controller to retry over and over, until it finally succeeds. So something is definitely still wrong.

I’ve been corresponding with a Lisa owner who’s got a Floppy Emu and Basic Lisa Utilities already set up, and he’s run a few tests for me. What’s strange is that this new firmware version is actually much worse than the old version, according to BLU. Despite the fact that this one actually works on the Lisa and the older one didn’t, this new version shows more disk errors in BLU, and more types of different disk errors. Hmmm.

 
Stepping Out

The other problem is that Floppy Emu on the Lisa is stepping to the wrong track for the desired sector… I think. On a 400K floppy, there’s only data on one side. There are 80 tracks, and each track has between 8 and 12 sectors. Each sector is 512 bytes. So 512 bytes per track times an average of 10 sectors per track times 80 tracks = 800 sectors and 400K. I’ve written a simple utility program where I can type in the sector number I want to read, and it fetches the data from the floppy and displays it, along with any error code returned by the read operation. With a 400K disk, if I request the last sector (number 799), it should step to the last track (track 79).

I can see the current track number on the Floppy Emu LCD, so I can verify whether it’s doing the expected thing. And when tested on a Mac Plus or a Mac SE, the Floppy Emu with a 400K disk image does what it should: it steps to track 79. But on the Lisa, under Macworks, when requesting sector 799 the Floppy Emu consistently steps to track 35 and returns bogus data. What the heck?

It turns out that track 35 is exactly where you’d expect to find sector 799, if the disk were a double-sided 800K disk. So maybe the Lisa is somehow confused, and thinks there’s a double-sided disk and drive present. But if this were the case, reading and writing files from the disk through the Finder shouldn’t work at all – it should be hopelessly broken. Yet as far as I can tell, it works, just very slowly. Could there be something about my testing program that’s flawed? I just don’t know.

It’s also possible this stepping weirdness is some kind of problem with the particular Lisa I’m using for testing. From what I’ve learned, the Lisa originally supported 400K floppies only. Later an 800K upgrade kit became available, which included a new 800K-compatible ROM chip for the Lisa’s IO board. I’m running Macworks Plus on the Lisa, which is supposed to make the Lisa act like a Mac Plus, which had an 800K drive. But if this Lisa doesn’t have the 800K ROM chip on its IO board, maybe using Macworks Plus will cause this kind of strange stepping problem.

 
Download

If you’ve got a Lisa and a Floppy Emu, and want to test this out, you can download a few different firmware variations here. There’s a single CPLD firmware file (firmware.xvf), and a few different AVR firmware files (femu.bin), each of which uses a slightly different strategy for bitslips. In my tests, the “address to data gap size 20” AVR firmware doesn’t work, but all of the others one do. But they’re all very slow. If you try it, please let me know how this firmware works for you, as well as the details of your Lisa hardware and software configuration. Thanks!

The Lisa computer was Apple’s precursor to the Macintosh, and it shared a lot of the same hardware and software. I’m going to look at adding Lisa support to my Floppy Emu disk emulator for Macintosh.

The Emu can already emulate a standard Sony 400K floppy drive, and the Lisa 2 aka Macintosh XL can use a standard Sony 400K floppy drive. (The relatively rare Lisa 1 used 5 1/4 inch Twiggy floppies.) So I *think* they should already be compatible at a low level, from an electrical and interface standpoint. That means the Lisa support could be added with just a firmware update, and no hardware changes necessary. My challenge is that I don’t actually own a Lisa! But with the assistance of a few kind Floppy Emu fans who are also Lisa owners, I’ve started getting closer.

The first obvious task is that the Emu firmware must be modified to support tag bytes. On both the Lisa and the Macintosh, a floppy sector’s data contains 12 bytes of tags, plus 512 bytes of normal data. On the Mac, the tags aren’t used for anything, and Floppy Emu just treats them as if they were always zero. Standard .dsk image files don’t even store the tag bytes, although Disk Copy 4.2 images do. But unlike the Mac, the Lisa needs those tag bytes in order for Lisa-formatted disk images to work correctly. So at a minimum, the firmware will need to fetch the tag bytes for each sector from the DC42 image file, instead of just pretending they’re zero.

 
Macintosh Emulation on the Lisa

But wait! Even without changing anything on the current Emu firmware, it should be possible to get it working on the Lisa under Macworks XL. Macworks is software for the Lisa 2 that basically turns the computer into an emulated Macintosh. After booting Macworks XL from a standard Lisa disk, you’ll then see the familiar Macintosh blinking question mark as it awaits a Mac boot disk. At that point, it should be possible to use a standard Floppy Emu and a Macintosh disk image to boot the Mac OS on the Lisa. Or boot into Mac OS with another disk, then use Floppy Emu to mount a second Macintosh disk. A helpful Lisa owner tried this exact experiment… and it didn’t work. The Lisa-as-Mac recognized that a disk was inserted, but complained that it wasn’t initialized, and offered to format it.

So why didn’t it work? I need to find the answer to that question before I even start worrying about tag bytes and other changes. My Lisa helper sent a few interesting screenshots, including the one above.

When booted using Macworks, the Mac OS on the Lisa includes a floppy control panel for something called the PFG, which I learned is the programmable frequency generator. Those control panel options look intriguing, but I’m not sure what they do. He tried normal and desperate modes with the same results.

From what little I could piece together, the PFG is an extra piece of hardware that not all Lisa 2’s have. If present, its purpose is to enable the Lisa to read floppies that were written in Macintosh II series computers that have three bit slip markers per sector. The bit slip marker is a special bit sequence on the floppy that helps the floppy controller get synchronized correctly. Apparently the Mac only needs 3 of them, although early Macs wrote 5 of them. The Lisa needs 5. With the Mac II series, the floppy logic was optimized to write only 3 bit slip markers, which made floppies written by those machines unreadable by the Lisa – hence the need for the PFG. I think.

The PFG shouldn’t be necessary when using a Floppy Emu, because the Emu sends at least 10 bit slip markers, and possibly as many as 55. So maybe there are too many, and that creates a problem? It shouldn’t be, given my knowledge of the Mac OS disk routines, if the Lisa is faithfully emulating a Mac.

 
Troubleshooting

To troubleshoot this, I need to find a way to get low-level floppy error data instead of just useless “this disk is not initialized” messages. Deep in the floppy routines, it knows if the read operation failed because it couldn’t adjust the drive speed properly, or couldn’t step to the desired track, or couldn’t find the sector on the track, or the sector checksum was wrong, or any of about 10 other possible failure reasons. There are a couple of ways I could do that:

1. I’ve already written a simple floppy testing program for the Mac. If I can get a Lisa with a hard drive and Macworks, I can copy the program onto the HD and run it from there. The trouble is, the generous soul who lives nearby and offered to lend me his Lisa doesn’t have an HD for it.

2. There’s a program called BLU (Basic Lisa Utility) that can be loaded from a floppy disk, and then used to run a variety of low-level tests, including floppy tests. The manual in appendix D shows the error info that’s provided, and it’s quite detailed. Unfortunately it’s sent to the serial port and not the screen, so I’d have to rig up a serial connection to another machine in order to see the output.

Without a hard disk, option 2 is really my only choice. But there’s another problem: I need a real floppy drive to load BLU from disk. But I need a Floppy Emu in order to test it. And the Lisa 2 only has a single floppy port. Hot swapping the drives is not an option. So I think what I’ll have to do is build a custom cable similar to my previous daisy chain adapter. This cable/adapter will allow the connection of two floppies drives to the same port, with both of them powered at the same time, and an external switch to control which one is enabled.

Other questions I’m unsure about:

• Does the Lisa have an IWM controller chip, like the Mac? I think it does. But possibly it’s clocked at a different speed.
• Is my understanding of the purpose of the PFG correct? Do all Lisas have one, or only some of them?

Assuming I can ever get this sorted under Macworks, then there are many other questions I’ll need to answer about tag bytes, the Lisa filesystem, and probably the DART disk image format. But getting Mac disks to work on the Lisa under Macworks is the first step.

The Sonic Bow Tie is an electronic kit for engineering geeks with a sense of humor, available now at the BMOW store. The circuit board is shaped and sized like a real bow tie, and is colored classic black. Once assembled, a piece of ribbon can be anchored through the board’s central mounting holes, making it easy to wear at the collar of a dress shirt or tied around a ponytail.

Wearable computing is the latest trend, and you’re at a party listening to some hipster brag about his new iWatch. “Hmm, not bad…” you say. Then you casually reach for your collar and switch on your SONIC BOW TIE 3000. Wham! Your audience is blown away by your neck-based audio-visual spectacle. Lights flash and a digital melody bursts forth. With a wave of your hand you exert theremin-like controls, shifting the pitch of digital warbling at will. The onlookers cry out “WHAT IS THIS SORCERY?!”

Attending a wedding soon? Graduation ceremony? Audience with the pope? The Sonic Bow Tie 3000 is the perfect geek accessory for any formal occasion.

Ladies: are bow ties not your style? Turn it around, and make a dazzling electronic ponytail holder perfect for your next Maker Faire presentation or inaugural ball.

While a pair of jumbo 10 mm LEDs flash, the bow tie repeats a simple 8-note digital melody, alternately soothing and annoying those around you. A center mounted photo-resistor acts as a light sensor, biasing the melody’s pitch. Turn your body towards the light, and the pitch shifts upward. Turn away or shade the sensor with your hand, and the pitch shifts downward. Fortunately there’s also an on/off switch, for when your friends threaten you with bodily harm if they hear one more second of that #*&($#@!

The kit contents are simple through-hole parts, so it’s easy to solder even for a beginner. Build one for yourself, or get a kit for your kid/student/friend and assemble it together. Who wants the boring LED blinker in a typical learn-to-solder kit, when you could have a crazy bleeping sonic bow tie theremin?

  
How it Works

The fun begins with a classic 555 timer, configured in astable mode to generate a square wave with a frequency around 1000 Hz. This is IC1A as shown in the circuit diagram. The exact frequency of the square wave is determined by the values of C3 and R1. R1 is a photo-resistor whose resistance varies with illumination. This causes the timer frequency to shift up or down in response to changing light conditions. When connected to a speaker, it creates a continuous tone whose pitch changes depending on the light.

A continuous tone isn’t very interesting, but we’re not done yet. A second 555 timer is also configured in astable mode, generating a square wave at about 4 Hz (250 millisecond period). This is IC1B in the circuit diagram. A pair of LEDs are connected to this square wave output, causing them to blink 4 times per second.

The 4 Hz signal is also used as the clock input to IC2A, a 4-bit binary counter. The circuit uses a CMOS CD4520 binary counter chip, instead of a more common 7400 series binary counter, because the CD4520 can tolerate supply voltages up to 20 V. This makes it possible to run the entire circuit directly off a 9 V battery, with no voltage regulator.

The lowest three bits of the current count are connected through series and parallel resistors to the control voltage input of the first 555 timer. This biases the continuous tone up or down in pitch, with a new bias voltage appearing every 250 milliseconds when the counter advances. The result is a repeating melody of eight notes, whose relative pitches are set by the binary counter, and whose overall pitch can be shifted further up or down by changing illumination at the photo-resistor.

 
Wear and Usage

To wear the Sonic Bow Tie 3000 around your neck, drop the battery inside your front shirt collar and allow it to hang loose by the clip wires. Normally this is all that’s needed to anchor the bow tie at your collar. If desired, a ribbon or shoelace can be passed through the two holes in the center of the circuit board, and tied around your neck.

To wear the bow tie as a ponytail holder, pass a ribbon through the center holes, and tie it around your hair at the base of your skull. The battery can be dropped inside the rear of your shirt collar, or hidden inside your hair.

The pitch bends of the digital melody are controlled by the level of illumination on a photo-sensor mounted at the tie’s “knot”. The bow tie works best indoors, in a room with moderate lighting. To shift the melody’s pitch higher, move closer to a light source, or turn the bow tie to face directly towards the light. To shift the melody’s pitch lower, move away from the light source, or shade the photo-sensor with your hand. By waving your hand rapidly above the photo-sensor, a warbling vibrato effect can be achieved. Is it science, or sorcery?