Apple II software often used hard-coded timing for 5.25 inch floppy disk I/O, for example to control the duration of each track step or the rate at which bytes are written and read from the disk. Since the Apple IIGS had a faster 2.8 MHz CPU than earlier 1 MHz Apple II models, code that performed disk I/O needed to be slowed to 1 MHz execution speed in order to work as expected. How was this done?
I think I know part of the answer: the first sector on a 5.25 inch floppy disk is loaded into RAM using a small ROM routine located at $C600. This is the IIGS's built-in equivalent of the Disk II Controller Card. As I understand it, the CPU is automatically slowed to 1 MHz when executing code from this memory range. And the CPU is also slowed to 1 MHz when accessing memory-mapped I/O locations used by the disk controller hardware.
But after sector zero is loaded into RAM, most disks would begin a bootstrap process in which additional code for handling disk I/O was loaded to RAM and executed directly from RAM. For DOS this would be RWTS; for other disks it might be something custom. How did the IIGS know to also run this code at the slower 1 MHz speed?
I've been using a logic analyzer to examine the disk I/O activity while booting a DOS 3.3 System Master and a few other 5.25 inch floppy disks on a IIGS. I've examined the lengths of the pulses on the PHASE inputs when stepping between tracks, as an indicator of the speed at which the disk I/O code is running. Using the IIGS built-in disk controller, the pulse lengths are the same whether the CPU is set to fast (2.8 MHz) or normal (1 MHz) speeds, and disks loads normally at either speed. But with the custom disk controller card that I'm developing, after sector zero gets loaded, the pulse lengths are about 2.5x shorter when the CPU speed is set to fast, and most disks don't boot properly. It seems that I've inadvertently broken whatever mechanism the IIGS normally uses to keep disk I/O code running at backwards-compatible 1 MHz speeds. How is that handled normally?