Talk:Commodore DOS

message: 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)
replies: text: 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)
thread_title: Necessity of Non-English reference

message: 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)
replies: text: Yes, the article is correct, about both the address and the reason for it. Mirror Vax 23:32, 9 January 2006 (UTC)
thread_title:  $0401 or $0400? 

message: 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)
thread_title:  Save with replace question 

message: 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)
thread_title:  Last or Least? 

message: 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)
thread_title:  The & command 

message: 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)
replies: text: 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)
thread_title: Relative files

message: 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)
replies: text: 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)
thread_title:  File types 

message: 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)
thread_title:  File open modes 

message: 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)
thread_title:  Save-replace fix 

message: 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)
thread_title:  Version discussion 

message: The sample code after "Partial directories can be loaded by adding a colon and a template" shows up as . SgeoTC 20:02, 25 August 2018 (UTC)
replies: text: Fixed; needed a .—Dah31 (talk) 02:53, 8 October 2018 (UTC)
thread_title:  Example code not rendering properly