Talk:Commodore DOS

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Mid-importance).

Necessity of Non-English reference

Regarding the (presumably) Finnish-language reference that was listed in this article a while ago: is this absolutely necessary for the article's information, or may equally detailed info be had from the (combination of) the other two sources? (knowing them, I have to admit I'd be surprised otherwise). If not essential, I think en.WKP policy (I should check this, I know...) is to list English-language refs only. --Wernher 13:11, 28 August 2005 (UTC)[reply]

Sorry for a lateish reply. Well, the Wikipedia insists to cite sources, and Lundahl's is the only book I've used to get information from, probably the best book on the subject in Finnish. I think the other sources have the same exact same stuff on broad terms, but I can't say if they have all of the weird little details. And for the life of me I can't figure out where to get the cited English books, I've never read them, and it's not like the small library around the corner has all of the microcomputer books from the eighties. =/ --wwwwolf (barks/growls) 13:55, 10 January 2006 (UTC)[reply]

$0401 or $0400?

Does the directory listing really begin at $0401? The start of the screen memory of the Commodore 64 is $0400, and it continues all the way to $07FF, although as the visible screen only consists of 1000 character locations, the last visible position is at $07E7. — JIP | Talk 22:57, 9 January 2006 (UTC)[reply]

Yes, the article is correct, about both the address and the reason for it. Mirror Vax 23:32, 9 January 2006 (UTC)[reply]

Disk copy command

I seem to remember (wow, was it really twenty years ago?) that two-drive units like the 4040 implemented a command to copy the entire contents of one drive to the the other. Imagination? 121a0012 (talk) 06:14, 13 March 2008 (UTC)[reply]

I'm pretty sure it's possible there was such command. I seem to remember reading about something like that. --wwwwolf (barks/growls) 20:50, 13 March 2008 (UTC)[reply]

This command is also available on the MSD-2 dual disk drive. To invoke this on either the 4040 or the MSD-2, enter the following commands:

 OPEN15,8,15 : PRINT#15,"D0=1":FOR T = 1 TO 10000:NEXT:CLOSE 15

The "D0=1" command causes the drive to duplicate the data on drive 1, and put it on drive 0. It is possible in the example above that the T = 1 TO 10000 Loop isn't big enough. But that is beside the point. The command given, will duplicate the data. Dexter Nextnumber (talk) 04:27, 29 December 2009 (UTC)[reply]

Save with replace question

One of the reasons the save with replace error was not found for a long time, even though many users kept complaining about it, was that the error channel was religiously inspected on an operation by operation regularity.

I have a question about this bug that, if answered, might improve the main article.

What was the nature of the Revision 4 correction in the 1571 drive? Which bytes were changed? How did this modify the usage of the buffers?

There also exists a series of 1572 dual disk drives. Unfortunately, I never got my hands on one. How did the 1572 behave compared to the 1571, assuming they both had the same number of buffers, I'd have thought the save-with-replace bug even bit the dual disk drives, and not just the single disk drives. Dexter Nextnumber (talk) 21:36, 4 December 2009 (UTC)[reply]

Last or Least?

Regardless of whether you have a single or dual disk drive, the drive number is usually found in the decimal numbers found at the start of the command when opening the channel. It's my understanding that the drive number is reduced to a single bit, zero or one, and saved up in the Last Most Recently Used table, known as LMRU which some people translate as "Least" Most Recently Used. It is supposed to be a Last In, First Out sort of table. The idea is that, when you are switching randomly from one file to another, there may come a time you have to steal a bit to represent Drive 0 or Drive 1. One or the other. And the LMRU table is supposed to give you access to the most recent drive in use, and if you want to use the one that is most distant, or most out of use, you should use the one that is buried the deepest. The table can also be used to access different buffers, especially if you have been opening (without closing) a series of random files.

The main article could be improved by discussing the concept of the LMRU table. Dexter Nextnumber (talk) 21:42, 4 December 2009 (UTC)[reply]

The & command

The main article could be improved by discussing the & command. Speaking of which, isn't the & command a left-over from the days of hard drives like the Commodore 4040? Dexter Nextnumber (talk) 08:15, 17 December 2009 (UTC)[reply]

Relative files

There used to be some controversy over relative files, and which utility programs could back them up without changing them.

I think the main article could be improved by describing the way relative files were created, and changed. It would also help to explain which copy programs had a hard time backing them up. Dexter Nextnumber (talk) 22:56, 29 January 2010 (UTC)[reply]

I believe that the book "INSIDE COMMODORE DOS" had some misspellings in its section dealing with REL files. Be that as it may, the main page of this article could be improved if there were a link to an article on Commodore REL files. The main page of this article says that REL files are sequential in nature, like SEQ files. Okay, that may be true, but the data inside the REL file is supposed to be a series of Track & Sector links to the "Side Sectors" which are considered "data blocks." The main page would be improved vastly if there were a discussion of how this worked. Dexter Nextnumber (talk) 07:43, 23 March 2010 (UTC)[reply]

File types

The PKG USR and SEQ files were actually internally the same. You could do save"filename,u",8,1 and it would save your program to USR type of file. Likewise it was possible to write stream data into PKG file. It was also possible to LOAD"filename,s",8,1 to load a SEQ file. (This was hardly usefull, if the underlying file was not program tough.) The rel files could not be opened this way (or was it that they could be created with size zero, but not filled.) —Preceding unsigned comment added by 193.184.83.235 (talk) 14:02, 16 March 2010 (UTC)[reply]

I think you meant to say "PRG" filetype as opposed to "PKG" filetype. And you are right that they are internally the same. Dexter Nextnumber (talk) 07:44, 23 March 2010 (UTC)[reply]

File open modes

Is there and use of opening file in MODIFY mode except for fixing "splat" files?

Also it would worth to add information that files could be open in one of four modes:

READ
WRITE
APPEND
and MODIFY (but what does it do?)

--82.210.142.56 (talk) 22:00, 24 June 2010 (UTC)[reply]

Save-replace fix

The article currently states: "Commodore was made aware of Slaymaker's findings, and while they never issued an official update for the 1541 ROMs, they did fix the bug in Revision 4 of the 1571 ROMs."

I have two small problems with this. First, Commodore did issue official updates for this in December 1986: the release notes for the first upgrade to the 1541C firmware (i.e. 251968-02) specifically mention this fix, and thus 1541-II drives feature it as well since they're successors of this revision level (most 1541-II drives are 251968-03, with the exception of some Newtronics-equipped 1541-IIs that basically run on the older 901229-05, a regular 1541 firmware). And secondly, I have never seen a "Revision 4" of the 1571. The only known 1571 firmware revisions out there are 03 and 05. A "04" would be quite a find. Right now, the source of this "revision 4" seems to be Mr. Slaymaker's vague memory as quoted in a newsgroup from an e-mail (as sourced in one of the links at the bottom: "The 1571 ROMS starting with Rev 4, I believe, had the SAVE@ bug fixed"). My gut feeling is, he actually meant revision 5, since that would rather be the "fixed" or "updated" 1571 firmware revision.

87.143.152.27 (talk) 19:30, 25 September 2010 (UTC)[reply]

Version discussion

Missing among the information in this article is a discussion regarding new/changed features per version of CBM DOS. I think DOS 1 did not have support for relative files and I'm sure there are a host of differences. It would be helpful if there was a source somewhere that could list these out. — Preceding unsigned comment added by Kitsap1975 (talk • contribs) 16:07, 19 April 2017 (UTC)[reply]

Example code not rendering properly

The sample code after "Partial directories can be loaded by adding a colon and a template" shows up as {{{1}}}. Sgeo^TC 20:02, 25 August 2018 (UTC)[reply]

Fixed; needed a {{=}}.—Dah31 (talk) 02:53, 8 October 2018 (UTC)[reply]