VIC20 Penultimate+ Cartridge. Since The Future Was 8 bit took over production of these, many hundreds of them have been sold. With those, we've only had a couple of problems, which usually turn out to be the VIC20 itself being faulty, so it would be useful if there was a way of testing the host VIC20's RAM. There is a VIC20 diagnostics cartridge that was produced by Commodore back in the day, but that was only really usable with a set of loopback plugs. If you didn't have those, it would fail on the first pass and just sit there flashing the screen showing 'Serial bus BAD'.
Dead Test. This would only test the system RAM, but would do that using as little system resources as possible, to cope with faulty RAM, ROM or character ROM etc. This made use of the Ultimax mode, which was designed for the Max machine which had no internal ROM, so everything had to run from the cartridge.
+ has now been added to the Utilities menu on the VIC20 Penultimate+ Cartridge, and should be present in all cartridges shipped from December 2018 onward.
+ by holding down the reset button on the VIC20 Penultimate+ Cartridge for more than ten seconds on power on - the reset button is the one on the right for those of you playing along at home.
+ program.The get back to the normal menu, just press the reset button for less than ten seconds. The VIC20 Penultimate+ Cartridge is available now from The Future Was 8 bit. Use discount code WHONEEDSSPRITES as a reward for reading this far and not just looking at the pictures.
Ooh, have we got a video?Yes, we've got a video.
Small caveat about limiting use of zero page and stack memory.The first 1K of Block 0 is the internal RAM of the VIC20, which we need to test. It is also the zero page (0x0000-0x00FF) for which the 6502 processor has some shorter (and therefore faster) op codes, so I couldn't use those. It also contains the first page (0x0100-0x01FF) which is used for the stack, so I couldn't use the stack. That means no subroutines, JSR instructions usually take parameters off the stack, and push a return address there to go back to on an RTS instruction, so I was stuck with pretty linear code with no subroutines. That turned out to be less of an issue as there was enough space to 'unroll' all the code and simply repeat subroutines where they were required (using preprocessor directives to avoid actually creating multiple duplicates in the source code).
That was all working fine until I checked the VIC20 Kernal Source, the first thing it does is check for a cartridge being present. Unfortunately, to do that, it jumps to a subroutine a few bytes away to check and then jumps back, so this will need those few bytes of ROM to be working as well as some of the 1st page of RAM. Not ideal, but the best we can do without replacing the KERNAL ROM.