[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple ][ plus 13 sector! Problems...
- Subject: Re: Apple ][ plus 13 sector! Problems...
- From: mjmahon@aol.com (Michael J. Mahon)
- Date: 20 Jul 2004 19:08:20 GMT
- Newsgroups: comp.sys.apple2
- Organization: AOL http://www.aol.com
- References: <cditc0$2mo0$1@merope.saaf.se>
- Xref: g2news1.google.com comp.sys.apple2:2274
Paul Schlyter wrote:
>In article <qhhds3plac.fsf@ruckus.brouhaha.com>,
>Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote:
>
>> The final case occurs if the the start of the read is at the 0 bit. Because
>> the controller detects that it has read a full nibble by the most
significant
>> bit of the shift register being 1
>
>No, the controller doesn't detect anything by the MSB being 1. The
>controller merely transfers whatever bits it reads off the disk into
>its 8-bit shift register. Then it's the responsibility of the software
>(i.e. RWTS) to read a valid nibble by reading the shift register at the
>appropriate time.
>
>It's a tight loop in the RWTS which decides when a valid nibble is in
>the shift register (= when the high bit is a 1):
>
>nibloop: LDA (addr_of_shift_reg),X BPL nibloop
>
>where X contains the disk controller slot number multiplied by 16.
Actually, the controller state machine _does_ detect the
MSB going to 1, and enters a special sequence which keeps
the data in the shift register valid (and unshifted) for at least
two bit periods (16-17 sequencer clocks). This special detection
ensures that the polling loop in RWTS will find the valid byte,
since each iteration of this loop requires 7 processor cycles,
or 14 sequencer clocks, or almost two disk bit periods.
If the controller continued to shift disk bits into the shift register,
the data would remain valid for an average of only 8 sequencer
clocks, or 4 processor clocks, and the polling loop would not be
able to read it reliably.
>Note that there's no timeout or any other exit out of this loop if
>the high bit never should become 1 for some reason (e.g. hardware
>failure). There's no time for such "fancy" stuff if one wants to
>make sure to not miss any new bit which arrives in the shift register
>every 4'th clock cycle.
And there is no need for a timeout, since the disk read amplifier
will always generate occasional 1 pulses. The effect is that RWTS
cannot get stuck in this loop, but will get an I/O error instead.
>After a new valid nibble has been read, one has some 30 clock cycles
>to do some other stuff, which in the RWTS of DOS, ProDOS, CP/M (yep,
>the RWTS of the various CP/M implementations of Apple II are all
>written in 6502 assembly) and most other OS'es is just storing the
>nibble in a buffer. The RWTS of Apple Pascal though mamanges to
>actually de-nibblize the data as well, so when the sector has been
>read, it's been de-nibblized as well, and the next sector can be
>read+denibblized "on the fly", enabling Apple Pascal to read one
>track in just one disk revolution. In the other Apple II OS'es
>de-nibblizing is done separately after the sector read -- and this
>causes the RWTS to miss the next sector on the disk, forcing a read
>of one entire track to take at least two disk revoutions.
>
>The fast RWTS read code of Apple Pascal has to pay a price though:
>that code is very large, compared to the much more compact RWTS'es of
>the other Apple II OS'es. The Apple Pascal RWTS uses a well-known
>loop optimization trick: if the loop is to always be executed a fixed
>number of times, it executes faster if it is replaced with linear
>code. This is called "loop unrolling".
It would have been nice to offer a choice in ProDOS about whether
to use the standard RWTS or the faster one, by sacrificing some
space for the code and the track buffer.
-michael
Check out parallel computing for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/