Last week I wrote about some test results from Yellowstone, my FPGA-based universal Apple II disk controller based on the Laser UDC design. I described two especially worrisome problems: one with 5.25 inch disks on an Apple IIGS at “fast” CPU speed, and the other with 3.5 inch disks under GSOS. I think I’ve fixed both problems, or at least found work-arounds, but it’s raised a new concern. Both issues look like serious problems in the original Laser UDC ROM code, rather than anything related to my Yellowstone re-implementation. And if the UDC shipped with those bugs, I’m wondering how many other problems it may also have. I don’t want to build a new project on a shaky foundation.

 
GSOS and 3.5 Inch Disks

In last week’s Yellowstone tests, I discovered that 3.5 inch floppy drives weren’t working under GSOS. They caused an error during booting: Unidisk3.5 requires a driver. Install UniDisk3.5 driver on boot disk and re-boot system. A stock UDC card with the version 4.0 ROM was found to have the same problem. The strange thing was the error mentioning UniDisk3.5 when the drive wasn’t a Unidisk 3.5, but an Apple Disk 3.5. An actual UniDisk 3.5 worked fine. Installing the requested driver didn’t help: the same error still appeared.

After doing some poking, it seemed that the problem was related to the Device Information Block returned in response to a status call. There must be some critical DIB difference between the drives that work and the drives that generate an error. Because the UniDisk 3.5 is an intelligent device, DIB requests are handled by the drive itself. But the Apple Disk 3.5 is a dumb drive, and the Yellowstone firmware (ROM code) must handle DIB requests on its behalf. Presumably GSOS didn’t like something about the DIB response for the Apple Disk 3.5, resulting in that driver error message. I did some testing with various disk controllers and drives, and checked the type and subtype fields in the resulting DIB:

DISK CONTROLLER   DRIVE                          DIB TYPE/SUBTYPE 
IIgs built-in     Apple Disk 3.5                      01/C0
IIgs built-in     Unidisk 3.5 (real drive)            01/00
Yellowstone       Apple Disk 3.5                      01/00
Yellowstone       Unidisk 3.5 (Floppy Emu emulated)   02/20

The Yellowstone firmware, following the example of the UDC firmware, returned the same type/subtype for an Apple Disk 3.5 as the IIGS built-in disk controller does with a real Unidisk 3.5. That probably explains why the error message mentioned UniDisk3.5, but not why there was an error in the first place.

Changing the firmware to return 01/C0 instead of 01/00 changed the error message’s text to AppleDisk3.5, but didn’t help the underlying problem of the disk not working. My guess is GSOS sees the 01/00 or 01/C0 type IDs, and then based on that, it tries to make some extended status or control calls it expects those types of drives to support. But Yellowstone / UDC doesn’t handle those calls as expected, causing GSOS to complain about needing a driver. I’m not sure if Laser never tested the UDC with GSOS and 3.5 inch drives? Or maybe GSOS didn’t exist when the UDC was originally released?

My fix was to change Yellowstone’s type/subtype ID for the Apple Disk 3.5 to 02/00, which should indicate a general removable Smartport hard disk. This eliminated the errors under GSOS, and everything seems to work OK. I’m unsure if this change may create any new problems, however. A floppy disk isn’t the same thing as a removable hard disk, but maybe it doesn’t matter as long as the firmware knows how to read and write the disk. I’ll keep testing.

 
IIGS Fast Mode and 5.25 Inch Disks

After a closer look at many 5.25 inch disks, I realized that all DOS-based 5.25 inch disks failed to boot properly on a IIGS with the CPU speed set to “fast”. This included the DOS 3.3 System Master disk, Bank Street Writer, Donkey Kong, Choplifter, and many others. But 5.25 inch disks based on ProDOS all seemed OK, including the ProDOS System disk and others like Shrink It. Very strange.

I examined the disk I/O signals with a logic analyzer. For the DOS-based disks, after the initial drive recalibration and loading of sector 0, it looked like all the drive operations were happening about 2.5x too fast. This is roughly the speed difference between code running on a IIGS in fast mode versus normal mode. So for reasons unknown, the disk code wasn’t being automatically slowed to normal 1 MHz speeds as is required for 5.25 inch disk compatibility.

The Yellowstone firmware slows the IIGS to 1 MHz whenever one of Yellowstone’s disk API functions is called, and restores it to the previous speed when the function exits. For ProDOS-based software, I think all the disk I/O happens through the API, so the IIGS speed is adjusted as needed and everything works.

But for DOS-based software, only the loading of sector 0 is directly handled by Yellowstone firmware. After that, DOS’s RWTS routines bypass the Yellowstone firmware and directly control 5.25 inch drives through memory-mapped I/O registers. If the RWTS code runs at “fast” speed, then you get the behavior I observed, and disks won’t boot properly.

This explains why Yellowstone wouldn’t work for DOS-based 5.25 inch disks, but then how do other disk controller cards work? Why doesn’t a Disk II controller card have the same problem on a IIGS at fast speed?

 
Motor-On Detector Voodoo

Bits 0-3 at address $C036 on the IIGS are used to enable motor-on detection for a Disk II controller card in slot 4 through 7. It’s a nifty feature. Each bit enables motor-on detection for a different slot. When enabled, the IIGS attempts to keep track of the motor-on state for a Disk II controller card in that slot, by watching for memory accesses to $C0x9 (on) and $C0x8 (off), where ‘x’ depends on the slot number. When motor-on detection is enabled and the motor is on, the IIGS is automatically slowed to 1 MHz to ensure that disk-related code works as expected. Thanks to the folks at retrocomputing.stackexchange.com for clearing this up.

Now why does motor-on detection work for a real Disk II controller card, but not for Yellowstone? I’m not certain, but I suspect the IIGS firmware scans the installed peripheral cards during boot, and checks each card’s ROM signature to see if it’s a Disk II controller. If it is, the IIGS enables motor-on detection for that slot. But Yellowstone has a different ROM with a different signature, so it doesn’t get detected, and motor-on detection remains disabled.

The solution is for Yellowstone’s initialization code to manually enable motor-on detection, but this is trickier than it sounds, and it appears Laser themselves screwed this up. I’m working off UDC ROM version 2.3, which makes no attempt to enable motor-on detection. Patching it won’t be simple, because it’s a massive block of absolute address references with almost no free bytes where a patch could be inserted. UDC ROM version 4.0 was a major rewrite from v2.3, and it enables motor-on detection for ALL of slots 4-7, regardless of which slot the card is actually installed in. This is wrong, and potentially interferes with the operation of other cards in those slots that might use $C0x9 and $C0x8 for unrelated purposes. For now I’ve implemented a temporary “fix” that confirms motor-on detection will solve the problem with DOS-based disks, but my fix breaks other things. I’m still searching for a better solution.

One interesting side-effect of this motor-on detection mechanism is that IIGS disk controllers in slots 4-7 work differently than slots in 1-3. There is no motor-on detection for slots 1-3, so if you install a Disk II controller there, or any other disk controller that relies on motor-on detection, it won’t work for DOS-based 5.25 inch disks when the IIGS speed is set to fast. You can test this yourself. Install a Disk II controller in slot 4, and enable the card in the GS Control Panel. Try booting a DOS 3.3 disk and confirm it works. Now move the Disk II controller to slot 2 and try again, and watch the drive loop endlessly between tracks 0 and 2.