All the Commodore 64 KERNAL Revisions: Bugs, Fixes, and More!
Вставка
- Опубліковано 30 тра 2024
- We take a look through the differences, bugs, and fixes of the C64 KERNAL operating system ROM through the years, from the original silver label C64 through to the 64C, to the SX-64, Educator 64, the Japanese C64, the C64GS, and more.
To support 8-Bit Show And Tell:
Become a patron: / 8bitshowandtell
One-time donation: paypal.me/8BitShowAndTell
Great list of differences by Marko Mäkelä:
www.zimmers.net/anonftp/pub/cb...
Another list of differences:
commodore64.se/wiki/index.php/...
Lots of firmware to try on your EasyFlash 3:
www.zimmers.net/anonftp/pub/cb...
Credits music by: bedfordlevelexperiment.bandca...
Further info/errata:
Quite a few people have pointed out that the screen clearing behaviour in KERNAL v2 was actually to help hide the "screen sparkle" problem that former Commodore engineer Bil Herd describes in this video around 15:45: • VCFMW 11 - Bil Herd: T...
Rob Clarke says:
Your experiments with the 4064 kernal would not work that way on the real machine. There is no color RAM, so you cannot change the text colour, the board is hard-wired to only return white. Also, the Educator 64 and 4064 are fundamentally different machines. The Educator is a normal 64 with a SID and a monitor that can display different luma levels, ie. "shades of green". The 4064 is a standard PET monitor, so the video signal is either on or off, so true monochrome, no shades at all.
Index:
0:00 Intro - KERNAL revision differences
1:13 KERNAL v1: Silver Label C64
7:25 KERNAL v2: My first C64 & More
12:34 KERNAL v3 (final) on a breadbin
14:57 Commodore SX-64
17:09 64C + EasyFlash 3
17:48 PET 4064 / Educator 64
20:53 Japanese C64
24:02 Turkish, Swedish, Danish KERNALs
26:28 C64 Games System
28:20 Thanks! - Наука та технологія
As promised, here's the pinned errata/clarification - I'll add info here about anything I didn't get right in the video - apologies!
Quite a few people have pointed out that the screen clearing behaviour in KERNAL v2 was actually to help hide the "screen sparkle" problem that former Commodore engineer Bil Herd describes in this video around 15:45: ua-cam.com/video/-Zpv6u5vCJ4/v-deo.html
Rob Clarke says:
Your experiments with the 4064 kernal would not work that way on the real machine. There is no color RAM, so you cannot change the text colour, the board is hard-wired to only return white. Also, the Educator 64 and 4064 are fundamentally different machines. The Educator is a normal 64 with a SID and a monitor that can display different luma levels, ie. "shades of green". The 4064 is a standard PET monitor, so the video signal is either on or off, so true monochrome, no shades at all.
No SID so initials removed?
the sprites on it are so awesome ..i know the turqouse is a combination of all colors ! thats so natural i took all glitches and syntax errors for love, pure love💯🧡
the final cartridge( I & 2 ) would make it different colours, it was the only thing to do ...if a tape load didn't work..people would just make' the reset switch.
right on the back of the machine, i guess they just broke the ⚡chain simple and easy 💯🧡
The Errata doesn't stay pinned. Can you move them to the video description?
@@HutchCA But then too, software written that set the color to a light background and dark text/chars would also end up with crappy visibility.
The original Kernal was set to white to work similar to a PET in that it was just no color. What was found though is that the character ROM was a bit too slow and when graphics and sprites were being drawn the screen would get white snow in the image. This would often cause the sprite collision register to fire a collision detect and made many early games unplayable. At first Commodore had us techs adding a resistor and small capacitor to the video chip to try to stop the snow which only marginally helped. They then started sending us Kernal V2 which changed the default character color to the current background color. This eliminated the snow by making it the same color as the background. I actually figured out it was the character ROM being too slow when I got sick of having to fix the C64's we were selling and I started changing chips. When I found the character ROM had to be 150ns or faster I purchased a bunch of 65866 (I think??) 150NS eproms, these are the ones that fit the pinout of the C64, and burned the character set on them. These fixed all of the 64's that came in..no snow at all and no oddball sprite collision detections. I reported my findings to Commodore in Shamburgh IL and shortly after that the character ROMs were improved and Kernal 3 was released, changing the default character color to the current character color. Those were fun times.
That's not what I've been told. Albert Charpentier was the head of the LSI group at MOS Technology and was one of the two designers of the VIC-II chip. Charpentier was responsible for some of the chips that went into the VIC-20. Robert Yannes worked on Albert's design team.
Albert said that the problem was with the precharging circuit in the particular ROM chip they used. The precharging circuit was supposed to make the ROM run faster, but also made it sensitive to spurious signals. When the 6510 handed off control of the bus to the VIC-II chip, it sometimes randomly generated voltage spikes. This spike just happened to be exactly long enough for the ROM to interpret it as a valid address, causing it to feed the wrong data from a random address to the VIC-II. Since the ROM contained the C64 character set, the screen display would be littered with random slices of characters, aka "sparkle" or "snow".
So, getting rid of the sparkle might have had _nothing_ to do with the speed of the ROM chip. Once they were able to retool one of their production lines, Commodore replaced the ROM with another ROM that _didn't_ have the precharging circuit, and the sparkle went away. Or at least, that's _his_ story. I suppose comparing the speed of one of the later ROM chips with the speed of the original (sparkle-prone) ROMs might give more info. I'm inclined to believe Albert, because of where he worked... but on the other hand, you were one of the people that were _fixing_ the machines that the consumers brought in, so I'm inclined to believe you too. More research is needed. ;^)
@@SpearM3064 Well all I can say is that when I was finally invited to the Shaumburg office I was talking to their engineers about that finding and in the course of the conversation they mentioned that the failures they were having was because of the cheap RAM chips they were buying. The engineers had their jaws on the floor when I told them that it was a deficiency in how they designed the power supply and that it would eventually damage the regulator and cause an 8v ripple on the 5v DC line, killing the RAM. They wanted proof and I soldered a 5.6V Zener on the 5V line and popped the power off and on a dozen times to a 64 they had on the bench, and suddenly that zener light up like an LED before exploding. I can only speak from experience. And I think I still have a few of the ceramic 6567's with the cap and resistor soldered in my parts bins, not that it really solved all that much.
I wish Robin would pin this thread
If I ever run into you at a conference, I'd love a selfie of me and just your UA-cam hand. :D
would make a nice t-shirt too. Just Robin's hand hovering over a c64c :-)
As the Terminator said: "Talk to the hand!"
I wonder if those are paper or diamond hands.... (stonk joke;)
8:15 Collaboration with Adrian's Digital Basement maybe? :)
24:09 The text says "Teleteknik A.Ş", which was the distributor of Commodore 64s (and Amiga's) in Turkey. They published Commodore magazines and scheduled events about Commodore and Amiga also. Went bankrupt in '92.
However the colours are ugly :-))
@@polluks2 Turkish people knew computers from sci-fi movies back in the time, so it might be a retro-terminal style color selection. :)
As a Turkish person, I owned lots of c64s, but this is the first time I am seeing the Teleteknik ROM. It must be kind of rare. Most c64s sold in Turkey were imported from Germany.
As a Turkish citizen who lived the 80s playing with my and many of my friends' C64s, I can tell you that I had never seen a Turkish kernel before. I can recognize the company name shown there "Teleteknik A.Ş.". "A.Ş." is the abbreviation for "incorporated company" (Anonim Şirketi) in Turkish. That company was the sole distributor for 8bit and Amiga Commodore computers in Turkey until the end of 1992. I believe the reason characters seem wrong is that it appears you need the Turkish character ROM too, which you can find on the internet. But this is the first time I'm seeing the Turkish character set ROM being used :-) English alphabet is 26 characters, Turkish is 29. Missing (or unnecessary) is x and w, and additionally, there are "ı, ü, ğ , ş, ö, ç". Also, ı I and i İ are separate characters. But you can substitute English characters for the missing Turkish characters. So it seems to be a real unnecessary feat to have a Turkish character ROM which you would need only for Kernal anyway since for a program you can do whatever you want. However, I really don't remember seeing this kernel neither at a friend's house nor at a fair on a commodore back in the day and ever :-) Probably this was made as a proof of concept or maybe as a show-off?
There are some discussions online, even showing an ad by Teleteknik, a machine with Turkish F keyboard and this ROM. I believe it was tailored for people who wanted to use word processors, or switch from old typewriters since F keyboard is a lot faster for typing. I haven't heard of this either. Robin is great for unearthing this type of stuff.
@@DenizTurkmen Following your comment, I've done some research and found a related Teleteknik 's publication "Commodore Haberler Dergisi" (Commodore News Magazine) issue 5 dated October 1985. Apparently, Erman Elektronik, an authorized Teleteknik Commodore dealer in Istanbul/Erenköy, developed a Turkish word processing system called "Türkçeyazar" (Turkish writer). This system was comprised of a modded C64, modded MPS-802, a Turkish word processing program (Turkish Easyscript), a 1541, and a Sanyo green monochrome monitor. The modded C64 was called C-64T and the modded 802 was called 802T. The modded C64 and MPS-802 had a switch for switching custom kernal and character ROMs with the originals. At that time Teleteknik had a network of 162 authorized dealers and it was advertised that this mod could be applied in any authorized Teleteknik dealer for a cost of then 50.000 Turkish liras (about 96 USD then) which is about 235 USD inflation-adjusted today's money. Apparently, Teleteknik used this system for preparing their Commodore News Magazine publication. You can find 3 issues of that publication at this link including the relevant issue (page 17) retrodergi.com/commodore-haberler/
Very interesting info, thanks Tonguç!
That kernal rom bug that would cause the C64 to lock up after scrolling to the bottom of the screen and scrolling over two lines of text was so frustrating. I cannot count how many times that happened while I was typing in long BASIC program listings and losing my work because I had not stopped to save my progress to a data cassette. It instilled in me the notion of saving often. Apparently, the workaround for this bug was to simply change the default colors (background blue, foreground light blue) to something else (e.g. background black, foreground grey) before typing a BASIC program listing. I was never aware you could use the data cassette to unfreeze the Commodore 64 after it hung from that kernal rom bug.
12:00 My guess: it jumped into the tape routine and crashed out of it, while already having disabled interrupts. Triggering the tape routine again and finalising it correctly will re-enable interrupts.
I don't know how many hours of C64 I watched on this channel, I'm still not bored.
That was really interesting, Robin! I learned a few new things!
Hey, now you can drill through some C64 cases to install bodge wires in them!
Robin should've used a paperclip to reset his C64.
@@marinacelada3246 What joke?
@@marinacelada3246 What's annoying about a paperclip?
@@Okurka. Let it go... never mind.
There are still many nervous ex Commodore employees worried that Robin will uncover their secret message they hid 40 years ago.
50 years after and not a day to late😂
I think enough time has passed by now, that all the chips have been dumped, and analyzed for any hidden gems... but you never know. ;)
I don't know about the commodore 64 engineers, but I bet the Amiga guys left a message or two about the idiots who drove the company into the ground.
Longstanding mystery solved! When I was a kid, I borrowed a Cosmi game called 'Navy Seal' from a friend. The briefing screen before the mission would print text on the screen on my friend's C64C machine, but on my C64 breadbin the text was not visible even though the game worked otherwise. I must have had an -02 kernal in there.
One of the first rules of computing that I learned: Save when it's more trouble to recreate what you've done than it is to save.
Interesting that the Turkish kernal uses mixed upper and lower case characters in the banner.
And the ready was in lower case too.
@@wisteela < They were ahead of the times, while everyone else was still using upper case only. ;D
0:19 Ah, yes, the era before ubiquitous spellchecking.
4:12 The VIC-20 had a screen-fill character color of White. We'll assume they just didn't change this from the VIC, though the VIC had a default screen-background color of white, rendering naked screen POKEs invisible.
4:42 There's also lots of color-fringing around the letters. I don't know how people could stand that on the Apple II or the TI-99/4A - or with color-fringed sub-pixel fonts today in Windows!
6:00 Interesting - that's $FF80, one location before the Kernal JMP table.
10:50 What if you change the background color to white, clear the screen, and change the background back to blue?
12:44 The text is a lot more clear now.
13:22 I remember reading that they used the background color because using any contrasting color increased the "screen sparkle".
14:35 $FFF6, the last four bytes before the interrupt-vector table.
21:56 Tautology.
22:12 Seems like an endless source of incompatibility.
22:40 It'd be a spot to put a Japanese character set, though if the Kernal didn't set this up itself, they could just assume that software would take care of it in a way that lets the base machine be compatible with the rest of the C64 world. Did the Japanese C64s have a special character ROM?
Now that we've seen so many versions of the ROM I'm really looking forward even more to your in-depth review of Compute's Toolkit Kernal book from 1985
BTW - “Greyscale” is a kind of “Monochrome”. I may have misunderstood you, but it seemed like you were implying that monochrome was a binary color space consisting only of Black or White. Monochrome just means what it says on the tin mono + chroma, “one hue” or any color system that consists of only Black and White or a single hue and any of its shades at various degrees of saturation and brightness. That’s not to say that monochrome color can’t be digital or even just binary black and white; it’s meaning is just more broad.
If you already knew that, I apologize. Love your videos, I’ve learned a lot from them.
Thanks to that "KERNAL" spelling business, I used to spell it that way for all OS kernels. At the time, I thought it was like bite vs. byte...like it was computer-specific jargon. Thanks Robert Russel! :/
Same
I took my SX-64, a black-and-white tv, and a 2400 Baud VICModem to University with me and wrote, uploaded, compiled, executed, and debugged Pascal and COBOL programs on the University mainframes from my dorm room.
I had a question about one of my Pascal assignments and sent a VMSMail message to my Professor.
After a brief mail exchange, he commented that it looked like I was using a 40 column screen editor. I told him what setup I was using, and, after a brief pause, he said, "Why are you in my class?"
That's cool that on the SX version of the 64, the default drive from direct mode is the built-in 1541. Makes perfect sense!
Re the KERNAL version byte: the Apple //c had weirdness with the byte indicating the ROM version as well; it started at 255, then 0, 1, 3, and 4.
I wonder if in both of these cases, they just picked an unused ROM address and gave it meaning starting with the first revision after the original.
The screen clearing routine ($E544) works differently in the second revision because there was a problem with the VIC where errant pixels of foreground color would flicker randomly on blank characters. There wasn't enough time to fix the hardware, so for demonstration purposes, the screen clearing routine was temporarily changed to fill the color RAM with the background color.
Great stuff here Robin, thanks for sharing! Keep being awesome, and merry christmas!
You should cover the C64DTV + easter eggs! Especially the hidden messages!
Another great video! Love seeing all the changes the made
Awesome as usual Robin. Never loose that thoroughness!! :D Merry Shrismas!!!
Thanks for this video. Happy Christmas!
This was an extremely informative and fascinating video. I wish you were around when I was a kid getting into all this stuff, I would've learned a hell of a lot from you!
THANK YOU for not saying "RUNSTOP RESTORE". I'll bet you never say "instant delete" either.
I have a '64 from '82 which doesn't have the silver label. Oddly it's early enough to have the buggy VIC II (with snow). Sadly the clock generator went haywire and IIRC most if not all custom chips died.
I bought by first '64 when the 64C first appeared in stores. When I bought it, the original 64 and the 64C were both on the store shelf, but there was a promotional discount and the 64C was cheaper! It had a board in it that was meant for an original '64, not a 64C board. Sadly that one gave up the ghost in 1994 and all that remains are the keyboard springs (I have no idea why). For years the metal Commodore 64 label from it was stuck to the dash in my car.
Thank you for this video. I recall reading about the different ROM versions in a magazine, but completely forgot the differences.
Instant Delete, Clear Home, Runstop, and why not Exclamationmarkone while we're at it! :)
@@8_Bit one of my biggest pet peeves as a C64 user!
The biggest one as a computer user in general back when most people weren't: Everyone always assumed that the C64 was just the keyboard, and the computer was in the monitor. But these same people called the keyboard of their AT-clone the "computer", and the computer was the "hard drive" 🤪
@@KC9UDX That bugged me too, but that worked to my advantage later: several times at thrift shops in the '90s and early '00s I would find C64s (especially 64C) in with the other computer "keyboards" and priced accordingly, like $2.99!!
@@8_Bit the only time I saw Commodore computers in thrift stores at that time, and flea markets, etc, the sellers knew what they were but didn't charge anything for them. I think about all the complete Vic-20s I passed up for $1 😟
people can change out the Sid or Vic chip now-a-days ...they use multiple in a self made synthesizer..so it could be possible that it has been swapped...for the glitchy older type...it's a bummer...
the music industrie is a bummer
the sid machine - they really made that synth to accommodate" the Sid chip...to people are searching for good machines you never know what youre gonna find inside now-a-days..try to check before you buy
Robin, I love your videos. What an awesome video. Merry Christmas, brother.
Great video. I always found it strange that Sweden got a localized keyboard fof the C64, but we in Norway had to get by with the standard english keyboard layout. Oh well. It didn't keep me from loving my C64 :)
Super captivating and informative. Thanks!
Enjoyed the video, now I want to check what Kernals I have in all my various C64's. Quite enjoyed your ending Song with the words being based on the different Kernal version quirks!!!
Very interesting! Did not know that at all.
Merry Xmas to all 8 Bits! :-)
Greetings, Doc64!
another great video, thanks for sharing. Merry Xmas
ehy Robin, the final song is really good! just to relisten to it I watch again the whole thing! cheers
Great video :) One little question - what version of kernal(s) did the various types of C128's C64 mode have?
My "flat" C128 (unfortunately I don't have a 128D) has the revision 3 kernal when I do the ?PEEK(65408)
Yes, as far as I know all C128 machines shipped with a KERNAL v3 in C64 mode. The C128 mode ROM underwent at least one major upgrade (more on the BASIC side than the KERNAL, I think) and I get into that somewhat in this video: ua-cam.com/video/pvB6YnE0gwc/v-deo.html
Merry Christmas & Happy New Year!!!
:-)
Great video. We always used the poke trick to see which kernel we had. I had a tape turbo that was probably developed on v2, because before showing any graphics you would think it was loading on a blank screen with border color changing. But the same program would spit out bunch of garbage starting $0400 on my Commodore before showing loading graphics :)
as always, a great interesting video. mhh are there also different kernel versions on the c128/c128D?
The C64 mode in the C128 is the same KERNAL v3 that the last breadbins and all 64Cs have, as far as I know. The C128 mode did have at least two ROM sets; I think most of the fixes were in the BASIC portion of the ROM, but it's likely some aspects of the KERNAL were tweaked too. I explored some of the C128 bugs in this video: ua-cam.com/video/pvB6YnE0gwc/v-deo.html
Great Video, I was watching it early in the morning and had to get out of bed to see what KERNAL's I owned. My original C64 as a kid was a 2. My other one is a 3. Good Stuff!
Always important to stay watching till the very end for that little piece of magic. ☺️
Another great video, thanks!
It's cool that you still own your first C64. I no longer have my very first computer, a ZX Spectrum, nor do I have the Amiga 500 and Amiga 1200, both of which I loved very much. But I do have a model of the very first computer I've ever used, a ZX-81.
Very informative and interesting. I'm now pretty certain that my old 64 is a revision 2. It has a smaller manual that mentions the compatibility with Max cartridges.
The 4064 ROM - I just looked and it has a loop, not only zeroing the background and border colour but also the remaining VIC-2 colour registers. So any attempt at playing most C64 games could see you with all black sprites if the default IRQ routine was left in place.
The attribute clear-screen thing - I got bitten by that, wrote a game which relied on bars of the sides of the screen using special characters to force a collision to prevent your ship going offscreen, but I had no idea at the time of kernal revisions that didn't set the cell attribute to background colour.
C128 - I do suspect by that time they'd have gotten things right and settled on the one kernal version.
Check my channel ... I recently uploaded a video of Giana Sisters running on a real 4064. Only one shade of green indeed. IIRC only the educator had that, while the 4064/PET64 even had their mainboard moded to cancel out shading.
I was thinking that it would be cool to start reviewing programs that came in compute's gazette. Two really cool things that I can recall off the top of my head were something called CHR$ Graphics (Compute Gazette - Issue 73 -July 1989) and The Great Arcade Machine (Compute Gazette - Issue 68 - February 1989). Really cool stuff to support basic etc. I used CHR$ Graphics to make a pool or radiance/The Bard's Tale clone to adapt the Super Endless Quest #1 Prisoners of Pax Tharkas into a game. I actually got very far, intro, character building first part where you make it to Solstice. Unfourtunately my Dad had me throw all my stuff out in the mid 90's so I lost all my stuff. I also used the Great arcade machine to make a ninja shooter where you could throw ninja stars to kill samurai running around on the screen....really fun memories hours spent working on that stuff...
Several hundred thousand units were made in Canada (I own 4), and all of mine don't have the "made in Canada" sticker covering up a "made in USA" sticker - they just have a single original sticker saying made in Canada. Many Commodore fans forget that Commodore was founded in Canada and was originally a Canadian company (and hey, if that blows American viewer's minds, then they should look up the origin of IBM - also Canadian). Great trick with the PEEK(65408) -> The C64 Memory Map doesn't even show that! FYI - Vice shows "3" as it uses version 3 rom. Now you've made me want to check if I can run Jiffy DOS on Vice. :)
Thank You very much for Yours videos👍 Greetings from Poland!
Thank you very much!
Just have seen your video. Excellent explications as always. I noticed how old my C64 really is. And that Commodore really used what they accidentally found in their shelves. I have a 1983 250407 mainboard with a Version 3 Kernal 0584, a CPU from 5083 and a VIC-II from 0685. Think that one was replaced by service.
Commodore could probably have made an additional small fortune if they'd socketed all the ROM chips and sold updates for advanced users.
All the advanced users had modified kernals.
@@Okurka. Sure I had my Dolphin DOS but a lot of people would've settled for less.
Thanks for sharing!
Commodore's German manual referred to Kernel 2 for years. To every POKE into the character RAM there was a POKE into the color RAM. I don't know if they ever changed it.
As Bob was missing in the 4064 Kernel: I think these machines were sold without SID, as they shouldn't be machines to play with. I also think this Kernel disables the sprites every time it sets the background color to black. So it would be logical removing the BY.
Interesting video, thank you!
Excellent video =D
Hey Robin. I have a memory of a bug that I think is relevant. I thought maybe you could test for. The dates are best guesses, as this was a long time ago. I got my first computer in 4th grade, 1984. It was a Commodore 64 with the 1701 monitor and 1541 DD. One of the habits I picked up fairly quickly was to poke both the background and border to black. Around 7th grade, 1987 (I think), I started having issues with my C64. My uncle said he could fix it (he was good with electronics). But instead of fixing it, he swapped it out with one he had. The one he gave me, would not accept a poke 53280 to change the border color. If I recall correctly, there was a work around, but I cannot remember what it was.
try other colour pokes....instead of black..?
i remember most of the poke adresses it's so easy ...it where the first i guess from 48 hundreds and up to 64 hundreds color adresses from 64 somewhere sound adresses start ...
IIRC according to some video I watched ages ago the C64GS was more expensive to produce than the regular C64 too. Commodore did some weird things sometimes on the business side of things.
excellent video, learned alot i didn’t know 🙂
Very cool video !!!
I'm thinking about changing my middle name to "I'd like to have one just because". Very cool, I think I find the Japanese version the most strange. That 2k is pretty important.
very important, seeing as a lot of software is saved as a single line BASIC program with an SYS call at 0801 to code beginning at 0810 (or thereabouts), with the machine code afterwards in memory so you can just type RUN.
This change makes all of that incompatible
Great video as always! :)
9:29 Wasn't this the fix for the sparkle bug? Check out Bil Herds talk "VCFMW 11 - Bil Herd: Tales From Inside Commodore", 15:51.
Technically, it wasn't a bug. A "bug" would imply that it was an accident. It was a design feature of the ROM chip, which had been designed years before Commodore used it in the C64. More than three million of that particular chip were already in use in other platforms (such as the arcade game Asteroids) with no problems.
The sparkle was caused by a special precharging circuit in the ROM chip, which made the ROM run faster, but it also made the chip sensitive to spurious signals. The VIC-II chip and the 6510 microprocessor alternated control of the system bus, and when control passed from one to the other, voltage spikes were sometimes generated. If the voltage spike had been a few nanoseconds shorter or longer, it wouldn't have been a problem. By sheer coincidence, the spike was just wide enough that the ROM chip saw it as a valid address. It would ignore the next address request and feed the wrong data from a random address to the VIC-II. Since the chip contained the C64 character set, the screen display would be littered with random slices of characters.
So, until they could source new ROM chips, Commodore's interrim "solution" was to change the behavior of the CLR-HOME command. When you turned on the computer, the cursor color was initialized to the same color as the background (blue) and the screen was cleared. Then the cursor color was changed to light blue and the startup banner drawn. The sparkle was still there, but most of it was now the same color as the background, so it was less noticeable. In other words, all they were doing was _hiding_ the "bug" until they could ramp up a new production line to make ROM chips without the precharging circuit. Only the first few hundred thousand C64's had the "sparkle", which was fixed by September 1982, though reports of the defect continued well into the Christmas season.
@@SpearM3064 Wow, thanks for the in-depth explanation! :)
@@branchonequal You're welcome. And Merry Christmas! :)
@@SpearM3064 Thanks, wishing you the same! :)
I'm curious about the Japanese C64. Was the 2k removed from Basic used by the system in any way? An extra 2k at that location would have been very useful for assembly programming.
No, I see no reason why you couldn't change the start of BASIC to $0801 and use that 2K, or just leave it where it is and use that 2K as a "protected" area for assembly programming. My theory is that there was a custom character set that was supposed to be mapped into that location (loaded from disk maybe?) but since I don't have one of those Japanese Kernals to reverse-engineer, I'm just guessing.
Really weird, in a local electronics-store there was once some empty C64GS, so everything was missing, just the empty plastic case... bought one but never did anything with it... was just some bucks back then...
Great video!
Honestly, it's never crossed my mind that there are multiple kernal versions. Obviously there is, just strange I never thought about it before. :)
Speaking of kernals - did the source code ever leak out from Commodore, before or after their demise? That'd be a fascinating read. Yes, I know I can just disassemble it, but that's not the point; was curious if there'd be commentary from the programmers and such.
In Germany there were many books from a company named Data Becker. For many computer systems there was a book named intern, meaning internal. 64 intern had a commented disassembly of BASIC and KERNAL. I have revision 5. It just explains the differences between the normal 64 and 64SX.
And I am sure Commodore and Microsoft knew about it.
While re-watching this video, I just noticed that the power LED on your 64C is red, while mine is green.
I have a theory why Bob Yannes initials are missing in the 4064 Kernal ROM. First the 4064 and the Educator 64 are not the same and they have not the same Kernal ROM! The Educator 64 was a standard C64 board with standard ROMs in a CBM case (with an extra speaker added inside). The CBM4064 had this special Kernal and the boards had no SID Chip (and no speaker). The chip is not just missing - it was never populated on these boards. The missing SID chip could be the reason for removing the initials of Bob Yannes, right?
BTW: All Educator 64 were NTSC and all CBM4064 were PAL but there was an other C64 in a CBM case. The PET64 was the NTSC version of the CBM4064 with the 4064 Kernal and a board with no SID chip (and no speaker).
If you have any questions you may contact me via my website: www.c-64.org
Thank you for your awesome videos! I watch all of them!
From my understanding, Bob Yannes and others left MOS because they felt financially cheated out of the C64's success. Some of them set up PVI which attempted to create a keyboard for the Atari 2600 with enhancement chips. Atari Inc contracted with them for the product. Jack Tramiel got mad and sued Yannes and the rest individually while trying to use the various patents to the 6502 against them. Steve Ross, the chairman of Warner [parent company of Atari Inc at the time], had to step in and calm Jack down over the debacle. That was perhaps their first interactions which later led to Ross contacting Jack to purchase the assets of Atari Inc's Consumer Division when he panicked and decided to break up Atari in early 1984.
Yep! At around 12:12 you showed a massive portable reset switch. Nice.
A paperclip is easier.
@@Okurka. But also easier to get wrong and short something out.
12:30 I would love an analysis of that corner delete freeze bug. There must be something rather weird going on.
Yes, it'd be interesting to dig into! I've got it on my list of potential episode ideas now.
@@8_Bit According to another commenter, the bug can only be triggered if you're using specific colors. These are colors 2 (0010, red), 3 (0011, cyan), 6 (0110, blue), 7 (0111, yellow), 10 (1010, light red/pink), 11 (1011, dark grey), 14 (1110, light blue), and 15 (1111, light grey). The other colors are safe. If you decide to dig into this in another episode, I have a theory that it has something to do with the bit pattern. Take a look at the colors that I listed: in _every_ case, bit 2 is set.
Amazing minutia!
You mentioned that the EasyFlash can't replace the CHARROM. It's running in ULTIMAX mode this is why the HIGH BANKS appear over the KERNAL ROM in the 1st place. If you POKE 56834,4 when using the KERNAL replacement, it will revert to the real ROM value.
Maybe I'm reading into too much here, but the KERNAL responding with 170 reminds me of the early VIC-1540's when asked to report their version. They say V170. I wonder if that's related...
Unique video!
Very interesting the bug in the first versions. Terrible the computer crash... after a long programming session it was an immense joy to see the update saved on the disk😓😀👍
I love your videos
Its always nice to have your original of something even if it doesn't work I own 6 NES's but none matters as much as my original one (which I use in my living room) I also own 9 Gameboys, and though my original doesn't work I keep it because its my original.
I find it odd that the colors in the Commodore logo on the Games System boot screen are incorrect.
That lock up bug pissed me off sooo many times.
Does adjusting the output gain trimpot for the video output improve the quality at all on rev 1?
great idea !...people would just want a monitor output ...not the coaxial..
it' wouldve been been packed with goodies like that ...as a midi clock...or even just connecter cable to fit from c64 to c64 !! o.m.g.!!😳
Thanks!
I used to run into the bug with the lines at the bottom of the screen all the time, except I'm almost positive that mine used to automatically print the "PRESS PLAY ON TAPE" message when it happened. I made myself a reset switch and then would use a small Unnew program to get my BASIC program back.
Does the NEW comand erase basic memory? I always ignored it when actually writing a new basic program after turning it on but the gmagazines always put the new command in there at start
I'd guess that the "C-64T" on that screen is shorthand for "Commodore 64 for Turkey."
It's interesting that with the SX-64 the VIC-20 color scheme is back (but not "back again," since the idea of a return is built into "back").
One ROM fix that Commodore should have made early on, in both the C64 and 1541, was to speed up the floppy drive data transfer speed. The reason this was slow to begin with has a potentially long explanation that involves something very dumb that someone did to break the C64's board design (in a nutshell, it was supposed to have had the serial "burst mode" that the C128 had from the start, but some critical lines were removed to make room for a new mounting hole 🤬), but the problem still could have been fixed in the KERNAL and 1541 ROMs after release. Had this been done in a timely manner, then compatibility issues would have been very minor, if there would have been any at all, but apparently Commodore management didn't care. Obviously, third-party solutions were developed, but this really ought to have been fixed early on by Commodore and rendered a non-issue.
By the way, on an odd historical note, it appears that Commodore did make their own fast disk transfer protocol for the C64 at some point, so perhaps they were thinking about fixing this issue. I know (or think I know) this because of the game _Mail Order Monsters_ , which states "FAST DISK LOGIC COURTESY COMMODORE BUSINESS MACHINES INC." on the initial loading screen. I'm not sure how else to interpret the meaning of this statement, other than Commodore themselves providing a fastloader for this game. Now, anyone who has played this game on the C64 wouldn't think that it loads very fast, but for reference I've had the C64 version running side-by-side against the Atari version, and there isn't much of a difference in the loading times. The Atari has a slow disk transfer rate out of the box, as well, although it is significantly faster than the C64's, so this fastloader of Commodore's does make a big difference, even though it is much slower than third-party fastloaders. I don't know when this fastloader was made, but this game was released in 1985, so maybe it was too late and too slow to make a real difference, and Commodore shelved it. I still say they should gave gotten on this immediately and provided updated ROMs, even if they would have had to source the faster protocol from a third party.
Super interesting!
What about the ROM for the Drean C64? Is it any different?
As far as I know, the Drean C64 has the same v3 ROM as other C64s made at that time. Unfortunately I don't have one or I'd do a ROM dump and compare it myself!
@@8_Bit good to know. VICE can emulate it so if the ROM is different, it's probably there. Thanks for the reply!
I actually did some research and teleteknik AŞ(distributor of commodore computers) released a Turkish f keyboard c64 named Commdore Türkçeyazar(writes-in-turkish) which I guess is the Turkish kernal you showed in the video. I have never seen one here in Turkey though. Must be super rare
EDIT: Welp, now that I have delved deeper into the comment section other people wrote the same things that I wrote above. Better luck next time I guess.
How do you do your C64 screen captures for the videos?
I use a HDML Cloner Box Pro. Pretty happy with it.
Robin, I would love to see your JiffyDos video ...
Hi Robin. You did an interesting job giving ages of the machines .... after opening it up! I'm wondering if perhaps you would be able to match up the serial numbers printed on the bottom of the machine with their date a manufacture. Many folks go to EBay or Craigslist and there's the picture of the serial number sticker. Without a date of manufacture, it's hard to decide whether to purchase or not. I have searched all over and have not been able to find even a simple table matching runs of serial numbers to dates of manufacture.
. Please help us, Robin!
Hi Jeffry. If you look up the C-64 serial registry - Commodore 64 (C64) Preservation Project you can at least get an idea of the Board Assy # and Board Revision for various serial numbers, which are pretty directly related to the dates manufactured. You should be able to cross reference with various pages such as Dave Farquhar's blog article "Commodore 64 motherboard revisions" to get fairly good ideas of dates. But you'll never know for sure until each machine is opened up to see the individual IC date codes as there is a lot of variation. Ask the sellers to open them up and take pictures - some will.
@@8_Bit Thanks Robin!
Everyone, take your time to listen to the lyrics of the song at the end.
There are a lot of differences between the various revisions. Multiple breadbin designs, different long and short board revisions, and at least 2 64C style cases. Prefer the 250466 board.
i prefer the C type machine because the normal bread-bin would fit right on top..and you would lose the type-writer look and things where getting the look it deserves😂🏗
still cassetes and players didn't make the transition..so they kept the smoked yellow earlier type plastic.
flops came next ...5.4 hahahaha the horror💾
22:25 Moving Start of BASIC ram up by 2K might improve Vic-20 BASIC program compatibility, but it would harm the ability to run C64 programs in 2 common cases:
1) BASIC programs that needed more than 36K
2) Mixed BASIC/Assembly programs. For example programs the jumped into ML like: 10 SYS2070
It would be nice to know if you can break out of that GS animation into basic. Can you check this?
I briefly tried and couldn't find any way to get into BASIC; I believe most or all of the BASIC ROM is intact but short of modifying the ROM or doing some hardware change, I don't think you can get to the BASIC prompt.
@@8_Bit Back when I had a C64 with that version of the Kernal, I used a reset switch. I had a machine language program where I could type LOAD "UNNEW",8,1 and it would restore my program. This works because when you do a warm reset, memory locations $0801 and $0802 are set to 0, and the pointers in zero page are reset. Restore these pointers to their original value, and your program is still intact.
I wonder what happens if you plugin the cartridge while it's on? Does it just not load? Can it short out something?
It's probably fine, but the cartridge won't boot properly. The kernal checks for a cart before moving on to basic. I think I heard it looks for "CBM" at a certain address.
There's quite a good chance of breaking the machine by doing it, as the cartridge socket is connected directly to the data and address buses of the computer. I broke two ZX Spectrums back in the day by accidentally plugging joystick interfaces into the expansion connector while the computer was switched on.
@@Zeem4 yeah I wouldn't want to risk it either.
I used to plug in cartridges while the machine was powered on to copy/disassemble the contents of the cartridge in a machine language monitor. I probably did this a couple dozen times successfully without killing the machine, but it is risky and I would not recommend doing this today! I'll add that the Epyx Fastload cartridge particularly challenging for me to follow in disassembler!
To answer your question: if successful, the memory locations belonging to the cartridge get populated with the cartridge, and I seem to remember that if you are at a BASIC prompt, and not at a machine language monitor prompt, the system may crash.
_Hi Robin, do any of the Commodore 64 expansion cartridges include a math coprocessor, if someone wanted to write a 2D CAD app?_
I'm not aware of any C64 math-coprocessor cartridges. A few demos have used the 6502 processor in the 1541 disk drive as a math co-processor, but that's a highly specialized and optimized use to get a net gain, as the communication overhead between C64 and 1541 is so high.
@@8_Bit _Robin, that's a fascinating concept to use the processor of a peripheral to perform number-crunching! _*_Thanks for the reply!_*
@@8_Bit that's interesting. AMD made an ALU - and Intel had a licensed version of it as well - that was available as part of an expansion card for the Apple II line that gave it math-coprocessor abilities for spreadsheets and other business apps. I've heard conflicting stories about it also being available for the Atari 8-bits but that it's even more obscure for it than for the A2.
@@TheJeremyHolloway I did a little googling for the A2 card but didn't find it. For sure there's no official math coprocessor that works directly with the 6502 the way other processors had official math units, as the 6502 doesn't have that kind of extension built into it. But definitely the C64 is capable of accommodating things like external or replacement CPUs like the SuperCPU or Z80 cartridge from Commodore. It'd be neat to learn more about this A2 card.
@@8_Bit I'll look for the chip I'm referring to. It was obscure on the Apple II platform and triple obscure for Atari 8-bit. It was like a combo of the 4 AMD ALU chips Atari had used in their vector arcade games like Red Baron but on the Apple II, it was used for spreadsheets. There was a discussion of it in an Apple II group on Facebook and that's when it was brought to my attention that Intel also sold a licensed copy of it long before they rolled out their own 8087 for the 8088/8086...
Does anybody know where to buy the entire collection of Ahoy and Run on CD/DVD? I bought Compute! and Compute!'s Gazette so that I could get copies of articles I wrote at the time.
A great place to look for old computer magazines, manuals and other documentation is on archive.org. I checked, and sure enough they have both of them scanned and stored there
archive.org/details/ahoy-magazine
archive.org/details/run-magazine
@@Doug_in_NC Thanks!
AC/DC reference checks out.
I heard that kernal version 2 changed the color to match the background intentionally because it hid defects in the early VIC chips. After the defect got corrected the change wasn't necessary anymore. But I remember Bill Herd saying it was like glittery snow flakes. After it got fixed people were stealing vic chips at commodore. lol
The defect wasn't in the VIC chip, it was in the character ROM. (See my reply to Thomas
Müller.) But you're not wrong... they changed the color to match the background to hide the defect until MOS Technology could tool up a production line to produce new ROM chips without the defect.
@@SpearM3064 Bill Herd specifically said the Vic chip had a glitter pattern to it. Little dots showing up on the screen. I've seen it demonstrated. It's not the character rom. All that can do is flip on the wrong pixels. It's also why people were stealing vic chips at commodore. He was sick of his vic getting stolen so he had the fab send him a couple of tubes and he laid them out and said free to a good home. The vics eventually vanished and the problem was solved. At least this is what he said.
@@SpearM3064 I just saw your detailed comment. I don't see any possible way it could cause the colors to change. All it does it tell it where to plot the pixels. It doesn't affect the color. Anyway I don't know. I just know what Bill said.
@@awilliams1701 The sparkle doesn't cause the colors to change. They changed the color to hide the sparkle. Also, the stuff about the "precharging circuit" comes from one of the people who _designed_ the VIC-II chip, Albert Charpentier. I did some more research and found out that _both_ Albert and Bil are right. Some of the original production run of VIC-II chips have a flaw that causes sparkle once they heat up, but _all_ of the Rev.A boards with the 901225-01 character ROMs had sparkle because of the precharging circuit.
Is the MG contact cleaner really the same as Deoxit?
I don't know if it's 100% the same, but I've had just as good results with it as with Deoxit. It seems to be a lot better than the only other contact cleaner I can find easily here in Canada, which is the Canadian Tire brand :)
@@8_Bit Awesome, thanks for the quick reply. I'm in Vancouver, BC and I know Lee's Electronic carries Deoxit but it's a bit pricey. They also have MG which is cheaper than Deoxit. I guess I have to bite the bullet one day and get the real stuff.
that swe C64 is "normal" C64 (for me atleast ;-) )
I'm pretty sure the C64 version sold in the Finnish/Swedish market was the stock UK version, and the scandi ROMs and key caps were sold as an after-market add-on. And since it cost extra, and one actually had to pop open the case and change ICs to install them, it wasn't so popular. I was quite young, though, so I might not have known how it was exactly. But that's how I remember it.
@@FinnGamble Mine and most of my friends Swedish C64s came with the Swedish kernal pre-installed and real printed åäö-keys, not stickers. It probably depends on how early on you bought one.
I had a C64C in the late 80's in Finland, and some friends had C64's or C64C's as well. But I only learned a couple of decades later on internet about the existence of the Swedish layout.
I remember that we had some C64s with danish keyboard and charactersets in school - and I think I saw that the roms were eproms with stickers on them, but if they were bought that way, or some of the teachers had burned their own roms, I never found out.
Also, having the localized kernal and charset didn’t help much when you were printing documents - the printer also had to have a localized font, and we had one for the daisy-wheel printer, but I don’t remember how the dot-matrix (I think it was the 802) handled it.
Any incompatible programs for the SuX-64?
Every program published on cassette is incompatible with the SX-64 :) And it's also easy to write a program that would fail on the SX-64 but run on regular C-64s, but that would probably only be done to prove a point.