From: Patrycjusz R. Łogiewa (silverdr_at_inet.com.pl)
Date: 2005-05-04 20:13:58
On 2005-05-04, at 15:39, Spiro Trikaliotis wrote:
> Hello,
>
> * On Wed, May 04, 2005 at 12:39:43AM +0200 Patrycjusz R. ?ogiewa wrote:
>
>> You mean that the byte written to the $1c01 gets written again and
>> again until stopped?
>
> Exactly.
>
>> And that re-writing the register doesn't affect anything in the write
>> process? Timing?
>
> Well, it changes timing, but in no way that is relevant.
That's what I meant. The timing is affected but doesn't look like this
could have any relevance here.
> As told in the
> other mail (some minutes before), even some ROM routines do not do such
> a STA $1C01.
Could it be that there were other devices that required writing the
value again? Some pre-historical drives or so? Or could the the
original docs be saying something: "the value written to the register
will remain in effect until changed/stopped but don't count on this as
it may change with future implementations of the write logic" - Yeah a
pure speculation of course...
>
>> To Spiro:
>>
>> What was the exact process when you originally noticed the
>> problem/incompatibility?
>
> I wrote a probing fast formatter. Then, I added a verify of the just
> written track, where I did a byte-by-byte compare if anything that was
> read is exactly what was written before.
> With that compare, I discovered
> that the last sector written was always bad. Doing some more analyses,
> I
> found out that it was always the last 2 bytes which were wrong.
You mean the two padding bytes, right?
> Thus, I
> had this suspicion. I looked at the block write routine in the ROM -
> well, it did not do anything other than me. Then I looked at the ROM
> format routine again, and discovered that double BVC *. Then I thought
> about it, had a look into the 2031 schematic, and I found the reason.
Hm, possibly I am not too bright today (I also didn't follow the
earlier discussions on this subject too closely) but I still have
rather vague understanding here. What I believe is the outcome of this
discussion is:
1. Two BVCs are required to correctly "close-up" the track write
process because the first one checks if the previous rather then
current byte got written and since those are pad-bytes there is no need
to change anything in-between
2. The ROM formatting routine does this correctly, yet the ROM sector
write routine has a bug, which can make the last two bytes of a sector
be different from what they were left at by the formatting routine
3. In fact, every sector write should be closed up by the two BVCs if
we want to do it properly
Please correct the above if needed and add whatever is missing.
> Anyway, I wanted to be sure that my analyzes was right, thus, I asked
> here (which includes informing all other people here about that
> misconception of the 1541/1571 write process, which seems to be very
> common).
OK. This part I understand more or less clearly, I suppose... ;-)
--
$> man woman
Segmentation fault (core dumped)
$>
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.