PDA

View Full Version : @ Save and Replace Bug



KC9UDX
October 11th, 2014, 06:02 PM
I had always believed this only applied to the single drive models. Does it affect dual drive models, like a CBM 4040?

My 4040 seems to exhibit the symptoms, but I haven't really isolated it.

dave_m
October 11th, 2014, 08:02 PM
Does it affect dual drive models, like a CBM 4040?

My 4040 seems to exhibit the symptoms, but I haven't really isolated it.

Yes it does, but the SAVE and REPLACE command (SAVE@) was never officially referenced in any Commodore PET literature (don't know about VIC20 or C64). If you look in the PET BASIC 4 Users Reference Manual, it does list a DSAVE@ command but nothing about a SAVE@ command.

The confusion may have crept in with a Commodore Utility called 'DOS Wedge' but it would have used a 'left arrow' key as a shortcut to refer to the SAVE command. Users may have thought that it should also work on the original SAVE command. So use DSAVE@ if you have BASIC4 and there should be no problems.

KC9UDX
October 12th, 2014, 06:32 AM
I've been using DSAVE"@ and not SAVE"@

Maybe I have some other problem which is causing similar results.

dave_m
October 12th, 2014, 11:00 AM
I've been using DSAVE"@ and not SAVE"@

Maybe I have some other problem which is causing similar results.

Yes, perhaps you have found a new issue. The original issue had to do with not specifying a drive number with disk commands just prior to using the SAVE@. The literature says that not specifying a drive number should default to drive 0 but apparently it can sometimes cause problems with the Save and Replace.

Have you seen this article from Compute! Magazine #65 (https://archive.org/stream/1985-10-compute-magazine/Compute_Issue_065_1985_Oct#page/n79/mode/2up)?

Good luck with your investigation. Keep us informed.
-Dave

KC9UDX
October 13th, 2014, 06:17 AM
Yes, perhaps you have found a new issue.It may be as simple as an alignment problem. It only seems to happen on drive 0, and only when I DSAVE programs, not when other software writes files. But, it isn't repeatable enough to say that for certain.


The original issue had to do with not specifying a drive number with disk commands just prior to using the SAVE@. The literature says that not specifying a drive number should default to drive 0 but apparently it can sometimes cause problems with the Save and Replace.

Have you seen this article from Compute! Magazine #65 (https://archive.org/stream/1985-10-compute-magazine/Compute_Issue_065_1985_Oct#page/n79/mode/2up)?
I was a subscriber at the time. Unfortunately, it never occurred to me I'd be wishing I'd saved them in 2014. Thanks for the link. That brings back memories of the controversy! To this day, I'm not convinced always specifying the drive number or resetting the drive actually helps.

If I get a chance, I may try to run that demo program and see if I can replicate the results. I will be very disappointed if this really happens; only because I really looked forward to being able to reliable use the @ on the 4040 after all these years!

icbrkr
October 16th, 2014, 04:48 PM
I heard about the bug back in the day, and have been using save "@0:filename",8 ever since. I've never seen it show up on anything I've worked on.

fachat
November 5th, 2014, 02:38 AM
I used it extensively on my 1541 when I got it new, and got bitten hard a few times - I even tried to get it "repaired" because of the bug, but of course the service people couldn't find any problems....
Since then I did not use the SAVE "@ anymore." I probably didn't use it with drive number though.

André