From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2005-04-23 11:42:59
Hello,
* On Sat, Apr 23, 2005 at 10:41:18AM +0200 Nicolas Welte wrote:
> after your "hint" in the last mail,
he he...
> >So, we see that the last two GCR bytes are not needed at all, they are
> >just some dummy. Because of this, we do not get any read error when the
> >bytes are wrong.
>
> The extra bytes aren't just dummies, they actually serve an important
> purpose. As you know, GCR conversion always takes place in groups of four
> bytes data, and it yields five bytes GCR code.
Ok, this was known to me, as well as the header $0F $0F. With dummy, I
meant they do not contain anything important. We could call them "filler
byte" (or "filler dummy"), too.
> I have to dig deeper into the problem, but if you're right that the
> last GCR byte doesn't get written to the disk completely, I can
> imagine that this can lead to problems!
Yes, I was surprised about this, too, as I never read about this.
Anyway, I my tests highly suggest that this is the case.
> Still I'd like to know what formatters create such "broken" disks. I
> can't really believe the ROM formatter does this, otherwise much more
> disks would give these errors. Something that needs to be checked I
> believe :/
No, the ROM formatter does not have this problem. In fact, it was the
ROM formatter which brought me to the idea the two BVC * might be needed
at all. Anyway, as Ruud already pointed out, the formatter even writes
the additonal gap ($55 in GCR) byte going into read mode, thus, it is
not critical at all.
It is the normal "write" job routine which only executes one BVC * after
writing out the last byte to the DC in $F5C4 before it switches to read
mode at $F5CC-$F5F8 again. Thus, the ROM formatter generates correct
disks, but the write routine does not preserve this.
BTW: The cbm4win/cbm4linux formatter cbmformat does this job wrong, as
well as the 9-seconds-formatter. Anyway, I *never* saw any code
execute TWO "bvc *" before going into read mode (other then the ROM
format routine), thus, this error seems to be very wide spread.
Some more things to explain my thoughts: Looking at the schematic of the
equivalent of the custom IC in the 1541 (for the 2031, cf. funet), we
see that U6K pin 8 (which generates the byte ready signal) is (almost)
identical to U6K pin 12 (which generates the load signal for the
shifter, U3L, pin 1) if SOE is 1. The "almost" is due to the fact that
the LD signal for the shifter is ANDed with QA (:2) of U2N. This makes
sure that the LD is only done "at the right moment", while the BYTE
READY signal is not that timing critical.
Thus, if we execute the statements (taken from the DOS ROM routine)
.8:f5bf B1 30 LDA ($30),Y ; write the last bytes
.8:f5c1 50 FE BVC $F5C1
.8:f5c3 B8 CLV
.8:f5c4 8D 01 1C STA $1C01
then $F5C1 waits until the load for the PREVIOUS byte has been executed.
With STA $1C01, we give the data byte for the next round.
Why do I believe that it is the previous byte? I have seen code which
executes
BVC *
CLV
LDA something
STA $1C01
or even more commands between the BVC and the STA. OTOH, the CLK for the
shifter is at 250 kHz. Thus, if we let there be some commands between
the BVC and the STA, then the shifter would run empty, which would
destroy the written data as a garbage byte would be written.
Thus, it MUST be that $F5C1 waits for the previous byte to go into the
shifter U3L.
Now, the routines continues:
.8:f5c7 C8 INY
.8:f5c8 D0 F5 BNE $F5BF
.8:f5ca 50 FE BVC $F5CA
As I already explained, the BVC * on write makes sure we wait for the
previous byte to be loaded in the shifter. Thus, $F5CA waits for the
last byte to be loaded into the shifter.
Anyway, the routine continues:
.8:f5cc AD 0C 1C LDA $1C0C ; set read mode again
.8:f5cf 09 E0 ORA #$E0
.8:f5d1 8D 0C 1C STA $1C0C
With this, CB2 is set low, which results in -MODE going high. That is,
only some cycles after the last byte has gone into the shifter, the
drive cannot write anymore. In speed zone 1, we have a write frequency
of 250 kHz (16 MHz on U5M, pin 5, divided by 16 in U5M, divided by via
on U2N, pin 2). Thus, we need 32 cycles to output the whole byte via the
shifter. Of courses, from $F5CA to $F5D1, we would not need 32 processor
cycles!
> PS: I CC: this mail to Joe for obvious reasons.
I have done this, too.
> PPS: Spiro, can you change my cbm4win subscription to
> no_spam@x1541.de? It's what I use for mailing lists usually. Thanks
> :) I guess this is why my mails didn't end up on the list lately.
Ok, done. I added this mail address. Anyway, I did not remove the other
one, I just put it into "nomail".
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.