Talk:Commodore 1541

message: This article is in dire need of a better, in focus photo.  I may still have a (VIC-20 off-white color) old model in the attic collection, along with the latch and flip door beiges, so I'll try to take a couple photos or unified "stack" photo soon.  -- Todd Vierling 03:46, 17 Jun 2005 (UTC)
replies: text: Or, if I beat you to it, I'll do it. :-) --Wernher 15:56, 30 November 2005 (UTC)
thread_title: Better photo needed

message: I just wrote the following in the section on The serial interface: To ensure a ready supply of inexpensive cabling for its home computer peripherals, Commodore chose standard DIN connectors for the serial interface. I'm quite sure I read this sometime, somewhere, but I'll need to check it again. I think the decision was made when they developed the VIC-20. If someone knows more about this, feel free to comment. --Wernher 15:56, 30 November 2005 (UTC)
thread_title: Confirmation needed

message: Description of :Image:Commodore64 fdd1541 front.jpg, emphasis mine
:Front view of the most common version of the Commodore 1541 disk drive, with open disk slot. This version uses a Newtronics drive mechanism, and the rotating lever is used to hold the disk in place. Note that the small toggle switch in the lower right corner is an aftermarket addition.
Description of :Image:Commodore 1541-II.jpg, emphasis mine:
:Commodore 1541-II, the second of two upgraded versions of the CBM 1541 (the first upgrade was the 1541C). The 1541-II has the more modern 'radial handle' locking mechanism.
What is the difference between a radial handle and a rotating lever? boffy_b 23:13, 22 August 2006 (UTC)
replies: text: I think they are the same thing - 'more modern', as opposed to to the 'push down - release pop-out' type in the early 1541.  Personally, I thought all the brown 1541 models had that earlier type of release (but it seems that I am wrong).  I briefly had a 1541C that had the rotating latch, which I thougt was new to the 1541 range at the time. Jason404 (talk) 14:53, 18 October 2008 (UTC)
thread_title:  Locking mechanisms 

message: The second paragraph under the heading The serial computer interface reads:
Because a Commodore engineer at the production site took out two traces from the final drawing of the C64's motherboard, thinking they were redundant, the disk drive transferred data at a tenth of the speed it had initially been designed to handle (see "On The Edge, the rise and fall of Commodore" by Brian Bagnall, for more details).
I believe this is incorrect.  The Vic-20 also suffers from the slow speed of the serial bus.  I remember reading this is due to the 650X processor having to do manual bit-banging of the serial interface to read out a byte.  The VIA chip has a hardware shift register which was originally supposed to be used which would have been much faster as the CPU would be free to do other things until the VIA had read in a full byte but unfortunately there was a bug in the silicon which prevented it from working properly.  The VIA chip was also used in the Commodore PET computers for sound generation and the bug in these machines meant sound needed to be turned off (disable the shift register) otherwise I/O operations (on a different parallel interface) would glitch.
--24.161.65.18 01:39, 26 September 2006 (UTC)
replies: text: Yes. The definitive reference is the IEEE Spectrum article (Commodore 64 should have a link to it). It was a deliberate design decision (in retrospect a poor one) to try to maintain compatibility with the 1540. (In fact, though, it wasn't compatible with the 1540!) Mirror Vax 06:29, 26 September 2006 (UTC)
thread_title:  Slow Bit-Banged Serial vs Fast Shift Register Serial 

message: The following paragraph needs a published source before it can be added to the article. The fix was described to me by a repair technician in the mid-1980s. Then I used it to repair my own 1541 when it finally would not hold its alignment. The fix worked perfectly, so I know the paragraph is factual, but I don't know if it was ever published.
Although a technician could realign the head, the head drive capstan was held to its motor shaft by a swage fitting that could loosen over time, eventually making realignment futile. Future misalignments could be virtually eliminated by drilling a hole diagonally into the top of the capstan and through the motor shaft, and then driving a snug-fitting pin into the hole.
I feel that this information reveals an important underlying cause for the issue, which users tended to blame entirely on copy protection.
Mwbrooks 00:03, 2 December 2006 (UTC)
replies: text: Yes, the head alignment was a big issue.  Early drives seldom outlasted their warranty period before they refused to read and write disks.86.176.156.193 (talk) 18:09, 29 November 2010 (UTC)
thread_title:  Head misalignment: source needed 

message: The Commodore 1570 was an upgraded 1541 for use with the Commodore 128, available in Europe.
Actually that sounds quite "1541-POV" to me. Technically, the 1570 was not an upgraded 1541 but a downgraded 1571. The 1570s originally should have been 1571s, except for that CBM didn't have enough heads and cases (and possibly other stuff) produced (or shipped) in time so the second heads of the would-be 1571s were replaced by the 1541-style dummy head, the DOS altered so that it wouldn't try to use it, and the whole thing packed into 1541-C cases with a new sticker on. Apart from the MFM capability mentioned in the text, just like 1571s, the 1570 can run at 2 Mhz. 
Anybody object if I change the text accordingly as soon as I bother? Cheers, Edwing 07:47, 21 April 2007 (UTC)
replies: text: Go on ahead, as you seem to know something about it that others do not. Jason404 (talk) 17:03, 23 November 2007 (UTC)

text: The temporary nature of the 1570 was given away by the sticker being a simple paper sticker rather than the more normal printed metal label.   Also, it wasn't the heads that were different, it was the complete drive as the 1570 used the same Alps drive that the earlier 1541s used.  One might have suspected that they were surplus stock from the earlier 1541s but the drives were different in that they contained a track zero sensor (and thus immuned from the misalignment issue.) 86.176.156.193 (talk) 18:15, 29 November 2010 (UTC)
thread_title:  Successor products 

message: Of course, the proper version of the Beatles song to be played on a Commodore 1541 would be When I'm a Sixty-Four. =) JIP | Talk 19:37, 28 February 2012 (UTC)
replies: text: <Groans> 109.145.22.224 (talk) 13:40, 27 April 2012 (UTC)
thread_title:  The drive head misalignment issue 

message: I have removed the original research tag because whoever placed it failed to provide any clue as to what they considered to be original research either in the article or here.  If anyone believes that the article does contain original research, then by all means restore the tag, but at least provide some sort of clue, either by identifying the problem with  or detailing it here. 86.159.159.194 (talk) 16:28, 18 October 2012 (UTC)
thread_title:  Original research tag 

message: This error occurs on this page, and several other Commodore-related pages.  And they all link to a seperate page Block allocation map.  I think this page, the mentioned page, and the several other Commodore-related pages all need to be fixed.  Specifically, BAM stands for Block Availability Map (not Block Allocation Map).  References include:
* 1541 User's Guide (CBM, Septemper 1982, p.9): "...[DOS] organizes them into a Block Availability Map, or BAM, and a directory."
* 1571 User's Guide (CBM, August 1985, p.23): "The VALIDATE command recalculates the Block Availability Map (BAM) of the current diskette..."
* 1581 User's Guide (CBM, 1987, p.34): "The COLLECT command recalculates the Block Availability Map (BAM) of the current diskette..."
I believe the reason Commodore calls it an availability map is because the set bits in the BAM indicate which blocks are available (opposite of allocated), and the sum of the available bits is stored in a seperate field to indicate the total number of available blocks of each track.  I also believe the wrong acronymn became popular because of one of the two commands that DOS makes available to manipulate the BAM, namely Block-Allocate (the other is Block-Free).  Regardless of my beliefs, Commodore is consistant and clear about the definition of BAM.
I just thought I should post this to discussion before I go making changes to multiple pages.Hydradix (talk) 14:09, 22 January 2013 (UTC)
thread_title:  BAM acronym is wrong 

message: Rotation speed, track-to-track speed, serial speeds, DMA, recovery time from reset, spinup time?  — Preceding unsigned comment added by 85.156.0.141 (talk) 14:41, 5 October 2013 (UTC)
thread_title:  Rotation speed, track-to-track speed, serial speeds, DMA? 

message: Hello fellow Wikipedians,
I have just modified one external link on Commodore 1541. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20050709013437/http://project64.c64.org/hw/1541_tricks.txt to http://project64.c64.org/hw/1541_tricks.txt
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 09:45, 11 August 2017 (UTC)
thread_title:  External links modified 

message: The infobox on the right states that the drive uses single-side single-density media, but the article later says it uses double-density.  — Preceding unsigned comment added by 90.195.165.114 (talk) 20:10, 24 November 2018 (UTC)
thread_title:  SD or DD media? 

message: If is it 1541, why do the two '1's in the photo look different?
Surely this means it's either 154I (uppercase i) or 154l (lowercase L) ... but we're not sure which.  I see that Commodore 154I redirects here, but Commodore 154l doesn't.
But all the sources refer to it as the 1541 likewise.  By a quick skim through the article, I can't seem to find anything addressing this discrepancy.
Can anyone shed light? — Smjg (talk) 09:39, 7 February 2022 (UTC)
replies: text: I came here with the same question. I'm going to assume that the number 1 is actually used in other places, like for example the documentation. But it would still be nice to know. Rua (mew) 15:46, 15 February 2023 (UTC)
thread_title:  1541?  154I?  154l?