Was Apple DOS 3.3 created because of the Apple III?

Question

I recently read a document which discussed how the Apple III would implement the Apple II emulation mode. On page 20, it goes on about difficulties involved with how the Apple III would have presumably a 16-sector disk format and how would an emulation mode work when the Apple II's DOS 3.2 was only 13-sector. It goes a bit more into how this would create maintenance implications with a worst case being supporting 5 versions of DOS 3.2 (the current one, a conversion one, a standard one and then 2 for the Apple III emulation).

Nowhere in that document did I see anything suggesting that DOS 3.3 with a 16-sector format was planned or upcoming which leads me to suspect that perhaps DOS 3.3 was created simply to make it easier for Apple III emulation?

So was DOS 3.3 and the Apple II's conversion to 16-sector format disks directly an influence or result of the Apple III's emulation mode?

Answer 1

TL;DR: No, not really. It was even more twisted. 16 sector was done for the Pascal System for the Apple II, independently and before the Apple III got it, but didn't get rolled out for DOS until after the Apple III was introduced (and failed).

---

Wozniak developed the 16 sector format in 1979 for the Apple Pascal System, as otherwise the UCSD P-System would not only be space constrained, but also extremely slow, as every 7th block would be spread across two tracks. The Pascal System went on sale as a set of disks and a PROM to be placed on the Disk II controller card. It was usually also bundled with a language card (16 KiB memory card).

At that time Apple was all about getting the Apple III to market. Management believed that it should be superior in every way and no II model should have similar capabilities. Thus disk controllers were still shipped with 13 sector PROMs and DOS 3.2 only supported 13 sector format. The 16 sector format was reserved for the Apple III (and Pascal). The Apple II emulation included a 13 sector RWTS, to be loaded before accessing any Apple II disks.

This created a situation that Pascal could use the same disk as DOS with about 20% more space and even worse, people using Pascal and DOS had to swap PROMs (or own two controllers). A very common hack was to solder the second PROM onto the first and select each with a manual switch. From an Apple management point of view they were different markets (home vs. school) so they could have different hardware, but reality was different and users became quite demanding to upgrade while using DOS.

The Apple III was introduced in spring 1980 and almost everyone at the company believed that the Apple II would be history half a year later. Well, history doesn't care for management and the Apple II was still runing strong, so policies got revised to tap into this by developing the LCA (Low Cost Apple) which became the Apple IIe. Its weird banking scheme is a result of the policy, still in effect at the time, that no II can be better than a III - so 128 Ki was defined as the maximum memory. But that's another story.

Long story short, to satisfy the demands of Apple II users for more disk space (and to generate additional sales), DOS got a facelift and the 13 to 16 sector kit was made available.

Answer 2

No, conversion to 16-sector format (and the necessary change from DOS 3.2 to DOS 3.3) was a consequence of Steven Wozniak realizing that he could get more capacity by tweaking the Apple II floppy driver controller hardware slightly. To quote from here:

After the Disk II had been in production for a while, Woz found out that the 8μs spec for the maximum allowable gap between flux reversals was overly conservative. The original Shugart format would generate longer gaps than 8μs in the code violation byte employed for address mark sync. The head amplifier's automatic gain control still coped tolerably well until reversals occurred maybe 14-15μs apart; 12μs was no problem. So he tweaked the Woz Machine PROM a little to stop it drifting out of sync when faced with more than one missing RDDATA pulse, and designed an improved GCR scheme based on disk nybbles that could now contain up to two successive zero bits. It turns out there are 66 of those, and reserving the same $D5 and $AA values for headers leaves just enough to represent 6 bits of user data per disk nybble.

The new two-zeroes rule also allowed for a much shorter self-sync sequence. Instead of eight nybbles written with 36μs spacing, self-sync needed only four at 40μs before the $D5 $AA mark sequence. [...]

Now there was room for 16 sectors per track, raising Disk II capacity to 143,360 bytes.

If I remember correctly, there were actually upgrades (probably in the form of new PROMs, don't remember the details) for early disk controllers, which wouldn't be able to work with the new 16-sector format otherwise.