Commented 1541-II DOS disassembly

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

silverdr@wfmh.org.pl

> On 2018-08-27, at 13:35, Mia Magnusson <[hidden email]> wrote:
>
> Or more probably they inherited SAVE@ from the larger drives and just
> didn't test things properly.

Judging by the fact that even some otherwise reputable sources, for a prolonged period of time, claimed that the bug is another Yeti, and basically an urban myth - they might have even tested things "properly". Meaning - given the elusive nature of the bug I wouldn't be too harsh on them for not testing ;-)

--
SD! - http://e4aws.silverdr.com/


smf
Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

smf
In reply to this post by MiaM
On 27/08/2018 12:35, Mia Magnusson wrote:
> Yes, but some stuff in the ROM is IMHO rather useless on a single
> drive, like the copy function. That function might btw be the function
> that are second in a "competition" of which function uses the most
> buffers.

I get the impression they pretty much hacked up the code for the single
IEEE 2031 drive on a friday afternoon and then hacked the IEC code in
over a weekend.

Adding extra checking code, which they weren't aware they needed, was
not on the cards.

> It should somehow put the disk in a state where it's obvious for a user
> that it needs validation.

Why? Surely save@ should just work. If it is too buggy to work, then how
can you guarantee that validation will be good enough to fix it?

> Maybe the "steal buffer" might had been intended for something else,
> and it just made the SAVE@ bug a little harder to trigger.

 From the description it seems the steal buffer is used whenever an
operation needs a buffer and there aren't any free.

What save@ didn't expect is that one of it's own buffers would be stolen.

> The reason that the 1541 has 5 buffers is surely that 1 buffer (1k ram)
> would be too few, and the next step using reasonable hardware (2k ram)
> is 5 buffers.

I suspect it has 5 buffers, because save@ requires 5 buffers.

> Or more probably they inherited SAVE@ from the larger drives and just
> didn't test things properly.
Standard commodore testing, they turned it on a couple of times and it
didn't always catch fire.

>> I guess they were scared that having 5 buffers free all of the time,
>> while earlier drives would only have 4, would be a compatilibity
>> nightmare.
> Rather that any general change might disturb some weird copy protection
> scheme.

That is what I meant by "compatilibity nightmare."


Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Spiro Trikaliotis
* On Mon, Aug 27, 2018 at 08:43:56PM +0100 smf wrote:
> On 27/08/2018 12:35, Mia Magnusson wrote:
 
> > It should somehow put the disk in a state where it's obvious for a user
> > that it needs validation.
>
> Why? Surely save@ should just work. If it is too buggy to work, then how can
> you guarantee that validation will be good enough to fix it?

Validation did *not* fix it.

As someone who was bitten by this bug back in the days - although, I did
not KNOW that this bug even existed! - I know for sure that after this
bug hits you, some other file was broken. A validation did not fix it in
the sense that the other file was not fixed by a validation. In fact,
two file entries in the directory used the same list of block lists
afterwards, something that was never intended in the floppy ROM! Note,
however, that the two files did not have to be identical. You might end
with the broken file starting with its original content, and after some
while, it links to some block of the new file. So, both files have the
same tail, but different heads.

> > Maybe the "steal buffer" might had been intended for something else,
> > and it just made the SAVE@ bug a little harder to trigger.
>
> From the description it seems the steal buffer is used whenever an operation
> needs a buffer and there aren't any free.
>
> What save@ didn't expect is that one of it's own buffers would be stolen.


> > Or more probably they inherited SAVE@ from the larger drives and just
> > didn't test things properly.
>
> Standard commodore testing, they turned it on a couple of times and it
> didn't always catch fire.

From a retrospective, having a look into the technical documentation for
this bug, it really seems it was very hard to catch it. There are some
references that speak about the bug, others say it does not exist, and
so on.

I remember I have read one article (in transactor, I believe) that was
the first one that was able to actually proof that the bug existed, by
doing operations over and over again. It took some time, even for a
large number of sophisticated hobby enthusiasts.

You can blame Commodore for many things, but here, I can understand that
it was very difficult.

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Spiro Trikaliotis
In reply to this post by MiaM
Hello,

* On Mon, Aug 27, 2018 at 12:09:07PM +0200 Mia Magnusson wrote:
> Den Sun, 26 Aug 2018 20:52:49 +0100 skrev smf <[hidden email]>:
 
> One thing is that five buffers are needed at all. To conserve buffers,
> the new version of the file could be saved with a special file type,
> and when the save is complete that could be detected by the normal
> save routine, and the old file scratched, and the normal scratch
> routine could search for a file with a special file type and change
> that to the normal file type. This could be considered not a bug as
> there really are five buffers in an otherwise bug free drive and there
> isn't much use for being able to SAVE@ while also having other files
> open at the same time.

But in this case, you are not better than doing a:

SAVE "NEWFILENAME",8
OPEN 1,8,15,"S0:OLDFILENAME"
PRINT#1,"R:NEWFILENAME=OLDFILENAME"
CLOSE 1

That is, you need enough space on the disk for both variants, the old
and the new file.

The "nice" thing about SAVE@ is that this is not needed. You just need
the space for the maximum of the size of the old file and of the new
file.


BTW, all speak about SAVE@. What about writing a file with @, that is:

OPEN 1,8,2,"@0:MYDATEFILE,S,W"

I would expect that the bug would trigger here, too? Or is it really
specific to SAVE@?

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Julian Perry
Re: Commented 1541-II DOS disassembly Hello Spiro,

Tuesday, August 28, 2018, 6:17:23 AM, you wrote:

> Hello,

> * On Mon, Aug 27, 2018 at 12:09:07PM +0200 Mia Magnusson wrote:
>> Den Sun, 26 Aug 2018 20:52:49 +0100 skrev smf <
[hidden email]>:
>  
>> One thing is that five buffers are needed at all. To conserve buffers,
>> the new version of the file could be saved with a special file type,
>> and when the save is complete that could be detected by the normal
>> save routine, and the old file scratched, and the normal scratch
>> routine could search for a file with a special file type and change
>> that to the normal file type. This could be considered not a bug as
>> there really are five buffers in an otherwise bug free drive and there
>> isn't much use for being able to SAVE@ while also having other files
>> open at the same time.

> But in this case, you are not better than doing a:

> SAVE "NEWFILENAME",8
> OPEN 1,8,15,"S0:OLDFILENAME"
> PRINT#1,"R:NEWFILENAME=OLDFILENAME"
> CLOSE 1

> That is, you need enough space on the disk for both variants, the old
> and the new file.

> The "nice" thing about SAVE@ is that this is not needed. You just need
> the space for the maximum of the size of the old file and of the new
> file.


> BTW, all speak about SAVE@. What about writing a file with @, that is:

> OPEN 1,8,2,"@0:MYDATEFILE,S,W"

> I would expect that the bug would trigger here, too? Or is it really
> specific to SAVE@?
There are some shortcuts when saving a file, as opposed to writing a sequential file.

Most notably with SEQ files the BAM is updated whenever a new track is required. With a PROGRAM file the BAM is only written out once the program file is closed after the save (I think the drive determines this from the Secondary address: if you write out a sequential file as "filename,p,w" but with a SA of (say) 2 it will still update after every track, but I'd be happy to be corrected). You can notice this just from the head motion. Neufield might have something on it.


Julian
[hidden email]
smf
Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

smf
In reply to this post by Spiro Trikaliotis
On 27/08/2018 21:13, Spiro Trikaliotis wrote:

> You can blame Commodore for many things, but here, I can understand that
> it was very difficult.

I accept it would be a difficult bug to find, but it's also clear that
the 1540 & 1541 didn't have any kind of priority at commodore & not
enough resources were given to it.



Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

MiaM
In reply to this post by Julian Perry
Den Tue, 28 Aug 2018 10:58:09 +1000 skrev Julian Perry
<[hidden email]>:

> Re: Commented 1541-II DOS disassembly Hello Spiro,
>
> Tuesday, August 28, 2018, 6:17:23 AM, you wrote:
>
> > Hello,
>
> > * On Mon, Aug 27, 2018 at 12:09:07PM +0200 Mia Magnusson wrote:
> >> Den Sun, 26 Aug 2018 20:52:49 +0100 skrev smf <[hidden email]>:
> >  
> >> One thing is that five buffers are needed at all. To conserve
> >> buffers, the new version of the file could be saved with a special
> >> file type, and when the save is complete that could be detected by
> >> the normal save routine, and the old file scratched, and the
> >> normal scratch routine could search for a file with a special file
> >> type and change that to the normal file type. This could be
> >> considered not a bug as there really are five buffers in an
> >> otherwise bug free drive and there isn't much use for being able
> >> to SAVE@ while also having other files open at the same time.
>
> > But in this case, you are not better than doing a:
>
> > SAVE "NEWFILENAME",8
> > OPEN 1,8,15,"S0:OLDFILENAME"
> > PRINT#1,"R:NEWFILENAME=OLDFILENAME"
> > CLOSE 1
>
> > That is, you need enough space on the disk for both variants, the
> > old and the new file.
>
> > The "nice" thing about SAVE@ is that this is not needed. You just
> > need the space for the maximum of the size of the old file and of
> > the new file.
>
>
> > BTW, all speak about SAVE@. What about writing a file with @, that
> > is:
>
> > OPEN 1,8,2,"@0:MYDATEFILE,S,W"
>
> > I would expect that the bug would trigger here, too? Or is it really
> > specific to SAVE@?
> There are some shortcuts when saving a file, as opposed to writing a
> sequential file.
>
> Most notably with SEQ files the BAM is updated whenever a new track
> is required. With a PROGRAM file the BAM is only written out once the
> program file is closed after the save (I think the drive determines
> this from the Secondary address: if you write out a sequential file
> as "filename,p,w" but with a SA of (say) 2 it will still update after
> every track, but I'd be happy to be corrected). You can notice this
> just from the head motion. Neufield might have something on it.

So, will the SAVE@ bug be triggered if you do this?
SAVE "@FILENAME",8,2
(I assume that the drive itself cannot know the difference between SAVE
and OPEN for write, but I might very well be wrong here)


--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

MiaM
In reply to this post by smf
Den Tue, 28 Aug 2018 09:08:25 +0100 skrev smf <[hidden email]>:
> On 27/08/2018 21:13, Spiro Trikaliotis wrote:
>
> > You can blame Commodore for many things, but here, I can understand
> > that it was very difficult.
>
> I accept it would be a difficult bug to find, but it's also clear
> that the 1540 & 1541 didn't have any kind of priority at commodore &
> not enough resources were given to it.

Yes. As 1540 afaik were really expensive compared to a VIC 20, they
would probably not had planned to sell that many units.

The fact that they made an official IEEE interface for VIC 20 is also
an indicator of that they weren't really expecting 1540 to sell that
much.

The 1540 were probably partially there just to make the VIC 20 seem
better in comparison with other computers. The more expensive
competitors like Atari and TRS-80 all had disk drives.

Btw how were stuff sold at different parts of the world? Here in Sweden
the importer Datatronic more or less exclusively sold the VIC / C64
range including periperials through their daughter company Handic to
resellers which usually were home electronics shops, while the PET/CBM
range were sold directly by Datatronic to afaik a set of more qualified
computer resellers (or maybe they sold directly to the end customer?).
That makes it seem kind of hard for a VIC 20 user to actually buy a
drive for the IEEE interface. Not super hard but you'd have to buy the
drive and the computer from different resellers even though everything
were made by the same company.

Was it something like this in other parts of the world also?

(Btw the Swedish importer made their own IEEE interface for C64, called
"Superbox 64" (three switcheable cartridge slots and an IEEE
interface)).

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Francesco Messineo
On Tue, Aug 28, 2018 at 12:12 PM Mia Magnusson <[hidden email]> wrote:

>
> Btw how were stuff sold at different parts of the world? Here in Sweden
> the importer Datatronic more or less exclusively sold the VIC / C64
> range including periperials through their daughter company Handic to
> resellers which usually were home electronics shops, while the PET/CBM
> range were sold directly by Datatronic to afaik a set of more qualified
> computer resellers (or maybe they sold directly to the end customer?).
> That makes it seem kind of hard for a VIC 20 user to actually buy a
> drive for the IEEE interface. Not super hard but you'd have to buy the
> drive and the computer from different resellers even though everything
> were made by the same company.
>
> Was it something like this in other parts of the world also?o

I'm not sure what distributor CBM had in Italy, but in 1982-1984,
VIC-20 and C64 were available in house electronic shops (TV,
washing-machines etc. kind of shops to be clear).
I saw this VIC-20 on one of these shops and convinced my father it was
a great thing to have :) It was mid-1982 and the shop was able to find
the power supply only one week after we bought that VIC-20 (it was the
old 2-pins 9V AC supply).
In the same years, the more "serious" PETs could be seen in the office
equipment stores (typing machines, copiers, etc. kind of stores).
Things quickly changed right after 1984, when specialized shops
started to pop up everywhere.

Frank

Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Julian Perry
In reply to this post by MiaM
Re: Commented 1541-II DOS disassembly Hello Mia,

In my spiral-bound copy of  Neufield I have a curious handwritten note scrawled by a much younger me - an almost unrecognisable fellow to me who once pored over this tome as a initiate might an undiscovered gospel. This note referred to $D367 (part of the STLBUF (Steal Buffer) routine). Make of it what you will.
"Save @0; bug caused here can be prevented. If drive allowed to steal buffer which encountered error $0F(Drive not ready) then save @0: bug does not strike."
I found it incomprehensible then (as I do now) why an allocated buffer from a seek command that returned "Drive not ready" was not able to be stolen / returned to the free pool, particularly as in most instances the buffer allocated had no file-handle associated with it (being from a failed intialisation predicating a directory listing)

>> There are some shortcuts when saving a file, as opposed to writing a
>> sequential file.

>> Most notably with SEQ files the BAM is updated whenever a new track
>> is required. With a PROGRAM file the BAM is only written out once the
>> program file is closed after the save (I think the drive determines
>> this from the Secondary address: if you write out a sequential file
>> as "filename,p,w" but with a SA of (say) 2 it will still update after
>> every track, but I'd be happy to be corrected). You can notice this
>> just from the head motion. Neufield might have something on it.

> So, will the SAVE@ bug be triggered if you do this?
> SAVE "@FILENAME",8,2

No. On the C64 at least the Secondary address is hardcoded in the save command. A quick peek at the kernal save to serial routine at $F5FA has the very first bytes hard-coding the secondary address ($61 / $01)

> (I assume that the drive itself cannot know the difference between SAVE
> and OPEN for write, but I might very well be wrong here)
There's some code in the 1541 around $D876 that seems program-file specific, but I've not delved further into it as yet.


Finally, it should be noted me feline assistant was most helpful, chewing away at some of my reference sources as I cooked up this reply :)

https://c2.staticflickr.com/2/1861/43604453194_e5f527b257_h.jpg



Julian

--
Best regards,
 Julian                            
[hidden email]
smf
Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

smf
On 28/08/2018 14:01, Julian Perry wrote:
> I found it incomprehensible then (as I do now) why an allocated buffer from a
> seek command that returned "Drive not ready" was not able to be stolen /
> returned to the free pool, particularly as in most instances the buffer
> allocated had no file-handle associated with it (being from a failed
> intialisation predicating a directory listing)

A couple of guesses spring to mind.

1. Left over debugging code, when an error occurs then being able to
look at the buffer would be quite useful. It was either left in by
accident, or because changing it was deemed too dangerous.

2. A workround for another bug which may have been fixed & the workround
left in, or it might be less serious than save@ and nobody noticed.



Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

MiaM
Den Wed, 29 Aug 2018 10:00:34 +0100 skrev smf <[hidden email]>:

> On 28/08/2018 14:01, Julian Perry wrote:
> > I found it incomprehensible then (as I do now) why an allocated
> > buffer from a seek command that returned "Drive not ready" was not
> > able to be stolen / returned to the free pool, particularly as in
> > most instances the buffer allocated had no file-handle associated
> > with it (being from a failed intialisation predicating a directory
> > listing)
>
> A couple of guesses spring to mind.
>
> 1. Left over debugging code, when an error occurs then being able to
> look at the buffer would be quite useful. It was either left in by
> accident, or because changing it was deemed too dangerous.
>
> 2. A workround for another bug which may have been fixed & the
> workround left in, or it might be less serious than save@ and nobody
> noticed.

3. Maybe you are always supposed to deallocate a buffer when done?

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Rhialto
In reply to this post by MiaM
On Tue 28 Aug 2018 at 12:04:19 +0200, Mia Magnusson wrote:
> So, will the SAVE@ bug be triggered if you do this?
> SAVE "@FILENAME",8,2
> (I assume that the drive itself cannot know the difference between SAVE
> and OPEN for write, but I might very well be wrong here)

When I was trying to get a real 1520 plotter to work with Vice via a
ZoomFloppy, I noticed some weird differences between OPEN 1,6 and OPEN
1,6,0 (or some other seemingly unimportant difference).
Of course... I don't remember the details. But it turned out to be
impossible (or at least so difficult that I didn't bother) to map the
data sent on the IEC bus to the OpenCBM API to emulate it properly for
the plotter.

So there may well be other differences that the drive can tell.  And you
can always to the equivalent of OPEN "@FILENAME,PRG,W",8,2 and a bunch
of $FFD2 calls to save a file.

-Olaf.
--
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl      -- are condemned to reinvent it. Poorly.

signature.asc (465 bytes) Download Attachment
12