After many years, I finally got a Vic-20 (my first computer back in the '80s). It had the same symptoms you described in your video, and you know what? The kernal ROM was faulty! 😀 I just burnt a new kernal, and it's alive again. Now, I see the composite output quality is really poor... I'll follow your suggestions in your video about improving composite output quality. Gracias por tus excelentes vídeos, Noel!
What freaks me out about this is that I've not done any 6502 programming in over 35 years, yet I could follow your commentary quite easily and understood exactly what was happening. On the other hand I can't remember what I ate for tea last night!!!
I single stepped through almost the entire BBC micro ROM and knew how everything worked to a detail that is just amazing looking back at it 40 years later.
I loved my Vic 20. I had the base model with 5K RAM. I made good use of the cassette interface to get more out of the limited RAM by loading in parts of the program and data from tape as needed. It cost about $99 at the time I got mine and I was super-impressed by how nice the keyboard was, compared to the similarly-priced ZX-81.
You're absolutely right. That's how I feel when I'm learning new things that come up in my videos, so I'm extremely happy to hear that other people enjoy that too! 😃
Hi Noel, as always a nice video. I have a tip for you. I noticed that you are using a glass fiber contact cleaner to clean the board contacts. Glass fiber is pretty abrasive and actually damages the protective gold layer. Next time you have to clean similar contacts try a simple pencil eraser, you will be surprised with the result.
About two years ago I pulled a VIC-20 out of a dumpster. It didn't boot, but I had another one that worked, so I just swapped socketed chips over until the working one stopped working. Well, the first chip was the VIC-1 which was OK, the second chip was the Kernal and that didn't work, so I put the known good one in the faulty VIC-20 and there was nothing else bad with it, so I was happy, made one of these crappy socket adapter constructs, burned a new one and now I have two VIC-20s. But all I ever do with it is sing along to ALL MECHANICAL CREATURES UNDER HUMILIATION COMBINE TOGETHER AND FIGHT FOR ROBOTIC LIBERATION. Also I just found out if you share a 1541 disk drive between a C16 and a VIC-20, the C16 doesn't mind at all, but the VIC-20 really doesn't like it. So the C16 has to be unplugged if I want to use the VIC-20.
Hi Noel. Interesting video. I always find that the best route for initial diagnostics is voltages, clocks, reset line, interrupts. Loading a reset vector (and possibly an initial stack pointer) on startup is an extremely common sequence for any CPU. The VIC-20 is obviously also looking for a cartridge "signature" during its startup sequence - another very common technique. I thought it was very strange how you spelled Kernel for the EPROM until something in the depths of my memory dragged up this particular Commodore-ism! Keep the videos coming 👍😁
Cool! These videos give me a bit more confidence that fixing these problems are indeed doable. Unfortunately I don’t have an eprom programmer though ..
That surprised me that it was a ROM, I thought it was one of the 6522 chips. It has been a lot of years since I repaired any Commodore computers, Nice find. Lee
Thank you! Apparently the ROM is a VERY common cause of black screens on VIC-20s, but really, it could have been many things that prevented the CPU from executing the code.
The Vic 20 was my 1st ever computer, followed by the commodore 64 which supported sprites from memory. I remember buying an assembler cartridge so I could program the 6502 in machine code. It was hard going for a while, but it helped me understand how the CPU operated, calling internal routines to switch out the ROMs and use the memory underneath them for storage etc. It also helped me understand computer architecture with address and data bus and the use for interrupt routines to name few. One thing that stood out is it had a tape drive which could take several minutes to find a game on it, the the same time again to load it. Great memories.
Thanks for another interesting watch Noel. Always feel like I'm learning something new. I've recently started getting more into electronics from building mods and basic fixes for old machines and these videos are great for ideas on what to look for.
The mark of the true professional is the ability to make the difficult stuff look easy. That, and the willingness to share one's successes and errors to the benefit of others. Bravo! The breadboard trick is a good one. Would it be equally handy to put the female header pins on an old (failed) chip or chip socket to hold them straight during soldering? Also, since the female header pins look to be of good quality, could you not have just removed the old socket from the board, soldered the adapter directly to it, and let the adapter serve as a new chip socket? (Lower profile for the whole thing that way, too.)
Personally I would use turned pin headers for adapters that have to plug into IC sockets, as the square pin type can easily damage the socket preventing an actual IC from working reliably in them. One "feature" of some versions of the 6502 that is not commonly appreciated is that if it reads certain undefined instruction opcodes it can cause the processor to "jam", giving the impression the CPU is faulty. If your kernal or basic ROM is faulty, the processor can be given one of these jam instructions. I'm not sure if this is true of the 6510 variants used in the C64, but the original 6502 fitted to the PET and VIC 20 does appear to suffer this "feature".
You're right about the pins. I didn't have any on hand and that EPROM is staying there permanently, so I didn't think much of it. But yes, if you have to take it out, then you should probably change the socket. That's a great insight about the 6502! I looked into it for a bit, but I wasn't able to see any normal instruction that would lock it up (like a HALT on the Z80). So some of those garbage opcodes would make a lot of sense.
@@NoelsRetroLab there are a handful of illegal opcodes sometimes referred to as "KIL", which mess up the microcode counter past the CPU decode ROM, resulting in essentially a continuous NOP in most cases, I think
Always good to see a Vic-20 saved from the bin. Good job as always. I may have considered removing the socket from the motherboard and soldered that adapter board directly in. It may be too tight for that socket and over time it may fail again.
A 6502 will disconnect itself from the bus and wait for reset as soon as it executes a so called "crash" code. This is why the CPU did seam dead: The bad ROM did result in random data on the bus, which could make the CPU either execute a crash code or end up in an endless loop. As soon as I saw you suspect the CPU I was expecting to be diagnosed fine in the end: It is perfectly normal behaviour for a 6502.
Right. That makes a lot of sense! That's the kind of thing you learn as you get more experience with particular CPUs. I kept looking through the instruction set for the equivalent of a HALT on Z80, but there was nothing like that. It turns out it's a normal behavior from executing "bad" opcodes. Very interesting. Cheers!
With the C64: Commodore didn't want to first build a game console that could only be started via a plug-in card. But the project was canceled and the function was found in the later C64. Therefore the plug-in card of the C64 can switch off all the kernel ROM and operate its own kernel. With the C20, plug-in cards were always an extension of the existing system.
I still have that Zaks book... Brilliant. I started out with the Ohio Superboard II before I designed a 2k memory mod and a 64 character mod... made all the better because of CEGMON.
I just had to replace a Kernal ROM on my Plus/4. Looks like they really tend to fail quite often. Lovely video, thanks for the deep dive in the start up sequence. 😊
You used the breadboard to align the male pin headers on the EPROM adaptor, but aligned the female headers manually. If you put male headers into the female ones, then you can flip the board over and use a breadboard to align the female headers too.
Good point. I think the female ones align correctly naturally and I never had a problem with them. Maybe because the male ones don't have a natural resting position, I find it impossible to align them correctly by hand on the first pass 😃
Because it is a shared bus, I think that any chip on the bus has the potential to stop all bus activity. I also had a VIC20 which produced video but just all black video. It was caused by a faulty RAM chip, and came back to life after changing that IC. Interestingly, the VIC 'dead test' on the 'Penultimate cartridge' worked and correctly detected the faulty RAM.
Great video! Thank you for sharing your work flow on diagnostics. The way the kernel ROM is kinda like how Color Basic, Extended Basic works on the TRS Color Computers. Then the cart ROM has two ways to be used on the Color Computer. This can also be a rabbit hole to go down. :O
With the MOS 6502, there isn’t any pin where one can completely disable/float the 6502 processor pins. Therefore it is not possible to make a diagnostic card that with its own processor can overtake and drive the bus. Also signals A14+A15 are not routed through to the expansion slot which adds another layer of difficulty. Just wondering if one is putting a larger capacity ROM in the kernal position, why not have a dip switch so one could swap between 2 different kernels like Jiffy DOS and PAL.
You wondered if the VIC diagnostics cartridge needed any functioning RAM to work. it’s actually a very well thought out system and includes 1K of RAM on the cartridge, though that doesn’t replace the video RAM it’s enough for the cartridge to run it’s diagnostics.
@@NoelsRetroLab The original diagnostics cartridge Commodore used in the 1980s used the same pcb as the Super Expander cartridge that had a 4K ROM which added some graphics and sound commands to BASIC and 3K of RAM, but they only populated 2 of the 6 512 byte RAM chips to give 1K of the RAM and replaced the ROM. Sven’s Hyper Expander PCB design reproduces the same functionality with modern parts, and can do a lot more if fully populated - fully expanding the RAM, multiple switchable ROM images etc. it’s a really good design.
@@NoelsRetroLab The lower address line selects when a memory address is odd or even. That means that when the CPU is fetching opcodes you can see lots of activity in it as it gets consecutive bytes. The R/W pin is not bad, honestly, but you depend on the code doing some writes to memory, that will be the case of the 6502, with a very limited register bank. Keep on the good work!
Noel: Always put the suspected dead part, like this CPU, into a working computer to prove it is faulty. Also Noel: Imma put this nice working ROM chip into the dead board and see if that fixes it... 😂 Just teasing. Keep up the awesome work! You're doing a great job saving those Commodores from landfill.
Aha! I figured there would be other similar ones. Good to know! I probably never asked myself that question since I don't have a diagnostics cartridge for the TI-99, but I'll remember that. Thanks!
@@NoelsRetroLab No problem. The 8K of cart space in a TI-99/4A cartridge is mapped into the CPU space starting at 0x6000. A special 'header' (a sequence of bytes) is required at the start of the cart ROM memory. the 4A console ROM checks for the header and if detected presents the cartridge as a menu option after the boot screen. All the best from the UK.
I used to repair C64's way back when. We had a test cartridge with LED array that could tell you what chips were good or not. All it needed was the video chip and CPU to run, as well as none of the address or data lines stuck. This was especially useful when all chips were socketed as I could pull them all except the two mentioned and start adding chips back in. But what about the kernel ROM you ask? I would suspect the C64 had circuitry to disable the kernel ROM and let RAM or expansion port take it over.
Good Video, good way to show the screen and to show the pinout of the chip and on which pins you are working, great for beginners to follow! One small thing: the adapter pins that go in the socket of the ROM seem very big (thicker than the ROMs original pins), they will probably ruin the Socket, or is this just fine?
You're right about the pins being too big for that adapter. Since I'm planning on leaving it there permanently, I'm hoping it's OK. Otherwise, you're better off using turned pins (which I didn't have any on hand).
Great video !! On my BBC Master 128, I had hard time finding why it was sometimes not working after power up. I found out that one of the ROM (It has 5 roms) was faulty wich is weird thinking that it is programmed once and there's no possibility to erase anything..
I don't sell anything liked that, but try a VIC-20 or even a C64 forum or FB group and I bet you'll find people there who can send you one for the cost of postage and little more. Good luck!
@@NoelsRetroLab Hi..my vic 20 is dead.. nothing will display on my tv .the led is ON . i replaced the MOS 6502 and 901486-01 and the 901486-06 and the MOS 901460-03 and the 6560-101 and both 6522.. still dead .any idea what is next to be replaced? i dont get no activity on the tv when i turn it ON
Could you have a “system test” ROM to replace the kernel, sorry, kernal ROM that has a reset vector that just jumps to the address at A000 since that seems to be the only bit of the kernal needed.
Yes, they're the same ones I used in the Dragon vs CoCo video. Go check it out. I just had to break a trace to wire one signal differently. They're super handy!
That's the problem: You can't! Without a working system ROM, you can't run anything from a cartridge. I guess the best option here is to put the diagnostics software in an EPROM and replacing the system ROM, but at that point you aren't testing it either. Not the best design from a maintenance point of view.
I don't know about the FCC, but those chips in there sure do! 😃 Jokes aside, I need to learn more about it (and maybe make a video). Has the FCC relaxed their regulations since then? What exactly is affected by something like this and how far does it extend? Because I'm not getting any solid information when I try to find out more about this.
@@NoelsRetroLab The clock speed of 1MHz means that traces in the computer will pulse at less than 1MHz. This the frequency range of medium wave radio, therefore bad EMF shielding will cause noise on AM radios. The 17 MHz of the crystal (and VIC) may interfere with short wave radio. These shields were mandatory in order to avoid that you get angry neighbours whose radio listening experience is hurt, by using your computer. Nowadays we use AM radio a lot less, however, shielding devices from emitting radio is still considered good engineering practise.
Even if a diagnostics cart for a system does not need the system's ROMs. A faulty system ROM can still corrupt the data bus. A faulty IC may not respect its chip select signal and hence corrupt the bus.
It could. "Normal" C64 carts work similar to the way the VIC20 works, with the cartridges mapped at $8000 and the kernel looking for a signature at a specific address to jump into the cartridge (sidenote: You can do funny reset tricks by writing the standard signature to the RAM at that address when no cart is present). However, the 6510 has extra IO pins and, in conjunction with the PLA, supports actual bank switching. It's designed such that, if you tie the EXROM cart pin to high, the second 8k of ROM in the cart will get mapped to $E000-FFFF - replacing the kernel, including the reset vector. I picked this up as a teen in the 80's when I modded my C64 to add a reset button and toggle switch on the cart port so that I could rip carts to floppies, as I couldn't afford an EPROM reader. :p
@@scottlarson1548 Absolutely. If you ground the EXROM cart pin, the second 8k of a 16k cart gets mapped to $A000 - replacing the BASIC ROM instead of the kernel ROM. This is how most 16k carts are configured. The first 8k always gets mapped to $8000. The exception is the carts for the Japanese MAX machines - they always tie EXROM high and map on top of the reset vector because the Commodore MAX had no built-in ROMs.
@@scottlarson1548 This one was more luck than wisdom (due to the desire to make the C64 compatible with the Ultimax), but it is for sure one of the features that make the C64 so powerfull. It's not just that the cartridge can choose, but it can also change dynamically. Many advanced tricks such as hidden fastload cartridges and freezer cartridges are made possible by this and completely impossible on other 8-bit computers. In general I'd say the C64 is still one of the most well designed computers ever.
Good question. I didn't check but I suspect it's totally dead. If you think about it, it doesn't read that many bytes from the ROM before it jumps to the cartridge, so it would be surprising if it was just one of those few bytes (but I guess it's possible).
MOS Technology ROMs are real ROMs, the data is hard wired in a metal layer during manufacturing, which means there isn't really a lot of possibility for corruption; any corruption would be actual defects in the chip and this would be very close to a dead chip.
@@danielmantione Thanks. I was wondering if they were OTP EPROMs, but probably at the volume these were made, a mask layer for the data contents made sense.
@@GodmanchesterGoblin The costs of a mask layer were likely also lower for Commodore than for others, because of the vertical integration of the company: Engineers designing computers could just walk downstairs to talk to people manufacturing the chips in the fab. The overhead costs for producing masks must have been low.
It would be interesting to compare the contents of the bad ROM with a good one. I wonder if they are masked ROMs or if they are OTP EPROMS...? (OTP=One Time Programmable, in plastic because it's a lot cheaper than a ceramic windowed package). If the whole ROM is bad, then it has clearly had its day. But it's also possible that only some bits have become corrupted, and if it was OTP EPROM then they most likely would have gone from a 0 to a 1 (the initial erased state is always all ones). In such a case it might be possible to reprogram the chip with a correct version of its original data using a suitable EPROM programmer. Note that you can only program a 1 to a 0 in this kind of device, so the original data would be required (not an alternative version with some differences), and the corruption must be from a 0 to a 1, and not the other way round. (Just thinking out loud - hope it helps.)
I should look into that. As far as re-programming them, I have no hopes of being able to do that 😃 My EPROM programmer is limited in the kind of voltages it supplies, and these kind of EPROMs (if they're even an EPROM) usually require high voltages. I really think it's a masked ROM though since it's labeled as MOS (and they fail often).
@@NoelsRetroLab I think you're right; it's most likely to be a masked ROM. And yes, EPROM and OTP ROM of that period require specific programming voltages - up to 21 volts in some cases - and that tends to require more specialised programming hardware.
So even though you can bypass the ROM in the C64 (or can you? I honestly don't know how that works and after this video I'm wondering) I've seen C64 repairs where a bad ROM prevented the dead test from working. So you never know.
I need to check the details of the C64, but yes, you can definitely bypass it. It's normal procedure to remove all the ROM and then test it. I believe there's a signal FROM the cartridge that tells the system to use the ROM in the cartridge instead of the system one.
"clearly I haven't been in this before" LMAO I BEG people to throw away the cardboard ones all the time. I'm not happy about the metal ones either, but I'm like that's on you. But the cardboard ones are harmful IMO.
I know, it looks like I'm horrible at spelling. Just going along with the way they're written in all the original documents. I blame some engineer with bad spelling back in the day 😃
20:20 Technically it's KERNEL not KERNAL I do understand that Robert Russell MADE AN HONEST MISTAKE IN SPELLING in his white-papers and then the program writers of the VIC-20 took it as gospel that the spelling was KERNAL (not knowing the spelling mistake that was made) and in turn they just adopted the name into VIC 20 but at the end of the day , it is a mistake. Carrying on a Mistake does not make it correct LOL When i learned computers as a young lad it was KERNEL Back in the days when we had M.C.P. (Master Control Program) so yeah , Technically it's "KERNEL" if it was me i'd be reprinting the label
@@Okurka. Oh... sorry.. Your'e correct I'll make the change EDIT : after making the change i found a few other mistakes as well. changed them as well thanks for the heads up.
"Just burn" The github instructions state if burning one ROM image burn to $E000 (for a 512 EPROM or EEPROM). Is that what you did here? @NoelsRetroLab
After many years, I finally got a Vic-20 (my first computer back in the '80s). It had the same symptoms you described in your video, and you know what? The kernal ROM was faulty! 😀 I just burnt a new kernal, and it's alive again. Now, I see the composite output quality is really poor... I'll follow your suggestions in your video about improving composite output quality. Gracias por tus excelentes vídeos, Noel!
What freaks me out about this is that I've not done any 6502 programming in over 35 years, yet I could follow your commentary quite easily and understood exactly what was happening. On the other hand I can't remember what I ate for tea last night!!!
I single stepped through almost the entire BBC micro ROM and knew how everything worked to a detail that is just amazing looking back at it 40 years later.
I loved my Vic 20. I had the base model with 5K RAM. I made good use of the cassette interface to get more out of the limited RAM by loading in parts of the program and data from tape as needed. It cost about $99 at the time I got mine and I was super-impressed by how nice the keyboard was, compared to the similarly-priced ZX-81.
It's amazing how you always go deep to understand the problem and not settling for just making it work again, great!
Glad you like that too. That's my favorite part about solving problems 😃
Few things are as rewarding as learning and understanding more of what you care about.
Your channel is the gift that keeps on giving!
You're absolutely right. That's how I feel when I'm learning new things that come up in my videos, so I'm extremely happy to hear that other people enjoy that too! 😃
Hi Noel, as always a nice video. I have a tip for you. I noticed that you are using a glass fiber contact cleaner to clean the board contacts. Glass fiber is pretty abrasive and actually damages the protective gold layer. Next time you have to clean similar contacts try a simple pencil eraser, you will be surprised with the result.
I like how you show the chip diagram and where you put your probe and the scope all in the same window and explain everything you are doing it right!
Great job, I love VIC-20, my first home computer in 80's. Regards, Pasquale IW0HEX
About two years ago I pulled a VIC-20 out of a dumpster. It didn't boot, but I had another one that worked, so I just swapped socketed chips over until the working one stopped working. Well, the first chip was the VIC-1 which was OK, the second chip was the Kernal and that didn't work, so I put the known good one in the faulty VIC-20 and there was nothing else bad with it, so I was happy, made one of these crappy socket adapter constructs, burned a new one and now I have two VIC-20s. But all I ever do with it is sing along to
ALL MECHANICAL CREATURES
UNDER HUMILIATION
COMBINE TOGETHER AND FIGHT FOR
ROBOTIC LIBERATION.
Also I just found out if you share a 1541 disk drive between a C16 and a VIC-20, the C16 doesn't mind at all, but the VIC-20 really doesn't like it. So the C16 has to be unplugged if I want to use the VIC-20.
Whatever Noel is repairing or doing, I always learn something. Oh, how I love this channel !!!!
Glad to hear it!
Yet another VIC20 saved and another excellent video!
Well done Noel! Great to also see easy repairs. A knowledgeable support network is always a bonus.
Very true! 👍
Hi Noel. Interesting video. I always find that the best route for initial diagnostics is voltages, clocks, reset line, interrupts. Loading a reset vector (and possibly an initial stack pointer) on startup is an extremely common sequence for any CPU. The VIC-20 is obviously also looking for a cartridge "signature" during its startup sequence - another very common technique. I thought it was very strange how you spelled Kernel for the EPROM until something in the depths of my memory dragged up this particular Commodore-ism! Keep the videos coming 👍😁
Cool! These videos give me a bit more confidence that fixing these problems are indeed doable. Unfortunately I don’t have an eprom programmer though ..
You can probably have somebody in a retro group burn you a ROM and mail it to you easily. Just ask around.
I absolutely love these commodore repair/diagnostic videos! You do such an amazing job. Thank you
Thank you very much!
Great explanation on fault finding on how the starts sequence works, please more of the same. Thank you.
Nice Noël, I will finish of my video for over two weeks and then sit back and relax and watch your awesome VIC20 come back to live!
That surprised me that it was a ROM,
I thought it was one of the 6522 chips.
It has been a lot of years since I repaired any Commodore computers,
Nice find.
Lee
Thank you! Apparently the ROM is a VERY common cause of black screens on VIC-20s, but really, it could have been many things that prevented the CPU from executing the code.
The Vic 20 was my 1st ever computer, followed by the commodore 64 which supported sprites from memory. I remember buying an assembler cartridge so I could program the 6502 in machine code. It was hard going for a while, but it helped me understand how the CPU operated, calling internal routines to switch out the ROMs and use the memory underneath them for storage etc. It also helped me understand computer architecture with address and data bus and the use for interrupt routines to name few. One thing that stood out is it had a tape drive which could take several minutes to find a game on it, the the same time again to load it. Great memories.
Thanks for another interesting watch Noel. Always feel like I'm learning something new. I've recently started getting more into electronics from building mods and basic fixes for old machines and these videos are great for ideas on what to look for.
Great to hear!
The mark of the true professional is the ability to make the difficult stuff look easy. That, and the willingness to share one's successes and errors to the benefit of others. Bravo!
The breadboard trick is a good one. Would it be equally handy to put the female header pins on an old (failed) chip or chip socket to hold them straight during soldering? Also, since the female header pins look to be of good quality, could you not have just removed the old socket from the board, soldered the adapter directly to it, and let the adapter serve as a new chip socket? (Lower profile for the whole thing that way, too.)
Thank you! Yes, very good point about removing the socket from the board. I should have done that.
Personally I would use turned pin headers for adapters that have to plug into IC sockets, as the square pin type can easily damage the socket preventing an actual IC from working reliably in them.
One "feature" of some versions of the 6502 that is not commonly appreciated is that if it reads certain undefined instruction opcodes it can cause the processor to "jam", giving the impression the CPU is faulty. If your kernal or basic ROM is faulty, the processor can be given one of these jam instructions. I'm not sure if this is true of the 6510 variants used in the C64, but the original 6502 fitted to the PET and VIC 20 does appear to suffer this "feature".
You're right about the pins. I didn't have any on hand and that EPROM is staying there permanently, so I didn't think much of it. But yes, if you have to take it out, then you should probably change the socket.
That's a great insight about the 6502! I looked into it for a bit, but I wasn't able to see any normal instruction that would lock it up (like a HALT on the Z80). So some of those garbage opcodes would make a lot of sense.
@@NoelsRetroLab there are a handful of illegal opcodes sometimes referred to as "KIL", which mess up the microcode counter past the CPU decode ROM, resulting in essentially a continuous NOP in most cases, I think
Always good to see a Vic-20 saved from the bin. Good job as always. I may have considered removing the socket from the motherboard and soldered that adapter board directly in. It may be too tight for that socket and over time it may fail again.
Thanks. Yes, that's not a bad idea. It would make the stack a bit shorter too, which would be nice.
@@NoelsRetroLab That too but when you popped that into the socket the sound was cringe loud..... at least to my ears. 🙂
Yes I winced then too! I would use turned pin headers if I was going to plug a daughter board into an IC socket.
Noel repairs in nutshell: "aaaaand, nothing." ;)
True. There's a lot of that along the way to finding the real fault 😃
A 6502 will disconnect itself from the bus and wait for reset as soon as it executes a so called "crash" code. This is why the CPU did seam dead: The bad ROM did result in random data on the bus, which could make the CPU either execute a crash code or end up in an endless loop. As soon as I saw you suspect the CPU I was expecting to be diagnosed fine in the end: It is perfectly normal behaviour for a 6502.
Right. That makes a lot of sense! That's the kind of thing you learn as you get more experience with particular CPUs. I kept looking through the instruction set for the equivalent of a HALT on Z80, but there was nothing like that. It turns out it's a normal behavior from executing "bad" opcodes. Very interesting. Cheers!
With the C64: Commodore didn't want to first build a game console that could only be started via a plug-in card. But the project was canceled and the function was found in the later C64. Therefore the plug-in card of the C64 can switch off all the kernel ROM and operate its own kernel.
With the C20, plug-in cards were always an extension of the existing system.
I still have that Zaks book... Brilliant.
I started out with the Ohio Superboard II before I designed a 2k memory mod and a 64 character mod... made all the better because of CEGMON.
Thank you Noel, as always a fascinating and interesting video! Learned a lot again. Best wishes, Michael
My pleasure!
I just had to replace a Kernal ROM on my Plus/4. Looks like they really tend to fail quite often. Lovely video, thanks for the deep dive in the start up sequence. 😊
Glad you enjoyed it! Yes, ROMs tend to fail a lot on VIC-20s and C64s for some reason. Not in other systems though!
Nice tip with with resistor bridge thing.
Assumptions... Very informative (as usual). Thanks very much for this!
Been watching your videos for a few weeks now and totally loving it. Keep up the great work.
Thank you! Welcome aboard!
Brilliant video as always
You used the breadboard to align the male pin headers on the EPROM adaptor, but aligned the female headers manually. If you put male headers into the female ones, then you can flip the board over and use a breadboard to align the female headers too.
Good point. I think the female ones align correctly naturally and I never had a problem with them. Maybe because the male ones don't have a natural resting position, I find it impossible to align them correctly by hand on the first pass 😃
Interesting and well presented, Noel....thank you.
Glad you enjoyed it!
Because it is a shared bus, I think that any chip on the bus has the potential to stop all bus activity. I also had a VIC20 which produced video but just all black video. It was caused by a faulty RAM chip, and came back to life after changing that IC. Interestingly, the VIC 'dead test' on the 'Penultimate cartridge' worked and correctly detected the faulty RAM.
TIL that the VIC-20 has a different cartridge signature string than the C64 (CBM80). Neat.
Great video!
Thank you for sharing your work flow on diagnostics.
The way the kernel ROM is kinda like how Color Basic, Extended Basic works on the TRS Color Computers. Then the cart ROM has two ways to be used on the Color Computer. This can also be a rabbit hole to go down. :O
With the MOS 6502, there isn’t any pin where one can completely disable/float the 6502 processor pins. Therefore it is not possible to make a diagnostic card that with its own processor can overtake and drive the bus. Also signals A14+A15 are not routed through to the expansion slot which adds another layer of difficulty. Just wondering if one is putting a larger capacity ROM in the kernal position, why not have a dip switch so one could swap between 2 different kernels like Jiffy DOS and PAL.
Hi Noel. Great video!
The only thing bad about this video is that I have a meeting in 5 minutes and can't finish watching it now :)
🤣
You wondered if the VIC diagnostics cartridge needed any functioning RAM to work. it’s actually a very well thought out system and includes 1K of RAM on the cartridge, though that doesn’t replace the video RAM it’s enough for the cartridge to run it’s diagnostics.
I don't know! I meant to ask Sven and I forgot. I should check with him!
@@NoelsRetroLab The original diagnostics cartridge Commodore used in the 1980s used the same pcb as the Super Expander cartridge that had a 4K ROM which added some graphics and sound commands to BASIC and 3K of RAM, but they only populated 2 of the 6 512 byte RAM chips to give 1K of the RAM and replaced the ROM. Sven’s Hyper Expander PCB design reproduces the same functionality with modern parts, and can do a lot more if fully populated - fully expanding the RAM, multiple switchable ROM images etc. it’s a really good design.
Another lovely video. Thank you.
To check CPU activity I prefer to use the lowest address bit (A0 in your case) tends to be a very busy signal.
Oh right, the lower address bits make sense on a 6502 because that's the area it stores a lot of register-like values, right? I'll keep that in mind.
@@NoelsRetroLab The lower address line selects when a memory address is odd or even. That means that when the CPU is fetching opcodes you can see lots of activity in it as it gets consecutive bytes. The R/W pin is not bad, honestly, but you depend on the code doing some writes to memory, that will be the case of the 6502, with a very limited register bank.
Keep on the good work!
Noel: Always put the suspected dead part, like this CPU, into a working computer to prove it is faulty.
Also Noel: Imma put this nice working ROM chip into the dead board and see if that fixes it...
😂
Just teasing. Keep up the awesome work! You're doing a great job saving those Commodores from landfill.
5:45 Programming the 6502 book by Rodney Zaks.
Thanks.
Be prepared to sell an internal organ to get it in hardcopy
Fantastic book! Really, all of Zaks' books about CPUs are great (Z80, 6809, etc).
TI-99/4A also requires a working ROM before you can use the cartridge port!
Aha! I figured there would be other similar ones. Good to know! I probably never asked myself that question since I don't have a diagnostics cartridge for the TI-99, but I'll remember that. Thanks!
@@NoelsRetroLab No problem. The 8K of cart space in a TI-99/4A cartridge is mapped into the CPU space starting at 0x6000. A special 'header' (a sequence of bytes) is required at the start of the cart ROM memory. the 4A console ROM checks for the header and if detected presents the cartridge as a menu option after the boot screen. All the best from the UK.
That was interesting repair. Now we know, that VIC-20 can't work without kernel ROM..
What code remains was in that bad ROM?
I used to repair C64's way back when. We had a test cartridge with LED array that could tell you what chips were good or not. All it needed was the video chip and CPU to run, as well as none of the address or data lines stuck.
This was especially useful when all chips were socketed as I could pull them all except the two mentioned and start adding chips back in.
But what about the kernel ROM you ask? I would suspect the C64 had circuitry to disable the kernel ROM and let RAM or expansion port take it over.
Will the Winbond W27C512 work in these situations. The datasheet states it is electrically erasable.
Good Video, good way to show the screen and to show the pinout of the chip and on which pins you are working, great for beginners to follow! One small thing: the adapter pins that go in the socket of the ROM seem very big (thicker than the ROMs original pins), they will probably ruin the Socket, or is this just fine?
You're right about the pins being too big for that adapter. Since I'm planning on leaving it there permanently, I'm hoping it's OK. Otherwise, you're better off using turned pins (which I didn't have any on hand).
Great video !! On my BBC Master 128, I had hard time finding why it was sometimes not working after power up. I found out that one of the ROM (It has 5 roms) was faulty wich is weird thinking that it is programmed once and there's no possibility to erase anything..
ROMs fail a lot on VIC-20 and C64s. They don't fail as often in other computers, but it happens. I've had bad ROMs on Amstrad CPCs as well.
Hi, I like your video and my vic20 does exactly like the one in your video. You wouldnt have any Kernal -06 avail for sale or the Eepprom?
I don't sell anything liked that, but try a VIC-20 or even a C64 forum or FB group and I bet you'll find people there who can send you one for the cost of postage and little more. Good luck!
@@NoelsRetroLab Hi..my vic 20 is dead.. nothing will display on my tv .the led is ON . i replaced the MOS 6502 and 901486-01 and the 901486-06 and the MOS 901460-03 and the 6560-101 and both 6522.. still dead .any idea what is next to be replaced? i dont get no activity on the tv when i turn it ON
Curious to know what could brick the kernal rom, like I doubt that it came from the factory that way.
Age bricked the MOS chip.
Could you have a “system test” ROM to replace the kernel, sorry, kernal ROM that has a reset vector that just jumps to the address at A000 since that seems to be the only bit of the kernal needed.
another one saved. >> where did you get the vic-20 diag kit?
Excelente video!! Saludos desde España!
Gracias!
Hi Noel! Where can I get the VIC 20 test cartridge with the clear shell?
Were you able to close the case with this modification? I saw a different video where someone had done a VIC 20 mod and the case wouldn't close.
I'm curious about the Dragon cartridge. Do these adapters work with the 2532s in the Dragon cartridges?
Yes, they're the same ones I used in the Dragon vs CoCo video. Go check it out. I just had to break a trace to wire one signal differently. They're super handy!
@@NoelsRetroLab Great stuff, thanks!
Sounds like it would be a good idea to make a replacement Kernel ROM diagnostics tester. Put that in to test the system.
That's the problem: You can't! Without a working system ROM, you can't run anything from a cartridge. I guess the best option here is to put the diagnostics software in an EPROM and replacing the system ROM, but at that point you aren't testing it either. Not the best design from a maintenance point of view.
@@NoelsRetroLab Diag264 for the C16/Plus4 works this way: You plug it into the KERNAL socket.
How did you photograph the thumbnail for this video? Back lit, but legible IC markings.
Thanks for great content !!!
Glad you enjoy it!
I'm sure the FCC appreciates your removal of the emf shield.
I don't know about the FCC, but those chips in there sure do! 😃 Jokes aside, I need to learn more about it (and maybe make a video). Has the FCC relaxed their regulations since then? What exactly is affected by something like this and how far does it extend? Because I'm not getting any solid information when I try to find out more about this.
@@NoelsRetroLab The clock speed of 1MHz means that traces in the computer will pulse at less than 1MHz. This the frequency range of medium wave radio, therefore bad EMF shielding will cause noise on AM radios. The 17 MHz of the crystal (and VIC) may interfere with short wave radio. These shields were mandatory in order to avoid that you get angry neighbours whose radio listening experience is hurt, by using your computer.
Nowadays we use AM radio a lot less, however, shielding devices from emitting radio is still considered good engineering practise.
Nice video, keep it up, thanks :)
Even if a diagnostics cart for a system does not need the system's ROMs. A faulty system ROM can still corrupt the data bus. A faulty IC may not respect its chip select signal and hence corrupt the bus.
Replace the RF 4-pin choke too. They are still made.
Did you try the old ROM again? Perhaps it just needed a re-seat and some de-oxide.
I just repaired a C64 with a bad Kernal ROM! Shame the original ROMs aren't widely available.
Does this mean that the C64 diagnostic cartridge somehow replaces the kernal ROM in the memory map?
It could. "Normal" C64 carts work similar to the way the VIC20 works, with the cartridges mapped at $8000 and the kernel looking for a signature at a specific address to jump into the cartridge (sidenote: You can do funny reset tricks by writing the standard signature to the RAM at that address when no cart is present). However, the 6510 has extra IO pins and, in conjunction with the PLA, supports actual bank switching. It's designed such that, if you tie the EXROM cart pin to high, the second 8k of ROM in the cart will get mapped to $E000-FFFF - replacing the kernel, including the reset vector.
I picked this up as a teen in the 80's when I modded my C64 to add a reset button and toggle switch on the cart port so that I could rip carts to floppies, as I couldn't afford an EPROM reader. :p
@@3vi1J Was there any way that a C64 cartridge could keep the ROM mapped so the code could still make calls to the kernal? I never owned a C64.
@@scottlarson1548 Absolutely. If you ground the EXROM cart pin, the second 8k of a 16k cart gets mapped to $A000 - replacing the BASIC ROM instead of the kernel ROM. This is how most 16k carts are configured. The first 8k always gets mapped to $8000. The exception is the carts for the Japanese MAX machines - they always tie EXROM high and map on top of the reset vector because the Commodore MAX had no built-in ROMs.
@@3vi1J So the cartridge could chose to keep the kernal ROM mapped or replace it depending on what it needed. What a great design!
@@scottlarson1548 This one was more luck than wisdom (due to the desire to make the C64 compatible with the Ultimax), but it is for sure one of the features that make the C64 so powerfull. It's not just that the cartridge can choose, but it can also change dynamically. Many advanced tricks such as hidden fastload cartridges and freezer cartridges are made possible by this and completely impossible on other 8-bit computers.
In general I'd say the C64 is still one of the most well designed computers ever.
It has some AMD chips? (Two chips on lower left corner of the board).
I didn't know they made 6116 SRAM either.
Yes, Commodore occasionally bought ROM and RAM chips from AMD.
I've seen bad ROMs keep a C64 from dead testing, too.
Interesting to see that it was assembled in Hong Kong and not China 🙂
You're going to need to get yourself a Coleco ADAM and look at all it's quirks
8:45 Why you use this chip tester?
Did a retro chip tester from Stephan's 8bit-museum can test a 6502 CPU's ?
Because it's the only chip tester that I have that tests the 6502. I love Stephan's tester but it can't do a large IC like this one.
Just curious, was the old ROM corrupted or just dead?
Good question. I didn't check but I suspect it's totally dead. If you think about it, it doesn't read that many bytes from the ROM before it jumps to the cartridge, so it would be surprising if it was just one of those few bytes (but I guess it's possible).
MOS Technology ROMs are real ROMs, the data is hard wired in a metal layer during manufacturing, which means there isn't really a lot of possibility for corruption; any corruption would be actual defects in the chip and this would be very close to a dead chip.
@@danielmantione Thanks. I was wondering if they were OTP EPROMs, but probably at the volume these were made, a mask layer for the data contents made sense.
@@GodmanchesterGoblin The costs of a mask layer were likely also lower for Commodore than for others, because of the vertical integration of the company: Engineers designing computers could just walk downstairs to talk to people manufacturing the chips in the fab. The overhead costs for producing masks must have been low.
It would be interesting to compare the contents of the bad ROM with a good one. I wonder if they are masked ROMs or if they are OTP EPROMS...? (OTP=One Time Programmable, in plastic because it's a lot cheaper than a ceramic windowed package). If the whole ROM is bad, then it has clearly had its day. But it's also possible that only some bits have become corrupted, and if it was OTP EPROM then they most likely would have gone from a 0 to a 1 (the initial erased state is always all ones). In such a case it might be possible to reprogram the chip with a correct version of its original data using a suitable EPROM programmer. Note that you can only program a 1 to a 0 in this kind of device, so the original data would be required (not an alternative version with some differences), and the corruption must be from a 0 to a 1, and not the other way round. (Just thinking out loud - hope it helps.)
I should look into that. As far as re-programming them, I have no hopes of being able to do that 😃 My EPROM programmer is limited in the kind of voltages it supplies, and these kind of EPROMs (if they're even an EPROM) usually require high voltages. I really think it's a masked ROM though since it's labeled as MOS (and they fail often).
@@NoelsRetroLab I think you're right; it's most likely to be a masked ROM. And yes, EPROM and OTP ROM of that period require specific programming voltages - up to 21 volts in some cases - and that tends to require more specialised programming hardware.
So even though you can bypass the ROM in the C64 (or can you? I honestly don't know how that works and after this video I'm wondering) I've seen C64 repairs where a bad ROM prevented the dead test from working. So you never know.
I need to check the details of the C64, but yes, you can definitely bypass it. It's normal procedure to remove all the ROM and then test it. I believe there's a signal FROM the cartridge that tells the system to use the ROM in the cartridge instead of the system one.
"clearly I haven't been in this before"
LMAO I BEG people to throw away the cardboard ones all the time. I'm not happy about the metal ones either, but I'm like that's on you. But the cardboard ones are harmful IMO.
kernAl?
I know, it looks like I'm horrible at spelling. Just going along with the way they're written in all the original documents. I blame some engineer with bad spelling back in the day 😃
20:20 Technically it's KERNEL not KERNAL
I do understand that Robert Russell MADE AN HONEST MISTAKE IN SPELLING in his
white-papers and then the program writers of the VIC-20 took it as gospel that the spelling was KERNAL (not knowing the spelling mistake that was made)
and in turn they just adopted the name into VIC 20
but at the end of the day , it is a mistake.
Carrying on a Mistake does not make it correct LOL
When i learned computers as a young lad it was KERNEL
Back in the days when we had M.C.P. (Master Control Program)
so yeah , Technically it's "KERNEL"
if it was me i'd be reprinting the label
*I
@@Okurka.
Oh... sorry.. Your'e correct
I'll make the change
EDIT : after making the change i found a few other mistakes as well.
changed them as well
thanks for the heads up.
@@martinkuliza *You're
@@Okurka. that doesn't sound right, i do know the difference between Your and You're
let me check
@@Okurka. i checked, that word doesn't even appear in my comment.
where did you see it ?
Psst... You spelt Kernel wrong on your label! 🤫😏
Your "music" is annoying as hell.
"Just burn" The github instructions state if burning one ROM image burn to $E000 (for a 512 EPROM or EEPROM). Is that what you did here? @NoelsRetroLab