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.