|WikiProject Computing / Software|
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)
- 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)
$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)
- Yes, the article is correct, about both the address and the reason for it. Mirror Vax 23:32, 9 January 2006 (UTC)
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)
- 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)
- 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)
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)
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 & 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)
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)
- 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)
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 184.108.40.206 (talk) 14:02, 16 March 2010 (UTC)
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:
- and MODIFY (but what does it do?)
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.