From: fisher2557@iscsvax.uni.edu
Newsgroups: comp.sys.apple2
Subject: Re: Apple II RWTS codes.
Date: 26 Aug 92 11:23:24 -0500
Organization: University of Northern Iowa

In article <1992Aug25.073024.13293@ausom.oz.au>, paw@ausom.oz.au (Peter Watson) writes:
> Austin C. Phelps (bbs-aphelps@jwt.UUCP) writes :
> 
>>chiu@ucsee.berkeley.edu writes:
>>
>>>>In the Steve Wozniak interview at Kansasfest, Woz claimed that the RWTS
>>>>routines were probably the most difficult code he had ever written, and he
>>>>doubted if _he_ could do it again! You sure are aiming high!
>>>
>>>I'm sure he's just been polite. Word around is that he wrote a lot of it
>>>in only a couple of days...
> 
> I think you guys need to go a little deeper into your history. Yeah, Woz
> wrote a lot of the RWTS code in a couple of days - _BUT_ he spent a lot
> more than that playing around to get the essential read/write a nibble
> timing-CRITICAL code right, and I think that's what he was referring to.
> The "couple of days" bit was once he had routines that basically worked,
> he could then write something more elaborate for the computer show Apple
> were intending to demo the Disk ][ at. (They did demo it - with a 'DOS'
> only accepted single-key commands, on a disk with stuff stored at absolute
> sector locations!)
> 
> You should also remember that Woz 'only'(!) wrote the RWTS code - Randy
> Wiggington wrote the File Manager, and some third-party bozo wrote the
> DOS user interface (control-D commands, etc). Woz commented that this code
> looked like it had been generated by a high-level language compiler!
> 
>>And put together a DOS together in a couple of days. Beside in the book
>>Understanding the Apple IIe that author claims that ProDOS READ_BLOCK is
>>better and faster than RWTS.
> 
> The ProDOS READ_BLOCK routine is definitely faster than the equivalent DOS
> code, because it reduces the double handling that DOS did for most reads.
> But be careful - ProDOS pretty much uses the original RWTS subroutines for
> the actual read/write nibble routines. You can't speed them up, for the
> same reason that adding several women won't produce a baby any faster!
> 
>>Austin C. Phelps                bbs-aphelps@jwt.UUCP
> 
> Cheers,
> Peter
> -- 

well.......  yes you can.

In an old issue of Nybble, there is a program that custom formats each track,
allowing 4k to be written to each track in one chunk.  The denibblizing is done
"on the fly" so when it reaches the end of the "sector" (basically the whole
track is one giant sector) it is fully decoded and at the destination memory
address.  This sucker can read in a whole disk, all 35 tracks, in 12.5 seconds. 
Now that's not bad.  Writing requires nibblizing ahead of time, so it takes a
bit longer, but hey, with speed-up like that for read, who cares?  It's GREAT
for slide shows!  As fast as you can say "click-click" (and I DO mean AS FAST
AS YOU CAN SAY IT) it's loaded a hi-res image.  This is assuming the drive is
spinning and the head is at the correct track.  That's the ONLY slow-down. 
BEWARE.  There is a bug in the part that check for dos or prodos, and it can
accidentally put itself in prodos mode when you're in dos, which results in it
not operating properly.  As to direct disk access, I've written many an
assembly lang program to do direct reads and writes, and it's tough...  but
definitely worth it.  It's really fun to have Central Point interested in
seeing your code! ;-)   Pity they didn't want to pay for it, or they'd have a
copier that'd copy ANYHING.  period.
   If that guy is still looking for some info on direct disk access, send me $5
for photocopies and postage and I'll mail back some useful information,
starting at the hardware and ending at the ].  I highly recommend an asembler
that can count clock cycles!  (Merlin Pro works well)
 Nathan Fisher
 1157 Mitchell
 Waterloo IA 50702-3344
-- 

later,
 Nathan                           (this tag line is umop ap!sdn)
  FISHER2557@ISCSVAX.UNI.EDU             "do I know WHO?..."
Newsgroups: comp.sys.apple2