Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: Disk timing
Message-ID: <1990Mar19.115619.19368@spectre.ccsf.caltech.edu>
Date: 19 Mar 90 11:56:19 GMT
References: <1848@crash.cts.com> <18491@boulder.Colorado.EDU> <12667@thorin.cs.unc.edu> <39559@apple.Apple.COM> <1990Mar17.112032.18 <1990Mar18.095408.1765@spectre.ccsf.caltech.edu> <90077.155936JLS139@psuvm.psu.edu> <429@helens.Stanford.EDU>
Sender: news@spectre.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 28

joe@hanauma.stanford.edu (Joe Dellinger) writes:

>In article <90077.155936JLS139@psuvm.psu.edu> JLS139@psuvm.psu.edu (Abaddon) writes:
>>In article <1990Mar18.095408.1765@spectre.ccsf.caltech.edu>,
>>toddpw@tybalt.caltech.edu (Todd P. Whitesel) says:
>>
>>    Correct me if I am wrong, but under DOS 3.3 wasn't disk access based
>>in software (RAM) and wasn't writing based on critical timing loops.

Sorry to nitpick but I didn't actually say that.

[ explanation of DOS 3.3 software timing deleted ]

I might add that the fact DOS 3.3 was RAM based meant that the computer acted
as the drive controller, and the interface cards and drive hardware could be
extremely simple as a result. This was one of Woz's greatest hacks and I think
it's probably the single greatest hardware hack in PC history. The fact that
it demanded a lot from the CPU didn't become a problem until recently when
we started using interrupts; the //c+ has a disk coprocessor and that takes
care of it.

The bulky drive controllers that everyone else was using at the time were far
more expensive than the Disk ][; this was a major factor in the inital success
of the Apple ][ and //e. That and the BASIC in ROM gave the base system quite
a few capabilities that people found endless use for, and still do today.

Todd Whitesel
toddpw @ tybalt.caltech.edu