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? :)
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. :\
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.
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.
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.
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. ;)
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
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^)
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.
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.
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?
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.
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 :(
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!
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.
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 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.
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.
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.
You have explained it nicely. I did not know about that track 42 thing. I guess,I have to try that :-) The CBM80 issue can be circumvent with a slightly modified Kernal. github.com/svenpetersen1965/C64-Kernal-2.1
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.
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!
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.
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.
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!
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.
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!
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.
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 ...
At the last bit showing the copy protection of the Karateka i think there was other game companies that had done the same .. knowing that the Basic hacker pirate would not know and will send it too the Computer Repair Shop where all it needed is too re initialize " Drive track reset . but here is something too look at, about the Copy Protection Scheme Karateka has ! its more then you think .. interesting.. the Link : tcrf.net/Karateka_(Commodore_64)
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)
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 :)
Only on the C64 does the joystick mess up the keyboard. 😒 Nearly every C64 user I knew had a copy of Fast Hackem to copy games. I gave a few of those copies out. 😝
For all its strengths there are some truly shocking user experience liabilities and failures on the C64, particularly considering it was a relatively late entrant in the market and everybody should have known better. The port 1 "oh yes it will just completely mess up your keyboard input, hope you don't mind" is just one of the more obvious ones.
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.
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.
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....
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?
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.
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.
Regarding the Ultima copy protection: Yie ar Kung-Fu had something similar. You MUST turn-off the drive after loading the game, or it will crash. This is especially tricky on a C128D with integrated drive, see www.lemon64.com/forum/viewtopic.php?t=9998&sid=b327503a8d3d100c51fd2e6489ba15d3 On a related note: Yie ar Kung-Fu uses 6 digits to display the score (000000). As a kid I always wondered what would happen if you reach 999999. After hours of play on a rainy day in the early '90s I was very disappointed to find out that it just rolls over to 0 when you reach a million :-)
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.
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?
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 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.
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'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.
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.
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 :) )
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)
True (and somewhat pointless) Story. I saved for months for a 1541 drive. Finally the day came when I had enough so off I popped to my local computer shop to buy a 1541 ..they had none in stock but they had a 1541-II for the same price so I bought it thinking as it's 'II' it will be better and maybe faster ...epic mistake. The drive die before 2 weeks was up so I took it back and they replaced it. The 2nd one died some 10-12 days later so again I took it back but they had no more so they sent it off for repairs. ..three weeks I waited and finally I got it back and it died on my the very next day! (I'd only played 10-12 games on it) so.. I took it back again and by this point I was getting angry. it was sent away again and this time it returned within 2 weeks. I took it home and.. it seemed okay and the next day too. a week later I heaved a sigh of relief at finally having a working floppy drive ..and it died 2 days later. Now I was furious and the shop owner was sick of it too and he wanted no more of it so gave me a full refund. I went into town the same day and to the only other computer shop in my town and bought a 'compatible' drive which was cheaper. it was an Oceanic drive with a funky little multicoloured drive led which showed a different colour depending on what the drive was doing. I had that drive for over 5 years (until I sold my C64 to buy an Amiga) and it worked flawlessly! So the lesson of the day is to buy compatible drives rather than the piece of junk 1541-II.
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.
Sometimes i broke the drive with fastloader i just insert a program disk and type the load"*",8 or load"*",8,1 -i not remember exactly- command the drive back to work. Don't ask me how or why i don't know.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I remember hearing that the write protect detection was just a courtesy and it was possible to write to disk even if it was write protected. is this true?
No, it is impossible. The write protect sensor is routed to a gate array, which will not enable the write head in that condition. Software cannot override this.
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?
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.
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.
The very first time I loaded a C64 floppy in 2017 my head got stuck and I had to find the reinitialization procedure. I still don't know why it happened. I was either loading Arkanoid or Maniac Mansion, both originals, and it got stuck on a black screen. When I got tired of waiting I did not know that you were supposed to power off the disk drive first so I blamed that after learning the correct power sequence, but now I'm not so sure. I actually had two identical 1541 drives and it happened to both (black screen, then stuck head). Before learning of the re-init I thought I had a disk that was killing drives left and right! Still not sure why it was happening since both of those disks work now. *shrug*
Thanks! The music is part of an unreleased track by my band Bedford Level Experiment. In case you wanted to check out our released stuff: ua-cam.com/users/bedfordlevelexperiment
I have such a C64, I thought its broken but after MINUTES (litterally 15 or 20 minutes) it worked again. I will never use POPEYE game again, it just came on again, later had a black screen, later worked again
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.
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? :)
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.
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
Complete tangent -- Fred Savage used the same joystick in The Princess Bride..
You see the joystick and the 1541, but never the c64 itself..
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.
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.
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.
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.
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...
"The old computer says, 'Creak'." I really dig this dry humor.
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
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^)
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.
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.
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?
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.
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.
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 :(
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!
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.
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 :)
You with your new c64 and 1541, I think you looked like young Sheldon
Holy crap! This makes me wonder if my drive that died in 1992ish wasn't actually dead!
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 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.
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.
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.
You have explained it nicely. I did not know about that track 42 thing. I guess,I have to try that :-) The CBM80 issue can be circumvent with a slightly modified Kernal. github.com/svenpetersen1965/C64-Kernal-2.1
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.
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!
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.
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
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!
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.
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!
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.
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 ...
At the last bit showing the copy protection of the Karateka i think there was other game companies that had done the same .. knowing that the Basic hacker pirate would not know and will send it too the Computer Repair Shop where all it needed is too re initialize " Drive track reset . but here is something too look at, about the Copy Protection Scheme Karateka has ! its more then you think .. interesting.. the Link : tcrf.net/Karateka_(Commodore_64)
That's some cruel copy protection.
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)
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 :)
Using a metal screwdriver on an opened and powered disc drive is a very bad idea...
I'm curious if a re-format of your copied disk would have worked as well? Perhaps this is what they were pushing toward?
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.
Only on the C64 does the joystick mess up the keyboard. 😒
Nearly every C64 user I knew had a copy of Fast Hackem to copy games. I gave a few of those copies out. 😝
For all its strengths there are some truly shocking user experience liabilities and failures on the C64, particularly considering it was a relatively late entrant in the market and everybody should have known better. The port 1 "oh yes it will just completely mess up your keyboard input, hope you don't mind" is just one of the more obvious ones.
Did you do a vide about what Super Snapshot is??
Thanks for opening the drive and showing what's happening inside! Nice and useful video!
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.
Love your videos ... also, I wonder how many 1541s were thrown out because of things like this.
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.
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....
if I remember correctly there are multiple copy protections on Kareteka
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 had the first one happen to me last night.. on an emulator.
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.
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.
LMAO. Now I know how i "bricked" my 1541 back in the early 90's. But that's good, I still have it and can unbrickit and sell it. Profit! xD
Regarding the Ultima copy protection: Yie ar Kung-Fu had something similar. You MUST turn-off the drive after loading the game, or it will crash. This is especially tricky on a C128D with integrated drive, see www.lemon64.com/forum/viewtopic.php?t=9998&sid=b327503a8d3d100c51fd2e6489ba15d3
On a related note: Yie ar Kung-Fu uses 6 digits to display the score (000000). As a kid I always wondered what would happen if you reach 999999. After hours of play on a rainy day in the early '90s I was very disappointed to find out that it just rolls over to 0 when you reach a million :-)
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.
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?
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 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.
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'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.
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.
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 :) )
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)
True (and somewhat pointless) Story. I saved for months for a 1541 drive. Finally the day came when I had enough so off I popped to my local computer shop to buy a 1541 ..they had none in stock but they had a 1541-II for the same price so I bought it thinking as it's 'II' it will be better and maybe faster ...epic mistake. The drive die before 2 weeks was up so I took it back and they replaced it. The 2nd one died some 10-12 days later so again I took it back but they had no more so they sent it off for repairs. ..three weeks I waited and finally I got it back and it died on my the very next day! (I'd only played 10-12 games on it) so.. I took it back again and by this point I was getting angry. it was sent away again and this time it returned within 2 weeks. I took it home and.. it seemed okay and the next day too. a week later I heaved a sigh of relief at finally having a working floppy drive ..and it died 2 days later. Now I was furious and the shop owner was sick of it too and he wanted no more of it so gave me a full refund. I went into town the same day and to the only other computer shop in my town and bought a 'compatible' drive which was cheaper. it was an Oceanic drive with a funky little multicoloured drive led which showed a different colour depending on what the drive was doing. I had that drive for over 5 years (until I sold my C64 to buy an Amiga) and it worked flawlessly! So the lesson of the day is to buy compatible drives rather than the piece of junk 1541-II.
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.
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!
Sometimes i broke the drive with fastloader i just insert a program disk and type the load"*",8 or load"*",8,1 -i not remember exactly- command the drive back to work. Don't ask me how or why i don't know.
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.
Speaking of 1541 drive programs - there's a routine out there that makes your 1541 play music... maybe you covered this in another video.
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.
Karateka had two versions of copy protection Xemag on some and signature check after the title on others. Xemag used fat tracks.
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.
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.
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.
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.
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.
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.
Then I came across with "broken drive" in my childhood, I used LOAD":*",8,1 to fix it.
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.
I have to clean the read/write heads so much no days, I don't even keep the lip on the 1541.
Green Beret (and possible more Imagine releases) tape version dont work if a drive is present.
Oh my gosh- Bonus brand discs really being me back! I was an apple II guy though. :)
I remember hearing that the write protect detection was just a courtesy and it was possible to write to disk even if it was write protected. is this true?
@Mr T. Guru I was sure I heard it was done via software, by just not checking the status of the write protect sensor before writing.
No, it is impossible. The write protect sensor is routed to a gate array, which will not enable the write head in that condition. Software cannot override this.
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!
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.
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.
They were some very helpful tips thank you.
The very first time I loaded a C64 floppy in 2017 my head got stuck and I had to find the reinitialization procedure. I still don't know why it happened. I was either loading Arkanoid or Maniac Mansion, both originals, and it got stuck on a black screen. When I got tired of waiting I did not know that you were supposed to power off the disk drive first so I blamed that after learning the correct power sequence, but now I'm not so sure.
I actually had two identical 1541 drives and it happened to both (black screen, then stuck head). Before learning of the re-init I thought I had a disk that was killing drives left and right! Still not sure why it was happening since both of those disks work now. *shrug*
Ah yes.. I remember being upset since I thought I broken the Commodore...
Great Video and I remember doing the same back then, thinking my Dad was going to kill me for wrecking the drive! What's the music at the very end?
Thanks! The music is part of an unreleased track by my band Bedford Level Experiment. In case you wanted to check out our released stuff: ua-cam.com/users/bedfordlevelexperiment
I have such a C64, I thought its broken but after MINUTES (litterally 15 or 20 minutes) it worked again. I will never use POPEYE game again, it just came on again, later had a black screen, later worked again
I would love to find one of those C64s to demonstrate! But it would be very annoying if it was the only C64 I had!
Sam's Journey has the same problem as Ultima VI.
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.
Yeah, the autofire-"bug" has bothered me often back in that time.