Re: Aw: Re: CBM DOS bug?

From: Greg King <>
Date: Wed, 06 Aug 2014 02:14:32 -0400
Message-id: <>
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 list
Received on 2014-08-06 08:00:03

Archive generated by hypermail 2.2.0.