On 2014-08-01 6:06 AM, "André Fachat" wrote: > > But, I have also written another test program that does exactly this -- open a "#" file, do the B-A and B-F, close the "#" file; and only then, do the > directory. The directory in the PET, in fact, shows 661 blocks free as expected! > However, when looking at the disk image later with c1541 (or a hex dump), it shows 664 blocks free! > > So, either the drive does not write the updated BAM back to disk -- or, VICE does not flush the changes back to the file. But, I doubt the latter; the very same > program runs fine in VICE with a 1001 emulation instead of the 4040 -- and, allocates the blocks on the d82 disk image. But, I guess the real test will be the real machine. > Is someone willing to do this test with a real 4040? (I currently only have a DOS 1 3040 drive out of storage.) It's VICE. My tests show that it doesn't flush if it quits while the disk image still is "attached". But, if I detach the image before I quit VICE, then it does flush that image. Then, both the 2031 and 4040 emulations give me what I want to see! I swear -- we must be BLIND! I tested the program for a _long_ time before I noticed this bug: > > 100 d=8 > 1000 open1,d,15,"i0" > 1010 gosub 9000 > 1020 open2,d,2,"#" > .... > 9000 input#1,a,b$,c,d <--- ! I advise you to do what BASIC 4 does; don't think "device number" -- think "unit number": 100 u=8 After you fix that bug, you should add another line: 1015 directory Then, you can see a before-and-after comparison. Message was sent through the cbm-hackers mailing listReceived on 2014-08-06 08:00:03
Archive generated by hypermail 2.2.0.