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 realy. It was even more twisted. 16 sector was done for the Pascal System for the Apple II, independant and before the Apple III got it, but didnt 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 extrem slow, as every 7th block would 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 controler card. Usually also bundled with a language card (16KiB memory card).

At that time Apple was all about geting the Apple III to market. Management belived that it should be in any way superior and no II model should have similar capabilities. Thus disk controllers where still shiped 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 the second PROM onto the first and select each with a manual switch. From an Apple management point of view they where different markets (home vs. school) so they coudl 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 close to everyone at the company belived that the Apple II would be history half a year later. Well, history doesn't care for management and the Apple II still did run strong, so policies got revised to tap this by developing the LCA (Low Cost Apple), which became the Apple IIe. Its weired banking scheme is a result of the back then still existing policy that no II can be better than a III so 128k was defined as maximum memory. But thats another story.

Long story short, to satisfy 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.