As 2021 draws to a close, Yellowstone is very nearly finished, with just a few details left to iron out. I recently tested a new v2.3 prototype with a couple of small PCB changes, and so far it’s looking good. The new PCB fixes an obscure problem with the Unidisk 5.25 and Disk IIc, where one of those specific drives connected as Drive 2 would interfere with another 5.25 inch drive at Drive 1. Initially I’d planned to write this off as a known compatibility issue, but I had second thoughts, and rushed through a new PCB revision.

Parts sourcing continues to be a major problem. The good news is that I was able to find more of the FPGAs that Yellowstone needs, but I had to go through a third-party dealer in Hong Kong and pay roughly twice the normal price. I have enough parts now to manufacture about 500 Yellowstone cards. Beyond that, the outlook is murky. I expect the semiconductor shortage to get worse before it starts getting better, and many parts are currently quoting lead times of a year or more. Given the current environment, Yellowstone should probably be considered a “limited edition” in 2022, with the possibility of some restock in 2023 or 2024.

I’ve received a couple of manufacturing quotes already from CircuitHub and MacroFab, two vendors with automated web-based quoting tools. These are helpful sanity checks and estimates, but they’re not yet fully baked quotes that I could move ahead with as-is. Optional features like beveled PCB edges and gold fingers require a custom quote. Programming and testing requirements are also difficult to factor in to automated quoting tools.

The preliminary information looks like beveled PCB edges and gold fingers would add about 30 percent (combined) to the total cost. I don’t know the cost breakdown between the two features. 30 percent is quite a lot, and I’m debating whether people will be willing to pay 30 percent more for a card with these features. The prototypes have square edges and ENIG fingers, and it doesn’t seem to have been an issue for the beta testers, so I’m leaning against including these extra features.

I talked to the support staff at Circuit Hub, and they were reluctant to discuss using my own-designed Yellowstone tester. They felt that the quality of their assembly process was so high, with automated visual and x-ray testing, that additional functional testing was unnecessary. And they stressed that if an assembly problem were ever found, I could send the board back to them for free rework. I admit to lacking experience here, but this makes me uneasy. It puts the onus on me to actually test each board before it’s sold, instead of having the vendor do it, but that’s exactly the type of work I want to outsource. And it assumes that free rework would make it acceptable to receive faulty boards. The cost of faulty boards is mostly lost time for testing and troubleshooting, not the cost of rework. By the time I’ve tested a board myself, confirmed that it fails, diagnosed the problem, and identified it as an assembly problem, I could probably just fix it in five minutes with a soldering iron. I’m not going to ship a board back for that. But I don’t want to be doing that kind of work in the first place. To be fair, they did say they would do functional testing if I really wanted it, but their process doesn’t seem to be designed for this, and they implied that it would be expensive.

I have the general impression that the automated quoting vendors like CircuitHub and MacroFab are geared more towards low volume prototyping, or simple projects involving common parts. I think they may not have the most competitive prices either, but we’ll see. For anything slightly non-standard, or for the most competitive pricing, I think it may still be necessary to go the traditional route of phoning or emailing a vendor, and having an actual person-to-person discussion about manufacturing options and requirements. I’ll be doing that soon.

One other interesting option is Seeed Studio’s Fusion PCB service. They have a semi-automated quoting tool, but the tool still needed some manual help to finish my quote, and even then it wasn’t entirely correct. However, the total quoted cost was less than half the cost from the two other vendors. They even agreed to include functional testing for free, but other options like beveled edges and gold fingers don’t seem to be available at all. The big downside is the two-way trans-Pacific shipping that would be needed. I would need to ship all the FPGAs to them for assembly, which they don’t really like doing, and which would create extra paperwork hassles and tax/tariff concerns. I would still prefer to work with a local vendor, or at least a vendor in the same country, if I can find one that’s competitive.

Most vendors are quoting lead times of about two months, so if I can get started with manufacturing soon, I could have product ready for sale by March. The lunar New Year holiday is fast approaching though, and that usually shuts down most Chinese businesses for a couple of weeks. That may delay the schedule, depending on what vendor and manufacturing process I ultimately choose. But barring any further unexpected problems, final Yellowstone cards should be available by March or April at the latest. Woohoo!

Read 6 comments and join the conversation 

Yellowstone is inching slowly towards the start of manufacturing. One question that’s arisen is the type of surface plating to use on the PCB. The default / cheap plating is HASL or Hot Air Solder Leveling, which is just a thin layer of solder, consisting mostly of tin. This is what BMOW’s other products use. But engineering wisdom says that for an edge connector, or any PCB surface that will send electrical signals across a mechanical contact surface, you should use ENIG plating. ENIG is Electroless Nickel Immersion Gold, and it’s a layer of nickel covered in a second layer of gold. It’s more expensive, but more durable.

So ENIG then? Well, maybe not. I recently learned about a problem called galvanic corrosion that occurs when two dissimilar metals are in contact for a long time. The peripheral card slots in an Apple II computer have tin fingers, I believe – at least they’re not obviously gold-colored. Does that mean an ENIG plated board inserted into an edge connector slot with tin fingers is doomed to contact corrosion and premature failure? A quick check of other Apple II peripheral cards in my office showed they all have gold-colored connectors. I’m uncertain if they’re ENIG or something else, but probably ENIG.

Read 9 comments and join the conversation 

While chasing down some Yellowstone hardware bugs, I discovered an unexpected analog-type behavior on the enable input of the Unidisk 5.25 (A9M0104). This is an active low digital input that’s used to enable or disable the disk drive. Under the right conditions, something inside the drive itself is creating a substantial load on this input signal, or actively driving the signal. So instead of a nice clean 0 to 1 transition, I see stuff like the graph shown above. When the intended enable output from Yellowstone switches from low to high, the actual signal climbs from 0V to about 3.3V (on a 5V system) for about 50 microseconds, then quickly drops to 1.2V, then starts slowly rising. Then about 250 microseconds later when the PHI1 input switches from high to low, the enable signal crashes to 0V before quickly recovering to 2.9V, and eventually reaching 3.3V again. This causes buggy behavior and errors. Hmmm.

This problem only happens when PHI1 is high at the time when the enable signal is de-asserted. If PHI1 is low, the the enable signal follows a clean transition from 0 to 3.3V:

If PHI1 is high, but remains high forever instead of transitioning like the first example, then there’s still trouble with the enable signal, but the crash to 0V doesn’t happen:

The Unidisk 5.25 isn’t a very common drive, and many Apple II collectors have never heard of it. For comparison, here’s a repeat of the first example with a common Disk II drive instead of the Unidisk 5.25. There’s something strange, but it’s not as severe, and the crash to 0V doesn’t happen:

That’s all the evidence. Now let’s look at some schematics to try and determine what’s going on here.

 
Schematics Research

Yellowstone has two independent disk connectors. This weirdness with the enable signal only happens when the drive is connected to Yellowstone’s J2, which uses a different method than J1 to create the enable output. For J1, the enable signal is actively driven high or low by a 74LS244. But for J2, the enable signal is actively pulled low by a 74LVC07, and passively pulled high by a 10K pull-up resistor to +5V:

This creates a weak enable high signal for J2, which is certainly part of the problem here. But before saying “you shouldn’t do it that way”, I’d like to understand why this doesn’t work here, and what exactly is going wrong.

The first oddity is that even when the system’s at rest, the enable voltage is about 3.3V rather than the expected value around 5V. Since the high signal comes from the 10K pull-up resistor, the voltage should theoretically be about 5V as long as nothing in the drive is consuming more than a tiny amount of current from the enable signal. So it seems something in the drive *is* consuming appreciable current from the signal, or is otherwise influencing the signal voltage.

The second oddity is PHI1’s influence. What does PHI1 have to do with anything, and why should it affect the enable voltage? The PHI0 to PHI3 inputs are normally used to control the stepper motor for switching between tracks on the disk. But the PHI1 signal also has a second purpose related to the write-protect detection circuit:

You can confirm this by checking the schematic for the Disk II analog board, although the write-protect switch itself isn’t shown:

(click the image for a hi-res version) PHI1 is routed through the write-protect switch and becomes the value for the WPROT output, and is also used to gate the WRREQ input and prevent writing to write-protected disks. This explains why PHI1 is different from PHI0, PHI2, and PHI3, but not how it might affect the ENABLE input signal’s voltage.

That’s the Disk II. What about the Unidisk 5.25? It should be very similar, but unfortunately I can’t find any reliable schematic of the Unidisk 5.25 analog board. There’s this Unidisk 5.25 schematic, but I’m not sure it’s what it claims to be. It shows a drive with two 25-pin connectors, but the Unidisk 5.25 only has a single 19-pin connector. There’s also this Unidisk 5.25 PCB image, but it also shows two 25-pin connectors. I think both of these may actually be for the Duodisk, or for some never-released prototype, rather than for the A9M0104 Unidisk 5.25. So we’re forced to guess about what’s inside the Unidisk 5.25, with the knowledge that it’s mostly the same as the Disk II except with a half-height drive instead of full height.

A few things on the Disk II analog board schematic are noteworthy. The ENBL input has a 1K pull-up resistor to +5V (R1), so the 10K pull-up on Yellowstone isn’t relevant or necessary for this particular drive. ENBL is connected to three digital inputs. Two are 74LS inputs with input current about 0.1 mA, and the third is some type of inverter/transistor array with an input current around 1 mA. That’s a fairly large amount of input current. If my math is right, 1.2 mA though the 1K pull-up resistor R1 would drop 5V down to 3.8V, which is at least in the general neighborhood of the 3.3V that I measured.

ENBL is also connected through a 1K series resistor R9 to something called -MTRON. That’s not shown, probably because it’s part of the Shugart drive mechanism and not the analog board. What’s there? Given the series resistor and the fact that ENBL is active low, I’m guessing maybe there’s a PNP transistor at -MTRON? What else is there? Could this be the source of all the strangeness?

When the write-protect switch is closed, PHI1 will have an extra 10K pull-up to 5V at R12. It will also be connected to a couple of 74L125 inputs. But I don’t see any capacitors or other interesting details on the PHI1 circuit path that might explain what’s happening. Except for the power supplies, I don’t see any inductors or capacitors anywhere that look like they might cause the weird behavior I’ve observed.

Could the +5V supply inside the Unidisk 5.25 be changing? It’s isolated from the external +5V input by an inductor, so it’s possible. And resistor R1 would cause any large change on the internal +5V to influence the ENBL voltage too.

It’s worth mentioning that the Unidisk 5.25 is known to have something strange about its write-protect circuit behavior, and the drive isn’t compatible with the Apple IIgs ROM 03. But I’ve never found any definitive explanation for just what it is about the Unidisk 5.25 that’s different. I discussed this in another blog post from a few years ago, but in a different context, and my information about the Unidisk 5.25 was mostly speculation:

Apple IIgs ROM 03 Headaches

There’s also a Unidisk 5.25 analog board Twitter thread in which another Apple II hacker pondered some of the same questions about the write-protect circuit, but I don’t think he ever found answers.

According to some Yellowstone beta testers, the Disk IIc A2M4050 also has similar problems when it’s connected to Yellowstone’s J2. I don’t have a Disk IIc, so I can’t confirm if it’s the same enable voltage problem as the Unidisk 5.25, but I’d bet it is.

 
Solutions?

Without knowing exactly why the Unidisk 5.25 behaves this way at Yellowstone’s J2, I can still see a few potential solutions.

The easier solution is to make the enable signal’s pull-up stronger, so it more closely approximates an actively-driven signal’s logical high output. I was able to test this by paralleling an additional resistor with Yellowstone’s pull-up. I tried successively smaller and smaller pull-up resistor values (stronger pull-ups), and the enable signal gradually improved, and the “crash to 0V” became a crash to 0.5V, then 1.0V, etc. With 470 ohms in parallel with the original 10K ohms, the low point of the crash was improved to 2.0V and the drive began working normally. This solution acknowledges that something unexplained is pulling ENBL low, so it compensates by pulling ENBL high more strongly. But it doesn’t actually explain the problem, and it means about 12 mA would be wasted in Yellowstone’s 74LVC07 whenever J2’s enable is driven low.

The better solution is probably to redesign the Yellowstone PCB, so J2’s enable can be actively driven high and low, instead of using the ’07 and a pull-up resistor. Then J2’s enable circuit would match J1’s. I didn’t do this initially because I ran out of buffer pins, and didn’t want to add another chip just for this one signal. Even now, when I consider the prospect of revving the PCB yet again, and going through another round of verification and beta testing, I feel sick.

A possible third solution might be to leave the hardware as-is, and solve the problem in firmware. Since I’ve characterized the problem and when it happens, maybe I can tweak the firmware to avoid it. For example, maybe I can ensure PHI1 is always low before J2’s enable is de-asserted, or else insert a few milliseconds of blanking time whenever J2’s enable is de-asserted, to ensure nothing else happens while the enable signal voltage is acting strangely. But any firmware solution would be more like a bandage than a true fix, so it’s probably better to identify and fix the root cause.

Read 5 comments and join the conversation 

Here’s the part of our program where I describe a problem I’m having, and somebody tells me what I’ve done wrong, because I’m not smart enough to figure it out myself. The problem is with the Yellowstone disk controller, the Apple IIgs, and 80 column display mode. It’s a minor issue, but so far it’s defeated my attempts to fix it.

If you hold the Control-D keys during boot-up, Yellowstone will change its behavior and briefly display a text message “YELLOWSTONE DISK II MODE”, then continue booting. This works well on all the computers that the beta testers and I have tried, except for the Apple IIgs when the display type is set to 80 column mode. In this one case, the computer immediately crashes into the Apple II monitor when cold booting and holding Control-D.

• Holding Control-D during a reset works OK. It only crashes from a cold boot after you turn on the power switch.
• If the IIgs display type is set to 40 column mode, it works OK.
• If I replace the calls to HOME and COUT (the ROM’s text output subroutines) with NOP instructions, then it doesn’t crash anymore in 80 column mode, but I don’t get my text either.

I’m guessing there is 80 column firmware somewhere that’s not yet initialized during a cold boot, or that some Apple II soft switches for 80 column mode aren’t yet configured. That would explain why it works OK when I reset the computer with Control-OpenApple-Reset, and only fails from a cold boot. I vaguely recall reading somewhere that 80 column support is implemented as a virtual peripheral card in slot 3, which won’t have been initialized yet when my card in slot 6 is being initialized, because higher numbered slots are initialized first.

According to the docs, the soft switch at address $C00C will turn off 80 column mode. I tried making the Yellowstone firmware touch this address before calling HOME and COUT, but it still crashes. I also noticed that touching $C00C interactively from the Apple II monitor prompt will turn off 80-column mode but also locks up the computer with a weird animating pattern, so I’m not sure that’s the correct method of disabling 80-column mode. These Apple II soft switches can sure be challenging to understand.

Read 6 comments and join the conversation 

The goal of a “do everything” disk controller for Apple II is getting closer to reality, thanks to the efforts of the hard-working beta testers. If all goes well, I’m hoping to have Yellowstone cards available for sale in the first months of the new year. Yellowstone is designed to support virtually every type of Apple 5.25 inch, 3.5 inch, or smart disk drive that exists, including Macintosh drives running on the Apple II, and the results from the beta testers have been very encouraging so far. But it’s not all perfect. Here are a few of the issues that beta testing has uncovered.

 
Unidisk 5.25 and Disk IIc Problems at Drive 2

The Unidisk 5.25 and the Disk IIc work fine when connected as Drive 1, but in some situations they appear to interfere with Drive 1 if they’re connected as Drive 2. I don’t have the hardware needed to troubleshoot this one directly, but I should be receiving a Unidisk 5.25 next week. My best guess is that the outputs on these drives have a different type of driver circuit than other drives, which causes the tri-state signals to take longer than normal to get pulled to a logical “1” voltage by Yellowstone’s pull-up resistors. So their “0” outputs effectively overlap with Drive 1’s. Or it may be something completely different.

 
Third-Party 3.5 Inch Drive Problems

All of the Apple-brand 3.5 inch drives are working, including the Apple 3.5, Unidisk 3.5, Apple SuperDrive, and various Macintosh 3.5 inch drives. But third-party drives from Applied Engineering, Dataspace, Ehman, and Laser only work sporadically or don’t work at all. The Applied Engineering 3.5 drive is supposed to work with a stock Apple IIgs, but the other three reportedly don’t work with any stock Apple computer or disk controller, but do work with the original UDC disk controller. (It seems like that would have greatly limited their sales appeal.) I have a Laser 3.5 for testing, and I should be receiving an Applied Engineering 3.5 drive next week.

 
Obscure Crash on Apple IIgs

If your IIgs is configured for 80 column mode, and you use one of the several methods to enable Yellowstone’s Disk II mode immediately from power-on, it will crash. This doesn’t happen after a warm start or reboot, only directly from power-on. It also doesn’t happen in 40 column mode. I suspect my code that prints “YELLOWSTONE DISK II MODE” is doing something bad in 80 column mode. It just calls the HOME and COUT routines in the Apple II ROM. I haven’t looked into this further yet.

 
3.5 Inch Disk I/O Speed

Depending on what software you’re running and what you’re doing with it, 3.5 inch disk I/O through Yellowstone is anywhere from a little to a lot slower than 3.5 inch disk I/O with the same drive on the Apple IIgs built-in disk port. 5.25 inch disk I/O and smart disk I/O (like the Unidisk 3.5 and Floppy Emu Smartport Hard Disk) are about the same speed as the Apple IIgs built-in disk port. I’m not sure why 3.5 inch I/O is behaving differently, but it may be some combination of sector interleave and code optimization.

 
Possible Disk Corruption with VidHD

One tester reported that a specific Apple IIgs hardware configuration including VidHD would corrupt 3.5 inch disks during power-up. When VidHD was removed, the problem disappeared. I think this is actually a VidHD problem and not Yellowstone. There was a long discussion on Facebook’s Apple II group earlier this year about people experiencing disk corruption when using VidHD. Initial reports were that the latest firmware fixed it, but that was later called into question.

 
Possible Problems with TransWarp Accelerator

One tester reported problems when running Yellowstone on a specific unenhanced Apple IIe system with a TransWarp accelerator. The problem didn’t appear with the TW on a different computer, and couldn’t be confirmed by the only other tester with a TransWarp. For now it’s unclear if this is a Yellowstone problem or something else.

 
Cable Routing Difficulties

A few testers reported that the disk ribbon cables were difficult to route through the opening in the rear of the computer, or that the cables pushed against the card in the neighboring slot. I’ve experimented a bit with using right-angle connectors and some other ideas, but there’s probably nothing much I can do without changing the entire board layout. I think the testers experienced this frustration more often than a typical user will, because the testers are constantly plugging and unplugging different drives in order to verify them.

There are a few more open issues beyond these, but most of them are hopefully at the level of errata, and don’t need to delay production of the final Yellowstone cards. Any Yellowstone firmware bugs that are discovered after launch can be fixed with a firmware update, which can be done in-system on the Apple II computer without any special programming tools.

Be the first to comment! 

In the world of Apple II disks, there are two major types of disk controller cards: the original Disk II controller (and clones), and everything else. Both have their place. The “everything else” category includes the Apple 3.5 disk controller card, Liron card, SCSI cards, IDE cards, and more. These cards provide a standard API for software to read/write blocks, get drive status, and format the disk, all without requiring the software to know anything about how the disk actually works. These cards have built-in smarts to handle the low-level details. In contrast the original Disk II controller card is dumb as dirt, and forces the software to handle virtually all of the low-level details. And yet it’s an amazing piece of technology for its time.

The first Apple II models had no built-in floppy disk support. The Disk II controller was cleverly designed to add that missing support at a very low cost, and was a major reason why Apple II computers became so popular. This disk controller was simpler, and cheaper, and more flexible, and just all-around better than any of its contemporary competition. It’s the ultimate example of Woz can-do technology.

 
Floppy Disk 101

A floppy disk is just a plastic circle with a magnetic coating. Loaded into a drive, the disk rotates at about 300 RPM. A stepper motor moves the read/write head linearly from the center of the disk to the outer rim. This arrangement provides for a few dozen concentric rings where a serial stream of 1s and 0s can be stored.

How do you get from these basics to higher-level concepts like bytes, tracks, and sectors? How are logical data bytes encoded into bit patterns on the disk? When reading the disk, how are the bits framed into bytes? How do you find track zero, or the boundaries between sectors? The conventional answer to these questions in the 1970s was extra hardware, and lots of it. This made the disk controllers and the drives themselves complex and expensive, putting them mostly out-of-reach for an inexpensive home computer system.

It was late 1977 when Apple set its sights on finding an alternative to cassette tape data storage, and began looking into options for a floppy drive for the Apple II. They were still a small and unproven company, and the Apple II had only been available for about six months. Woz didn’t know much about the subject of floppy disks, but he agreed to take on the challenge.

Woz’s approach was to remove virtually all of the hardware that controls the disk, and take a software-driven approach akin to bit-banging. Apple went to Shugart, the inventors of the 5.25 inch floppy drive, and requested a stripped-down version of Shugart’s SA400 drive with most of the control electronics removed. It was just a simple mechanism with one motor for spinning the disk and a stepper motor for moving the read/write head. As the legend goes, the entire Disk II hardware design was conceived and built by Woz and Randy Wigginton over a few weeks during Christmas vacation 1977, including writing the first version of DOS, and the working disk drive was demoed at CES in January 1978. Additional help was provided by Apple engineers Cliff Huston and Wendell Sander. 40+ years later I’m amazed by how quickly this small team was able to make everything work.

A few years ago I asked Woz about the Disk II development, and he said this:

I have no idea how I came up with that incredible disk controller. I was good at creating anything in electronics, analog or digital. I had no prior experience of any kind, not even in classes, regarding disk hardware or software. So my thinking had to be from the ground up. I had to sense data coming from the disk and make decisions about 0’s and 1’s based on timing.

I had taken a graduate level course at Berkeley (although an undergrad, I only took grad courses in anything having to do with computers in any university) on state machines and thought of how I could use 2 simple low cost chips as a state machine to do this, sort of a minimal microprocessor hand-built. At the time I just knew that it would read and write data but I assumed that I was leaving out many ingredients of a disk controller due to not knowing what they did. I assumed this because my design took so few parts. But in the end, mine did more in some good ways, especially since it was in the computer and tied to software that could alter how it worked, which eventually led to greater storage and faster speed that would not have been possible using the normal disk. Plus, I took about 20 chips off the drive itself and bypassed them from my own controller, because they were just middlemen that got in the way of things.

The best work I did, over and over, was partly due to not having money and having to learn how to use the fewest parts of anyone, and also due to the fact that everything great I created I had never done before.

 
A Tour Of The Disk II Controller

The Disk II controller card is basically just a fancy shift register. It knows how to read and write bits at a fixed rate of 1 bit every 4 microseconds. The card also has a tiny 256 byte ROM containing bootstrap code that runs when the computer first turns on. It’s a minimal 6502 program with just enough smarts to locate track 0, sector 0, load it into the computer’s memory, and then execute it. Every other aspect of disk control is handled by software.

The card contains only eight simple chips. There’s a 256 byte ROM containing the bootstrap code, and a second 256 byte ROM used as part of a state machine (more on this in a moment). There’s also a 74LS174 hex flip flop providing the inputs for the state machine. A 74LS323 eight bit shift register is the heart of the whole design. A 74LS259 addressable latch stores the desired state of the motors and the drive 1 or 2 selection. There’s a 556 dual timer, and a 74LS05 hex inverter and 74LS132 quad NAND to provide some needed glue logic. That’s it. That’s the entire disk controller. Here’s the schematic:

Let’s go through the challenges of floppy disk I/O one at a time, and look at how the Disk II controller design solved them.

 
Challenge #1: byte framing. The data coming from the disk is a continuous stream of 1s and 0s, and there are no start or stop bits. So how do you know where one byte ends and the next byte begins? Woz’s solution was to require that every byte written to the disk have 1 as the most significant bit. During a disk read, the state machine takes bits from the disk one at a time, moving the shift register one position left and appending the new bit at the right. It keeps going until the left-most bit position holds a 1, at which point the state machine says “Aha! Here is a complete byte!” Then the CPU stores the byte, and the process begins again. The state machine clears the shift register after the MSB becomes 1, so it’s ready to shift in the eight bits for the next byte.

By itself this solution isn’t enough. If the state machine starts reading bits in what was actually the middle of a byte, it will probably misinterpret a 1 bit in the middle of the byte as being the 1 bit for the MSB position. But this scheme ensures that if the state machine gets the byte framing correct just once, whether by luck or another method, it will continue to be correct from then on. So the challenge is finding a way to guarantee the framing is correct before beginning to read disk data.

The conventional solution is to write a special 50-bit pattern of so-called sync bytes to the disk, immediately before each sector. These aren’t really bytes at all, but a 10-bit pattern 1111111100 repeated five times. This pattern has the interesting property that no matter where the byte framing is initially, it will fall into correct synchronization after at most five repetitions of the pattern, just by following the state machine rules described previously. This solution is entirely software-driven, and is merely a convention. The hardware itself has no mechanism to guarantee correct byte framing. There are other methods of ensuring framing, and some of the bizarre richness of Apple II copy-protection schemes arises from different approaches to framing taken by the custom I/O routines in many games.

 
Challenge #2: byte encoding. If every byte written to disk must have 1 as the MSB, then how do you write a zero byte, or any other byte with a value less than 128? And there are other restrictions too: every byte written to disk must have no more than two consecutive zero bits. If there are three consecutive zero bits, the disk hardware can’t reliably read back the data. Given these two requirements, there are only 66 possible 8-bit values that are permitted to be written to the disk. How then can arbitrary 8-bit values be stored?

The answer is to split up the logical 8-bit bytes, and store their bits in subgroups as part of multiple disk bytes. The standard way of doing this is a GCR encoding scheme called 6-and-2. With 66 possible values for the disk byte, and two reserved values, that leaves 64 possible disk bytes for encoding data. 64 is 2 to the 6th power, so six logical bits can be encoded in every disk byte. A series of three disk bytes can encode the first six bits of three logical bytes, and a final fourth disk byte can encode the last two bits of the three logical bytes, concatenated together. This means the number of bytes stored on disk is 4/3 times the number of logical bytes, ignoring headers and checksums and padding.

You might wonder how the Disk II controller bootstrap code accomplishes the GCR decoding for sector 0, track 0. At first glance, it would seem to require storing a 64-entry reverse lookup table in ROM, which is already one quarter of the very limited ROM space available. The bootstrap code actually uses a much cleverer solution, and constructs a 256-entry forward lookup table in RAM on the fly, using only 30 bytes of 6502 code!

The Apple II floppy byte encoding has evolved over time, resulting in a changing number of sectors and total disk capacity. The first version of the Disk II controller card didn’t permit any consecutive zeroes to be written to the disk. This further limited the number of possible disk bytes, and forced the use of a less efficient 5-and-3 encoding scheme. It was only possible to fit 13 sectors per track, resulting in 114 KB total disk capacity. Apple DOS 3.1 and 3.2 used the 5-and-3 scheme. Eventually Woz or one of his teammates realized that with a small change to the state machine, it would be possible to read two consecutive zeroes reliably. All it required was a change to the contents of the state machine ROM, essentially fixing a small bug in order to make the bit timing measurements more reliable. No hardware changes were needed to the Disk II controller. The more efficient 6-and-2 scheme was introduced beginning with DOS 3.3, ushering in the 16 sector tracks and 140K disks we’re familiar with now.

As with the byte framing, this whole encoding scheme is purely a software convention. There’s nothing about the hardware that implements 6-and-2 or 5-and-3 or any other encoding method. Sector 0 track 0 must be encoded using 6-and-2, because that’s what the ROM bootstrap code expects, but after that anything goes. Software is free to use any other encoding scheme it wishes, and many copy-protected programs use novel encoding schemes in order to obfuscate their workings.

 
Challenge #3: sectoring. Once you’ve got the bitstream correctly framed into disk bytes, and the disk bytes correctly decoded into logical bytes, how do you make any sense of the data? It’s a ring buffer, so how do you know where the data begins and ends? 1970s floppy disks often used one or more small holes punched in the disk at regular intervals around the circumference. A small opening was cut in the disk’s dust jacket in order to reveal the index holes as they passed underneath. Hardware inside the disk drive sensed when these holes passed by as the disk rotated, and this information was used to determine where a new track or new sector began.

It’s easy to see why this might be undesirable. The hole-sensing hardware adds extra complexity and cost. And in the case of hard-sectored floppies with a hole for every sector, the number of sectors becomes part of the hardware design and can’t be changed. Apple’s move from 13-sector to 16-sector format would have been impossible with hard-sectored disks.

The Disk II design takes a software-driven approach to sectoring. Any index holes on the disk are ignored. When it wants to find a particular sector on the current track, the computer begins reading bytes, ignoring everything it sees until it finds the three-byte sequence D5 AA 96. This signature marks the beginning of a new sector on the disk, and is possibly the most famous byte sequence in the entire kingdom of Apple II arcana. On the wall of my office hangs a 5.25 inch floppy disk with a D5 AA 96 greeting signed by Woz himself:

A short sector header follows this signature, and among other things the header contains the sector number. If it’s the sector number the computer was looking for, then it reads the bytes that follow. If it’s not the right sector, then it keeps looking for another D5 AA 96 to indicate the beginning of the next sector, and tries again.

This whole business is – you guessed it – purely a software convention. The D5 AA 96 signature, the sector header, the length of sectors, and everything else are merely conventions. There’s nothing whatsoever about the Disk II controller card hardware that requires software to work this way, and some software takes a different approach. One well-known example was the game Prince of Persia, which used a custom scheme called RWTS18 that was optimized for reading as opposed to writing, and used six 768-byte sectors per track instead of the standard sixteen 256-byte sectors.

 
Challenge #4: finding tracks. So far we’ve only discussed data in a single one of the concentric rings on the disk. These rings are usually called tracks, but as we’ll see, the definition of exactly what constitutes a track can sometimes be fuzzy. So how do you switch between tracks, or locate a specific track? And just how many tracks are there? The Disk II and its controller hardware don’t answer these questions. Instead, it’s all (say it with me now) software-driven.

On the disk media there’s no such thing as a track – it’s just a featureless round expanse of magnetic media. Tracks are created when the read/write head remains at a fixed radial position while the disk spins underneath and bits are written. Then the head moves inward or outward to a new radial position, and writes a new track.

The head movement is controlled by a stepper motor, under direct software control. The stepper consists of four electromagnets, and at any moment the software can turn any of them on or off. A series of permanent magnets are attached to a gear that moves the read/write head, and by activating the electromagnets in the right sequence, they can attract or repel the permanent magnets and move the head. If stepper electromagnet 0 was on, and then electromagnet 1 is turned on and electromagnet 0 turned off, the head will move a small radial distance. Then if electromagnet 2 is turned on and electromagnet 1 turned off, the head will move further in the same direction.

How closely can you space the tracks? It turns out that two of these head movements are normally needed in order to move the head far enough so that a track won’t interfere with its neighbors. If you try to write tracks with only one head movement between them, the magnetized areas of the disk media from the adjacent tracks will bleed into each other and cause a mess. For this reason, two movements are normally considered to be equal to one track, and a single movement is a half track. Quarter tracks are also possible, but aren’t used by most software. If electromagnet 0 was on, and then electromagnet 1 is also turned on, the head will move a quarter track. If electromagnet 0 is then turned off, the head will move an additional quarter track.

The method of locating track 0 is as crude as can be. The disk controller doesn’t know at what track the read/write head is currently located, so software must activate the stepper motors in sequence in order to move the head continuously in the direction of track 0. Eventually the head will reach track 0 and can move no further, but the software will keep activating the stepper motors, driving the head against a mechanical stop and producing the familiar rat-a-tat sound of an Apple II floppy drive during boot-up. After 80 half steps, the head is guaranteed to be at track 0. From that point on the software must keep track of all stepping movements, and remember what track the head is currently on, in order to perform relative steps. If the software gets confused, say by reading what it thinks is track 20 but finding data for a different track there, it will usually recalibrate by repeating the track 0 seek and then immediately stepping back to the desired track. This creates a clack-clack sound that many long-time Apple II users will recognize as the sign of a failing disk.

It’s customary to store 35 tracks per disk, but this is merely a convention. The true limit varies slightly from one drive to the next, and is determined by the maximum and minimum linear positions of the read/write head. Non-standard disks with up to 40 tracks are sometimes seen.

Copy-protected Apple II games very often play funny tricks with track stepping. A simple trick is locating a track at some odd number of half-steps from track 0. Tracks must be at least two half steps apart, but there’s no rule saying they can’t be three half steps apart, so you might find a game disk with data on tracks 0, 1, 2.5 and 4. This will confuse disk copy programs that only expect to find data on integer numbered tracks.

A more advanced trick is writing data on two tracks that are just a half step apart, but only using half the circumference of the disk for each track, so the magnetized areas won’t interfere with each other. There might be a half-track’s worth of data at track 2 from twelve o’clock to six o’clock around the disk, and then another half-track’s worth of data at track 2.5 from six o’clock back around to twelve o’clock. Data that’s written this way is easy to read, but is difficult to write without specially-crafted routines, making disk copies difficult.

 
Bootstrap Code Disassembly

A disassembly and analysis of the 256-byte bootstrap routine is fascinating. Starting with literally nothing, this code must bang directly on soft switches to control the stepper and read the shift register. It must activate the stepper electromagnets in the right pattern to reach track zero, and then begin reading bytes. It must recognize the D5 AA 96 signature, and check to see if it has the right sector. It must use a GCR decode table which it constructs on-the-fly in order to convert disk bytes. It must perform 6-and-2 decoding to reconstruct three logical bytes from four disk bytes, load the whole sector into a RAM buffer, and then jump to the just-loaded code. And all of this in only 256 bytes!

Woz gets the job done with five bytes to spare, and only about 100 lines of 6502 assembly code. But due to space constraints, some features were omitted. The Disk II controller bootstrap code doesn’t verify the checksum on sector 0, something that was “fixed” in later disk controllers but caused incompatibility with some games. There’s also no error handling, so the bootstrap code will keep trying forever to load sector 0. This explains why an Apple II with Disk II controller card appears to hang during booting if there’s no disk in the drive, or a bad disk, rather than show a nice error message like the Apple IIc or IIgs.

 
Disk II Controller Hardware Design

This discussion has focused on what the Disk II controller does, without going into much detail about precisely how it does it, and how those eight chips are used. For an excellent and very thorough breakdown I recommend reading Chapter 9 of Understanding the Apple II by Jim Sather. It goes into additional detail about the flux patterns on the disk and much more.

The design of the state machine is quite interesting, and I haven’t seen it described anywhere other than in Sather’s book. Anyone who remembers concepts like Mealy and Moore state machines from a long-ago class will recognize Woz’s work. The state machine ROM is just a simple lookup table. Its inputs are the current state, the read/write mode, the MSB of the shift register, and the next bit coming from the disk. The outputs are the next state and a set of control signals. Depending on the control signals, the state machine may shift the value in the shift register and append a zero or one bit, or clear the shift register, or parallel load the shift register from the data bus.

The state encodings are carefully chosen such that state bits can double as control bits. For example, when writing data to the disk, the value on the write head is also the most significant bit of the current state number. When reading data from the disk, the state sequences are chosen so as to frame pulses corresponding to 1 bits into an appropriate 4 microsecond window, and insert zero bits whenever 1.5 bit windows (6 microseconds) have elapsed without seeing a pulse. For my Yellowstone FPGA-based disk controller I’ve implemented the equivalent functionality in a hundred lines of Verilog; Woz did it with a 256-byte ROM and a hex flip-flop.

 
Putting It All Together

The words “software-driven” have come up again and again here, and that’s the theme of the Disk II controller. It enables a very flexible design using minimal hardware, but it pushes a tremendous amount of complexity onto the software. Modern software designers might call this bad practice, and would prefer to see that complexity abstracted away behind a standard interface, so the software only has to be concerned with actions like “read block 31”. And that’s exactly how all other Apple II disk controllers work. But in order to work with a Disk II controller, software like DOS 3.3, ProDOS, and most games need to include tons of extra code for manipulating the stepper, locating sectors, performing GCR decoding, and the whole kitchen sink. It’s a little bit crazy, but it works.

If you’ve read this far, you may be interested in the BMOW Floppy Emu disk emulator. Collectors of old Apple II, Macintosh, or Lisa computers will find the Floppy Emu invaluable for running software downloaded from the web, and transferring files between vintage and modern machines. The Floppy Emu stores hundreds of disk images on an SD memory card, and uses custom hardware to mimic many different kinds of Apple floppy disk drives and hard drives. Read more about it here.

During the 10+ years I’ve spent delving into every aspect of Apple’s disk drive designs, it’s been a remarkable journey. Years ago I used to think I understood how it all worked, but today I realize I hardly knew anything at all. Now I believe I’ve got everything mapped out, but of course there are probably still holes in my understanding that I’m blind to. Did I explain anything incorrectly here, or forget to mention something important? Let’s hear about it. Please leave a comment below.

Read 9 comments and join the conversation