Small note: when I mention the zero page (and stack) is the first (and second) 100 bytes of RAM, I wasn't clear in the video that it is the first $100 of RAM when counting in hexadecimal. It's actually 256 bytes when counting them up in in decimal. Also, I was chatting with Matt about where people can buy a cart with the ROM already installed. He is looking to work with vendors so people can buy it directly without having to build one. Please check Matt's website (in the description) for more info, which is where he'll put updates as he has them.
We've recently been learning, largely through Dave McMurtie's excellent research, that the Commodore Max was actually released shortly after the Commodore 64. The short version of the history is that Commodore created the VIC-II and SID chips but they didn't immediately have a use for them. An engineer in Japan began creating the Max using the VIC-II and SID, then the American team started making what became the Commodore 64, borrowing some ideas from the Max, but also pushing some ideas back to the Max. In the end the design influences went both ways: the C64 was released, then the Max only in Japan. So it's probably more correct to think of the Max as the C64's little brother, rather than a predecessor.
@@8_Bit Fascinating!! So I suppose the MAX is an earlier overall design but still came out after? I saw in your video you thought maybe 40k MAX machines were released. pretty interesting really. Little brother is definitely a good analogy though!
Hello Adrian. In he mid 80's I had a co-op job at our board of education doing chip level repairs on PET's, C64's and IBM PC's. I wrote assembler code that would run in the P?ET boot ROM area (always socketed) that did pattern testing for RAM. It used a LED isplay board from another tool we had for the C64 that had 8 LEDs that would be run from the user port. On a 32k PET it would light a LED for a stuck bit and beep once for bank 1 and twice for bank 2. I found out in the late nineties that this code was still being passed around! And man didd I hate re-aligning 1541 drives abused by coy protection software. The 22 Philips screws made of pot metal were always stripped to death by the time I got to them. Sounds like this new system has some secret sauce we had not thought of in my time repairing Commodore gear. Thank you for the video!
Great demonstration of Matt's new project, there's nobody better to put it through its paces. I also had a great time meeting Matt at VCFMW, and he surprised me with a disk and updated manual for his famous DesTerm program for Commodore 128. It was an honour to meet the man behind my beloved Super Snapshot's SnapTerm program that I've used in a few videos.
@@8_Bit yeah it's so funny, Matt was chatting to me and then I introduced him to the other Matt of RetroBits channel (who was next to me) They chatted a bit. Then later Matt of RetroBits came up to me and said he couldn't believe he was just casually talking to Matt Desmond!! Like you RetroBits Matt used to use DesTerm 128 back in the day as well. So he was blown away to have just met Desmond. Funny how VCF works that way right?????
Great video. Thanks for introducing Matt's cartridge to a wider audience. While watching this video I downloaded the files, burnt an EPROM, put it into a Bwack Versa64 cartridge PCB and am now running it on my SX64! I love Matt's documentation as well, very detailed.
Late 80's I worked for a shop that had a cartridge with a 4x4 LED matrix to tell what chips were bad. Hardly needed anything on the board. CPU and I forget which chip provided the clock.
I have watched this video last night, after I had prepared to sleep and got so excited about it, that I had to get up again and start to solder a versa64cart to try this software at 11:30pm. This is probably the hottest new C64 development, that I have seen in a long time. I totally like the idea with the screen memory being in ROM. Wow.
There are a lot of clever people out there still writing diagnostic software for these computers. Thanks Adrian for showing them off and using them to fix vintage computers.
When I get the chance to have a ROM chip and a ROM Programmer, I'll test it on my Commodore 64 to see exactly what my problem is. Thank you so much for sharing this!
You could have some logic (GAL) on the cartridge that boots in MAX mode but can be switched in software to any other addressing mode. This logic could also test the PLA cartridge IO & ROM chip selects & cartridge mode select lines. No software currently tests this cartridge slot functionality. It would also be easy to add an LCD interface and a small SRAM for known good RAM for the test software to use. Or you could even add a 6502 CPU and have the card boot as a DMA device and take over the C64 bus, interrogate it externally and if it tests ok, then boot to MAX mode etc...
Good idea, but it could be done with even simpler logic. Just something that reacts om the decoded I/O address range signals, that in turn switches _EXROM on/off, would switch over to regular C64 mode. The tricky thing is that the ROM moves from E000-FFFF to A000-BFFF when this happens, so you would need to copy the code that does the switching over to RAM and have it jump back to rom. Or you could have an additional EPROM mapped to _ROML as that resides at $8000-$9FFF both in regular C64 mode and in MAX mode. Or the code that does the switching could reside in a place in EPROM that when the switch is done continues executing the stock KERNAL at a place where it jumps to some place in what KERNAL thinks is BASIC, which in fact would be the _ROMH EPROM (i.e. the one always used by MAX carts). An override switch disabling this feature would be a good idea to be able to run the test even on C64s that malfunctions severely.
@@Thesecret101-te1lm I was originally thinking to use an Atmel micro (use the serial port to send debug/test commands) but a proper NMOS 6502 would probably be a better bus load/drive test.
@@Gameboygenius The "max" signal (_GAME low and _EXROM high) can be flipped at any time (I assume that you probably want to synchronize flipping it with the CPU clock as I would assume that the PLA don't latch it internally, and flipping it in the middle of a cycle where the address decoding would differ depending on its state would probably create unpredictable results). This is how cartridges like the rhe Final Cartridge, Action Replay, Super Snapshot and whatnot could do their thing when "freezing" the computer and jumping into the carts menu system, offering for example saving a snapshot of the current state and/or examining memory content with a machine language monitor and so on, and then being able to jump back to the running program which in most cases would work fine afterwards unless there were some sneaky "cartridge detection" code (as a copy protection measure). I also think you can toggle the other combinations at any time too (I.E. _EXROM low and _GAME high to have an 8k ROM at address 8000, or both low to have two 8k ROMs at 8000 and A000, or both high to have the stock configuration).
I sure wish I had the equipment to build that ROM chip, and push button. I used to have the equipment, but when I had Cancer, I had to sell all my things to pay for charges accrued. Hopefully I can get one of those soon.
Way cool! I wrote a EPROM-hosted RAM test for the Osborne 1. Had to pull the BIOS ROM and insert the RAM test. It executed entirely inside the CPU with no need for a stack. Bad 4164s were a thing back in the day.
Awesome video, thanks Adrian! I have ordered a new cart with this on the ROM to use on my black screen C64. Though I think it might be a multiplexor, which might mean I still won't see anything according to your comment about the Vic needing working multiplexors.
Wow! Matt Desmond... now *that's* a name I haven't heard in a long time! I was a faithful user of DesTerm 128 for many years. Glad to see he's back in the community, and again developing some awesome tools!
That colour scheme is fine for most of us, but I hope there’s enough room in the ROM to implement a colourblind mode too! Red/green is usually known as an issue for colourblind technicians (looking orange/brown for both), but blue and purple also look the same (just blue) in many types of colourblindness! Oh, just noticed the full list in the full mode :) that’s definitely usable regardless of colour vision! But of course that’s only once it can get that far in the test. F1 to implement an alternate palette on that first screen would still be worthwhile imo (tho, again, not sure if it’s feasible in the space!)
Idea for the cart. Add a switch on the pull down line that puts it in Max Mode. If the switch is closed, for max mode, it runs as it currently does. If you open the switch, it disables max mode, and allows it to check the Full range of RAM that aren't accessible in Max mode.
can't be done, because it runs from ROM, if you switch memory config at runtime you will bank ROM out, you would need second version of the cart running as typical C64 $8000 cart, not MAX
@@C64Lover I would assume that you'd need to turn the computer off to toggle the switch. if it needs a different ROM entirely, that could be done with the same switch, you should even put the "Other ROM" in a different memory location of the same EEPROM, and present it differently based on the state of the switch.
One idea I had is if you have an MCU of some kind on the cartridge, like a Pi Pico or something else, maybe it could monitor the address and data lines and determine what parts of the test are running and provide some kind of output via serial over USB or something. Maybe even use an integrated web server in the Pi Pico to provide a virtual screen of some kind. It's probably pie in the sky stuff but it should be theoretically possible.
I was going to suggest something similar. I've always wondered if it was possible to use something like a Pi Pico or RPI2040 as a diagnostic device for a C64. In this case it could switch between diagnostic ROM code for MAX mode and c64 mode, but make it so it outputs diagnostic data to one of those I2C displays too. Additionally, if it's possible, implement an REU into it so the device itself could DMA access the 64's (and if possible the 128... pretty please? :) ) memory to do advanced diagnostics. Theoretically the RPI could manipulate the data the VIC is seeing in MAX mode so it could also update what's being seen on the 64's display instead of having to rely on changing the border to indicate what bit is bad.
I had one thought about the new ROM. If the system has to get out of MAX mode to test the full amount of RAM one option would be to add a flip flop to the board that controls the line that puts it in to MAX mode. It should default to MAX mode on power on and/or reset. A write to the ROM space would toggle the flip flop to take it out of MAX mode. Writing to ROM a second time could put it back in to MAX mode.
I'm a bit embarrassed that this is the first time I've heard of the Commodore Max. Adrian - what happens to many of your fixed 64s? Do they get to go live in the country on a farm to play with the other fixed computers?
If someone didn't already know what the zero-page and stack page were, he (or she) might be confused by the references to the first and second "hundred" bytes of memory. They are, of course, 256 bytes each, or 100 in hexadecimal. I don't think I've ever hear someone just say "hundred" before when they meant that. But I think most viewers of this channel know what they are anyway.
For the next generation, a ROM cart that has a display on it. Even without write access it could be done by a microcontroller and reading certain addresses in the ROM space would update the display.
Of course! Then again, you might consider this an opportunity: you could buy this, too, and upload a review comparing and contrasting their features and limitations....
@@Blood-PawWerewolf I don't know for a certainty, but given its flexibility in use, I'd be surprised if a working solution couldn't be created. I have no experience with this ROM, but I'm planning to get one now that I know about it.
What tools did microcomputer techs have back in the 1980s and '90s? I suspect that a lot of the ones Adrian uses were either not around or unaffordable for most shops, and, of course, there was no Internet yet.
@@mar4kl Actually, we had a lot of the same or similar cartridges including the one that shows a lot of tests on screen and the octopus dongle one. We also had one I have not seen here for black screen boot that had LEDs that showed probable issues. But the one in this video is indeed cool.
@@mar4kl you also have to remember the marketplace, (it's possible I'm mostly remembering PC clones), -but one had to weigh the benefits of "fixing" vs providing new parts, and balancing that with keeping labor lower than the price of a new part or whole new computer. Commodore itself (maybe mostly thanks to Tramiel?), would judge some repairs not worth it the possibility of selling whole new C64 or eventually, upgrading to a C128. Competition was cut-throat, and store/repair places that sold multiple computers would also want to move those rather than repair. A lot of what Adrian is doing here was simply judged more trouble than worth the tech's time (more specifically their pay per hour!) including diagnosis of certain problems. So A LOT was not around for techs to use, and "unaffordable" in a larger sense, not just absolute "too expensive" way. RPrice_OG apparently had a different experience specifically with cartridges, so, maybe that was earlier than mine.
Theoretically it should be possible to make a diagnostic cartridge that can start in MAX mode on reset but put itself into 64K mode to test the remainder of RAM and the ROMs. You'll need the equivalent of two inverters and an SR flip flop, with Q going to /GAME and !Q going to /EXROM, R input connected to inverted /RESET, and the S input connected to inverted /ROML. May be able to optimize that down to the gates available on a single TTL chip. When the C64 is turned on or reset, /RESET goes low, is inverted and resets the flip flop. This sets Q=/GAME=0 and !Q=/EXROM=1 so it's in MAX mode and can run dead tests. Once the dead test passes, it runs code in RAM that does a read to $8000. This pulls /ROML low in MAX mode, which is inverted to set the flip flop. Now Q=/GAME=1 and !Q=/EXROM=0, so we're out of MAX mode with the ROM connected to /ROML still visible. It should be possible to use the same ROM for $8000 and $E000 by ANDing /ROML and /ROMH together, so the ROM /OE is low if either is low. After all, MAX mode has the reset vector at the end of ROM, and normal mode looks for vectors and the CBM80 signature at the start. Plenty of room for the dead and full tests to not overlap, and a switch that grounds /EXROM would bypass MAX mode on reset, with the diagnostic ROM still visible at $8000 like a normal cartridge.
My cousin traded me some stereo equipment for his old Vic 20 after he was finished high school. He walked me through connection to the TV and startup. It showed the Commodore screen then boot screen then stayed stuck in "reboot" something like that. That's all it would do.
When you talked about the VIC II having to use the C64s 64k of RAM because it doesn't have any, I was wondering if what you are describing is like how the C128 in 40 column mode uses the VIC II for video output but in 80 column the C128 uses a 2nd video chip called the VDC that early C128s had 16k of RAM for it and in later ones and the C128DCR the VDC had 64k of video RAM.
If you are counting cycles anyway, you should be able to display dynamic text from ROM, by changing the screen pointer during an HBLANK. I guess that only let's you change one line at a time, but... I guess you could change the pointer on non aligned rows for a neat effect too...
I suppose the ultimate would be to remove the 6502 and insert an embedded Rasp Pi which can emulate a 6502 or directly access the entire bus and analyse the signals even without an external clock and with a poor / noisy power rail.
The 6510 is normally not socketed, therefore you would need to do desoldering before you could do diagnosis. A cartridge is the desired method. However, the C64 does allow a cartridge to replace the CPU, so an emulated CPU is a possibility.
With a bit of logic would it be possible to toggle the MAX line once the 4K only tests are done to flip the C64 back to normal mode and carry on testing all the RAM? Since the 6502 has no IO port space it'd need to have a sequence of writes to avoid false triggering the change back to normal mode during RAM tests, but still doable.
While the 6526 VIA running hot is a good indicator of it being bad, the other tests you did don't seem to me to be conclusive. If there was supposed to be a pull-up resistor on that pin but it was disconnected or intermittent, and the VIA was never designed to pull the pin to +5V but instead used open-collector mode, then you'd get exactly the same symptoms. I'd think that a quick fix would be to install a 10K resistor between the pin and +5V. That would bypass any problems with the PCB or pull-up resistor.
I can see that Desmond's C64 RAM test was somehow inspired by Noel's Llopis Amstrad Diagnostics, at least on the graphical RAM test, which is great as it has proven to be a very useful tool 😊
@@jasejj Indeed! I forgot about D.Smiths/B.Alford ZX Diagnostics that show any bad low ram bit using the border 😊. Kudos to all who make this possible. We are lucky to have those tests nowadays, they are really helpful.
@@8_Bit thank you.. ah! I already know the product… in Italy costs around 35 dollars for the 2ml tube… (not a joke… really :) ) more or less 17.500 dollars per liter 🤣🤣🤣😅😅😅
@@ytdemori DeoxIT is fairly expensive here in Canada too, but not that bad! Instead I use MG Chemicals 404B which is made in Canada and very cost-effective.
@@8_Bitthank you for this suggestion.. but seem that this product is not available in Europe for some reason... If I understand correctly contains some chemicals that are forbidden in Europe (I'm not sure... I found this product only on two sites on Europe both have a note that explain that is available only for USA)
Does this work with the C128? I have a 128D with the dreaded black screen, and as you point out in your video, all I get from the dead test cart is a more-or-less randomly blinking white screen that doesn't tell me much.
Such a cartridge will run on the C128, however is useless to do any diagnosis, because on the C128, the Z80 proceessor starts first. Therefore if the computer has bad RAM, the Z80 will for sure crash and the compute will never start the Dead Test. For the C128, you need the "Kinzi C128 Dead Test" ROM. This works by unplugging the C128 KERNAL ROM and repacing it with the Kinzi C128 Dead Test ROM.
Is it not possible for a cartridge to switch the computer in and out of Max Machine mode? I think that's what the fancy Lt. Kernal hard drive used to do. But it had a lead that clipped on to a point inside the computer, so maybe it can't be done through just the cartridge slot pins. (I used to know, but don't remember.)
Because of how it started working sometimes when you were banging it around, it seems like the 6502 just had a bad solder joint, the chip itself might be good. Maybe put it in the socket and see what happens
Very interesting! Can Matt add support for reading the ROMs? Since all official versions are dumped the crc32 is known so they could be read to identify a bad rom where a C64 has soldered-in ROMs.
It's only possible if he adds hardware to the cartridge that allows exiting Ultimax mode. Ultimax mode makes all ROMs inaccessible. That's also why both a Dead Test and Diagnostics cartridge was needed.
Maybe you can send him some "known bad" chips so that he can try them on his board, and make adjustments to the firmware that detect these defects, and reports them properly
That looks great but it seems to me a custom cartridge with a tiny bit of hardware on it say 2-4 digits 7 segment display sat in address space and you could pretty much get down to needing just a CPU (+ perhaps PLA) to be able to run. Early stage error codes of missing broken VIC could be on that display as fault codes
oh wow... I didn't know about the max mode... I wondered how the deadtest rom might work, but I never looked it up... And I call my self a collector... I'm ashamed...
Could you change the address lines on the CPU to address other 4k ram areas, if the CPU was socketed using socket with dip switches please on top. I hope you get the idea.
I thought zero page was the first 256 bytes of RAM and the stack was the second 256 byte section, not the first and second 100 byte sections as you seem to say in this video. The stack starts at $0100 hex so maybe that was the confusion? Anyway, it always impresses me how these new things are still being developed for the good old C64 (and other retro systems too).
I thought the black and white flashing of the old dead test was to catch even issues with the video chip. Like even half broken, you might still get the flashes. Would that make the old dead test superior in this very specific failure mode? What would the new diagnostic rom do with such a half broken video chip?
28:54 you said it "makes it works". If I was sitting there, I would see a scrambled display and not conclude it works. I would have missed some clue totally. Where am I going wrong here? What on the screen told you it was working when it was still all glitched looking?
I wonder if it would be possible to switch out of max mode at runtime? I've seen people replace the PLA with ROMs, and while that does have its problems, it says to me that the inputs aren't stateful. A cursory glance online says that the read/write signal is routed to the cartridge port, so it seems like that could be used to implement a rudimentary write to cartridge space to flip the right signals to switch out of max mode. Perhaps there is something beyond that that's stateful that means it isn't possible, but I'd definitely be curious to see if it could work
@@8_Bit good to know! Of course it would need some logic, but hopefully that could be minimal. Ignore addresses entirely, and just check for cartridge selection and the write signal being both "true" and then just clock a d flip flop or something, with the inverted output piped back into the input.
C64 can swap all its memory banks with both ROM and RAM on a cartridge, and if I remember correctly, there is already both the system ROM + BASIC ROM with additionally 64k of RAM "parallel" in the C64, amounting to more than 64k total memory! The cartridge thus do not need any working memory on the motherboard to work, because it simple swaps it out with its own memory. How it is able to read / test the swapped out memory banks is beyond my understanding, though…
Too bad you don't have Swift-link,or the CMD SwiftLink re-release or the CMD Turbo232 or a homebrew. Adrian, you must get at least one of these!!! The DesTestMAX-SL "Swift-Loader" uses the SwiftLink-232 (or compatible) cartridge for a remote terminal to display (and possibly buffer) all fault information rather than attempt to store and display it locally.. There's also newer plans/homebrew versions of Swiftlink. Whereas the original Swiftlink claimed all 256 locations in the IO memory map of the C64/C128, upgrades like "Retro Link232" reduces that to 16 locations and allows the user to select which 16 byte “bank” will be used. I'm curious if his might, or might not?, help allow March U test on memory above 4k
Has anyone considered adding LEDs for +5V and maybe even the clock and /RESET signals? I know that adds components and a bit of complexity but might also give a quick insight into some major signals
Currently I have three km 64 is that don't work after they all work at 1:49. But all of them show some Behavior like proper color screen for the boot up like these SX 64 so it looks like I need one of these cartridges
Small note: when I mention the zero page (and stack) is the first (and second) 100 bytes of RAM, I wasn't clear in the video that it is the first $100 of RAM when counting in hexadecimal. It's actually 256 bytes when counting them up in in decimal.
Also, I was chatting with Matt about where people can buy a cart with the ROM already installed. He is looking to work with vendors so people can buy it directly without having to build one. Please check Matt's website (in the description) for more info, which is where he'll put updates as he has them.
I was going to comment about your page size mistake.
@@danman32mission accomplished
Can you tell us what the silkscreen is on the cart Matt is using for the cart he gave you? His documentation doesn't give any specfic recommendations.
Not me, shouting at my screen, it's 256 Adrian! 😅😅😅
Very cool video btw. Keep up the good work. 🤘
@adriansdigitalbasement I figured you meant 100 hex though.
Matt Desmond's software was the stuff of legends, great to see he's still creating stuff for Commodores today!
We've recently been learning, largely through Dave McMurtie's excellent research, that the Commodore Max was actually released shortly after the Commodore 64. The short version of the history is that Commodore created the VIC-II and SID chips but they didn't immediately have a use for them. An engineer in Japan began creating the Max using the VIC-II and SID, then the American team started making what became the Commodore 64, borrowing some ideas from the Max, but also pushing some ideas back to the Max. In the end the design influences went both ways: the C64 was released, then the Max only in Japan. So it's probably more correct to think of the Max as the C64's little brother, rather than a predecessor.
@@8_Bit Fascinating!! So I suppose the MAX is an earlier overall design but still came out after? I saw in your video you thought maybe 40k MAX machines were released. pretty interesting really. Little brother is definitely a good analogy though!
Lol. He's fixed so many C64s he can't find a broken one...
@@myleft9397 someone no one said ever. Except me. Kind of hilarious really!
@@adriansdigitalbasement do you know if it work with Kung Fu Flash?
@@cactuslist
Check it yourself. Use cartconv with the parameter "-t ulti"
Hello Adrian. In he mid 80's I had a co-op job at our board of education doing chip level repairs on PET's, C64's and IBM PC's. I wrote assembler code that would run in the P?ET boot ROM area (always socketed) that did pattern testing for RAM. It used a LED isplay board from another tool we had for the C64 that had 8 LEDs that would be run from the user port. On a 32k PET it would light a LED for a stuck bit and beep once for bank 1 and twice for bank 2. I found out in the late nineties that this code was still being passed around!
And man didd I hate re-aligning 1541 drives abused by coy protection software. The 22 Philips screws made of pot metal were always stripped to death by the time I got to them.
Sounds like this new system has some secret sauce we had not thought of in my time repairing Commodore gear. Thank you for the video!
I have zero interest in C64 but still watch every video because I just enjoy you fixing them.
Same here. The process is fun to watch. Also, SID chip tunes are pretty sick.
Same here
Great demonstration of Matt's new project, there's nobody better to put it through its paces. I also had a great time meeting Matt at VCFMW, and he surprised me with a disk and updated manual for his famous DesTerm program for Commodore 128. It was an honour to meet the man behind my beloved Super Snapshot's SnapTerm program that I've used in a few videos.
@@8_Bit yeah it's so funny, Matt was chatting to me and then I introduced him to the other Matt of RetroBits channel (who was next to me) They chatted a bit. Then later Matt of RetroBits came up to me and said he couldn't believe he was just casually talking to Matt Desmond!! Like you RetroBits Matt used to use DesTerm 128 back in the day as well. So he was blown away to have just met Desmond. Funny how VCF works that way right?????
Looking for info if DesTestMax will work in KungFuFlash?
Great video. Thanks for introducing Matt's cartridge to a wider audience. While watching this video I downloaded the files, burnt an EPROM, put it into a Bwack Versa64 cartridge PCB and am now running it on my SX64! I love Matt's documentation as well, very detailed.
@@michaelcarey awesome!
Thanks for your content and your kindness.
I appreciate the super thanks!! Thank you very much!
Late 80's I worked for a shop that had a cartridge with a 4x4 LED matrix to tell what chips were bad. Hardly needed anything on the board. CPU and I forget which chip provided the clock.
Drinking game - take a shot whenever Adrian says "ROM" whomever lives the longest wins.
Still going.
I have watched this video last night, after I had prepared to sleep and got so excited about it, that I had to get up again and start to solder a versa64cart to try this software at 11:30pm. This is probably the hottest new C64 development, that I have seen in a long time. I totally like the idea with the screen memory being in ROM. Wow.
Every C64-video day is going to be a good day!
There are a lot of clever people out there still writing diagnostic software for these computers.
Thanks Adrian for showing them off and using them to fix vintage computers.
When I get the chance to have a ROM chip and a ROM Programmer, I'll test it on my Commodore 64 to see exactly what my problem is. Thank you so much for sharing this!
You could have some logic (GAL) on the cartridge that boots in MAX mode but can be switched in software to any other addressing mode.
This logic could also test the PLA cartridge IO & ROM chip selects & cartridge mode select lines. No software currently tests this cartridge slot functionality.
It would also be easy to add an LCD interface and a small SRAM for known good RAM for the test software to use.
Or you could even add a 6502 CPU and have the card boot as a DMA device and take over the C64 bus, interrogate it externally and if it tests ok, then boot to MAX mode etc...
Good idea, but it could be done with even simpler logic. Just something that reacts om the decoded I/O address range signals, that in turn switches _EXROM on/off, would switch over to regular C64 mode. The tricky thing is that the ROM moves from E000-FFFF to A000-BFFF when this happens, so you would need to copy the code that does the switching over to RAM and have it jump back to rom. Or you could have an additional EPROM mapped to _ROML as that resides at $8000-$9FFF both in regular C64 mode and in MAX mode. Or the code that does the switching could reside in a place in EPROM that when the switch is done continues executing the stock KERNAL at a place where it jumps to some place in what KERNAL thinks is BASIC, which in fact would be the _ROMH EPROM (i.e. the one always used by MAX carts).
An override switch disabling this feature would be a good idea to be able to run the test even on C64s that malfunctions severely.
@@Thesecret101-te1lm I was originally thinking to use an Atmel micro (use the serial port to send debug/test commands) but a proper NMOS 6502 would probably be a better bus load/drive test.
Is this possible while the system is running, or is the max signal latched on reset?
@@Gameboygenius The "max" signal (_GAME low and _EXROM high) can be flipped at any time (I assume that you probably want to synchronize flipping it with the CPU clock as I would assume that the PLA don't latch it internally, and flipping it in the middle of a cycle where the address decoding would differ depending on its state would probably create unpredictable results).
This is how cartridges like the rhe Final Cartridge, Action Replay, Super Snapshot and whatnot could do their thing when "freezing" the computer and jumping into the carts menu system, offering for example saving a snapshot of the current state and/or examining memory content with a machine language monitor and so on, and then being able to jump back to the running program which in most cases would work fine afterwards unless there were some sneaky "cartridge detection" code (as a copy protection measure).
I also think you can toggle the other combinations at any time too (I.E. _EXROM low and _GAME high to have an 8k ROM at address 8000, or both low to have two 8k ROMs at 8000 and A000, or both high to have the stock configuration).
A very interesting project for Commodore repair techs. Good work, both of you!
Great job. Love to see some old micro's still getting the love they deserve.
I sure wish I had the equipment to build that ROM chip, and push button. I used to have the equipment, but when I had Cancer, I had to sell all my things to pay for charges accrued. Hopefully I can get one of those soon.
Way cool! I wrote a EPROM-hosted RAM test for the Osborne 1. Had to pull the BIOS ROM and insert the RAM test. It executed entirely inside the CPU with no need for a stack. Bad 4164s were a thing back in the day.
Awesome video, thanks Adrian! I have ordered a new cart with this on the ROM to use on my black screen C64. Though I think it might be a multiplexor, which might mean I still won't see anything according to your comment about the Vic needing working multiplexors.
Very interesting. While I’ll almost certainly never own a C64, working or otherwise, I enjoy watching these videos.
Great information Adrian and sure appreciate the time and great video
Looks really good nice to see new products for the c64
Too cool to see this old marvel gets such lovely atte tion! Thanks for your video!
Wow! Matt Desmond... now *that's* a name I haven't heard in a long time! I was a faithful user of DesTerm 128 for many years. Glad to see he's back in the community, and again developing some awesome tools!
Same Matt Desmond that programmed Desterm128? Sign me up !
That colour scheme is fine for most of us, but I hope there’s enough room in the ROM to implement a colourblind mode too! Red/green is usually known as an issue for colourblind technicians (looking orange/brown for both), but blue and purple also look the same (just blue) in many types of colourblindness!
Oh, just noticed the full list in the full mode :) that’s definitely usable regardless of colour vision! But of course that’s only once it can get that far in the test. F1 to implement an alternate palette on that first screen would still be worthwhile imo (tho, again, not sure if it’s feasible in the space!)
Idea for the cart.
Add a switch on the pull down line that puts it in Max Mode.
If the switch is closed, for max mode, it runs as it currently does.
If you open the switch, it disables max mode, and allows it to check the Full range of RAM that aren't accessible in Max mode.
can't be done, because it runs from ROM, if you switch memory config at runtime you will bank ROM out, you would need second version of the cart running as typical C64 $8000 cart, not MAX
@@C64Lover I would assume that you'd need to turn the computer off to toggle the switch. if it needs a different ROM entirely, that could be done with the same switch, you should even put the "Other ROM" in a different memory location of the same EEPROM, and present it differently based on the state of the switch.
Certainly makes it easier to sort out bad RAM before delving into something else being a problem, clever little creation there... :)
Bummed I can’t make it to PRGE and see you this year. Have a good show.
One idea I had is if you have an MCU of some kind on the cartridge, like a Pi Pico or something else, maybe it could monitor the address and data lines and determine what parts of the test are running and provide some kind of output via serial over USB or something. Maybe even use an integrated web server in the Pi Pico to provide a virtual screen of some kind.
It's probably pie in the sky stuff but it should be theoretically possible.
I was going to suggest something similar. I've always wondered if it was possible to use something like a Pi Pico or RPI2040 as a diagnostic device for a C64. In this case it could switch between diagnostic ROM code for MAX mode and c64 mode, but make it so it outputs diagnostic data to one of those I2C displays too. Additionally, if it's possible, implement an REU into it so the device itself could DMA access the 64's (and if possible the 128... pretty please? :) ) memory to do advanced diagnostics.
Theoretically the RPI could manipulate the data the VIC is seeing in MAX mode so it could also update what's being seen on the 64's display instead of having to rely on changing the border to indicate what bit is bad.
We talked about me fixing one of these boards and having absolutely nothing happening...guess I know what I need to try now
I had one thought about the new ROM. If the system has to get out of MAX mode to test the full amount of RAM one option would be to add a flip flop to the board that controls the line that puts it in to MAX mode. It should default to MAX mode on power on and/or reset. A write to the ROM space would toggle the flip flop to take it out of MAX mode. Writing to ROM a second time could put it back in to MAX mode.
A commodore 64 video, yes !!! 🥳🎉🥳
Cooooool!
I'm a bit embarrassed that this is the first time I've heard of the Commodore Max.
Adrian - what happens to many of your fixed 64s? Do they get to go live in the country on a farm to play with the other fixed computers?
I might have heard of the Max from David Murray, but I certainly didn't know that the 64 has a Max mode.
If someone didn't already know what the zero-page and stack page were, he (or she) might be confused by the references to the first and second "hundred" bytes of memory. They are, of course, 256 bytes each, or 100 in hexadecimal. I don't think I've ever hear someone just say "hundred" before when they meant that. But I think most viewers of this channel know what they are anyway.
For the next generation, a ROM cart that has a display on it. Even without write access it could be done by a microcontroller and reading certain addresses in the ROM space would update the display.
Annnd of course this gets released AFTER I ordered a 4-in-1 diagnostic cartridge from Retro Rewind…
Of course! Then again, you might consider this an opportunity: you could buy this, too, and upload a review comparing and contrasting their features and limitations....
@@jamesarthurreed would it work on a flash cartridge?
@@Blood-PawWerewolf I don't know for a certainty, but given its flexibility in use, I'd be surprised if a working solution couldn't be created. I have no experience with this ROM, but I'm planning to get one now that I know about it.
Awesome! -Mark,
Awesome ROM and awesome video!
Boy, I wish I had that 30+ years ago when I was a Commodore tech.
What tools did microcomputer techs have back in the 1980s and '90s? I suspect that a lot of the ones Adrian uses were either not around or unaffordable for most shops, and, of course, there was no Internet yet.
@@mar4kl Actually, we had a lot of the same or similar cartridges including the one that shows a lot of tests on screen and the octopus dongle one. We also had one I have not seen here for black screen boot that had LEDs that showed probable issues. But the one in this video is indeed cool.
@@mar4kl you also have to remember the marketplace, (it's possible I'm mostly remembering PC clones), -but one had to weigh the benefits of "fixing" vs providing new parts, and balancing that with keeping labor lower than the price of a new part or whole new computer. Commodore itself (maybe mostly thanks to Tramiel?), would judge some repairs not worth it the possibility of selling whole new C64 or eventually, upgrading to a C128. Competition was cut-throat, and store/repair places that sold multiple computers would also want to move those rather than repair. A lot of what Adrian is doing here was simply judged more trouble than worth the tech's time (more specifically their pay per hour!) including diagnosis of certain problems. So A LOT was not around for techs to use, and "unaffordable" in a larger sense, not just absolute "too expensive" way. RPrice_OG apparently had a different experience specifically with cartridges, so, maybe that was earlier than mine.
Amazing!
I was there on Sunday!!!
Theoretically it should be possible to make a diagnostic cartridge that can start in MAX mode on reset but put itself into 64K mode to test the remainder of RAM and the ROMs. You'll need the equivalent of two inverters and an SR flip flop, with Q going to /GAME and !Q going to /EXROM, R input connected to inverted /RESET, and the S input connected to inverted /ROML. May be able to optimize that down to the gates available on a single TTL chip.
When the C64 is turned on or reset, /RESET goes low, is inverted and resets the flip flop. This sets Q=/GAME=0 and !Q=/EXROM=1 so it's in MAX mode and can run dead tests. Once the dead test passes, it runs code in RAM that does a read to $8000. This pulls /ROML low in MAX mode, which is inverted to set the flip flop. Now Q=/GAME=1 and !Q=/EXROM=0, so we're out of MAX mode with the ROM connected to /ROML still visible. It should be possible to use the same ROM for $8000 and $E000 by ANDing /ROML and /ROMH together, so the ROM /OE is low if either is low. After all, MAX mode has the reset vector at the end of ROM, and normal mode looks for vectors and the CBM80 signature at the start. Plenty of room for the dead and full tests to not overlap, and a switch that grounds /EXROM would bypass MAX mode on reset, with the diagnostic ROM still visible at $8000 like a normal cartridge.
7:15 he meant 256 bytes. I feel for the new learners who don't know your "hundred bytes" is a "creative use" of decimalspeak to say hex $0100 🙂
Great video and thanks a bunch! Quick question, can I simply save the destestmax rom (converted as crt) on a easyflash card ?
My cousin traded me some stereo equipment for his old Vic 20 after he was finished high school. He walked me through connection to the TV and startup.
It showed the Commodore screen then boot screen then stayed stuck in "reboot" something like that.
That's all it would do.
When you talked about the VIC II having to use the C64s 64k of RAM because it doesn't have any, I was wondering if what you are describing is like how the C128 in 40 column mode uses the VIC II for video output but in 80 column the C128 uses a 2nd video chip called the VDC that early C128s had 16k of RAM for it and in later ones and the C128DCR the VDC had 64k of video RAM.
Adrian has fixed ALL the C-64s! No more videos! AAAAAAAAAAAAAAAAA!
If you are counting cycles anyway, you should be able to display dynamic text from ROM, by changing the screen pointer during an HBLANK. I guess that only let's you change one line at a time, but... I guess you could change the pointer on non aligned rows for a neat effect too...
I'd love to see a flippy cart that has the one side for Max mode for basic diag then C64 mode for full harness test.
Good morning, are there any similar test cartridges for the VIC20?
I suppose the ultimate would be to remove the 6502 and insert an embedded Rasp Pi which can emulate a 6502 or directly access the entire bus and analyse the signals even without an external clock and with a poor / noisy power rail.
The 6510 is normally not socketed, therefore you would need to do desoldering before you could do diagnosis. A cartridge is the desired method. However, the C64 does allow a cartridge to replace the CPU, so an emulated CPU is a possibility.
so where do I buy a DesTestMax full working cartridge.. ?
With a bit of logic would it be possible to toggle the MAX line once the 4K only tests are done to flip the C64 back to normal mode and carry on testing all the RAM? Since the 6502 has no IO port space it'd need to have a sequence of writes to avoid false triggering the change back to normal mode during RAM tests, but still doable.
Yes, that is possible.
While the 6526 VIA running hot is a good indicator of it being bad, the other tests you did don't seem to me to be conclusive. If there was supposed to be a pull-up resistor on that pin but it was disconnected or intermittent, and the VIA was never designed to pull the pin to +5V but instead used open-collector mode, then you'd get exactly the same symptoms. I'd think that a quick fix would be to install a 10K resistor between the pin and +5V. That would bypass any problems with the PCB or pull-up resistor.
Thank you! Any recommendations/links for a cartridge PCB so I can make one of these for myself?
Tres trop bien!!
I can see that Desmond's C64 RAM test was somehow inspired by Noel's Llopis Amstrad Diagnostics, at least on the graphical RAM test, which is great as it has proven to be a very useful tool 😊
And of course the Spectrum diagnostic ROM which IIRC was the inspiration for Noel's CPC ROM.
@@jasejj Indeed! I forgot about D.Smiths/B.Alford ZX Diagnostics that show any bad low ram bit using the border 😊.
Kudos to all who make this possible. We are lucky to have those tests nowadays, they are really helpful.
Awesome video! Just a question… What do you use to deoxidizing the socket? At first sight seem IPA.. or is some better chemical product?
The product is called Deoxit.
@@8_Bit thank you.. ah! I already know the product… in Italy costs around 35 dollars for the 2ml tube… (not a joke… really :) ) more or less 17.500 dollars per liter 🤣🤣🤣😅😅😅
@@ytdemori DeoxIT is fairly expensive here in Canada too, but not that bad! Instead I use MG Chemicals 404B which is made in Canada and very cost-effective.
@@8_Bitthank you for this suggestion.. but seem that this product is not available in Europe for some reason... If I understand correctly contains some chemicals that are forbidden in Europe (I'm not sure... I found this product only on two sites on Europe both have a note that explain that is available only for USA)
Does this work with the C128? I have a 128D with the dreaded black screen, and as you point out in your video, all I get from the dead test cart is a more-or-less randomly blinking white screen that doesn't tell me much.
prob RAM or multiplexers.
Such a cartridge will run on the C128, however is useless to do any diagnosis, because on the C128, the Z80 proceessor starts first. Therefore if the computer has bad RAM, the Z80 will for sure crash and the compute will never start the Dead Test. For the C128, you need the "Kinzi C128 Dead Test" ROM. This works by unplugging the C128 KERNAL ROM and repacing it with the Kinzi C128 Dead Test ROM.
Is it not possible for a cartridge to switch the computer in and out of Max Machine mode? I think that's what the fancy Lt. Kernal hard drive used to do. But it had a lead that clipped on to a point inside the computer, so maybe it can't be done through just the cartridge slot pins. (I used to know, but don't remember.)
Because of how it started working sometimes when you were banging it around, it seems like the 6502 just had a bad solder joint, the chip itself might be good. Maybe put it in the socket and see what happens
Very interesting! Can Matt add support for reading the ROMs? Since all official versions are dumped the crc32 is known so they could be read to identify a bad rom where a C64 has soldered-in ROMs.
It's only possible if he adds hardware to the cartridge that allows exiting Ultimax mode. Ultimax mode makes all ROMs inaccessible. That's also why both a Dead Test and Diagnostics cartridge was needed.
Maybe you can send him some "known bad" chips so that he can try them on his board, and make adjustments to the firmware that detect these defects, and reports them properly
That looks great but it seems to me a custom cartridge with a tiny bit of hardware on it say 2-4 digits 7 segment display sat in address space and you could pretty much get down to needing just a CPU (+ perhaps PLA) to be able to run. Early stage error codes of missing broken VIC could be on that display as fault codes
Excellent
How does the swiftlink version work? Do you need a cartridge port expander to plug in both the swiftlink card and the DesTestMax cartridge?
you can use a cart expander or replace the kernal ROM with a ROM holding the Max-SL image
oh wow... I didn't know about the max mode... I wondered how the deadtest rom might work, but I never looked it up... And I call my self a collector... I'm ashamed...
Could you change the address lines on the CPU to address other 4k ram areas, if the CPU was socketed using socket with dip switches please on top. I hope you get the idea.
I thought zero page was the first 256 bytes of RAM and the stack was the second 256 byte section, not the first and second 100 byte sections as you seem to say in this video. The stack starts at $0100 hex so maybe that was the confusion? Anyway, it always impresses me how these new things are still being developed for the good old C64 (and other retro systems too).
100 hex bytes is what Adrian meant.
@@8_Bit For sure.
I thought the black and white flashing of the old dead test was to catch even issues with the video chip. Like even half broken, you might still get the flashes. Would that make the old dead test superior in this very specific failure mode? What would the new diagnostic rom do with such a half broken video chip?
Would this rom run off of an easy flash cartridge
Yes.
Nice. Btw, it's Kernel, not Kernal, or Colonel. :-)
28:54 you said it "makes it works". If I was sitting there, I would see a scrambled display and not conclude it works. I would have missed some clue totally. Where am I going wrong here? What on the screen told you it was working when it was still all glitched looking?
19:52 A simple raster split between ROM screen memory and RAM screen memory would go a long way in providing feedback to users in such a situation.
Is it just me, or did TH-cam recommend me a video talking about the Commodore 64?
Would this be useful for C128. Even only a part of the memory
Neat!
| Awesome ! | :3
I wonder if it would be possible to switch out of max mode at runtime? I've seen people replace the PLA with ROMs, and while that does have its problems, it says to me that the inputs aren't stateful. A cursory glance online says that the read/write signal is routed to the cartridge port, so it seems like that could be used to implement a rudimentary write to cartridge space to flip the right signals to switch out of max mode. Perhaps there is something beyond that that's stateful that means it isn't possible, but I'd definitely be curious to see if it could work
It's possible but require a bit more logic on the cartridge. Super Snapshot and other cartridges dynamically switch Max mode in and out in this way.
@@8_Bit good to know! Of course it would need some logic, but hopefully that could be minimal. Ignore addresses entirely, and just check for cartridge selection and the write signal being both "true" and then just clock a d flip flop or something, with the inverted output piped back into the input.
What cart PCB do you have that ROM installed in?
23:34 why would banging on the board like that change it from working once the ROM was removed to not working? 30:28 don't you mean CIA not VIA?
Huh, I did not that about the short board and U2 either.
C64 can swap all its memory banks with both ROM and RAM on a cartridge, and if I remember correctly, there is already both the system ROM + BASIC ROM with additionally 64k of RAM "parallel" in the C64, amounting to more than 64k total memory!
The cartridge thus do not need any working memory on the motherboard to work, because it simple swaps it out with its own memory.
How it is able to read / test the swapped out memory banks is beyond my understanding, though…
You scare me every time you manipulate those chips without using an anti-static device!
If MAX mode is enabled by pulling a pin to ground, couldn't a simple switch be installed on the cart to switch between MAX and kernel modes?
Do you have a link to buy a Retro system?
Great 😊
Oh, come on! When are they going to get around to doing February testing?? 😆🤣😝 (yeah, I’m biased here, I was a February baby.)
Welp, now Matt has to develop an updated version of the cartridge that can test for a busted CIA chip as well. :D
Too bad you don't have Swift-link,or the CMD SwiftLink re-release or the CMD Turbo232 or a homebrew. Adrian, you must get at least one of these!!! The DesTestMAX-SL "Swift-Loader" uses the SwiftLink-232 (or compatible) cartridge for a remote terminal to display (and possibly buffer) all fault information rather than attempt to store and display it locally.. There's also newer plans/homebrew versions of Swiftlink. Whereas the original Swiftlink claimed all 256 locations in the IO memory map of the C64/C128, upgrades like "Retro Link232" reduces that to 16 locations and allows the user to select which 16 byte “bank” will be used. I'm curious if his might, or might not?, help allow March U test on memory above 4k
Has anyone considered adding LEDs for +5V and maybe even the clock and /RESET signals? I know that adds components and a bit of complexity but might also give a quick insight into some major signals
Or if you can't burn it to an Eprom, is anyone selling the cart? A quick Google, couldn't find anything apart from Matts site. Thanks.
Is it possible to run this diagnostic as cartridge on 1541U2+?
Currently I have three km 64 is that don't work after they all work at 1:49. But all of them show some Behavior like proper color screen for the boot up like these SX 64 so it looks like I need one of these cartridges
GREAT! Sooo how do I get this cartridge???
DIY by downloading the code from the link?
Did U checked supposedly bad 6526 in other board ?