Disk Drive Testing
While I await the new Yellowstone v2.1 PCBs, I’ve been spending more time on testing. With my hacked-up v2.0 PCB, most things are working pretty well, especially with DOS3.3, ProDOS, or game disks. I can connect any odd combination of drives to the Yellowstone card, and expect that it will behave more-or-less correctly, but of course there are still a few bugs. Here’s what I’ve been working on recently.
Laser Bugs
Yellowstone supports booting from drive 1 or drive 2, but I noticed that if both drives were 5.25 inch floppies, then attempting to boot from drive 2 would always crash the computer. To find the cause, I had to go digging deep into the Laser ROM on which Yellowstone’s core disk routines are based. After some effort, I identified this as a bug in the original Laser ROM. With this drive configuration, if booting from drive 1 failed, it would prepare to boot drive 2 but never actually load anything from the disk. Then it would attempt to run the code in the uninitialized memory buffer where track 0 sector 0 was supposed to have been loaded. Doh! This is a surprisingly severe bug to find in a successful product from a major company in the 1980s, but maybe expectations were different back then.
I found another Laser-related bug in the 3.5 inch drive support. Although Yellowstone was already working OK for 3.5 inch drives, the disk I/O sounded like a panicked chicken or one of The Muppets. While reading from a disk, the 3.5 inch drive made an odd mechanical sound several times per second, which was not present when using the same drive with other disk controllers. I eventually tracked this down to the 3.5 inch / 5.25 inch switching behavior. After every sector read from the 3.5 inch disk, the Laser ROM routine was switching back to 5.25 inch mode before exiting, only to immediately switch back again for the next sector. This was causing the drive to turn on and off rapidly. I’m not sure how that made it through anybody’s QA process, because it made an obvious unpleasant noise.
With the Apple IIgs, if you boot the computer with a DOS3.3 disk using another controller card in a higher-numbered slot than Yellowstone, then Yellowstone’s ROM initialization code will never have an opportunity to run. The motor detectors for Yellowstone’s slot will never get enabled, so the IIgs won’t slow to 1 MHz when attempting to do I/O with Yellowstone’s drives. The result will be a garbled mess. Fortunately this is pretty obscure, and it only affects software based on DOS3.3 and not ProDOS, and where Yellowstone is not the primary boot device. I don’t think there’s any complete fix, but there are several possible work-arounds, including manually running the initialization code with PR#x for Yellowstone’s slot number.
GS/OS
Some other bugs I’ve identified, but not managed to fix yet. Most of them are related to GS/OS. When sitting at the desktop, GS/OS makes a Status call for each drive every 800 ms. I assume this is so it can update the GUI, and change a disk’s icon when it’s been swapped or removed. But this creates a problem for Yellowstone. Part of the data that’s returned by a Status call is the size of the disk. For 3.5 inch disks, the size is different for single-sided 400K disks and double-sided 800K disks, but it can’t know which type of disk is in the drive until it tries reading it. So every 800 ms, the drive spins up to read the disk and see whether it’s double-sided, over and over forever. It’s very distracting, and other disk controllers don’t have this problem. The Yellowstone Status call handler is going to need more smarts to cache the disk info instead of re-reading the disk each time, and to know when the drive must be checked again after a disk swap.
Yellowstone 5.25 inch drives currently aren’t working great with GS/OS, because GS/OS doesn’t know they’re 5.25 inch drives. It thinks they’re some new type of drive that supports standard API calls and that just happens to be 140K in size, so it treats them the same way as 3.5 inch drives, including the every 800 ms status call. But 5.25 inch drives can’t work that way. If you boot GS/OS while having a 5.25 inch disk in the drive, then everything works OK at first. But if you remove that disk and insert another one, GS/OS won’t know about it. If you click on the 5.25 inch drive icon, it’ll ask you to reinsert the original disk and there’s no way switch disks. If you boot GS/OS while having an empty 5.25 inch drive connected, it will complain that the disk can’t be read and needs to be initialized. If you cancel that, then the 5.25 inch drive disappears from the GS/OS desktop, never to be seen again.
With a standard Disk II controller card, or the built-in disk port of an Apple IIgs, 5.25 inch drives have a different behavior than other types of drives under GS/OS. It doesn’t attempt to access the drives or check their status until you choose to open them. As I recall, it also shows the 5.25 inch drive with a separate icon from the disk that’s in the drive. I’m not sure how to force GS/OS to treat Yellowstone 5.25 inch drives the same way, or if it’s even possible. The behavior may be determined by a signature check of the disk controller’s ROM, and if it looks like a Disk II controller, it’ll use the special 5.25 inch drive behavior. There might be a work-around if you’ve booted GS/OS from another drive and disk controller, and are then accessing one or two 5.25 inch drives using the Yellowstone card. But if Yellowstone is your only disk controller, with a Smartport hard drive at D1 and a 5.25 inch drive at D2, I’m not sure what the solution might be.
Floppy Emu
The Floppy Emu disk emulator has been my go-to testing device for use with Yellowstone, and I’ve found a couple of bugs with it too. When Floppy Emu is configured as a Unidisk 3.5 drive, but no disk is inserted yet, it displays a menu for selecting a disk. During this time the disk emulation is paused, and if the computer queries the drive, it will appear unresponsive. If you’re planning to boot from the emulated Unidisk 3.5 then you’ll probably never notice this, but if you use the Yellowstone card to boot from a ProDOS disk in another drive, then ProDOS will fail with a “Relocation/Configuration Error” mid-way through booting when it queries the Floppy Emu and gets no response.
In researching possible solutions for the GS/OS Status Call, I also realized that Floppy Emu isn’t correctly emulating one of the Sony 3.5 inch drive’s internal registers called SWITCHED. I had never found any documentation about this, so years ago when I created the emulator framework, I made this register always return zero. But now I realize that’s wrong. After experimenting with a real 3.5 inch drive, I see how it’s supposed to work. At power-on the SWITCHED register should be zero, and it should change to 1 if a disk is ejected automatically or manually with a paper clip. Software can set the value back to zero again. This probably explains why a few old Macintosh games like Dark Castle don’t seem to recognize when a new disk has been inserted, when they’re run from a Floppy Emu.
It’s not a Bug, it’s a Feature
With the exception of the GS/OS items, I think most of these issues should be possible to fix, and if I’m wrong then they’re at least easy to identify and work-around. But I’m a little worried about 5.25 inch drive handling under GS/OS. Hopefully it’s just a matter of providing the right flags in response to the Status call and other API calls. I suppose it’s not the end of the world if it never works, since most people who are running GS/OS with Yellowstone will have a separate Disk II card or the built-in disk port for their 5.25 inch drives. But I’d love to make this combination work if I can.
Read 15 comments and join the conversation15 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Do you have access to any non-Apple 3.5 drives for testing? I have a Chinon drive and Laser 3.5 drive, both of which work with my Laser 128EX (ROM version 4.3). I’m curious if they’ll work with the Yellowstone.
I don’t have either of those 3.5 inch drives, but they will probably work. If not, I’m guessing it would only require minor changes to make them work, if I had some equipment to test with.
For GS/OS, Yellowstone, and 5.25 inch drives, one possible path might be to write a custom device driver for Yellowstone 5.25 inch drives. I’m not sure what level of control that would permit, and whether it could produce something with the same look and behavior as standard 5.25 inch drives. I found the GS/OS Device Driver Reference on the web, but… it’s big. https://apple2.gs/downloads/library/Apple%20IIgs%20GS_OS%20Device%20Driver%20Reference%20-%20APDA%20A0008LL_C.pdf
I’m in SF if you’re interested in testing with those drives.
I think GS/OS polls 3.5″ drives connected to the onboard port too. I’ll double check, but I seem to recall seeing the activity LED faintly blinking on some drives. As for device drivers…..the source to GS/OS is…… out there… if you know where to look.
Apple’s 5.25″ driver puts two drive icons on the desktop and annoyingly polls the drives (GRIND GRIND GRIND) to check for a disk every time you enter Finder. You can force a check by double clicking one of the drive icons and if a volume is found, it is mounted as another icon on the desktop.
I’d say most people don’t regularly use 5.25″ drives in GS/OS and usually disable the driver. The reality is most 5.25″ software is either self booting or DOS 3.3 based. There is a DOS 3.3 FST, but its limited to read-only.
I think it’s fine to constantly poll 3.5 inch drives, as long as the polling is handled by the driver code and doesn’t require the disk motor to actually spin up and read the disk. One cheesy way to accomplish that would be to assume the disk is double-sided without actually checking it. That would probably break 400K disks under GS/OS though. A better way might be to use the SWITCHED register that I mentioned. Or I can dream up some other crazy solutions.
Despite its annoyances, the way that GS/OS handles 5.25 inch drives seems to work pretty well. Unfortunately it doesn’t handle Yellowstone 5.25 inch drives that way, because they’re not being recognized as the right type of drive. Instead they behave like some kind of crazy 140K hard drive and it doesn’t work very well with GS/OS. I’ve started looking at the GS/OS drivers book, but I’m not sure there’s going to be a solution for this. I’m not sure that GS/OS is even designed for the idea that two different disks sharing the same controller card could be of different types or require different drivers.
That’s good to know most people don’t normally use 5.25 inch drives in GS/OS anyway.
I discovered that I can get the correct 5.25 inch icon and behavior under GS/OS, with one very big exception, if I change the device type and subtype bytes in its DIB to 0A/00. I have been using 00/00 for 5.25 inch drives, which I copied from the original UDC ROM, even though the IIGS Firmware Reference says 00/00 means a type of “Apple IIgs memory expansion card” and is clearly wrong. 0A/00 isn’t listed anywhere as a meaningful value (the table of known values is in Chapter 7, page 124 of the Firmware Reference), but I found that value in a newer UDC ROM and decided to try it.
This would be great, except there’s a huge bug: if you remove the 5.25 inch disk and insert a new one, GS/OS continues behaving as if the old disk were present and will even show you its (cached) contents. Worse, if you insert a new disk and try to do stuff with the old disk that still looks like it’s there, it seems to corrupt the new disk. I verified this bug occurs when using the 0A/00 type bytes with Yellowstone, as well as with a real UDC short card with ROM version 4.0.
I’m not sure why that’s happening. It’s soooo close to the behavior I need, except for the weird inability to notice when a different disk is in the drive. I have a hunch it has something to do with whether GS/OS thinks the driver supports disk-switched errors. For the listed types in the Firmware Reference, a few of them have two subvariants, one that supports disk-switched errors and one that does not. My theory is that 0A/00 means the driver supports disk-switched errors, but since it never actually generates those errors, GS/OS behaves as if the disk was never switched. The solution may be as simple as finding a different type than 0A/00, but I have no idea how that value was determined in the first place, or what other values might be supported and what they mean.
Edit: found some more documentation on the type/subtype:
http://www.1000bit.it/support/manuali/apple/technotes/smpt/tn.smpt.4.html
http://www.1000bit.it/support/manuali/apple/technotes/smpt/tn.smpt.7.html
I would love to test any fix to the Floppy Emu with a fix for the issue you have above. I have a liron card with a unidisk 3.5 on my II+ and have issues like you mention above. If I swap out the unidisk 3.5 with the Floppy Emu in unidisk mode.
Would your FPGA have enough logic capacity to make the combination of a Yellowstone card and an attached 5.25″ drive appear to be a SmartPort device that happens to have 35 tracks of 8 sectors each (ideally responding to a request to read a sector on anything other than the most recent track read as a request to read a track, and fulfilling requests to read sectors from the last track read as requests to read from cache)? If so, that would not only make the card compatible with 5.25″ drives, but also allow improved read speed with them. The disk change issue could be resolved by watching the write-protect switch while a drive is active, and assuming a disk might change any time the drive is inactive (after the motor-spin timeout)
A 5.25 inch drive appears as a 140K Smartport or ProDOS block device, and software using the API won’t know anything about tracks or even that it’s a floppy disk. Other software based on DOS 3.3 or with a custom DOS will ignore the API and directly bang on the memory-mapped control registers, just like with a Disk II controller card or an IWM. Either way, it accomplishes the same thing. There’s no caching in the disk controller, but that’s an interesting idea. The card has 32K of RAM, of which only 2K is currently used.
I have the sketch of a solution for Yellowstone 5.25 inch drives and GS/OS, with some proof of concept code. Details are slightly murky, but I think the Yellowstone ROM routines need to return a fake disk-switched error or status bit for the Status, Read, and Write calls – fake because it doesn’t actually know if the disk was switched. The GS/OS loaded driver for 5.25 inch drives apparently uses a 1-second inactivity timer for this purpose, but I’m not sure why it doesn’t carry over to Yellowstone 5.25 inch drives.
Steve, odd thought. If your yellowstone sees a 5.25 drive. What about changing some throwaway bits in the signature to made the ROM signature match, match the apple ii controller card? Just a thought.
Because that driver isn’t being used for your card. That driver is only used for the built-in 5.25″ hardware or for a Disk ][ card (or clone). GS/OS is using a generated driver for your card. (Presumably using your card’s Smartport interface; generated drivers prefer to use the SmartPort interface (using Extended SmartPort if available), then ProDOS interface, then Pascal 1.1. interface, and fall back to BASIC interface (character devices only, obviously).)
A brief glance at … umm.. certain source code didn’t reveal any special handling of disk switched status in generated drivers. It just passes through whatever the SmartPort calls return.
Whereas the AppleDisk5.25 driver maintains a set of timers for its devices. On a read or write call it sets the timer for the device to 60. A VBL handler decrements the timer for each device if it’s non-zero. (VBL fires 60 times per second, so the disk will be marked as switched after 1 second of no I/O activity.) Since your Smartport code can’t depend on any timers on the Apple II (only the GS has built-in timers) it seems like you’d need to implement a timer on the FPGA and have your Smartport code query that.
Of course a GS/OS loaded driver for your card could implement a timer the same way as the AppleDisk5.25 driver, but it seems like it would be a lot easier to just use the GS/OS generated driver. (Certainly easier for users not to need to install a driver.)
Thanks Tim, I agree with your conclusions. Now that I understand the inner workings a little better, it mostly makes sense. I just hope I don’t accidentally break any normal functions while I’m adding this disk-switched timer for GS/OS, since the Yellowstone card’s ROM doesn’t know if a particular call comes from GS/OS or ProDOS or another application.
Yellowstone 5.25 inch drives are working nicely under GS/OS now. I implemented a pair of 1-second countdown timers for generating fake disk-switched events in the Smartport status handler, as discussed earlier.