silverdr_at_wfmh.org.pl
Date: 2009-01-25 18:27:55
On 2009-01-25, at 14:37, Ruud@baltissen.org wrote:
> Hallo Jim,
>
>
>> If you can create a small test program,
>
> 5 D=8 : TL=5
> 10 OPEN 3,D,3,"0:SEQTEST,S,W"
>
> 20 FOR I=1 TO TL
>
> 30 FOR K=1 TO 254
> 34 PRINT#3,CHR$(65+I); : NEXT K
>
> 38 PRINT"."; : NEXT I
>
> 40 CLOSE 3
>
> FYI: TL = number of sectors to be created
I just dropped it at my DolphinDOS - TL = 3, empty disk, after running
the prg - 660 BLOCKS FREE. After VALIDATE - 661 BLOCKS FREE. I
modified the prg a bit to create several files at one go. Each file
eats up one additional block. VALIDATE recovers them though.
10 D=8:TL=3:FL=3
20 FOR J=1 TO FL
30 OPEN 3,D,3,"0:SEQTEST"+RIGHT$(STR$(J),1)+",S,W"
40 FOR I=1 TO TL
50 FOR K=1 TO 254
60 PRINT#3,CHR$(65+I);
70 NEXT K
80 PRINT".";
90 NEXT I
100 CLOSE 3
110 NEXT J
READY.
But... I also checked it with an emulator (Power64) and... huh-huh ;-)
With "full drive emulation" it exhibits the same problem as the real
hardware but with the substitute emulation it also takes one block
more than needed, yet marks the files as four blocks long (instead of
needed three) BUT the pointer to the last block goes to lalaland. This
brings immediately ILLEGAL TRACK OR SECTOR on VALIDATE :-D So - the
"boundary error" happens not only to CBM programmers ;-)
P. S. Vice's virtual drive does not exhibit the bug. Only the "true
drive emulation" does.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.