I used to make 40 track formatted disk back in the day on 1540/41/71. Sometimes I would even copy data to unused dir sectors (track 18) to get more space. The reason it is "stuck" is because the drive won't home to track 0. The I0: (or just I) forces a read of the BAM, and, yes, tries harder by bump homing. If you new a disk it will "fix it" too.
I remember a separate command to cause more read attempts. The quick bunch of clicks before the error is the drive checking a half track to either side for data. If the disk is completely blank then it errors out. I THINK if there's something there to almost read, it will spend a long time trying and even bang the head to track 0 and back to see if that helps.
Great video. When I opened my brand new c64 + 1541ii combo pack back in the day I misread the setup instructions and set the 1541ii jumpers to device 9. First power up I tried to load"$",8 and got nothing... ...half a very unhappy hour later I realised what I'd done. My Dad was not impressed.
Another fun and very interesting video. Loved the tidbit about the Fujitsu RAM chips that would retain memory after for minutes after powering off. Also, the copy protection measures taken by Karateka seem a bit extreme and definitely questionable. Love Darren's scroller btw.
About multiple drives... many commercial software (usually games) used a fastloader to overcome slow performance of 1541 / C64 firmware. A few of these use the clock (CLK), data (DATA) and attention (ATN) lines similar to original ROMs, only faster transfer rates. These normally don't cause a problem with other devices. Most fastloaders (from my experience) use both CLK and DATA lines to transfer data (instead of just the DATA line)... this automatically translates into 2x speed at 'official' rates and much faster is possible. The 'good' ones (most) use a timing delay and special CLK/DATA handshake to control communication. However a few 'bad' fastloaders use the ATN line to control communication (it seems like Ultima VI is one). Any device that hasn't been 'uploaded' with special code to know about the non-standard ATN use will 'jam' the serial bus. All standard CBM serial devices will pull one of the DATA or CLK lines low (sorry don't remember which offhand)... anyway this means that neither the C64 nor the desired device (like disk 8) will be able to communicate because some 'unprogrammed' device (like disk 9 or a printer) is holding DATA or CLK low. Going off topic... You might think you could devise a scheme to use all three of CLK/DATA/ATN to get a 'baseline' speed-boost of 3x (at 'official' transfer rate, faster still possible). However among C64, 1541 and 1571 only C64 can 'write' the ATN line. So you could devise a 'fast-save' to use all 3 lines, but you can't create a 'fast-load'. I'm not sure about 1581, but the CMD hard-drives and Jim Brain's uIEC allow the disk to write ATN so 3x 'baseline' fastloader is possible with them. I have never seen this done. If it were done, any other serial device would cause interference like described above.
To be honest, the fact that the 1541 controller doesn't seek to its home position on power-up was kind of bad design (as was the DOS not safeguarding against seeking beyond the boundaries of the disk). The copy protection just exploited that flaw.
@@Stoney3K I think commodore worked around this in some versions of the 1541 ROM. I had a lever-door model that seeked until it banged the head every time it was powered on or reset. It often went out of alignment too. I also had an Excelerator Plus (and they copied the 1541 ROM) that did not seek at reset.
@@coyote_den And on regular Commodore disks the head didn't really need to seek back home anyway since there was a marker on each track when it was a properly formatted Commodore disk. PC (MFM) floppies didn't have this, and neither did a lot of proprietary fast loader formats.
@@slightlyevolved Unfortunately, the court would probably award you up to $400 for the loss of your drive... then, the company's lawyers would immediately show you didn't own the original and win a countersuit against you for piracy to the tune of $250,000 and 5 years in prison. :\
Wow, luckily the head in my 1541 never got stuck back in the day. Would have frightened me for sure... I remember doing the auto fire trick at my friend's place a couple of times to confuse him though. ;)
My long-gone C64c was modified to have a soft-reset button, shorting out the user port pins as described. Had a friend mount a momentary push-button switch to the side of the case and soldered wires directly to the user port pins.
Speaking of 1541 problems, anyone remember the old "save with replace" bug? You could put a "@" in front of the filename to replace an existing file when saving a new version. I'd heard of it, but still used "@" because it was so darn useful. Then one day it trashed a whole floppy, so I never used it again, instead just adding "1", "2", "3", etc. to my filenames until I ran out of space and I'd go back and delete the old ones. I remember all sorts of things being blamed for the problem, including the common heat build-up in the 1541. Years later someone (Phillip Slaymaker) finally found the cause and published an article in "Compute!" and a later one in "Transactor" (Sept. '86) along with some ROM changes to fix the problem. It turns out the DOS in the 1541 has roots from the PET days where the floppy system contained two drives, "0" and "1". The 1541 normally operated as "0" but actually had a "1" virtual drive. This, and certain situations that could occur when doing a save with replace would cause the in-memory buffered copy of the block allocation map (BAM) to be "stolen". Then the disk version would not get properly updated and cause the whole disk allocation to be trashed. I never had an EPROM programmer, so I never implemented the fix myself.
Yes, I remember following the drama and mystery of that bug as a kid, as it was talked about in the various magazines. Very interesting stuff. I believe the bug has been fixed in all JiffyDOS ROMs, so that's another way to protect your files.
@@8_Bit Yes, it *has* been fixed in JiffyDOS, but old habits die hard. I didn't get JiffyDOS until several years after the end of the 8-bit era, and by then I had gotten into the habit of never using save-with-replace, and adding a "0" to all drive commands (e.g. I0, N0, etc) to prevent that bug. Still do, even though it's no longer necessary. 8^)
Great video, cool to see some of the things that can scare you into thinking your C64 is borked. I remember the first time I encountered the autofire bug, I turned the C64 on and didn't know the autofire on the joystick in port 2 was on, and of course when I typed LOAD got the LQAD as your video shows. I definitely thought my C64 has a problem for a bit until I unplugged the joystick and suddenly everything miraculously worked again, then plugged it in again and again it didn't work. It was at this point I examined the joystick and found the autofire was on, and switching it off solved the problem. I also then did what Robin did in the video and plugged the joystick into port 1 and fiddled a bit to find out what it would do. Thanks also for the explanation about why most later games used port 2 as the default joystick port. Always wondered about that (long forgot about the joystick autofire issues until this video reminded me). Guess it made sense, although some games must have found ways around this issue, such as Rampage which has simultaneous 3 player, using both joystick ports and keyboard at the same time, never found any issues when playing that game in 3 player mode.
Yes, it seems with careful programming (and perhaps with careful key selection on the keyboard?) most or all of the keyboard problems can be avoided. That's something I've meant to look into in more detail sometime.
Great tip on that initialize. Going to try that on my 1541-II which recently stopped working and where cleaning it with isopropanol didnt do much. Cleaning my 1541C with it did work however. But now that I think about it, both drives failed on me about the same time which could mean that some disk I tried parked it in track 42 as you said, but that the 1541C was able to get out of that at one point.
I always used to use a fork to short pins 1&3 on the user port. Becoming complacent, I carelessly ended up shorting the C64. Lucky for me, only blew the fuse.
I should have explained, resetting the C64 preserves RAM, and allows you to PEEK and POKE around from BASIC or with a machine language monitor. One major use of this is to POKE cheats into memory to give infinite lives etc. and then SYS to restart the game. Using the power switch will (usually) corrupt or clear RAM.
@@GigsVT I remember resetting a C64 with pins 1 &3 , and i did it at school with Scissors well one time i did it wrong and blew the fuse. The computer room teacher said I was not to do that again. My own machine I put a reset switch on it, but some programs would not allow a reset.
absolutely loved your video. one of your most dedicated subscribers now. your deep dives remind me of the stuff that ModernVintageGamer does in his copy protection series, but you show stuff in even more detail!
4 года назад+1
Oh, I remember those "long to forget" memory chips. When we had to sell my C64 (sadly ... since a PC was needed in the school but my family did not have enough money to keep the C64 as well), a potential buyer of my C64 had been scared off because of this ...
4 года назад+1
Thanks for opening the drive and showing what's happening inside! Nice and useful video!
The game Knights of Legend would randomly lock up on me during play, which made it so hard to get anywhere in it. One day I took my C64 to a friend's house and the game worked fine! It turned out that having my MPS-803 printer connected would randomly crash the game.
I took my vic 20 and c64 out of storage last summer after being tucked away for 2 decades. I connected everything up and everything seemed to be working fine then every now and then every other key wouldn't work... for both computers! I found out it only happened when I tried to play a game. Eventually I discovered it was because I was using a Sega Genesis controller.
I thought i was going insane until I did a quick search on ebay. I remembered my old gray disk drive when I was a kid had one of those swing locks, not that latch type you have there. Thought I was remembering wrong till I saw they really did exist lol.
As for the multiple drives issue with Ultima VI, I remember a similar problem with some of the early Amiga (A1000) games where, if it was unexpanded (512k, with the OS loaded into part of that), if you had an extra floppy drive games would sometimes not work right because that extra drive uses a small(-ish) amount of memory to do its work and that meant the game didn't have enough. Speaking of memory expansion on that old A1000, just to give an example of how far we've come in terms of RAM prices, my mom bought the 256k memory expansion module for my A1000 as a Christmas present and it cost her about $300. For 256 _K!_ That's a quarter of *ONE* megabyte of RAM, folks. I just bought a 128 GIGABYTE SD Card for my wife's phone and it cost about $20. That's about 500,000 times as much memory for 1/15th the price. At this rate, 1 terabyte memory cards will be in Cracker Jacks boxes within the next 5 years...
The multiple drive issue with some C64 games and many C64 demos is caused by disk fast loaders integrated in those games and demos. They use the IEC bus in a way that only works if there are exactly 2 devices on the bus (the computer and one single drive). Hence those also do not work when a printer is connected and turned on.
@@Okurka. Different technologies, true, but they are indicative of how much prices have dropped. Even if you look at how much flash memory has dropped in the last 10 years, it's night and day. But if we stick with actual computer RAM it's the same: A 32GB DDR4 RAM module is about $100 now. I paid WAY more for a couple megabytes worth of RAM modules for my ancient Win95 machine.
It still happens every now and than that my 1541 gets stuck that way. Thanks to your video now i know how that happens :-) Now i don't have to open it anymore to move the head physically. Thanks for that!
Good memories. That autofire thing got me all the time back in the day. The lack of compatibility with other drives is because the fast loader in use in that game, mixed with its copy protection, will be sending bus signals that the second drive may misinterpret as being something it should respond to, and will respond. Fast loaders are basically viruses in that we would usually transfer a bit of software, a few hundred bytes or so to the drive and get it to run it. If you think about it, it was basically malware, except that it does a nice thing instead of a bad thing. The copy protection markers on extended tracks was exactly what caused this bug for me back in the day as well. Someone got me to format a disk I think to reset the head. Do you have one of those old head alignment testing disks?
That whole "Side One is Side Two" thing was mind blowing. The number of times I physically looked at the top side of the physical disk, thinking I was looking at side one... All those years, I was wrong.
At the end when he says "Thanks for watching..." i'm expecting him to follow it up with "Keep your joyStick on the Ice." Please do this just once, it would be a super funny nod to AvE.
Oh man! i remember bricking my 1541 as a kid. My dad somehow found a friend that was into computers and knew the command to re-initialize the drive. I was not able to play anything for days!
Thank you so much for this great video. I grew up with a C64 but just started using it again after a longer hiatus and totally forgot the floppy drive initialize trick you show at 10:50 in the video. I thought I had broken it since even power cycling didn't help and it would not show the directory of any floppy. Initializing it fixed it again.
Some EA games used to give me trouble loading on my 128 in 64 mode on my 1571. If I pulled on the disk at exactly the right moment on gamestart it would load. I wonder if it was something to do with the track slots. I heard it was a quirk of copy protection.
Wow, I went through at least two 1571s with my 128 because of that stupid drive thing. It drove me crazy! Although, it wasn't Karateka that triggered it. I'm sure it was other copied games, though. I wish my time machine was working. I want to go back and give myself that initialize command and spare younger me WEEKS of frustration and money!
Maybe the original Karateka disk has something saved on the tracks that would not be copied if you try to clone the disk as a copy protection. The borking may be an accidental side-effect when the game checks if there's data in the copy protection area or not.
We Apple II users had a bonus with our copy of Karateka. On the unmarked flip side of the disk was a second copy of the game that would boot with the graphics flipped upside down!
That's an extremely cool easter egg, or whatever we should call that :) Some online sources say the C64 version had this upside down version too, but I've never seen it; my original copy has the Atari 8-bit version on the flip side!
@@8_Bit Interesting. I wonder if all versions of Karateka were mastered as 2-sided, with different things on the flip? Especially wonder if the Atari version has the label on the back and the Commodore version on an unlabeled front?
A recent scare has been old disks that just have so much oxidation buildup that they coat the read sensor. Then no further disks work. Saw this on another channel...rather than open up the drive, if you don't have a cleaning diskette you can cut up a 3.5 cleaning diskette and take that white material and tape it over a 5.25 diskette's opening and dab it with alcohol, then send commands and presto cleaned.
3:01 Commodore could have filtered out the joystick interference by setting Port A to $FF and reading both Ports A and B. If either of the reads isn't $FF, then a joystick is shorting out a line. (I think you can read an output line to detect shorts, or else you can switch it to input with Port DDRA.) Do this both before and after scanning the keyboard, and if a joystick press is detected at either point, then throw out the keyboard scan. This method can only fail if a joystick switch is pressed and then released during the microseconds after the scanning starts and before it finishes. On the down side, if a joystick switch is stuck on, then the keyboard will seem "dead". 3:58 That's what I did with my VIC-20. I had a paperclip and laminated it with packing tape to hold its shape. Fortunately, the C128 had a built-in Reset button. 6:52 Interesting… if you need a particularly long loader, you can continue past the BASIC vectors you need to intercept, into the Cassette Buffer, and then onto screen RAM. 8:14 I guess it uses a fast loader that abuses the serial bus in such a way that any other drives on the bus will get confused and interfere with it, such as by using the ATN line to transfer data. 9:19 Just use your pirated copy of Fast Hack'em! 12:34 The reason they limited themselves to 35 tracks is that some of the earlier mechanisms that were supposed to support 40 tracks didn't work properly. Later mechanisms had no problem with 40 tracks, but the die was cast. 15:12 It does seem odd that it doesn't auto-fix the problem since normally when it runs into a read error, which it would when trying to read non-existent track 42, it does the head-banging thing to make sure it reached track 1. Maybe it senses no signal at all on the disk and assumes that the disk is completely empty and doesn't bother banging its head?
That's how I read the keyboard and joysticks, and the same method is used by GEOS, or else a GUI with a mouse or joystick would have been a lot harder to implement (might work with a user port interface, but that would have raised the cost of entry). Even port #2 had some interference with the KERNAL keyboard routine, albeit not nearly as much as port #1. As for the track 42 problem, my Blue Chip drive actually used its track 1 sensor, so it never, ever banged its head against the stop, but it still got stuck on track 42, which is undoubtedly due to its ROM's, ahem, 1541 roots.
That track 42 business is pretty neat. When I tried to copy the Abacus Basic-64 compiler nothing could touch it including Fast HackEm. It wasn't until finally, many years later using Star Commander (building d64 files) that I find out that data on that disk went all the way out to track 40. I guess I just wasn't persistent enough in 1986. I actually bought a backup copy from Abacus at the time.
About "CBM80": aren't there a bunch of games, that were released on multiple formats, including cartridge? Just thinking, that the same code was used on both cartridge and non-cartridge releases, which could explain the magic number being present.
Incidentally, the VIC-20 used a similar scheme, but since cartridges started at a different address the "80" was replaced by the address of the cartridge.
I think I heard that was because each floppy drive in use needed to use some Amiga RAM for buffers, and on some games it was too tight? That probably doesn't explain all cases though.
@@8_Bit A guy that I knew (that did ahem game modification) said it was a mix of the extra memory used and that some games specified memory area so the drives couldn't be used (he said it was a form of memory protection)
9:15 Omg! That happened to me! I vividly recall that 4 beat sound the file not found error returned. I had 100s of disks filled with content from the golden bbs days. I think I was going through some games and all of a sudden the drive wouldn't read anything anymore. I think that's why I boxed it up and archived the system. Nothing has made me want to power on my c64 more than watching the fix for that issue. Thank you for a great explanation! Cheers Side note: I had an apparently copy protected version of Karateka. There was an invisible forcefield/barrier that prevented the player from entering the final boss's door. It was only on my downloaded version, not the official version.
Hi, Robin! You have a Russian chip in your 1541! At 11:39 and 12:00, that brown EL7406 (position UD1) was made in the USSR! Or at least with Soviet technology, on Soviet made production line. The brown resin, and the font of the stamping makes it obvious. Maybe the Chinese bought chip fab lines from the Soviets? I have a board from a Datasette with the same brown EL74xx chip on it, i'm keeping that only for this reason. Here are some photos of Soviet TTL chips for comparison: retroelektro.uw.hu/muszer/omszov_oe92_ttl_checker/omszov_oe92_ttl_check_009.JPG i.ebayimg.com/images/g/kRQAAOSwTKtc1IZX/s-l1600.jpg Hey! I found a Twitter thread exactly on this topic! It's proven! Soviet made! Even the lead spacing is 2.5mm instead of 2.54mm twitter.com/tubetimeus/status/1031328650556141568 Here are some decapped EL74xx s, one of them has cyrillic marks on the die: radiopicture.listbb.ru/viewtopic.php?f=3&t=50&start=280&st=0&sk=t&sd=a Cool, huh? :)
I remember DI-Sector program was our goto for all needs even sector reading and sector editing. I copied Karateka using Di-Sector and never had this issue, though this issue also occurs if you interrupt the format process. Open 15,8,15 "I" was a life saver, I actually had friends parents pay me to fix this problem usually 5 or 10 bux as I was a complete jerk lol. Great video! Oh btw, I used the 1541's that had the lever disk door, and we did use more than one with all our Ultima games including 6. Maybe we were just lucky but we had a slew of these old drives back then as even repair shops would throw them out when it had this simple issue.
Since the SHIFT-LOCK key is wired directly to the Left SHIFT key, the light would also come on every time you press Left SHIFT, like I did eight times when writing this sentence.
@@csbruce isnt there a way to cut the trace from the 2 keys so the mechanical lock is on its own circuit thus the chance to include a led only in this branch?
@@alerey4363: You can't put it on a separate circuit or the Kernal's keyscanning routine won't read the key. Maybe you could do something with diodes to make it so the light only activates on the Lock key but not the regular Shift key it's tied to.
@@alerey4363: No, it's wired to the Left Shift key and generates the same scan code. If you disconnect it from the Left Shift key, the Kernal won't be able to scan it. Or maybe adding a light is way simpler than I'm guessing. The two keys effectively will be wired in parallel, so if you stuck an LED inline the path that goes across the Lock key, that might work. That part of the circuit would only close when the Lock key is down. There might be other electrical issues to deal with.
i think Jason Scott has a talk on the copy protection. maybe check out "Jason Scott Rescuing The Prince of Persia from the sands of time " or "DEF CON 18 - Jason Scott - You're Stealing It Wrong! 30 Years of Inter-Pirate Battles " ...maybe try the second one first
For hacking games, we used to shim the top of the 1541 a little bit, and tape a piece of index card to the head, then use a pencil to mark off important tracks on the card. You could watch for the mark and then yank on the card to cause an error while copying a game. It wasn't very scientific but with the right software and just the right touch you could reliably copy games or even force your way past some errors and protection schemes.
We got a C64 in 1983 and a 1541 shortly after that. I was only 9 yrs old. Dad took me to Toys R Us in San Antonio to buy a couple of games. Games ran on Joystick Port 2 but coming from Atari the games ran on Port 1. I couldn't play this one game for a few weeks due to this issue. After many attempts to get it working again I remember looking at both ports on side of C64. My 9 year old brain finally clicked and I tried the other port and sure enough it worked. Also learned a lesson about reading the instructions. :o)
Cool. I was actually just about to type up a comment asking if you could explain the joystick port behavior in regards to keyboard input when you said in the video you might do a video on it in the future. I'd be interested in that. I always knew joystick port 1 was really goofy (and avoided using it as much as possible) but I had no idea even joystick port 2 could cause unexpected keyboard behavior.
I didn't previously realize that Port 2 could cause problems either, but it does make sense. A keypress is detected by putting a '0' bit into keyboard-row-select register $DC00 and then checking for '0' bits in keyboard-column-read register $DC01. If a joystick switch is closed in Port 2, then this will force a '0' bit into the row-select register, which will hardware-select the corresponding row of the keyboard matrix, in addition to whatever row the keyboard-scanning routine has currently selected. This is why it causes pressed keys to be misread but doesn't cause spontaneous keypresses when no key is being held down like joystick Port 1 will.
Thank you so much , you saved alot of time , i use my commodore more often and stuff like this happens , i spent hours and couldn't find the problem. You sir helped me saving time
I remember with my 1541 sometime if there was some problem with copy protection the head would come too far forward (close to the center) of the disk and get stuck....and then no longer read any disks. Until you put the Head Vibration Protector cardboard insert if fits in but stops hanging out a little bit, push it all the way in and it would push the head back to the right place and it would read disks again...somehow I just figured out how to do it when it happened...It is like the extra little square tab sticking in was long enough to push the head back into place...must be like what that initialize command does...You should make another video showing that you can fix the karateka drive killer with that HVP insert that came with the drive originally. I remember when this first happened and I about holy crap I just broke this $200 disk drive too just like how Robin said!!!
My 1541 II got stuck once, and it took me days to find the solution... Initialize didn't work in that case, and I didn't have the original disk insert. My deepest thanks go to the kind soul that had the proper measurements for the "tracker card" as he called it. I quickly made one from tthe cardboard box of a package of frozen pizza (perfect thickness), and i've kept it in my box of floppies since. ;) And, yes, that tab is meant to push the drive head back to Track 1 if you want to transport, store or move the drive - it really does double as a hard reset tool if the drive gets stuck and the initialize doesn't work... :) I agree that Robin should show the trick with the insert - and how to cut out your own if you don't have an original. Bonus for making one for the 1571 as well, since the 1541 insert doesn't work for that one... I'd love to show people how to cut their own, but I can't seem to find the proper measurements anymore :(
I'd like to send out a fond wave out to my old 1541-II drives, wherever you may be... Things of beauty that should have been conceived so much earlier in Commodore history.
The problem with games malfunctioning with multiple drives attached is a consequence of their fast-loaders. The Vic20/C64 IEC connector has one transmit-only "attention" wire as well as two bidirectional wires that are normally used for clock and data. If a program outputs a pulse on the attention wire and then outputs a sequences of pulses on the clock and data wires to indicate that it isn't trying to communicate with to some particular device, that device will ignore everything on the bus until the next atttention pulse. Some fast loaders, however, use "attention" as a clock wire and use both of the other two wires for data. Normal IEC communication would have the drive output both clock and data, but having the C64 supply the clock and having the drive send data in response makes communication resilient against VIC-II cycle stealing. Using the attention wire for clocking means that the drive can send two data bits for each clock pulse. The problem with doing this is that if there are multiple devices on the bus, any device that isn't explicitly prevented from doing so will be likely to interpret some of the clock/data wiggles as attempts to address it.
Before I had the Action Replay I used some kind of three-way-reset (manually, I sticked some cables into the expansion port): • Normal reset (/RESET to GND) • Short reset (/RESET to GND via a capacitor, only a short impulse ignored by any device on the IEC bus. You can read the error from the 1541.) • (/EXROM to GND, /RESET to GND, release /EXROM to GND shortly after /RESET to GND was released. KERNEL reads $8000 and just receives garbage and cannot find the CBM80 magic text. /EXROM must be released soon as the memory test routine in KERNEL would overwrite the RESET vector at $8000.
I think the first game I tried to copy, which didn't work, was Beach Head II. The copy came up with a warning notice that it was a copy and wouldn't work. We had a dubious copy of Fast Hack 'Em, but it was only with a future update and the parameters disk that the copying worked.
Kareteka was notorious for being one of the first c64 & Atari-8 games with very effective copy protection schemes . it was one of the copy protections that directed the drive to look at a damaged or unreadable track and if the value didmt match the encoded hash the game wouldnt work or would only work for a few levels and then abort. i know it took years for A8 kareteka to be cracked, and even the smart copying systems like Happy Drive didnt do it. Supposedly the trak ( brand) z80 based atari drive would make copies because it could replicate the physically damaged areas of the floppy disk.
I think the joystick in port 1 is just acting like part of the keyboard. You can press up on the stick to get a 2 (at least I think it's up), or press 2 and send the character up... same thing to the computer. Basically just watching for those characters is the "joystick driver software" for port 1 (not for all types of controllers there, though). Right? As for how 2 works, I guess that's a little more complicated.
Actually joysticks do... in both ports :) Port 1: Up = 1 Down = Left arrow character Left = CTRL Right = 2 Fire = Spacebar Port 2: Up = Commodore key + F3 Down = Commodore key + S Left = Commodore key + F Right = Commodore key + H Fire = Commodore key + K Those presses will fill memory locations 56321 (port 1) and 56320 (Port 2) respectively with identical values for the corresponding joystick input. Robin has demonstrated how to read joysticks from those addresses in another video :)
As I recall, the 1541 disk drive can access 84 tracks labelled track 0.5 to track 42. Due to the width of the read/write head, it cannot effectively access adjacent tracks without the possibly of the magnetic fields bleeding into one another hence the half-tracks in the numbering scheme. However, some copy protection schemes took advantage of this. Most commercial disks only go up to track 40. But the very first production line of 1541's had issues accessing beyond track 35, hence the kernel on the C64 and 1541 doesn't _write_ beyond track 35 by default (but it does read). But the C64 and 1541 are both fully programmable, so commercial disks would usually store data up to track 40. As the speed of the disk spin was programmable, the head position was programmable, and the encoding of the magnetic flux to binary encoding was even programable, you had a lot of creative copy protection. The only thing not programable was the sync mark, I believe. Also, the 1541 does not have a way to detect which track it is on, so when it starts up, the head psychically seeks below track 1 causing it to hit the end and make that "gunshot noise" to sync itself up with track 1 before proceeding. And for some reason, when there's a file-not-found error, the head seeks to track 0, I believe, causing a prolong "gunshot noise". I don't know why. And if you position the head to track 42, which is a track number the drive recognizes, it tends to get stuck. Again I'm not sure why. But I had it happen to me when I was 8 years old with my shiny new drive and I disassemble it and physically moved the head to fix it. Regarding Ultima, Commodore ran into early issues programming the IEC bus communication on early version of the kernel (I forget why, but I think they were crunched for time) so they settled on a blocking, bit-for-bit serial asynchronous communication with full handshaking where only one device could communicate at a time, which worked but was dirt slow. It's why you see a lot of fast loaders out there. To work, all devices on the IEC need to honor the protocol. You can actually do parallel data data transmission and synchronous data transmission (the CPU speeds between the C64 and 1541 vary by a slight bit, something like 64:63 cycle ratio or something). Several of the pins are fully programmable. You can speed up loading in a way that doesn't break the IEC protocol or you make it even faster by breaking the protocol. This is probably where the lock up is occurring. If you have any devices on the bus that aren't using your custom protocol, it will likely break the communications. I've seen a fast loader that told me to switch off my printer before loading a game and it was blazing fast. I bet, I bet that's it. It's some customer loader, used for fast loading or copy protection or so the game or music can play while loading or all of the above, that bends the protocol thus doesn't play nice when there's more than the expected number of devices on the bus. That extra drive 9 is not being reprogrammed and thus is speaking out of turn and messing up communication between the C64 and drive 8. Anyway, this is all from memory, so I'm not 100% sure of the specific details, so feel free to correct me. I do miss growing up with my C64, though. :)
«As the speed of the disk spin was programmable» I don't think that's true. The only control is on-off in bit 2 of $1C00. «the encoding of the magnetic flux to binary encoding was even programable» I assume you're referring to the bit density-timing, for which the 1541 offered four operating speeds in bits 5 and 6 of $1C00. That could be used to make your custom disks unreadable at non-standard speeds. «The only thing not programable was the sync mark, I believe» The Sync mark was written by the disk drive itself since the Index Hole on the disk was unused, so the Sync mark and the entire framing of the data blocks was fully programmable. I assume this is why copiers went to full "Nybbling", because publishers were using custom disk formats. «Commodore ran into early issues programming the IEC bus … so they settled on a blocking, bit-for-bit serial asynchronous communication with full handshaking» They were originally planning for the VIC-20 to use a hardware shift register like the C128 does, but the shift register in the VIA chip had a hardware glitch and couldn't read data reliably. (Apparently, there's a simple hardware fix for this, but they didn't know it at the time.) But, the slow software bit-banging wasn't much of a problem for a computer with stock 5K of RAM. Ironically, the hardware shift register in the C64's CIA chip worked just fine, and so it could have had the fast serial bus to go with its 64K of RAM, but backward compatibility would have been too complicated for the time frame. «where only one device could communicate at a time» Any hardware bus with shared data lines can only have one "speaker" at a time, such as with USB 2.0. The IEC bus did allow for multiple simultaneous "listeners", though that would have limited utility. I think someone programmed a 1541 to spool directly to a printer without any intervention from the C64. «You can speed up loading in a way that doesn't break the IEC protocol» JiffyDOS managed to achieve high speeds while still playing nicely.
That's right! The control was on the clock speed so it was the data density that changed! Thanks for all the comments! I forgot how much I loved this stuff. I found a web page that has a lot of information about this stuff in regards to how it was used in copy protection-- I need to read it later when I have time. Here's the link to share: c64preservation.com/dp.php?pg=protection
I wrote: «Ironically, the hardware shift register in the C64's CIA chip worked just fine» Correction: While the shift register in the C64 was fine, the 1541 still used the VIA chip which still had the bug. It wasn't until the 1571 included the CIA chip that the problem was fixed on both sides.
The drive head didn't actually get "stuck" on track 42. That little shuttle it did back and forth was half stepping as it tried to read sector markers. The commodore drives were soft sectored and relied on blips on the disk to mark the beginning of the sectors rather than an LED shining through the index hole. (hard sectored) Although the index actually marks the beginning of a track. It seems the software engineers assume the head is always in the used area of the disk and just read for the track marker or sector markers. If they don't get anything, they half step the head one way and then the other in case it was just stopped a half step off the track. I bet a format command would put things right again since it does a home on the head.
Happened to me as well (stuck disk head). I have been opening the drive and moving the mechanism manually to unstuck it, until I discovered that INIT command restores it too.
One thing i always remember was when giving the advice, "Turn you computer off for 5 seconds" i always wondered why RAM which was powered by electricity managed any state. I could see an eprom doing that but not static RAM
The C64 uses dynamic RAM ICs, which use a tiny capacitor to store the value of a memory location. It does not use static rams for the main memory. That was one of the cost savings in the C64, the VIC-II chip had DRAM refresh circuitry so Commodore could use the cheaper DRAM (instead of the far more expensive static RAM).
As far as I know, thus is not a physical lock on the drive. It is more like a "bug" of the ROM. Let me elaborate. When you try to read the directory, the ROM will spin up the drive and read the current track (without moving). If it could read it, it would have figured out which track it was and move accordingly. Piece of cake. However, when unable to read the track, it will first assume that it is half track before or after a real track and try both options. Thus the slight back and forward motion you see. Under normal circumstances, either of these would have yielded a valid track and we go back to the first case. But here we're in track 42, which was never initialized, thus it will never be able to read and will just give up. This also happens when the heads are dirty and you try to read the directory, but only for the directory as far as I can tell. because when reading files it does try to recalibrate by going to track 0. Just my two cents.
Yes, I believe this is correct now; a few people have explained it to me since I made this video. Next time I make a video about the 1541 I'll try to explain this correctly. Thanks.
Never thought of the serial standard on the C64 as a precursor to USB - but yeah, i could see that. Not quite as close to USB as HexBus from what I've gathered, but still neat to realize. (Incidentally if you ever get some HexBus stuff for your TI, by all means do a video :) )
the 1541C (the white variant of the original 1541) is the only drive that would seek back to track 18 when powered on. On the other models, the head doesn't really get phisically stuck on tracks > 35, the problem is just firmware. The disk firmware first tries to detect on what track the head is currently positioned to. If it has been moved on an unformatted track (> 35) then it can't read any sync/format informations and the firmware just tries moving half a track forward then backwards just to compensate for any alignment issue. If it can't still identify a valid format, it gives an error. You can obtain the same behaviour inserting an unformatted disk when the head is on a valid track. The only way to have disk firmware seek back to track 1 is using the "INITIALIZE" or "I" command.
On a normal directory load the drive just checks the current position and the neighboring tracks without calling the recalibration as on format or initialize. With a dolphindos formatted disk (if it can read the sector header without dolphindos) or if being on track 35 max it will read the sector header and know where to find track 18. BTW: when formatting you can shorten the head bang by seeking to track 35 before doing it. Not an issue on 1541- II as there have a light sensor for track zero.
wow, jack attack...My son and I played HOURS of that game! the good old days...I still have a bunch of extra chips and games but no working computers....
In regards to Karateka, I am surprised the company wasn't sued. I don't know if this was INTENTIONAL or a flaw in their copy protection.. As far as copy protection on the C-64, early versions are the ones that caused most damage to drive. I call those "stepper motor" versions, for instance Sector error 21 caused the head to "bang" (what you referred to as the machine gun sound). Over time these protections caused the head to go out of alignment and really mess up your 1541 drive, where you could eventually no longer read disks properly or at all. Later copy protection did not bang the head (i.e. error #29) etc, but these copy protections (#21, #23, #27, #29( were easy and could easily be copied. Then came more sophisticated protection like half tracks, tracks beyond 35, as 35 is the normal upper limit, but modified routines written to drive could allow them to go beyond, for example the protection could be stored on track 40 or in a half track. Then more sophisticated protections like GCR, etc. So for Karateka, my theory is that it used one of the non conventional protections, meaning it would move the head to a non standard / non conventional area inside the drive (half track, past track 35, etc, and just LEVAE it there. So this explains why you could not access your disks anymore even after powering it off......This in my opinion could have very well been a flaw in the 1541 design, not automatically resetting the head's position So your INITIALIZE command does just that, it will RESET the head back into a normal position, unfortunately, the banging on the steppe rmotor is NOT a good thin for the 1541, eventually this caused 1541 drives to out of alignment, and the only way to fix it would be to open it up and re-align the heads, but you'd need special calibration software to do it, not something most people have access to, but a fairly easy fix. Good thing that eventually copy protection was non destructive, no banging of the head. But eventually you had sophisticated disk copy tools that were compatible with half track, though the multi protection and GCR ones were really tough (i.e. GEOS64) but all of these could be cracked by just bypassing check and jumping to start of game....... As far as games with multiple checks later on, another way could be to just emulate and fool the loader into thinking that the value it is comparing does match, so it can apply to any other checks. End result, no protection is uncrackable. BUT.......what if you were to store some the checks inside non standard tracks, now that would be tricky. So as to Karateka, well let's assume it was poor coding, it moved the head to a non conventional position and left it there instead of resetting its position back, as most other games do. Also Karateka has multiple protection routines, so even if you were to successfully copy the game with the right copier, you would have had weird game behaviour. Even when formatting a 1541 disk you would hear that initial stepper motor banging, good thing they eventually made formatters that did not exhibit this behaviour (flaw). I'm happy you figured it out using the "I" command . If this was done now company would face hefty lawsuits :D A few modifications to the ROM would have prevented the stepper motor bangs and automatically initialized the head's position upon powering on.
I had the track 42 error happen on my 1541 2 several times over the years. I found inserting the protective sleeve that ships with drive would also fix the problem. However, I have no idea if it did any physical damage as my drive never needed repairing in the 10 years I had my C64 and worked flawlessly other than the track error.
I have an old c64 well preserved in a plastic box with its cables and everything including 2 1541's. A month ago I decided to connect and play some time with it but.... It was runing abnormally, some characters on screen, did not boot a couple of times, etc.. looks to me it just died while being stored!
that is a common failure, some oxide deposit over IC sockets ... just pull up chips and reinserted it, that removes oxide so electric contact getting ok again...
Isopropyhol lol. I have a boxed 1541 drive that has been in storage for over 20 years. One day I'm going to set it back up, I just need another c64 as I do not have one. I also have a Oceanic drive which is also boxed and been in storage for at least the same amount of time, I do not have any idea if they work still. I am guessing they should as my dad would not have kept them I guess.
Interesting, as I recently just backed up most of my old disks and the only disk I had major failing to copy was the one I had with Kareteka. However, nearly all my games are already pirated copies. Another however is that the source copy runs fine on my C64.
Imagine the makers of Karateka deliberately messed up your 1541 for copying the game - that's cruel. Also the fact you were able to fix it yourself at age 12 is amazing. I would of cried to my mom to buy me a new one 😂🤣 Also I remember I had a Vic-1541 disk drive for my Commodore 64. I bought it used as a new one was so expensive. I remember some games wouldn't load up on the Vic1541 - the disk drive would make funky noises and then just stop and the small light would flash repeatedly. I wonder if it was due to functionality issues with such an old 1541 drive operating on a C64?
I couldn't even get Ultima VI to load on my C64c and 1541-II. So I took it to the store I bought it from and it worked there so I went back home and then it would load. I have no idea why.
The file not found error with the same sound happened to me as an 8-9 year old - but it was with a 3rd party disk drive with a turbo loading feature (the LED light was square and it would turn from green to red) I thought it was completely screwed. I wish I knew the initalise code back then as I don't think I ever recovered from it...
Have you ever heard of disk copy protection that will format or otherwise blank the disk if a copy is attempted? My brother once loaned his original disk of Alcon to a friend, and that friend tried to copy it, and when it was returned the disk was blank. My brother concluded it must have been a copy protection scheme. I'm doubtful of that, but none the less I've always been afraid of trying to make a backup copy of my original Alcon just in case it got the same blanking result. Can that happen?
I used to make 40 track formatted disk back in the day on 1540/41/71. Sometimes I would even copy data to unused dir sectors (track 18) to get more space. The reason it is "stuck" is because the drive won't home to track 0. The I0: (or just I) forces a read of the BAM, and, yes, tries harder by bump homing. If you new a disk it will "fix it" too.
I remember a separate command to cause more read attempts. The quick bunch of clicks before the error is the drive checking a half track to either side for data. If the disk is completely blank then it errors out. I THINK if there's something there to almost read, it will spend a long time trying and even bang the head to track 0 and back to see if that helps.
Great video.
When I opened my brand new c64 + 1541ii combo pack back in the day I misread the setup instructions and set the 1541ii jumpers to device 9. First power up I tried to load"$",8 and got nothing...
...half a very unhappy hour later I realised what I'd done. My Dad was not impressed.
Complete tangent -- Fred Savage used the same joystick in The Princess Bride..
You see the joystick and the 1541, but never the c64 itself..
Another fun and very interesting video. Loved the tidbit about the Fujitsu RAM chips that would retain memory after for minutes after powering off. Also, the copy protection measures taken by Karateka seem a bit extreme and definitely questionable. Love Darren's scroller btw.
About multiple drives... many commercial software (usually games) used a fastloader to overcome slow performance of 1541 / C64 firmware. A few of these use the clock (CLK), data (DATA) and attention (ATN) lines similar to original ROMs, only faster transfer rates. These normally don't cause a problem with other devices.
Most fastloaders (from my experience) use both CLK and DATA lines to transfer data (instead of just the DATA line)... this automatically translates into 2x speed at 'official' rates and much faster is possible. The 'good' ones (most) use a timing delay and special CLK/DATA handshake to control communication.
However a few 'bad' fastloaders use the ATN line to control communication (it seems like Ultima VI is one). Any device that hasn't been 'uploaded' with special code to know about the non-standard ATN use will 'jam' the serial bus. All standard CBM serial devices will pull one of the DATA or CLK lines low (sorry don't remember which offhand)... anyway this means that neither the C64 nor the desired device (like disk 8) will be able to communicate because some 'unprogrammed' device (like disk 9 or a printer) is holding DATA or CLK low.
Going off topic... You might think you could devise a scheme to use all three of CLK/DATA/ATN to get a 'baseline' speed-boost of 3x (at 'official' transfer rate, faster still possible). However among C64, 1541 and 1571 only C64 can 'write' the ATN line. So you could devise a 'fast-save' to use all 3 lines, but you can't create a 'fast-load'. I'm not sure about 1581, but the CMD hard-drives and Jim Brain's uIEC allow the disk to write ATN so 3x 'baseline' fastloader is possible with them. I have never seen this done. If it were done, any other serial device would cause interference like described above.
Your videos are like triple features. You came for the main point but you get other awesomeness. Always wanted to know why my karataka copy did this.
"The old computer says, 'Creak'." I really dig this dry humor.
I wonder how many 1541s the Karateka authors bricked for those who didn't find the drive re-initialization trick.
To be honest, the fact that the 1541 controller doesn't seek to its home position on power-up was kind of bad design (as was the DOS not safeguarding against seeking beyond the boundaries of the disk). The copy protection just exploited that flaw.
@@Stoney3K I think commodore worked around this in some versions of the 1541 ROM. I had a lever-door model that seeked until it banged the head every time it was powered on or reset. It often went out of alignment too. I also had an Excelerator Plus (and they copied the 1541 ROM) that did not seek at reset.
@@coyote_den And on regular Commodore disks the head didn't really need to seek back home anyway since there was a marker on each track when it was a properly formatted Commodore disk. PC (MFM) floppies didn't have this, and neither did a lot of proprietary fast loader formats.
@@slightlyevolved it is illegal to set a boobytrap for house protection...
@@slightlyevolved Unfortunately, the court would probably award you up to $400 for the loss of your drive... then, the company's lawyers would immediately show you didn't own the original and win a countersuit against you for piracy to the tune of $250,000 and 5 years in prison. :\
"Say it's 1984..."
That's why I love this t-shirt: www.amazon.com/dp/B07CF9HG5B/ref=cm_sw_r_tw_dp_U_x_hQRZDbRPNTRXY
Wow, luckily the head in my 1541 never got stuck back in the day. Would have frightened me for sure... I remember doing the auto fire trick at my friend's place a couple of times to confuse him though. ;)
Yeah I never encountered that one either. Would have definitely freaked me out.
That's what my friend did as wy, to piss me off, he moved the joystick when I tried to type something...
We always used the joystick-keyboard interference to start a two player game of Bubble Bobble :) No need to reach for the keyboard to press 2.
My long-gone C64c was modified to have a soft-reset button, shorting out the user port pins as described. Had a friend mount a momentary push-button switch to the side of the case and soldered wires directly to the user port pins.
Speaking of 1541 problems, anyone remember the old "save with replace" bug? You could put a "@" in front of the filename to replace an existing file when saving a new version. I'd heard of it, but still used "@" because it was so darn useful. Then one day it trashed a whole floppy, so I never used it again, instead just adding "1", "2", "3", etc. to my filenames until I ran out of space and I'd go back and delete the old ones.
I remember all sorts of things being blamed for the problem, including the common heat build-up in the 1541. Years later someone (Phillip Slaymaker) finally found the cause and published an article in "Compute!" and a later one in "Transactor" (Sept. '86) along with some ROM changes to fix the problem. It turns out the DOS in the 1541 has roots from the PET days where the floppy system contained two drives, "0" and "1". The 1541 normally operated as "0" but actually had a "1" virtual drive. This, and certain situations that could occur when doing a save with replace would cause the in-memory buffered copy of the block allocation map (BAM) to be "stolen". Then the disk version would not get properly updated and cause the whole disk allocation to be trashed. I never had an EPROM programmer, so I never implemented the fix myself.
Yes, I remember following the drama and mystery of that bug as a kid, as it was talked about in the various magazines. Very interesting stuff. I believe the bug has been fixed in all JiffyDOS ROMs, so that's another way to protect your files.
@@8_Bit Yes, it *has* been fixed in JiffyDOS, but old habits die hard. I didn't get JiffyDOS until several years after the end of the 8-bit era, and by then I had gotten into the habit of never using save-with-replace, and adding a "0" to all drive commands (e.g. I0, N0, etc) to prevent that bug. Still do, even though it's no longer necessary. 8^)
Great video, cool to see some of the things that can scare you into thinking your C64 is borked.
I remember the first time I encountered the autofire bug, I turned the C64 on and didn't know the autofire on the joystick in port 2 was on, and of course when I typed LOAD got the LQAD as your video shows. I definitely thought my C64 has a problem for a bit until I unplugged the joystick and suddenly everything miraculously worked again, then plugged it in again and again it didn't work.
It was at this point I examined the joystick and found the autofire was on, and switching it off solved the problem. I also then did what Robin did in the video and plugged the joystick into port 1 and fiddled a bit to find out what it would do.
Thanks also for the explanation about why most later games used port 2 as the default joystick port. Always wondered about that (long forgot about the joystick autofire issues until this video reminded me). Guess it made sense, although some games must have found ways around this issue, such as Rampage which has simultaneous 3 player, using both joystick ports and keyboard at the same time, never found any issues when playing that game in 3 player mode.
Yes, it seems with careful programming (and perhaps with careful key selection on the keyboard?) most or all of the keyboard problems can be avoided. That's something I've meant to look into in more detail sometime.
Great tip on that initialize. Going to try that on my 1541-II which recently stopped working and where cleaning it with isopropanol didnt do much. Cleaning my 1541C with it did work however. But now that I think about it, both drives failed on me about the same time which could mean that some disk I tried parked it in track 42 as you said, but that the 1541C was able to get out of that at one point.
I always used to use a fork to short pins 1&3 on the user port. Becoming complacent, I carelessly ended up shorting the C64. Lucky for me, only blew the fuse.
how is that easier than flipping the power quickly? power is right there on the side. I'm not getting it.
I should have explained, resetting the C64 preserves RAM, and allows you to PEEK and POKE around from BASIC or with a machine language monitor. One major use of this is to POKE cheats into memory to give infinite lives etc. and then SYS to restart the game. Using the power switch will (usually) corrupt or clear RAM.
My old C64 has had an added external Fuse holder on the side and two buttons for Serial and Main reset for years
@@GigsVT I remember resetting a C64 with pins 1 &3 , and i did it at school with Scissors well one time i did it wrong and blew the fuse. The computer room teacher said I was not to do that again. My own machine I put a reset switch on it, but some programs would not allow a reset.
Hey, friend!
Thanks for making these videos! I have fond memories of the Commodore 64 and, later, the Amiga. Good to see I’m not alone. ;)
You with your new c64 and 1541, I think you looked like young Sheldon
absolutely loved your video. one of your most dedicated subscribers now. your deep dives remind me of the stuff that ModernVintageGamer does in his copy protection series, but you show stuff in even more detail!
Oh, I remember those "long to forget" memory chips. When we had to sell my C64 (sadly ... since a PC was needed in the school but my family did not have enough money to keep the C64 as well), a potential buyer of my C64 had been scared off because of this ...
Thanks for opening the drive and showing what's happening inside! Nice and useful video!
I always found it quite hilarious that the controller inside the diskdrive is basically a full C64 without the keyboard 😂
And it doesn't have the BASIC, Kernal or character ROM... so it is not a Commodore 64 at all...
Thiesen yeah yeah. The 1541 has its own ROM
Almost
this cries for an overall hack of the 1541 drive to make it a computer on its own or at least supercharge it as a floppy drive
@@alerey4363 This has been done. The 1541 has been used for calculations by some C64 software, early parallel processing :)
The game Knights of Legend would randomly lock up on me during play, which made it so hard to get anywhere in it. One day I took my C64 to a friend's house and the game worked fine! It turned out that having my MPS-803 printer connected would randomly crash the game.
Ouch. And that was a game that was hard to get anywhere in to begin with...
@@jpcompton Yes, those darn Cliff Trolls! lol
I took my vic 20 and c64 out of storage last summer after being tucked away for 2 decades. I connected everything up and everything seemed to be working fine then every now and then every other key wouldn't work... for both computers! I found out it only happened when I tried to play a game. Eventually I discovered it was because I was using a Sega Genesis controller.
I thought i was going insane until I did a quick search on ebay. I remembered my old gray disk drive when I was a kid had one of those swing locks, not that latch type you have there. Thought I was remembering wrong till I saw they really did exist lol.
As for the multiple drives issue with Ultima VI, I remember a similar problem with some of the early Amiga (A1000) games where, if it was unexpanded (512k, with the OS loaded into part of that), if you had an extra floppy drive games would sometimes not work right because that extra drive uses a small(-ish) amount of memory to do its work and that meant the game didn't have enough.
Speaking of memory expansion on that old A1000, just to give an example of how far we've come in terms of RAM prices, my mom bought the 256k memory expansion module for my A1000 as a Christmas present and it cost her about $300. For 256 _K!_ That's a quarter of *ONE* megabyte of RAM, folks. I just bought a 128 GIGABYTE SD Card for my wife's phone and it cost about $20. That's about 500,000 times as much memory for 1/15th the price. At this rate, 1 terabyte memory cards will be in Cracker Jacks boxes within the next 5 years...
You can't compare ram prices with flash memory.
The multiple drive issue with some C64 games and many C64 demos is caused by disk fast loaders integrated in those games and demos. They use the IEC bus in a way that only works if there are exactly 2 devices on the bus (the computer and one single drive). Hence those also do not work when a printer is connected and turned on.
@@Okurka. Different technologies, true, but they are indicative of how much prices have dropped. Even if you look at how much flash memory has dropped in the last 10 years, it's night and day. But if we stick with actual computer RAM it's the same: A 32GB DDR4 RAM module is about $100 now. I paid WAY more for a couple megabytes worth of RAM modules for my ancient Win95 machine.
It still happens every now and than that my 1541 gets stuck that way. Thanks to your video now i know how that happens :-) Now i don't have to open it anymore to move the head physically. Thanks for that!
Good memories. That autofire thing got me all the time back in the day.
The lack of compatibility with other drives is because the fast loader in use in that game, mixed with its copy protection, will be sending bus signals that the second drive may misinterpret as being something it should respond to, and will respond. Fast loaders are basically viruses in that we would usually transfer a bit of software, a few hundred bytes or so to the drive and get it to run it. If you think about it, it was basically malware, except that it does a nice thing instead of a bad thing.
The copy protection markers on extended tracks was exactly what caused this bug for me back in the day as well. Someone got me to format a disk I think to reset the head.
Do you have one of those old head alignment testing disks?
That whole "Side One is Side Two" thing was mind blowing. The number of times I physically looked at the top side of the physical disk, thinking I was looking at side one... All those years, I was wrong.
At the end when he says "Thanks for watching..." i'm expecting him to follow it up with "Keep your joyStick on the Ice."
Please do this just once, it would be a super funny nod to AvE.
Oh man! i remember bricking my 1541 as a kid. My dad somehow found a friend that was into computers and knew the command to re-initialize the drive. I was not able to play anything for days!
Holy crap! This makes me wonder if my drive that died in 1992ish wasn't actually dead!
Thank you so much for this great video. I grew up with a C64 but just started using it again after a longer hiatus and totally forgot the floppy drive initialize trick you show at 10:50 in the video. I thought I had broken it since even power cycling didn't help and it would not show the directory of any floppy. Initializing it fixed it again.
Some EA games used to give me trouble loading on my 128 in 64 mode on my 1571. If I pulled on the disk at exactly the right moment on gamestart it would load. I wonder if it was something to do with the track slots. I heard it was a quirk of copy protection.
The same grinding noise was heard when it happened. It did not put the drive in an inoperable state for other disks.
I'll try to remember the name of one of the EA games it happened on and try to get one.
Wow, I went through at least two 1571s with my 128 because of that stupid drive thing. It drove me crazy! Although, it wasn't Karateka that triggered it. I'm sure it was other copied games, though. I wish my time machine was working. I want to go back and give myself that initialize command and spare younger me WEEKS of frustration and money!
I just had this happening to my new old used 1541 I picked up. It was Strike Fleet from EA. Your initialize tip helped me. Thanks!
Maybe the original Karateka disk has something saved on the tracks that would not be copied if you try to clone the disk as a copy protection. The borking may be an accidental side-effect when the game checks if there's data in the copy protection area or not.
We Apple II users had a bonus with our copy of Karateka. On the unmarked flip side of the disk was a second copy of the game that would boot with the graphics flipped upside down!
That's an extremely cool easter egg, or whatever we should call that :) Some online sources say the C64 version had this upside down version too, but I've never seen it; my original copy has the Atari 8-bit version on the flip side!
@@8_Bit [citation needed]
@@8_Bit Interesting. I wonder if all versions of Karateka were mastered as 2-sided, with different things on the flip? Especially wonder if the Atari version has the label on the back and the Commodore version on an unlabeled front?
Must be the Australian copy!
A recent scare has been old disks that just have so much oxidation buildup that they coat the read sensor. Then no further disks work. Saw this on another channel...rather than open up the drive, if you don't have a cleaning diskette you can cut up a 3.5 cleaning diskette and take that white material and tape it over a 5.25 diskette's opening and dab it with alcohol, then send commands and presto cleaned.
Oh my gosh- Bonus brand discs really being me back! I was an apple II guy though. :)
3:01 Commodore could have filtered out the joystick interference by setting Port A to $FF and reading both Ports A and B. If either of the reads isn't $FF, then a joystick is shorting out a line. (I think you can read an output line to detect shorts, or else you can switch it to input with Port DDRA.) Do this both before and after scanning the keyboard, and if a joystick press is detected at either point, then throw out the keyboard scan. This method can only fail if a joystick switch is pressed and then released during the microseconds after the scanning starts and before it finishes. On the down side, if a joystick switch is stuck on, then the keyboard will seem "dead".
3:58 That's what I did with my VIC-20. I had a paperclip and laminated it with packing tape to hold its shape. Fortunately, the C128 had a built-in Reset button.
6:52 Interesting… if you need a particularly long loader, you can continue past the BASIC vectors you need to intercept, into the Cassette Buffer, and then onto screen RAM.
8:14 I guess it uses a fast loader that abuses the serial bus in such a way that any other drives on the bus will get confused and interfere with it, such as by using the ATN line to transfer data.
9:19 Just use your pirated copy of Fast Hack'em!
12:34 The reason they limited themselves to 35 tracks is that some of the earlier mechanisms that were supposed to support 40 tracks didn't work properly. Later mechanisms had no problem with 40 tracks, but the die was cast.
15:12 It does seem odd that it doesn't auto-fix the problem since normally when it runs into a read error, which it would when trying to read non-existent track 42, it does the head-banging thing to make sure it reached track 1. Maybe it senses no signal at all on the disk and assumes that the disk is completely empty and doesn't bother banging its head?
Aha csbruce!! I've been curious :) I remember you from the C=Hacking days, thanks for your contributions!
@@8_Bit: I figured you'd recognize my name if I "delurked", considering that you published in C= Hacking.
Fun part was if you mixed up the sides when doing the paper clip reset, you burned the fuse lol. A proper scare.
That's how I read the keyboard and joysticks, and the same method is used by GEOS, or else a GUI with a mouse or joystick would have been a lot harder to implement (might work with a user port interface, but that would have raised the cost of entry). Even port #2 had some interference with the KERNAL keyboard routine, albeit not nearly as much as port #1.
As for the track 42 problem, my Blue Chip drive actually used its track 1 sensor, so it never, ever banged its head against the stop, but it still got stuck on track 42, which is undoubtedly due to its ROM's, ahem, 1541 roots.
4:08: "So here, I just press my reset button, and the computer does not reset, just the game resets."
Also, a wild floppy appears.
That track 42 business is pretty neat. When I tried to copy the Abacus Basic-64 compiler nothing could touch it including Fast HackEm. It wasn't until finally, many years later using Star Commander (building d64 files) that I find out that data on that disk went all the way out to track 40. I guess I just wasn't persistent enough in 1986. I actually bought a backup copy from Abacus at the time.
About "CBM80": aren't there a bunch of games, that were released on multiple formats, including cartridge? Just thinking, that the same code was used on both cartridge and non-cartridge releases, which could explain the magic number being present.
Incidentally, the VIC-20 used a similar scheme, but since cartridges started at a different address the "80" was replaced by the address of the cartridge.
Some games on the Amiga didn't like multiple floppy drives.
I think I heard that was because each floppy drive in use needed to use some Amiga RAM for buffers, and on some games it was too tight? That probably doesn't explain all cases though.
@@8_Bit A guy that I knew (that did ahem game modification) said it was a mix of the extra memory used and that some games specified memory area so the drives couldn't be used (he said it was a form of memory protection)
9:15 Omg! That happened to me! I vividly recall that 4 beat sound the file not found error returned. I had 100s of disks filled with content from the golden bbs days. I think I was going through some games and all of a sudden the drive wouldn't read anything anymore. I think that's why I boxed it up and archived the system.
Nothing has made me want to power on my c64 more than watching the fix for that issue. Thank you for a great explanation! Cheers
Side note: I had an apparently copy protected version of Karateka. There was an invisible forcefield/barrier that prevented the player from entering the final boss's door. It was only on my downloaded version, not the official version.
Hi, Robin! You have a Russian chip in your 1541! At 11:39 and 12:00, that brown EL7406 (position UD1) was made in the USSR! Or at least with Soviet technology, on Soviet made production line. The brown resin, and the font of the stamping makes it obvious. Maybe the Chinese bought chip fab lines from the Soviets? I have a board from a Datasette with the same brown EL74xx chip on it, i'm keeping that only for this reason.
Here are some photos of Soviet TTL chips for comparison: retroelektro.uw.hu/muszer/omszov_oe92_ttl_checker/omszov_oe92_ttl_check_009.JPG
i.ebayimg.com/images/g/kRQAAOSwTKtc1IZX/s-l1600.jpg
Hey! I found a Twitter thread exactly on this topic! It's proven! Soviet made! Even the lead spacing is 2.5mm instead of 2.54mm
twitter.com/tubetimeus/status/1031328650556141568
Here are some decapped EL74xx s, one of them has cyrillic marks on the die:
radiopicture.listbb.ru/viewtopic.php?f=3&t=50&start=280&st=0&sk=t&sd=a
Cool, huh? :)
I remember DI-Sector program was our goto for all needs even sector reading and sector editing. I copied Karateka using Di-Sector and never had this issue, though this issue also occurs if you interrupt the format process. Open 15,8,15 "I" was a life saver, I actually had friends parents pay me to fix this problem usually 5 or 10 bux as I was a complete jerk lol.
Great video! Oh btw, I used the 1541's that had the lever disk door, and we did use more than one with all our Ultima games including 6. Maybe we were just lucky but we had a slew of these old drives back then as even repair shops would throw them out when it had this simple issue.
about the undetected pressed shift-lock key it could be a nice solution to implement a green led indicator on the case
Since the SHIFT-LOCK key is wired directly to the Left SHIFT key, the light would also come on every time you press Left SHIFT, like I did eight times when writing this sentence.
@@csbruce isnt there a way to cut the trace from the 2 keys so the mechanical lock is on its own circuit thus the chance to include a led only in this branch?
@@alerey4363: You can't put it on a separate circuit or the Kernal's keyscanning routine won't read the key. Maybe you could do something with diodes to make it so the light only activates on the Lock key but not the regular Shift key it's tied to.
@@csbruce are you saying that the shift-lock key generates another keycode different than the other 2 shift keys??
@@alerey4363: No, it's wired to the Left Shift key and generates the same scan code. If you disconnect it from the Left Shift key, the Kernal won't be able to scan it. Or maybe adding a light is way simpler than I'm guessing. The two keys effectively will be wired in parallel, so if you stuck an LED inline the path that goes across the Lock key, that might work. That part of the circuit would only close when the Lock key is down. There might be other electrical issues to deal with.
Show us the copy protection, I would love to see you reverse :)
i think Jason Scott has a talk on the copy protection. maybe check out "Jason Scott Rescuing The Prince of Persia from the sands of time
" or "DEF CON 18 - Jason Scott - You're Stealing It Wrong! 30 Years of Inter-Pirate Battles
" ...maybe try the second one first
For hacking games, we used to shim the top of the 1541 a little bit, and tape a piece of index card to the head, then use a pencil to mark off important tracks on the card.
You could watch for the mark and then yank on the card to cause an error while copying a game. It wasn't very scientific but with the right software and just the right touch you could reliably copy games or even force your way past some errors and protection schemes.
That's some cruel copy protection.
We got a C64 in 1983 and a 1541 shortly after that. I was only 9 yrs old. Dad took me to Toys R Us in San Antonio to buy a couple of games. Games ran on Joystick Port 2 but coming from Atari the games ran on Port 1. I couldn't play this one game for a few weeks due to this issue. After many attempts to get it working again I remember looking at both ports on side of C64. My 9 year old brain finally clicked and I tried the other port and sure enough it worked. Also learned a lesson about reading the instructions. :o)
Cool. I was actually just about to type up a comment asking if you could explain the joystick port behavior in regards to keyboard input when you said in the video you might do a video on it in the future. I'd be interested in that. I always knew joystick port 1 was really goofy (and avoided using it as much as possible) but I had no idea even joystick port 2 could cause unexpected keyboard behavior.
I didn't previously realize that Port 2 could cause problems either, but it does make sense. A keypress is detected by putting a '0' bit into keyboard-row-select register $DC00 and then checking for '0' bits in keyboard-column-read register $DC01. If a joystick switch is closed in Port 2, then this will force a '0' bit into the row-select register, which will hardware-select the corresponding row of the keyboard matrix, in addition to whatever row the keyboard-scanning routine has currently selected. This is why it causes pressed keys to be misread but doesn't cause spontaneous keypresses when no key is being held down like joystick Port 1 will.
Thank you so much , you saved alot of time , i use my commodore more often and stuff like this happens , i spent hours and couldn't find the problem. You sir helped me saving time
I remember with my 1541 sometime if there was some problem with copy protection the head would come too far forward (close to the center) of the disk and get stuck....and then no longer read any disks. Until you put the Head Vibration Protector cardboard insert if fits in but stops hanging out a little bit, push it all the way in and it would push the head back to the right place and it would read disks again...somehow I just figured out how to do it when it happened...It is like the extra little square tab sticking in was long enough to push the head back into place...must be like what that initialize command does...You should make another video showing that you can fix the karateka drive killer with that HVP insert that came with the drive originally. I remember when this first happened and I about holy crap I just broke this $200 disk drive too just like how Robin said!!!
My 1541 II got stuck once, and it took me days to find the solution... Initialize didn't work in that case, and I didn't have the original disk insert.
My deepest thanks go to the kind soul that had the proper measurements for the "tracker card" as he called it.
I quickly made one from tthe cardboard box of a package of frozen pizza (perfect thickness), and i've kept it in my box of floppies since. ;)
And, yes, that tab is meant to push the drive head back to Track 1 if you want to transport, store or move the drive - it really does double as a hard reset tool if the drive gets stuck and the initialize doesn't work... :)
I agree that Robin should show the trick with the insert - and how to cut out your own if you don't have an original. Bonus for making one for the 1571 as well, since the 1541 insert doesn't work for that one...
I'd love to show people how to cut their own, but I can't seem to find the proper measurements anymore :(
The talking hands is pretty precise and has a nice voice.
I'd like to send out a fond wave out to my old 1541-II drives, wherever you may be... Things of beauty that should have been conceived so much earlier in Commodore history.
The problem with games malfunctioning with multiple drives attached is a consequence of their fast-loaders. The Vic20/C64 IEC connector has one transmit-only "attention" wire as well as two bidirectional wires that are normally used for clock and data. If a program outputs a pulse on the attention wire and then outputs a sequences of pulses on the clock and data wires to indicate that it isn't trying to communicate with to some particular device, that device will ignore everything on the bus until the next atttention pulse. Some fast loaders, however, use "attention" as a clock wire and use both of the other two wires for data. Normal IEC communication would have the drive output both clock and data, but having the C64 supply the clock and having the drive send data in response makes communication resilient against VIC-II cycle stealing. Using the attention wire for clocking means that the drive can send two data bits for each clock pulse. The problem with doing this is that if there are multiple devices on the bus, any device that isn't explicitly prevented from doing so will be likely to interpret some of the clock/data wiggles as attempts to address it.
Before I had the Action Replay I used some kind of three-way-reset (manually, I sticked some cables into the expansion port):
• Normal reset (/RESET to GND)
• Short reset (/RESET to GND via a capacitor, only a short impulse ignored by any device on the IEC bus. You can read the error from the 1541.)
• (/EXROM to GND, /RESET to GND, release /EXROM to GND shortly after /RESET to GND was released. KERNEL reads $8000 and just receives garbage and cannot find the CBM80 magic text. /EXROM must be released soon as the memory test routine in KERNEL would overwrite the RESET vector at $8000.
That joystick thing brought back some memories... trying to type while your brother or friend messes with joystick
I think the first game I tried to copy, which didn't work, was Beach Head II. The copy came up with a warning notice that it was a copy and wouldn't work. We had a dubious copy of Fast Hack 'Em, but it was only with a future update and the parameters disk that the copying worked.
I can imagine the panic as a kid when your new shiny breaks...
They were some very helpful tips thank you.
Yeah, the autofire-"bug" has bothered me often back in that time.
Using a metal screwdriver on an opened and powered disc drive is a very bad idea...
Kareteka was notorious for being one of the first c64 & Atari-8 games with very effective copy protection schemes . it was one of the copy protections that directed the drive to look at a damaged or unreadable track and if the value didmt match the encoded hash the game wouldnt work or would only work for a few levels and then abort.
i know it took years for A8 kareteka to be cracked, and even the smart copying systems like Happy Drive didnt do it. Supposedly the trak ( brand) z80 based atari drive would make copies because it could replicate the physically damaged areas of the floppy disk.
I have to clean the read/write heads so much no days, I don't even keep the lip on the 1541.
Love your videos ... also, I wonder how many 1541s were thrown out because of things like this.
I think the joystick in port 1 is just acting like part of the keyboard. You can press up on the stick to get a 2 (at least I think it's up), or press 2 and send the character up... same thing to the computer. Basically just watching for those characters is the "joystick driver software" for port 1 (not for all types of controllers there, though). Right? As for how 2 works, I guess that's a little more complicated.
Actually joysticks do... in both ports :)
Port 1:
Up = 1
Down = Left arrow character
Left = CTRL
Right = 2
Fire = Spacebar
Port 2:
Up = Commodore key + F3
Down = Commodore key + S
Left = Commodore key + F
Right = Commodore key + H
Fire = Commodore key + K
Those presses will fill memory locations 56321 (port 1) and 56320 (Port 2) respectively with identical values for the corresponding joystick input.
Robin has demonstrated how to read joysticks from those addresses in another video :)
As I recall, the 1541 disk drive can access 84 tracks labelled track 0.5 to track 42. Due to the width of the read/write head, it cannot effectively access adjacent tracks without the possibly of the magnetic fields bleeding into one another hence the half-tracks in the numbering scheme. However, some copy protection schemes took advantage of this. Most commercial disks only go up to track 40. But the very first production line of 1541's had issues accessing beyond track 35, hence the kernel on the C64 and 1541 doesn't _write_ beyond track 35 by default (but it does read). But the C64 and 1541 are both fully programmable, so commercial disks would usually store data up to track 40. As the speed of the disk spin was programmable, the head position was programmable, and the encoding of the magnetic flux to binary encoding was even programable, you had a lot of creative copy protection. The only thing not programable was the sync mark, I believe.
Also, the 1541 does not have a way to detect which track it is on, so when it starts up, the head psychically seeks below track 1 causing it to hit the end and make that "gunshot noise" to sync itself up with track 1 before proceeding. And for some reason, when there's a file-not-found error, the head seeks to track 0, I believe, causing a prolong "gunshot noise". I don't know why. And if you position the head to track 42, which is a track number the drive recognizes, it tends to get stuck. Again I'm not sure why. But I had it happen to me when I was 8 years old with my shiny new drive and I disassemble it and physically moved the head to fix it.
Regarding Ultima, Commodore ran into early issues programming the IEC bus communication on early version of the kernel (I forget why, but I think they were crunched for time) so they settled on a blocking, bit-for-bit serial asynchronous communication with full handshaking where only one device could communicate at a time, which worked but was dirt slow. It's why you see a lot of fast loaders out there. To work, all devices on the IEC need to honor the protocol. You can actually do parallel data data transmission and synchronous data transmission (the CPU speeds between the C64 and 1541 vary by a slight bit, something like 64:63 cycle ratio or something). Several of the pins are fully programmable. You can speed up loading in a way that doesn't break the IEC protocol or you make it even faster by breaking the protocol. This is probably where the lock up is occurring. If you have any devices on the bus that aren't using your custom protocol, it will likely break the communications. I've seen a fast loader that told me to switch off my printer before loading a game and it was blazing fast. I bet, I bet that's it. It's some customer loader, used for fast loading or copy protection or so the game or music can play while loading or all of the above, that bends the protocol thus doesn't play nice when there's more than the expected number of devices on the bus. That extra drive 9 is not being reprogrammed and thus is speaking out of turn and messing up communication between the C64 and drive 8.
Anyway, this is all from memory, so I'm not 100% sure of the specific details, so feel free to correct me. I do miss growing up with my C64, though. :)
«As the speed of the disk spin was programmable» I don't think that's true. The only control is on-off in bit 2 of $1C00.
«the encoding of the magnetic flux to binary encoding was even programable» I assume you're referring to the bit density-timing, for which the 1541 offered four operating speeds in bits 5 and 6 of $1C00. That could be used to make your custom disks unreadable at non-standard speeds.
«The only thing not programable was the sync mark, I believe» The Sync mark was written by the disk drive itself since the Index Hole on the disk was unused, so the Sync mark and the entire framing of the data blocks was fully programmable. I assume this is why copiers went to full "Nybbling", because publishers were using custom disk formats.
«Commodore ran into early issues programming the IEC bus … so they settled on a blocking, bit-for-bit serial asynchronous communication with full handshaking» They were originally planning for the VIC-20 to use a hardware shift register like the C128 does, but the shift register in the VIA chip had a hardware glitch and couldn't read data reliably. (Apparently, there's a simple hardware fix for this, but they didn't know it at the time.) But, the slow software bit-banging wasn't much of a problem for a computer with stock 5K of RAM. Ironically, the hardware shift register in the C64's CIA chip worked just fine, and so it could have had the fast serial bus to go with its 64K of RAM, but backward compatibility would have been too complicated for the time frame.
«where only one device could communicate at a time» Any hardware bus with shared data lines can only have one "speaker" at a time, such as with USB 2.0. The IEC bus did allow for multiple simultaneous "listeners", though that would have limited utility. I think someone programmed a 1541 to spool directly to a printer without any intervention from the C64.
«You can speed up loading in a way that doesn't break the IEC protocol» JiffyDOS managed to achieve high speeds while still playing nicely.
That's right! The control was on the clock speed so it was the data density that changed!
Thanks for all the comments! I forgot how much I loved this stuff.
I found a web page that has a lot of information about this stuff in regards to how it was used in copy protection-- I need to read it later when I have time. Here's the link to share: c64preservation.com/dp.php?pg=protection
I wrote: «Ironically, the hardware shift register in the C64's CIA chip worked just fine» Correction: While the shift register in the C64 was fine, the 1541 still used the VIA chip which still had the bug. It wasn't until the 1571 included the CIA chip that the problem was fixed on both sides.
The drive head didn't actually get "stuck" on track 42. That little shuttle it did back and forth was half stepping as it tried to read sector markers. The commodore drives were soft sectored and relied on blips on the disk to mark the beginning of the sectors rather than an LED shining through the index hole. (hard sectored) Although the index actually marks the beginning of a track.
It seems the software engineers assume the head is always in the used area of the disk and just read for the track marker or sector markers. If they don't get anything, they half step the head one way and then the other in case it was just stopped a half step off the track.
I bet a format command would put things right again since it does a home on the head.
Happened to me as well (stuck disk head). I have been opening the drive and moving the mechanism manually to unstuck it, until I discovered that INIT command restores it too.
One thing i always remember was when giving the advice, "Turn you computer off for 5 seconds" i always wondered why RAM which was powered by electricity managed any state. I could see an eprom doing that but not static RAM
The C64 uses dynamic RAM ICs, which use a tiny capacitor to store the value of a memory location. It does not use static rams for the main memory. That was one of the cost savings in the C64, the VIC-II chip had DRAM refresh circuitry so Commodore could use the cheaper DRAM (instead of the far more expensive static RAM).
As far as I know, thus is not a physical lock on the drive. It is more like a "bug" of the ROM. Let me elaborate. When you try to read the directory, the ROM will spin up the drive and read the current track (without moving). If it could read it, it would have figured out which track it was and move accordingly. Piece of cake. However, when unable to read the track, it will first assume that it is half track before or after a real track and try both options. Thus the slight back and forward motion you see. Under normal circumstances, either of these would have yielded a valid track and we go back to the first case. But here we're in track 42, which was never initialized, thus it will never be able to read and will just give up. This also happens when the heads are dirty and you try to read the directory, but only for the directory as far as I can tell. because when reading files it does try to recalibrate by going to track 0. Just my two cents.
Yes, I believe this is correct now; a few people have explained it to me since I made this video. Next time I make a video about the 1541 I'll try to explain this correctly. Thanks.
Speaking of 1541 drive programs - there's a routine out there that makes your 1541 play music... maybe you covered this in another video.
if I remember correctly there are multiple copy protections on Kareteka
Never thought of the serial standard on the C64 as a precursor to USB - but yeah, i could see that. Not quite as close to USB as HexBus from what I've gathered, but still neat to realize. (Incidentally if you ever get some HexBus stuff for your TI, by all means do a video :) )
I'm curious if a re-format of your copied disk would have worked as well? Perhaps this is what they were pushing toward?
the 1541C (the white variant of the original 1541) is the only drive that would seek back to track 18 when powered on.
On the other models, the head doesn't really get phisically stuck on tracks > 35, the problem is just firmware. The disk firmware first tries to detect on what track the head is currently positioned to. If it has been moved on an unformatted track (> 35) then it can't read any sync/format informations and the firmware just tries moving half a track forward then backwards just to compensate for any alignment issue. If it can't still identify a valid format, it gives an error. You can obtain the same behaviour inserting an unformatted disk when the head is on a valid track.
The only way to have disk firmware seek back to track 1 is using the "INITIALIZE" or "I" command.
On a normal directory load the drive just checks the current position and the neighboring tracks without calling the recalibration as on format or initialize. With a dolphindos formatted disk (if it can read the sector header without dolphindos) or if being on track 35 max it will read the sector header and know where to find track 18. BTW: when formatting you can shorten the head bang by seeking to track 35 before doing it. Not an issue on 1541- II as there have a light sensor for track zero.
Karateka had two versions of copy protection Xemag on some and signature check after the title on others. Xemag used fat tracks.
Did you do a vide about what Super Snapshot is??
wow, jack attack...My son and I played HOURS of that game! the good old days...I still have a bunch of extra chips and games but no working computers....
In regards to Karateka, I am surprised the company wasn't sued. I don't know if this was INTENTIONAL or a flaw in their copy protection.. As far as copy protection on the C-64, early versions are the ones that caused most damage to drive. I call those "stepper motor" versions, for instance Sector error 21 caused the head to "bang" (what you referred to as the machine gun sound). Over time these protections caused the head to go out of alignment and really mess up your 1541 drive, where you could eventually no longer read disks properly or at all. Later copy protection did not bang the head (i.e. error #29) etc, but these copy protections (#21, #23, #27, #29( were easy and could easily be copied. Then came more sophisticated protection like half tracks, tracks beyond 35, as 35 is the normal upper limit, but modified routines written to drive could allow them to go beyond, for example the protection could be stored on track 40 or in a half track. Then more sophisticated protections like GCR, etc.
So for Karateka, my theory is that it used one of the non conventional protections, meaning it would move the head to a non standard / non conventional area inside the drive (half track, past track 35, etc, and just LEVAE it there. So this explains why you could not access your disks anymore even after powering it off......This in my opinion could have very well been a flaw in the 1541 design, not automatically resetting the head's position
So your INITIALIZE command does just that, it will RESET the head back into a normal position, unfortunately, the banging on the steppe rmotor is NOT a good thin for the 1541, eventually this caused 1541 drives to out of alignment, and the only way to fix it would be to open it up and re-align the heads, but you'd need special calibration software to do it, not something most people have access to, but a fairly easy fix.
Good thing that eventually copy protection was non destructive, no banging of the head.
But eventually you had sophisticated disk copy tools that were compatible with half track, though the multi protection and GCR ones were really tough (i.e. GEOS64) but all of these could be cracked by just bypassing check and jumping to start of game....... As far as games with multiple checks later on, another way could be to just emulate and fool the loader into thinking that the value it is comparing does match, so it can apply to any other checks. End result, no protection is uncrackable.
BUT.......what if you were to store some the checks inside non standard tracks, now that would be tricky.
So as to Karateka, well let's assume it was poor coding, it moved the head to a non conventional position and left it there instead of resetting its position back, as most other games do. Also Karateka has multiple protection routines, so even if you were to successfully copy the game with the right copier, you would have had weird game behaviour.
Even when formatting a 1541 disk you would hear that initial stepper motor banging, good thing they eventually made formatters that did not exhibit this behaviour (flaw).
I'm happy you figured it out using the "I" command . If this was done now company would face hefty lawsuits :D A few modifications to the ROM would have prevented the stepper motor bangs and automatically initialized the head's position upon powering on.
Very interesting video, thanks for the detailed information!
I have that very autofire joystick. I seem to recall having had some problem with it as well.
I had the track 42 error happen on my 1541 2 several times over the years. I found inserting the protective sleeve that ships with drive would also fix the problem. However, I have no idea if it did any physical damage as my drive never needed repairing in the 10 years I had my C64 and worked flawlessly other than the track error.
I have an old c64 well preserved in a plastic box with its cables and everything including 2 1541's. A month ago I decided to connect and play some time with it but.... It was runing abnormally, some characters on screen, did not boot a couple of times, etc.. looks to me it just died while being stored!
that is a common failure, some oxide deposit over IC sockets ... just pull up chips and reinserted it, that removes oxide so electric contact getting ok again...
I had that joystick as a kid. Don't have it anymore.
Isopropyhol lol. I have a boxed 1541 drive that has been in storage for over 20 years. One day I'm going to set it back up, I just need another c64 as I do not have one. I also have a Oceanic drive which is also boxed and been in storage for at least the same amount of time, I do not have any idea if they work still. I am guessing they should as my dad would not have kept them I guess.
Interesting, as I recently just backed up most of my old disks and the only disk I had major failing to copy was the one I had with Kareteka. However, nearly all my games are already pirated copies. Another however is that the source copy runs fine on my C64.
Green Beret (and possible more Imagine releases) tape version dont work if a drive is present.
Imagine the makers of Karateka deliberately messed up your 1541 for copying the game - that's cruel.
Also the fact you were able to fix it yourself at age 12 is amazing. I would of cried to my mom to buy me a new one 😂🤣
Also I remember I had a Vic-1541 disk drive for my Commodore 64. I bought it used as a new one was so expensive. I remember some games wouldn't load up on the Vic1541 - the disk drive would make funky noises and then just stop and the small light would flash repeatedly. I wonder if it was due to functionality issues with such an old 1541 drive operating on a C64?
Wow, I remember that joystick interference! It was frustrating!
I couldn't even get Ultima VI to load on my C64c and 1541-II. So I took it to the store I bought it from and it worked there so I went back home and then it would load. I have no idea why.
Then I came across with "broken drive" in my childhood, I used LOAD":*",8,1 to fix it.
The file not found error with the same sound happened to me as an 8-9 year old - but it was with a 3rd party disk drive with a turbo loading feature (the LED light was square and it would turn from green to red) I thought it was completely screwed. I wish I knew the initalise code back then as I don't think I ever recovered from it...
I wish I had my old 64C... I need to find one...
Have you ever heard of disk copy protection that will format or otherwise blank the disk if a copy is attempted? My brother once loaned his original disk of Alcon to a friend, and that friend tried to copy it, and when it was returned the disk was blank. My brother concluded it must have been a copy protection scheme. I'm doubtful of that, but none the less I've always been afraid of trying to make a backup copy of my original Alcon just in case it got the same blanking result. Can that happen?