Commented 1541-II DOS disassembly

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

Commented 1541-II DOS disassembly

silverdr@wfmh.org.pl
The best DOS disassembly so far I've seen is in "Das Große Floppybuch zur 1541". Do we have it (or better - the latest DOS[*]) available as some text file?

* - the one I have in the book does not cover the latest 1541-II version.
--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Spiro Trikaliotis
Hello Patryk,

* On Sun, Aug 12, 2018 at 12:59:15AM +0200 [hidden email] wrote:
> The best DOS disassembly so far I've seen is in "Das Große Floppybuch zur 1541". Do we have it (or better - the latest DOS[*]) available as some text file?

I prefer "Die Floppy 1541" by Karsten Schramm (M&T):

https://spiro.trikaliotis.net/Book

The disassembly is also available as TXT, and the whole book as Word
document.

Why do you believe that "Das große Floppybuch" is better? From what I
remember, there were much more uncommented places in that than in "Die
Floppy 1541".

Regards,
Spiro.

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

smf
Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

smf
The 1540 is slightly different, but it might be worth cross referencing
to the original source.

https://github.com/mist64/cbmsrc/tree/master/DOS_1540

It would be interesting if someone applied the 1541 patches to the source.


On 12/08/2018 06:31, Spiro Trikaliotis wrote:

> Hello Patryk,
>
> * On Sun, Aug 12, 2018 at 12:59:15AM +0200 [hidden email] wrote:
>> The best DOS disassembly so far I've seen is in "Das Große Floppybuch zur 1541". Do we have it (or better - the latest DOS[*]) available as some text file?
> I prefer "Die Floppy 1541" by Karsten Schramm (M&T):
>
> https://spiro.trikaliotis.net/Book
>
> The disassembly is also available as TXT, and the whole book as Word
> document.
>
> Why do you believe that "Das große Floppybuch" is better? From what I
> remember, there were much more uncommented places in that than in "Die
> Floppy 1541".
>
> Regards,
> Spiro.
>

Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Ruud
In reply to this post by silverdr@wfmh.org.pl
Hallo Patryk,


> Do we have it (or better - the latest DOS[*]) available as some
> text file?

http://www.baltissen.org/newhtm/sourcecodes.htm

Where else? :)


--
   
Kind regards / Met vriendelijke groet, Ruud Baltissen
www.Baltissen.org







Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

silverdr@wfmh.org.pl
In reply to this post by Spiro Trikaliotis

> On 2018-08-12, at 07:31, Spiro Trikaliotis <[hidden email]> wrote:
>
>> The best DOS disassembly so far I've seen is in "Das Große Floppybuch zur 1541". Do we have it (or better - the latest DOS[*]) available as some text file?
>
> I prefer "Die Floppy 1541" by Karsten Schramm (M&T):
>
> https://spiro.trikaliotis.net/Book
>
> The disassembly is also available as TXT, and the whole book as Word
> document.
>
> Why do you believe that "Das große Floppybuch" is better?

I don't recall ever saying that :-) I only wrote that out of those I've seen, the best was the one from "Das Große Floppybuch". I haven't seen the one in "Die Floppy" until now.

> From what I
> remember, there were much more uncommented places in that than in "Die
> Floppy 1541".

The question is "which exactly version is this?". As you did the disassembly, I take you used the same one as what was originally in the book, right?

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


Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

silverdr@wfmh.org.pl
In reply to this post by Ruud

> On 2018-08-12, at 12:36, [hidden email] wrote:
>
> Hallo Patryk,
>
>> Do we have it (or better - the latest DOS[*]) available as some
>> text file?
>
> http://www.baltissen.org/newhtm/sourcecodes.htm
>
> Where else? :)

:-)))

Although - please check:

http://www.baltissen.org/files/1541var.a65

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


Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Spiro Trikaliotis
In reply to this post by Ruud
Hello,

* On Sun, Aug 12, 2018 at 12:36:06PM +0200 [hidden email] wrote:
 
> > Do we have it (or better - the latest DOS[*]) available as some
> > text file?
>
> http://www.baltissen.org/newhtm/sourcecodes.htm
>
> Where else? :)

There is also https://spiro.trikaliotis.net/cbmrom.

Unfortunately, the comments are as complete as I want them to be.
However, it is rather easy to find the differences between the different
ROMs if you are a little bit used to read this.

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 silverdr@wfmh.org.pl
Hello Patryk,

* On Sun, Aug 12, 2018 at 12:41:01PM +0200 [hidden email] wrote:
>
> > On 2018-08-12, at 07:31, Spiro Trikaliotis <[hidden email]> wrote:
[...]
> > Why do you believe that "Das große Floppybuch" is better?
>
> I don't recall ever saying that :-) I only wrote that out of those
> I've seen, the best was the one from "Das Große Floppybuch". I haven't
> seen the one in "Die Floppy" until now.

I misinterpreted your statement, then. ;)

> The question is "which exactly version is this?". As you did the
> disassembly, I take you used the same one as what was originally in
> the book, right?

Yes, the book is left untouched. Thus, it is the -05 ROM, but the
autostart routine is also included (with an appropriate comment).

Never ROMs have not been included, however.

Regards,
Spiro.

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

Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

silverdr@wfmh.org.pl

> On 2018-08-12, at 21:49, Spiro Trikaliotis <[hidden email]> wrote:
>
>>> Why do you believe that "Das große Floppybuch" is better?
>>
>> I don't recall ever saying that :-) I only wrote that out of those
>> I've seen, the best was the one from "Das Große Floppybuch". I haven't
>> seen the one in "Die Floppy" until now.
>
> I misinterpreted your statement, then. ;)

:-)

>> The question is "which exactly version is this?". As you did the
>> disassembly, I take you used the same one as what was originally in
>> the book, right?
>
> Yes, the book is left untouched. Thus, it is the -05 ROM, but the
> autostart routine is also included (with an appropriate comment).
>
> Never ROMs have not been included, however.

I take the 251968-03 is the latest, right? Do we remember where was the SAVE"@ problem fixed (in which version)?

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


Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Spiro Trikaliotis
Hello,

* On Fri, Aug 24, 2018 at 05:29:47PM +0200 [hidden email] wrote:
 
> I take the 251968-03 is the latest, right?

According to https://spiro.trikaliotis.net/cbmrom, yes.

> Do we remember where was the SAVE"@ problem fixed (in which version)?

We might try to find it by limiting the search area.

I know for sure that 901229-05 did not include it yet.

The -06 ROM only added a patch to $EE40. Instead of JSR to $C8C6
directly, it goes to $FF2F which adds a LDA #$FF, STA $51 before the
JSR.

I am not sure about the intention of this patch, but I doubt it has to
do with the SAVE "@ bug.

So, I tend to believe that one of the 251968-0x added the patch.

Regards,
Spiro.

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

smf
Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

smf
https://en.wikipedia.org/wiki/Commodore_DOS#The_save-with-replace_bug

he save-with-replace bug[edit]

Commodore DOS also offers a "Save-with-Replace" command, which allows a file to be saved over an existing file without the need to first SCRATCH the existing file. This was done by prepending an @symbol to the file name during the OPEN or SAVE operation - for instance, SAVE "@MY PROGRAM",8. For years rumors spread, beginning with the 4040 drive, of a bug in the command's implementation. At first, this was denied by some commentators. Prizes were offered to prove the existence of the bug.[1] By early 1985 Compute! magazine advised readers to avoid using the command.[2] That year various authors independently published articles[1][3][4][5] proving that the Save-with-Replace bug was real and including methods by which it could be triggered.

Affected devices included the single-drive 1541 and dual-drive 4040; the 8050 and 8250 did not exhibit the issue.[1] Some commentators suggested the bug could be avoided by always explicitly specifying the 0: drive number when saving,[3] though it was later shown that any disk operations without a drive number were sufficient to lead to the bug.[6] The bug stemmed from the fact that the affected DOS implementations were modified versions of the DOS contained in earlier Commodore PET dual drives such as the 8050. This created a "phantom drive 1:" on single-drive systems, resulting in the allocation of an unnecessary buffer under some conditions. Since the Save-with-Replace command used all five drive buffers, and because the method by which the "phantom" buffer was allocated did not meet specifications, this resulted in scrambled data being written to the disk under some conditions.

In September 1986, Philip A. Slaymaker published an article[7] describing in great detail the cause of the bug and providing patches to the 1541 drive ROMs; readers with an EPROM burner could produce their own patched ROMs which could be swapped into the drive. Commodore was made aware of Slaymaker's findings, and while they never issued an official update for the original 1541's ROMs, they did fix the bug in Revision 5 of the 1571 ROMs, and also in the ROMs for the 1541-c and 1541-II drives. Although not supported by Commodore, it is known that the 1541-II firmware (but not that of the 1541-c) can also be used in an original 1541 drive by using EPROMs, which will fix the bug for that drive as well.


Philip A. Slaymaker's compute article is here

https://groups.google.com/forum/#!topic/comp.sys.cbm/2Ya1rrnjSzA


On 25/08/2018 08:43, Spiro Trikaliotis wrote:
Hello,

* On Fri, Aug 24, 2018 at 05:29:47PM +0200 [hidden email] wrote:
 
I take the 251968-03 is the latest, right?
According to https://spiro.trikaliotis.net/cbmrom, yes.

Do we remember where was the SAVE"@ problem fixed (in which version)?
We might try to find it by limiting the search area.

I know for sure that 901229-05 did not include it yet.

The -06 ROM only added a patch to $EE40. Instead of JSR to $C8C6
directly, it goes to $FF2F which adds a LDA #$FF, STA $51 before the
JSR.

I am not sure about the intention of this patch, but I doubt it has to
do with the SAVE "@ bug.

So, I tend to believe that one of the 251968-0x added the patch.

Regards,
Spiro.

Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Spiro Trikaliotis
Hello,

* On Sat, Aug 25, 2018 at 11:09:23AM +0100 smf wrote:
 
> In September 1986, Philip A. Slaymaker published an article^[7] describing in
> great detail the cause of the bug and providing patches to the 1541 drive ROMs;
> readers with an EPROM burner could produce their own patched ROMs which could
> be swapped into the drive. Commodore was made aware of Slaymaker's findings,
> and while they never issued an official update for the original 1541's ROMs,
> they did fix the bug in Revision 5 of the 1571 ROMs, and also in the ROMs for
> the 1541-c and 1541-II drives.

For the article, cf.
http://csbruce.com/cbm/transactor/pdfs/trans_v7_i02.pdf, page 37-39 in
the PDF, or 33-35 as written on the page.

Interestingly, it seems Philip A. Slaymaker fixed the problem, but he
does not know for sure which of the patches fixes it, or if it is all of
them.

Or do I misunderstand that article?

Regards,
Spiro.

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

smf
Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

smf

On 25/08/2018 12:52, Spiro Trikaliotis wrote:
> For the article, cf.
> http://csbruce.com/cbm/transactor/pdfs/trans_v7_i02.pdf, page 37-39 in
> the PDF, or 33-35 as written on the page.
>
> Interestingly, it seems Philip A. Slaymaker fixed the problem, but he
> does not know for sure which of the patches fixes it, or if it is all of
> them.
>
> Or do I misunderstand that article?
If you think he does not know, then I think you misunderstood the article.

Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Spiro Trikaliotis
Hello,

* On Sat, Aug 25, 2018 at 06:52:54PM +0100 smf wrote:

>
> On 25/08/2018 12:52, Spiro Trikaliotis wrote:
> > For the article, cf.
> > http://csbruce.com/cbm/transactor/pdfs/trans_v7_i02.pdf, page 37-39 in
> > the PDF, or 33-35 as written on the page.
> >
> > Interestingly, it seems Philip A. Slaymaker fixed the problem, but he
> > does not know for sure which of the patches fixes it, or if it is all of
> > them.
> >
> > Or do I misunderstand that article?
> If you think he does not know, then I think you misunderstood the article.

I am referring to statements like the following:

   "A possible SAVE@ related bug is in the serial bus communication
   routines. [...]

   Gerry Neufeld's theory of a serial bus ATN related SAVE@ bug is
   presented in [...] If a new command is sent before SAVE@ is
   completed, the BAM or directory may not be updated correctly [...] I
   have not tested his theory either, [...]"

So, we have a bug which might affect SAVE@, or it might not. Nobody
knows, not even the author.

This looks to me as if he is not completely sure about the nature of
SAVE@. He knows he has fixed it, but he does not know for sure which
patches all belong to the fix.


Having said this: If using absolute LDA $00FF,X instead of ZP LDA $FF,X
is part of the fix, then 251968-01 does not include that fix yet.
Thus, 251968-02 is the first ROM on the 1541 that includes this. All
1570 and the 1571-03 ROM (which is the first 1571 ROM known to me)
include that fix, too.

Regards,
Spiro.

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

smf
Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

smf
On 25/08/2018 20:47, Spiro Trikaliotis wrote:
> This looks to me as if he is not completely sure about the nature of
> SAVE@. He knows he has fixed it, but he does not know for sure which
> patches all belong to the fix.

Again, if you think he's unsure then I think you've misread the article.:

> I am referring to statements like the following:
>
>     "A possible SAVE@ related bug is in the serial bus communication
>     routines. [...]

Right, it's a theory by someone else that hasn't been verified and
contains errors. It looks like it could cause problems to other
operations other than save@ & I'm not sure if it's possible to trigger
that with the standard basic command. By fixing the bug and disabling
ATN when it's supposed to be disabled then it can't cause any issues.

My main intention of posting this wasn't so that you could criticise how
sure he is of his work, but give an explanation of why the changes were
made.

The article is clear why the changes were made.

> Having said this: If using absolute LDA $00FF,X instead of ZP LDA $FF,X
> is part of the fix, then 251968-01 does not include that fix yet.
> Thus, 251968-02 is the first ROM on the 1541 that includes this. All
> 1570 and the 1571-03 ROM (which is the first 1571 ROM known to me)
> include that fix, too.

Right the 02 rom is the first with the save@ bug fix according to the release notes from commodore. They list some other bug fixes as well.

http://www.zimmers.net/anonftp/pub/cbm/firmware/drives/new/1541/1541C.251968-02.txt 




Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

Rhialto
In reply to this post by smf
Wikipedia seems to contradict itself:

On Sat 25 Aug 2018 at 11:09:23 +0100, smf wrote:
> https://en.wikipedia.org/wiki/Commodore_DOS#The_save-with-replace_bug
...
> Affected devices included the single-drive 1541 and dual-drive 4040; the
> 8050 and 8250 did not exhibit the issue.^[1]
...
>  The bug stemmed
> from the fact that the affected DOS implementations were modified versions
> of the DOS contained in earlier Commodore PET dual drives such as the 8050.
> This created a "phantom drive|1:|" on single-drive systems, resulting in the
> allocation of an unnecessary buffer under some conditions. Since the
> Save-with-Replace command used all five drive buffers, and because the
> method by which the "phantom" buffer was allocated did not meet
> specifications, this resulted in scrambled data being written to the disk
> under some conditions.

For the 4040 there would not be a phantom drive 1:, and SAVE@ would also
not use "all five" buffers, since it had 12 buffers. So causing buffer
exhaustion is much more difficult.

I don't remember with certainty if there were alreay rumours about the
bug at the time of the 4040 (as Wikipedia states), but there could have
been. If there indeed was a problem, the explanation would likely be
different than for the 1541.

-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
smf
Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

smf
On 26/08/2018 17:29, Rhialto wrote:

> I don't remember with certainty if there were alreay rumours about the
> bug at the time of the 4040 (as Wikipedia states), but there could have
> been. If there indeed was a problem, the explanation would likely be
> different than for the 1541.

If the fixes in that article actually work (which commodore seem to
think they do) then it would seem likely that the 4040 bugs are different.

It doesn't come as a surprise that commodore could manage to mess up the
same thing twice.



Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

MiaM
Den Sun, 26 Aug 2018 20:52:49 +0100 skrev smf <[hidden email]>:

> On 26/08/2018 17:29, Rhialto wrote:
>
> > I don't remember with certainty if there were alreay rumours about
> > the bug at the time of the 4040 (as Wikipedia states), but there
> > could have been. If there indeed was a problem, the explanation
> > would likely be different than for the 1541.
>
> If the fixes in that article actually work (which commodore seem to
> think they do) then it would seem likely that the 4040 bugs are
> different.
>
> It doesn't come as a surprise that commodore could manage to mess up
> the same thing twice.

For the 1541 there are three different factors that's all needed to
trigger the bug.

One thing is the "phantom drive" thing which is fixed here, making all
five buffers free.

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.

One thing is that the drive seems to allow allocating (and
deallocating?) sectors on more tracks than it can cache BAM for without
somehow forcing a BAM update or just abort the operation. This is IMHO
the real bug that causes corruption, although it's the "phantom drive
buffer" bug that triggers this bug and also that bug fix also makes
SAVE@ work better. But fixing this bug would mean that SAVE@ would just
fail instead of cause corruption in cases where SAVE@ cannot do it's
job (like with some other file open at the same time).

I'm not sure how the 4040 and it's siblings work, but at least the last
factor might be present there too, at least if it allows the BAM to not
always be in a buffer. Although with 12 buffers it would require a
bunch of buffers in use by open files to trigger that last bug. That
would only happen if you SAVE@ your program while it has exited without
closing it's files.

Another trigger, both for the 4040 and 1541, and similar drives if they
have the bug, is if using a peripherial sharing device like VIC Switch
or it's sibling PET Switch / MBS (German name Mehrbenutzersystem). In
such case it's fairly reasonable to assume that one client can have
files open on a drive while another client uses SAVE@. For educational
usage it might not have happened that much as using data files from
self written software might be something that a school would never
reach, so a sAVE@ bug could probably mostly be triggered if some user
uses word processing software or similar while some other user writes
code and uses SAVE@. For office use it's not that likely that SAVE@
would be used at all, except for software development and it seems
likely that a software development company could afford one drive for
each user.

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

smf
Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

smf
On 27/08/2018 11:09, Mia Magnusson wrote:
> One thing is that the drive seems to allow allocating (and
> deallocating?) sectors on more tracks than it can cache BAM for without
> somehow forcing a BAM update or just abort the operation.

I thought it tried to force a BAM update, but it fucks up due to
stealing it's own buffer.

You can argue there isn't enough checking going on, but they have
limited rom space.

You could argue that it should fail and force the user to close handles,
but I assume they came to the decision that saving a program was a
higher priority.

In the 1541 case the buffer shouldn't even have been allocated. I think
it's interesting that they didn't fix that bug & instead allowed the
buffer to be stolen.

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.


Reply | Threaded
Open this post in threaded view
|

Re: Commented 1541-II DOS disassembly

MiaM
Den Mon, 27 Aug 2018 12:00:10 +0100 skrev smf <[hidden email]>:

> On 27/08/2018 11:09, Mia Magnusson wrote:
> > One thing is that the drive seems to allow allocating (and
> > deallocating?) sectors on more tracks than it can cache BAM for
> > without somehow forcing a BAM update or just abort the operation.
>
> I thought it tried to force a BAM update, but it fucks up due to
> stealing it's own buffer.
>
> You can argue there isn't enough checking going on, but they have
> limited rom space.

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.

It's kind of obvious that they came to the conclusion that the code
wouldn't fit in a smaller ROM space (like 8k or 12k) and then just
reused as much as possible from the larger drives without much thought
about what would actually be usable.

> You could argue that it should fail and force the user to close
> handles, but I assume they came to the decision that saving a program
> was a higher priority.

It should somehow put the disk in a state where it's obvious for a user
that it needs validation. (If a validate would solve the mess SAVE@
might create, as I understand it it does).

> In the 1541 case the buffer shouldn't even have been allocated. I
> think it's interesting that they didn't fix that bug & instead
> allowed the buffer to be stolen.

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

Btw where the SAVE@ function a part of the very first Commodore drives,
or is it an add-on? If it were part of the first drive, are there any
evidence of it being planned from the beginning or a later add-on?

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. This of course assuming that there were no way of using
page 2 as a buffer.

In theory, they might have just concluded that "SAVE@ seems to work,
we'll include it" after choosing RAM size, while other parts of the ROM
might had been written and tested before SAVE@ became part of the ROM.

Or more probably they inherited SAVE@ from the larger drives and just
didn't test things properly.

> 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.


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

12