From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2005-05-07 10:36:34
Hello,
* On Fri, May 06, 2005 at 07:59:46PM +0200 Patrycjusz R. ?ogiewa wrote:
> I read through this explanations and they seem really cogent. The
> question remains if you have really verified this?
Well, I cannot verify this as I do not own any IEEE drive.
> I believe that we would have to take down the bit images of the 4040
> and 1541 (according to your terminology) tracks freshly formatted and
> then cross-rewritten and compare it this way. This would be something
> that I am tending to believe the "incomdos" authors did and they have
> somewhat similar, yet different explanations, starting from p. 208.
Yes, thank, I now had a look at it. I believe I can explain their 100
bit vs. 90 bit gap problem for the 4040:
According to your explanation, the 4040 writes 9 gap (GCR-)bytes. This
gives 9 * 10 = 90 bits.
Anyway, when the drive executes the last BVC *, the "write shifter"
already latched the byte to be written. Thus, even if we change to write
mode immediately, the last byte will be written as 10th byte, resulting
in a gap length of 10 * 10 = 100 bits.
One remark: This is not true if the disk is to be formatted, as the
formatter does not have to switch into write mode, and thus, it
generates a 90 bit long gap.
What is happening with the 1541? Here, 8 * 8 = 64 bits are expected, but
the authors see a gap of 92 bits. Here, I have the following idea:
On a freshly formatted disk, newer 1541 disks write a 9 bit non-GCR gap
of $55. Anyway, the last 2 bytes of the data block are $0F $0F, which
translates into $x5 $55 $55. Thus, there are chances the authors of
Inside Commodore Dos counted these last two bytes as GAP bytes,
resulting in the count of (9+2)0 * 8 = 88 bit.
Now, the 1541 write mechanism has the same "problem" as the 4040 write
mechanism when writing a block: If it wants to go into write mode after
counting the last byte, the shifter already latched the last byte, which
is exactly what it has read before ($55) since the PA of the VIA is
still in read mode. Thus, it writes another $55 byte on the disk,
resulting in a GAP of (9+2+1)*8 = 92 bit which can be observed.
Of course, this all is pure speculation which would have been to be
proven. Furthermore, if the 4040 ROM has that $0F $0F filler for the
data block header, it would not explain why the authors count
differently for the 4040 and the 1541. This would only make sense if the
4040 ROM does not write the $0F $0F filler as part of the data block,
but as part of the intra-sector GAP. This might be the case as:
1. $0F $0F translates into $x5 $55 $55 in GCR
2. The 4040 can write "half" GCR bytes, while the 2031/15xx cannot
Of course, the authors tell that tests could not show this problem to
happen very often.
But remember: The authors examined 1541-03 drives (I conclude this from
the section "late news" on page 215, which compares -03 and -05 ROMs).
Which older drives (-02 and before), the other explanation from my mail
some days ago holds true, which is a totally different beast!
> Yet it seems to me unlikely (speculation) that people at CBM have cut
> off last BVC from the sector write routine (the thing we started with
> ;-) to improve compatibility with 4040.
Yes, I remember. ;-) In fact, I did not know that the 4040 counted in
GCR bytes, thus, I thought that Commodore reduced 10 (non-GCR) bytes to
8 (non-GCR) bytes, and then went back to 9 (non-GCR) bytes.
Anyway, it now seems to me that Commodore used 8 (GCR-) bytes, took over
that value for the 2031/1540 (which use non-GCR) and wondered about the
problems. Then, they increased the number to 9 (non-GCR) bytes on the
1541-03 ROMs to minimized the problem.
> >I have not checked any disk, but are you sure about 100+ bytes?
>
> Again - to be sure I would have to take the bit image, which I didn't
> but I quoted the same source, which I thought to be reliable.
Well, "sometime", I will do this test. If this is true, the probing
routine of the drive is not very good, despite the fact that it is very
slow.
> >Furthermore, it is not only the tail gap of the last sector; it's the
> >other way around: If the last sector's tail gap is that high, then
> >the blocks are not written very balanced all over the track,
>
> Yes. There is supposedly a bigger gap at the end of the track.
Well, "bigger" gap does not mean that one has to be 100+ bytes long.
> Well, such situations _will_ happen if the drive(s) are misadjusted
> but I think they have put enough buffer (as you calculated yourself)
> to cover the regular, acceptable deviations in drives' speed anyway.
> If that doesn't prove to be enough (since the drive exceeds the
> acceptable limits) then the drive needs servicing anyway.
Well, the arguments I showed in another mail where for ONE drive. These
arguments were not meant for different drives.
Let's calculate the length of a track in bytes. As I am lazy, I'm just
quoting from a mail of WoMo here. I came to the same formula
independently from him, so it is just for the sake of not writing too
much that I quote him, not that I did not follow the formula: ;-)
f := base clock frequency, which is 4MHz
(this is not completeley true, the base clock is 16Mhz, but after
beeing divided by the speed zone divisor, it is divided by 4
again,
so the overall virtual base frequency results to 4Mhz again)
omega := rotation frequency of the main disk motor
(300Upm +-3% on most drives, aka. 5/s)
dvsr := speed zone divisor of 13, 14, 15 or 16
f
Tracklength (Bytes) := TlB = ------------------
omega * dvsr * 8
Now, take speed zone 3 (track 1-17, dvsr = 13). Then, we get a tracklength with 300 rpm of
4 MHz
TlB(300 rpm) = --------------- = 7692,3 Byte
5 * 13 * 8
Take the same for 303 rpm:
4 MHz
TlB(303 rpm) = --------------- = 7616,1 Byte
5,05 * 13 * 8
And the same for 297 rpm:
4 MHz
TlB(297 rpm) = --------------- = 7770,0 Byte
4,95 * 13 * 8
You see, the track length differs by (7770 - 7616 byte) = 154 byte
between the drive with 303 rpm and the drive with 297 rpm! That is, PER
sector, the difference is 154 byte / 21 = approx. 7,3 byte!
With this, you see why a probing formatting routine is very important if
you want to share disks between different drives.
> >Yes, this is true. Anyway, it IS remarkable that Commodore reduced this
> >gap by 2 between the 4040 and the 2031, and increased it again by 1
> >between the 1541-02 and 1541-03. I'm sure there was some reason for it.
>
> AFAIR it was 9 GCR bytes vs. 8 non-GCR, with the actual bit patterns
> taking even more for some reason - interesting for what reason though.
> It would have to be verified if that was indeed changed _twice_ as you
> suggested. Don't have resources at hand to verify it.
Well, here, a simple byte compare suffices. Take the 1541-e000-02 and
1541-e000-03 ROMs from funet an perform a byte compare. You will see
that both images differ in exactly three positions:
l_f586: jsr l_f78f
jsr l_f510
- ldx #$08
+ ldx #$09
l_f58e: bvc l_f58e
and
bne l_fcc2
- ldx #$08
+ ldx #$09
l_fcd1: bvc l_fcd1a
and
-l_fee6: .byte $10
+l_fee6: .byte $0E
The latter is just the ROM checksum. The other two differences are the
counter for the intra-sector gap of the write routne ($F58D) and the
counter for the intra-sector gap of the format routine ($FCD0).
I have checked every 2031, 1540, 1541 and 157x ROM I found on funet:
There are only these two variants, anything before 1541-03 has 8 byte,
1541-03 and the later (including 157x) have a 9 byte gap.
> >BTW: You all know the "wrong" empty sectors of the 1541 disks, don't
> >you? That is, instead of being all $00, the sectors are $00, $01, $01,
> >... on track 1, and $4B, $01, $01, $01, ... on all subsequent tracks?
>
> Yes. There is one INX too much at $FC86, which both increments the
> value passed to A by one (hence $01) and skips the first byte when
> writing to the buffer later on (hence the first byte different). Some
> ages ago, I recall wondering what did they have in mind to make it this
> way... ;-)
Yes. Interesting, the 1540 and 2031 ROM have a NOP ($EA) there, while
even the 1541-01 ROM has the INX. Interesting: INX ($E8) and the NOP
differ in only one bit.
> At least the 1541 leaves its clearly distinguishable mark on the disk
> ;-)
Yes, I believe this was the intention of this change.
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.