1541 Disk Drive on Vic-20
P98McCabe
After about 13 years of non-use, I recently started playing with my VIC-20
Computer and associated peripherals.
No problems with the computer itself; but the 1541 disk drive is getting
"flakey." The manual for the 1541 is long gone, so I'm trying to remember the
command sequences for disk operations.
Old disks seem to work fine. Programs load, save, and verify normally. I
can't find any of the disks with a "disk wedge" program, so I'm trying to
control the drive from basic.
Problem Number One: Formatting a new disk
If memory serves, you could format a disk with the following command sequence:
100 open 1,8,15
110 print#1,"NO:VIC DISK,AA"
120 close 1
130 end
When I run this program, the disk spins for a while. The red light begins
flashing, and the program terminates with no error message. The status
function (ST) returns either 0 (no error?) or 128 (device not present?).
Regardless, the disk is apparently not formatted. At least, you cannot save or
load information from the disk.
Any suggestions?
Micheal H. McCabe
p98m...@aol.com
John Iannetta
Are you perhaps using High Density diskettes (aka Quad Density or 1.2 Mbyte
diskettes)? If so, that is probably the problem. Use either Double Density
(aka 360 Kbyte) or Single Density diskettes with the CBM 1541 and 1571 drives.
--
When backing up your hard drive, shift into reverse gear S M O O T H L Y.
John
Carlsson, Anders
> 100 open 1,8,15
> 110 print#1,"NO:VIC DISK,AA"
> 120 close 1
> 130 end
Make sure the command you send to the drive on line 110 reads:
print#1,"N0:VIC DISK,AA"
That is, a zero instead of the letter O you wrote. The zero is a leftover
from the double-drive CBM/PET systems, I think. You might omit it, but
maybe it is best to keep it.
--
Anders Carlsson
P98McCabe
Thanks to all who replied to my question regarding the VIC-20 and 1541 disk
drives.
The problem seems to be a "flakey" error with the 6522 VIA.
Micheal H. McCabe
p98m...@aol.com
Darren Spiteri
> print#1,"N0:VIC DISK,AA"
> That is, a zero instead of the letter O you wrote. The zero is a leftover
> from the double-drive CBM/PET systems, I think. You might omit it, but
> maybe it is best to keep it.
It really isn't required from my experience, I never use the 0 in dos commands
and have never had a problem.
N:foo,xx always works for me. Comments?
--
+-\___ ___ ______ __ __/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\-+
: / __)| _ \||_ _| /__/_/ NOTE: Above email address is fictitious. :
|:__ \: _:: :: : @# '') "Bunch of savages in this town..." - Dante |
`(____/|_|><|_||_|><><\__3- - -*(at)hempseed(dot)com><><><><><><><><><>'
Cameron Kaiser
>>That is, a zero instead of the letter O you wrote. The zero is a leftover
>>from the double-drive CBM/PET systems, I think. You might omit it, but
>>maybe it is best to keep it.
>It really isn't required from my experience, I never use the 0 in dos commands
>and have never had a problem.
>N:foo,xx always works for me. Comments?
The 0 is intended to indicate which drive in which device. Dual drives like
the MSD use N0:xxx,xx to format the disk in device 8 drive 0 and N1:xxx,xx to
format the disk in device 8 drive 1.
A rumour states that the 1541 had a schizophrenic personality when it came to
dual drives. Gazette mentions that a fair portion of the '41's ROM code is
dedicated to convincing the disk drive it's drive 0 and only drive 0, but it
can get confused and start dealing with the phantom drive 1 unless explicitly
told to be drive 0. This could be the crux of the infamous save-and-replace bug
that people occasionally observe (though this is a topic of its own -- a
lot of people blame save-and-replace bugs on trying to save to a nearly full
disk, since s-and-r keeps two copies of the program on disk simultaneously and
a nearly full disk may not have the capacity).
In any case, using 0 won't hurt anything, and you might call it an extra tiny
bit of safety. (Literally ;-)
--
-------------- The Commodore 64 lives: http://computerworkshops.home.ml.org/ --
Cameron Kaiser (posting with a Commodore 128) | "When in doubt, take a pawn."
cdkaiser@concentricMUNGEnet | -- Mission: Impossible
-- personal page: http://calvin.ptloma.edu/~spectre/ ------ CBMSF Unit $EA31 --
John/Lori
always specifing device 0 to avoid the save-with-replace bug.
An excerpt from that article follows, and is being posted with
P. A. Slaymaker's kind permission.
Also included is some follow up information excerpted from an email
message I recieved from Dr. Slaymaker.
From the email message:
> The
> Transactor V7 article is more complete technically than the COMPUTE!
> articles.
>
> 1) Transactor V6 #1 July '85 "Save @ Exposed!" by Charles H. Whittern
> He shows bug exists, but is not using 0: in all commands, nor does he
> know why bug occurs.
>
> 2) Compute! Oct/Nov '85 "Save-with-Replace: Debugged at Last" by P. A.
> Slaymaker.
>
> 3) Info #9 Dec '85-Jan '86 "Save@: Gerry Neufield's Theory on an Old
> Bug" by editors
> I comment on this theory in the next article.
>
> 4) Transactor V7 #2 Sept '86 "Eliminating SAVE@ and Other 1541 Bugs" by
> Philip A. Slaymaker
>
<snip>
> I've not paid attention to the C64 for a long time, however, a few comments
> pertain:
>
> 1) The SAVE@ bug is present in all 1541 drives. I'm not aware that 1541
> ROMS were ever updated by Commodore. The 1571 ROMS starting with Rev 4, I
> believe, had the SAVE@ bug fixed.
>
> 2) The SAVE@ bug occurs even if "0:" is used correctly in the SAVE
> commands. ANY preceeding command (LOAD or doing a directory) without the
> drive number sets the drive up for the SAVE@ bug.
>
> 3) Since I believe the bug is caused by stealing one of the five internal
> 1541 memory buffers, any DOS extender which downloads code into the drive
> may use a memory buffer and aggrevate the SAVE@ bug. I found the SAVE@ bug
> was made worse when using "Fast Load" and "Mach" which were C64/1541fast
> loaders 11 years ago.
>
> 4) My last article in Transactor V7 #2 pointed out a number of other
> seemingly innocuous bugs which normally didn't affect 1541 performance, but
> could be disastrous for DOS extender programs which download code and could
> have their code or variables modified.
>
> 5) My suggested ROM changes were not directly implemented by Commodore in
> the 1571. They used their own code. I don't know what third party ROMs for
> the 1541 may have changed.
>
> Note that most products and addresses mentioned in the articles are totally
> out of date.
>
> You may relay this information to others through newsgroups, etc. I won't
> be able to honor general requests from other people for reprints of these
> articles. However, if I ever do resurrect the old info, I could email you
> or post it to the comp.sys.cbm group.
>
>
> Philip A. Slaymaker
From the Compute! article:
Save With Replace:
Debugged At Last
Part 2
What actually causes the Save-with-Replace bug? When and how
does it occur and is there a fix for it? We have performed
extensive testing to determine exactly how the bug happens.
As explained last month, we've determined that the bug is avoidable
if the drive number (drive 0) is specified in all disk commands.
If you don't always specify drive 0, the bug occasionally bites.
That's significant information in itself--but we wanted to know WHY.
DOS Thievery
First, we should note that although the SAVE@ command deletes a disk
file and saves a replacement in a single operation, it works
differently than if you issued separate SCRATCH and SAVE commands.
SAVE@ calls entirely different DOS routines--the SCRATCH and SAVE
are executed as part of a continuous procedure, and the SAVE@
command therefore requires that more drive buffers be available.
DOS V2.6 has five internal buffers, numbered 0 to 4. These buffers
start at memory pages $300, $400, $500, $600, and, $700, respectively.
Normally an image of the disk's BAM (block availability map) is stored
in the page at $700, an image of the directory sector in use is stored
a $600, and the other three buffers are available for file use.
As long as a buffer is active, it cannot be used for anything else.
If DOS has assigned an internal channel to the BAM at $700, then trying
to open a direct channel to buffer 4 (from BASIC: OPEN 2,8,2"#4") will
produce a 70,NO CHANNEL,00,00 error.
Similarly, DOS assigns channels and Buffers to the directory sector
and file sectors which are being read or written. Normally DOS
assigns two read or two write channels and uses only three of the
five buffers. The SAVE@ command, however, requires all five
buffers--two read, two write, and the BAM. If DOS can't find a free
buffer, it tries to steal an assigned but inactive buffer.
This thievery causes the SAVE@ command to occasionally fail-- for
reasons which will be discussed shortly.
Why does omitting the drive number in disk commands cause DOS to
steal a buffer? When a file is opened or loaded via the OPEN
routine ($D7B4), DOS searches the internal directory to look for
the specified file name (DOS routine names and addresses in this
article conform to those listed in INSIDE COMMODORE DOS, Datamost,
1984). ONEDRV ($C312) determines whether a drive was specified.
OPTSCH ($C3CA) assigns a default or specified drive for each file
in the command, and also calls AUTOI ($C63D). AUTOI reads the BAM
of the disk in the specified drive, and also tries to initialize
drive 1 if no drive was specified. Usually buffer 3 ($600) is
allocated for the phantom drive 1 BAM, and a B1 SEEK command is
issued to the disk controller. This results in an internal
DRIVE NOT READY error in the disk controller. The error is trapped
by AUTOI but not reported outside the disk drive. This leaves
buffer 3 allocated but inactive. FFST ($C49D) then reads the
directory and tries to find the file.
The reason this inactive buffer assignment is important is that
the SAVE@ command requires all five buffers, but only four are now
available. Whenever DOS needs to allocate a buffer, it calls
GETBUF ($D28E). If one is not free, GETBUF tries to steal an
inactive one by calling STLBUF ($D339). If the drive number is
always specified and no direct access buffers are allocated,
STLBUF is never called. We verified this by modifying GETBUF after
copying DOS onto an EPROM (Eraseable-Programmable Read Only Memory).
If a channel can't be stolen, then a NO CHANNEL error occurs.
But if STLBUF is called, the SAVE@ bug sometimes occurs.
Stealing The Wrong Buffer
STLBUF can be called several times during a SAVE@ command.
The result is that the BAM and directory sectors can be reassigned
to different buffers during a single SAVE@. We have found the BAM
and directory sectors in every drive buffer after different SAVE@
commands. We have found copies of the current directory sector in
two different buffers, one an old sector and one properly updated,
but the wrong one had been written to the disk. Somehow, the
pointers to the BAM and directory sectors are not properly
accounted for. Which buffer is stolen by STLBUL depends on prior
buffer usage and the values stored in LRUTBL,Y ($FA,Y), the least
recently used table. It appears that STLBUF updates all pointers
except LRUTBL,Y. This means that multiple calls to STLBUF may steal
the wrong buffer--in this case the wrong buffer to steal is the BAM!
The BAM is stored in the drive in one of the buffers. STLBUF
should not steal the drive 0 BAM, but should instead take back the
unused buffer incorrectly assigned to drive 1. It never steals the
drive 1 BAM, buffer 3 at $600, because STLBUF cannot take a buffer
which encountered a drive error. Remember that an internal DRIVE
NOT READY error did occur, because there is no drive 1!
To test this, we copied into EPROM an altered version of DOS with
STLBUF modified to allow stealing a buffer with this error. This
allowed the phantom drive 1 BAM buffer to be freed, and the SAVE@
bug did not strike during test with this modified DOS.
If this buffer-stealing occurs, why does SAVE@ work most of the
time? We must dig deeper into DOS to answer this question. When a
file is opened and blocks (or sectors) are written to a disk, the
BAM is NOT directly updated in the drive memory. Instead, a BAM
image for each of two tracks is stored at BAM ($2A1-$2B0). Each
time a new block is allocated by WUSED ($EF90), it is recorded in
the BAM image. When a new track is tested for free sectors, DOS
checks if it has a BAM image for it. If not, it calls SWAP ($F05B),
which first updates the BAM with the BAM image from the next-to-last
track, copies the new track's BAM map into the BAM image, and then
zeros that track in the BAM. This all works perfectly--most of the
time.
After the last file sector is written to the disk, the BAM still
has not been written to the disk. In fact, the BAM in the drive is
wrong because it has not yet been updated from the BAM images.
When a file is closed, the disk directory is closed, CLSDIR ($DBA5),
by reading in the file's directory sector, testing for a replace
file type, and then rewriting it to the disk. MAPOUT ($EEF4) is
called to read the BAM off the disk, if necessary, and to then
update it from the BAM images by calling PUTBAM ($F0A5). The
updated BAM is then written back to the disk.
During a SAVE@ command, DOS performs an additional step after
reading the directory sector. The file type is designated as
replace, so DELFIL ($C87D) is called to delete the original version
of the file from the BAM. It reads in the first sector, FRETS
($EF5F), and then proceeds to trace through the file and delete
sectors in the BAM images. The BAM is then written to the disk.
Bungled BAM
Normally this procedure works correctly. But havoc results if the
BAM buffer is stolen while the file is being closed. This can
happen during a SAVE@ command because DELFIL requires two additional
buffers. The BAM can be stolen at different points during the
procedure, depending on which buffers were previously used--which,
in turn, depends on the number of sectors in the file and the tracks
on which it is stored.
After the BAM is stolen, it is read back in when needed and
updated from the BAM images. Only TWO tracks can be updated,
however, since there are only two images. If more than two tracks
have been accessed by SAVE@, the BAM may NOT be correctly updated.
A track could be updated correctly, left unchanged, or fully
allocated, depending on when the BAM was stolen.
If extra sectors are allocated, the BAM is incorrect, but no
permanent harm is done. A validate command will cure the problem.
If sectors are not allocate, then a new file will be saved on top of
the old file's sectors. In the example program listed in Part 1,
a fourth SAVE@ command would result in the file being written on top
of the old file's first four sectors, and then the whole new file
would be scratched--a tragic result, indeed.
Based on these findings, we recommend that you avoid the SAVE@
command when direct access channels to the drive are open or if you
don't always specify the drive number in disk commands. you should
also avoid SAVE@ when using programs or cartridges intended to
speed up access on the 1541 disk drive. These programs often
reserve internal drive buffers and may cause problems even if the
drive number is specified. If you're using the DOS Wedge, we
recommend issuing a >UI or >UJ command before each SAVE@ command to
be sure all the buffer pointers are reset. Many word processors also
allow you to send these commands to the drive. Otherwise, the drive
should be turned off and then on before using SAVE@. (On the SX-64,
press the drive reset button.)
During our studies we found several other minor bugs in DOS V2.6,
including the subroutine which puts the value 2 at the drive memory
location $197. This bug does no harm since it affects a normally
unused section of drive memory. However, we have found it can
affect DOS routines downloaded into the drive. There may be other
bugs or quirks which we have not found, so the Commodore DOS
controversy may never be fully closed.
David Murray
> p98m...@aol.com (P98McCabe) writes:
>
> > 100 open 1,8,15
> > 110 print#1,"NO:VIC DISK,AA"
> > 120 close 1
> > 130 end
>
> Make sure the command you send to the drive on line 110 reads:
>
> print#1,"N0:VIC DISK,AA"
>
> That is, a zero instead of the letter O you wrote. The zero is a leftover
> from the double-drive CBM/PET systems, I think. You might omit it, but
> maybe it is best to keep it.
This is all fascinating.. I used to have an "Indus GT" floppy drive for my
C64 years ago.. It was the coolest thing.. It was 1541 compatible and was
much smaller and sleeker. It had an LED display showing the track the head
was at at all times and even cooler than that.. It had 2 drives, sort of.
It had a ROM-Disk built in. So if you typed LOAD"1:$",8 you would get a
whole different directory full of fast-loaders and other usefull stuff that
was always there. Of course, you couldn't write to it, but it was cool.. I
wish I still had that thing!
--DavidM
gippah
> A two part article by P.A. Slaymaker in Compute! Nov,Oct 85 recommends
> always specifing device 0 to avoid the save-with-replace bug.
>
> An excerpt from that article follows, and is being posted with
> P. A. Slaymaker's kind permission.
>
> Also included is some follow up information excerpted from an email
> message I recieved from Dr. Slaymaker.
Yeah I remember this article, and I was very impressed that someone had found
the bug. Or so they'd thought. A few years later another magazine (or maybe it
was the same magazine, I don't remember....it has been 10 years after all)
published another article stating that the bug could STILL creep up even if you
took the precautions specified here, and explained why.
It's really best just to save your programs with a new filename and then scratch
the old one. It's just simply not worth the risk to use save-with-replace.
This way, too, you can have another copy in case you mess one of them up
accidentally. Archives are good, particularly when you've spent a day or two
working on something.
Cameron Kaiser
> This is all fascinating.. I used to have an "Indus GT" floppy drive for my
>C64 years ago.. It was the coolest thing.. It was 1541 compatible and was
>much smaller and sleeker. It had an LED display showing the track the head
>was at at all times and even cooler than that.. It had 2 drives, sort of.
>It had a ROM-Disk built in. So if you typed LOAD"1:$",8 you would get a
>whole different directory full of fast-loaders and other usefull stuff that
>was always there. Of course, you couldn't write to it, but it was cool.. I
>wish I still had that thing!
I'm the owner of a GT, myself, inherited from a friend's garage. A most cool
disk drive, but it seems to be a little flaky with the serial bus (I have to
disconnect the *printer* or the Indus, or turn the Indus on 24/7, or devices
start hanging whenever a LISTEN goes out on the bus).
For Indus owners who are interested, the GT is 100% compatible with Epyx
FastLoad and COMPUTE!'s TurboDisk. Too bad I have a 128DCR, or the Indus would
be my drive #8.
Cameron Kaiser
>It's really best just to save your programs with a new filename and then
>scratch
>the old one. It's just simply not worth the risk to use save-with-replace.
I've gotten in this habit. I wrote a utility a while back that would intercept
a save-with-replace and rewrite it into a scratch and a normal save. If I can
find the source, and people are interested, I'll post it. (Unless John
Iannetta writes his own first. ;-)
Geoff Oltmans
> Too bad I have a 128DCR, or the Indus would be my drive #8.
Trade'ya my flat 128 and 1571 for the 128DCR. ;)
*Geoff!*
Cameron Kaiser
>>Too bad I have a 128DCR, or the Indus would be my drive #8.
>Trade'ya my flat 128 and 1571 for the 128DCR. ;)
Nope :-)
Decimal
gippah wrote:
> John/Lori wrote:
>
> > A two part article by P.A. Slaymaker in Compute! Nov,Oct 85 recommends
> > always specifing device 0 to avoid the save-with-replace bug.
> >
> > An excerpt from that article follows, and is being posted with
> > P. A. Slaymaker's kind permission.
> >
> > Also included is some follow up information excerpted from an email
> > message I recieved from Dr. Slaymaker.
>
> Yeah I remember this article, and I was very impressed that someone had found
> the bug. Or so they'd thought. A few years later another magazine (or maybe it
> was the same magazine, I don't remember....it has been 10 years after all)
> published another article stating that the bug could STILL creep up even if you
> took the precautions specified here, and explained why.
>
> It's really best just to save your programs with a new filename and then scratch
> the old one. It's just simply not worth the risk to use save-with-replace.
>
> This way, too, you can have another copy in case you mess one of them up
> accidentally. Archives are good, particularly when you've spent a day or two
> working on something.
What I read was this:
THis was quite a screwed up problem in commodore drive roms... at least in the 15*1
series. See, when they wrote the drive roms for the 1541, they just took the code
from the old two-disk drives, and removed the code for drive 1... but the one bit of
code they neglected was the save-with-replace code. When the drive goes to
save-with-replace, it attempts to steal a buffer from a nonexistent drive 1.When it
attempts to store data in this nonexistent buffer, its lost. Sometimes, the data
stored in this nonexistent buffer is part of the BAM (block availability map, if I
remember correctly) that was vital, and without the vital area of the BAM in the
buffer to re-write back onto the disk.. the data on the disk is lost.
This, and other bugs in the ROMS became a standard in the 1541... and started
getting embedded into protection schemes. Then, it was simply too late. It became
embedded into the 1571 and 1581 as well.
In short, the 15*1 series of drives spend half their time convincing themselves
that they're one drive, not two.
-Decimal