From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2005-04-22 16:57:23
Hallo Ruud,
* On Fri, Apr 22, 2005 at 03:40:46PM +0200 Baltissen, GJPAA (Ruud) wrote:
> OK, I really hope I know what you mean by now :)
> The only difference I see is that one switch is done directly and the
> other by calling a subroutine.
... and that one switch is done after two bvc *, while the other is done
just with one. ;-)
> The only two reasons I can think of are that 1) someone forgot that
> there existed a routine for this at all and 2) to save time. But the
> last argument is contradicted by calling the routine $F5F2 at $F5D9.
> This routine takes a lot of time. Another details that strengthens 1):
> when going through the sources, I encountered several routines that
> are only called from one place. It is possible that (one of) the
> programmer(s) thought that he/someone else would use it later again.
It might also be that the code just grew, with different programmers,
and the one did not know what the other had written some months/years
before.
> > They are just there to make sure all 325 (GCR) byte are
> > written to the disk.
>
> No.
> The first 69 bytes are written from $FCE9 to $FCF5.
> The next 256 bytes are written from $FCF7 to $FD02.
> Then several $55 bytes are written from $FD04 to $FD10.
Ah, ok, now I see *your* point. :-)
Nevertheless, have you had a look into my code?
Starting from NxtSec until DtaByt3, a block is written to the disk. The
last commands are:
NxtByt2 lda BUFFER1,y
DtaByt2 bvc DtaByt2
clv
sta DC_DATA
iny
bne NxtByt2
; check if there is another sector to be written
dec SECTOR2
bne NxtSec ; another sector, process that one
DtaByt3 bvc DtaByt3 ; wait for the current byte to be written
clv
DtaByt4 bvc DtaByt4 ; wait for another byte to be written
clv
jsr KILL ; KILL = $FE00, set to read mode
The last byte written is the last (325th) byte of the block.
OTOH, in the verify routine (starting at VerNxtSec),
VerDt1 bvc VerDt1
clv
lda DC_DATA
cmp BUFFER1,y
bne VerErrorData
iny
bne VerDt1
the compare fails for Y=$FF only, and only on the last block written
before going to read mode, if DtaBy4 bvc DtaByt4; clv are removed.
I have checked, it is *only* the last byte which is problematic. If I
remove the last block from the verify, I do not get and error. If I
add
iny
cpy #$ff
bne VerDt1
to ignore the last written byte, the verify does not fail, either.
BTW: This test does not always fail. Sometimes, it fails on the first
written track, sometimes, I happen to go until track 8 before the verify
fails.
Again, as I told, removing the "DtaByt4 bvc DtaByt4; clv" does not
decrease the readability of the block from the floppy routines.
BTW: Running on VICE, the verify never fails, regardless if I do the
double "bvc *", or not.
> > What I want to say: The "write" routine inside the DC only writes
> > 324 (GCR) byte (possibly, plus some bits), not all 325 byte.
>
> I disagree with you as can be seen above.
Yes, obviously. ;-)
> > From my oversations, IMHO, the 1541 write routine for writing
^^^^^^^^^^^
"observations"
> > a block is wrong, but it does not do any harm.
>
> IMHO the way you see it is wrong :) No offence meant.
Yes, I see we do not agree. ;-)
> It seems that there is only one solution:
>
> HELP, CAN ANYBODY ELSE ON THIS LIST HAVE A LOOK AT OUR PROBLEM, PLEASE
> ????
Yes, this would be very helpful. I know here are people which know about
the circuitry in the 2031 and early 1540. It would be very helpfull is
someone could jump in. :-)
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.