Post by Narf the M » Thu, 26 Jan 2006 08:17:27

The save command doesn't seem to want to save over previously written
data. This makes typing in games rather hard.



Post by Anders Car » Thu, 26 Jan 2006 18:18:08

"Narf the Mouse" < XXXX@XXXXX.COM > writes:

Assuming you're using floppy emulation in one way or another:


The @ is to replace an existing file with the new one, and 0 is
the unit number on device 8 (can be omitted unless dual drive).

Anders Carlsson



Post by Narf the M » Fri, 03 Feb 2006 23:33:38

Thanks. (Must remember where I drop messages)


Post by Christian » Sat, 04 Feb 2006 22:03:50

Narf the Mouse schrieb:

The @-Parameter is heavily bugged and tends to destroy lots of data from
time to time. DONT DO IT.


open 1,8,15,"s:name":close1:save"name",8

Christian Brandt


Post by Anders Car » Wed, 08 Feb 2006 00:07:34

Christian Brandt < XXXX@XXXXX.COM > writes:

Yes, and DSDD floppies once used on a PC compatible disk drive are
prone to yield read and write errors once reformatted on a 1541, so
don't reuse those neither.

Anders Carlsson


Post by Christian » Sat, 18 Feb 2006 14:07:30

Anders Carlsson schrieb:

are you sure?

I did that for years without any problem. But there is a chance that
an 25 years old disk/diskdrives just dies because of physical stress,
basically scrubbing off the last bits of the magnetic surface.

Christian Brandt


Post by Ruud.Balti » Sat, 18 Feb 2006 20:48:23

> The @-Parameter is heavily bugged and tends to destroy lots of data

This so called bug only happens if you try to save a file when the free
space of the disk is less then the size of that file. Reason: the drive
first saves the new file and then removes the old file. With to less
space on the end of the operation, for an unknowing user it looks if
something has gone terribly wrong.

I use this command regurlary and AFAIK I never had any problem.
Therefor I want to ask anyone believing this bug really exists: proof
it to me! And I only accept something as proof if anyone can reproduce
the error following clear instructions.

Regarding the unusable PC floppies. Being a Dutchman, I want to get
things cheap as possible. So I reuse old PC floppies. (hmmmm, another
reason for being so cheap is that I don't know any place where I can
buy new ones :) And so far I don't have any problem. OK, occasionally I
run into a floppy that cannot be formatted by a 1541 but in ALL cases
it could not be formatted by a PC as well! I even know if floppies that
weren't accepted by a PC but were no problem for my 154. (That was in
the 1980's, I was a student then and was forced to be cheap :)

And I don't have to tell you that 1.2 MB floppies are no good for us
but I still regurlary bump into people who still don't know with all


Post by MagerVal » Sun, 19 Feb 2006 01:07:36

>>>>> "RB" == Ruud Baltissen < XXXX@XXXXX.COM > writes:

RB> Therefor I want to ask anyone believing this bug really exists:
RB> proof it to me! And I only accept something as proof if anyone can
RB> reproduce the error following clear instructions.

I have an old source disk at home that I lost to the @: bug - I don't
remember the circumstances, but I should make a D64 of it and take a
look at it. IIRC the directory is completely screwed up and doesn't
match the actual contents of the disk.

___ . . . . . + . . o
_|___|_ + . + . + . Per Olofsson, arkadspelare
o-o . . . o + XXXX@XXXXX.COM
- + + . ~cl3polof/


Post by silverd » Tue, 21 Feb 2006 09:06:32


Ruud, I thought that bug has been already torn apart so many times as to
leave no doubts ;-) At least I recall there was an article in (AFAIR)
Compute!'s Gazette or Compute!, which gave clear instructions on where
it originates from, how to reproduce it (specific conditions needed) and
how to avoid it. I also recall verifying that in the eighties and
switching to the @0: version of the command instead of @: after having
positive verification results on my old 1541. I also recall a second
verification right when I installed my first DolphinDOS. I wanted to be
sure if the authors' claims of having it fixed were true (they were).


Post by Ruud.Balti » Tue, 21 Feb 2006 20:15:05

Hallo Patryk,

Is there anybody out there willing to scan this article?

To be honnest, I never used the @0: version, with a 1541why should I?
Is worth a try to see if that particular command messes up things.


Post by Pasi Ojal » Tue, 21 Feb 2006 22:43:52

Because the bug dies when you always use the drive number in
the commands. Is that a good-enough reason for you?:-)

Well, it has been a couple of years since the save-replace-bug has
been discussed, so it was about time it appeared again.. :-)

/My worst problem was laughter. I would go into fits of laughter and I could
not stop. Anything could set me off. The sheer madness of my own position
might set me off. This can still happen to me fairly easily. No loss, no
pain, no deepening understanding of my predicament changes it./ -- Lestat


Post by Leif Bloom » Wed, 22 Feb 2006 01:28:14

Transactor Magazine had a series of highly detailed descriptions of the
SAVE@ bug, complete with 1541 kernal dissembly and everything.

A program that proves the bug is here: ~csbruce/cbm/transactor/v6/i1/p020.html

A summary here: ~csbruce/cbm/transactor/v7/i2/p033.html

More background info: ~csbruce/cbm/transactor/v6/i4/p070.html