The products and services mentioned within are no longer available.
Sometimes when I am asked to do a job, I get a little carried away and 'over deliver'. That may have happened this time.
I was asked if I could add a little memory tester to the 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'.
Looking to the Commodore 64, there are two common diagnostic utilities, the C64 Diagnostics, which suffered the same issues as the VIC20 with the need for loopbacks, but did keep cycling even if a problem was found.
The other option for the Commodore 64 was the 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.
My plan was to aim for something more like the C64 Dead Test, as it would used to test systems that may well have faulty RAM or ROMs etc. so would need to use as little of those as possible to cope with then being faulty. To that end, I set about writing this in assembler, and tried to work without using any of the VIC20s RAM, relying only on the RAM within the Penultimate Cartridge, which would have been tested during production of the cartridge. That limited me to assembly language, with no subroutines, and no use of the shorter, faster zero page addressing modes (with a small caveat - more details at the end of the post when most people will have stopped reading).
I started with the same sort of layout I had used on the original Penultimate Cartridge menu, rewritten to account for the limitations outlined above. That seemed to be working, so time to add some tests. I started at the start of RAM. The first 1K is provided by two 2114 SRAM chips, this is shown as 'RAM 0'. There is then a 3K gap (which can be filled with expansion RAM from the cartridge port). I'm not testing that here, as that is not part of the VIC20.
The final 4K of block 0 is provided by eight 2114 SRAM chips on the original (2 pin power) VIC20. The later VIC20-CR uses two 6116 RAM chips. This is shown in four 1K chunks, RAM 4,5,6 and 7. RAM 4 is used as the screen RAM, so that is tested differently, each character on the screen is first backed up, then tested by writing and reading values as you would normally do, then returned to it's original value. You can follow the cursor as it runs over the screen, which is preserved during the process.
The last block of memory is the colour RAM. This is tested in a similar way, one character at a time. This block of memory is only 4 bits wide, a single 2114 RAM chip. The results of the other blocks have included eight green ticks for bits that have passed, or red crosses for bits that have failed. From that you should be able to narrow any failures down to a single chip on either type of machine.
On the colour RAM, the lower 4 bits are shown as dashes as they are not implemented in hardware. The chevron indicates the block currently being tested, four for each 1K of RAM, 256 bytes at a time (which is quite handy on an 8 bit system). The dots indicate blocks as yet untested. Here are some screenshots from real hardware with RAM faults (or chips missing to simulate these).
A fault in the right hand 6116 shows up as errors in blocks 6 and 7.
That's if the whole chip is bad, but it will also detect smaller errors, down to a single bit, here simulated by bending up the leg of D6, so bit 6 will fail over the enter range of that chip.
The other bits pass, as they are connected, but the results of bit 6 will be wrong so that bit fails and the whole chip is marked as fail.
A fault in the left hand 6116 would be in blocks 4 and 5, which includes the video RAM, so the display will not be readable - the VIC chip is limited to using RAM inside the VIC20 for screen and colour RAM. I would have liked to map those to external RAM to avoid using the internal RAM, but that's not possible. however, the errors show up in red if the colour RAM is working, so that should point the finger at that particular chip.
A fault with the colour RAM likewise makes it difficult to read the screen, but again with knowledge of what the screen should show, you can see where the fault lies.
That's all the RAM tested, but lets also test the ROM chips. The C64 Dead Test doesn't do that, but I think it would be useful thing to add, hence Dead Test+.
The character ROM, BASIC ROM and KERNAL ROM are all checksummed and compared against a list of known 16 bit checksums for the common VIC20 ROMs. The results are shown, alongside a short description. A test is done on power up to check certain bytes in the KERNAL ROM to see if it is NTSC, and the video mode set accordingly. The spelling of 'colour' is adjusted so that it is spelled incorrectly differently if an NTSC ROM is present.
When all tests have completed, the VIC will play a short sound through each of it's three voices, then it will loop around again. A counter at the bottom of the screen shows a cycle count so you can use this for soak testing.
The VIC chip can display characters using the character ROM, or a font held in RAM. This alternates each cycle, so that if the character ROM is faulty, you should see a valid display when it switches to the RAM font.
You can also see the faulty ROM highlighted in red even if the character ROM is completely bad.
The VIC20 Dead Test+ 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.
Obviously, if the VIC20 is faulty, then it's quite likely you are not going to be able to navigate the menu system, so you can also run the VIC20 Dead Test+ 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.
This will bypass the menu and go straight into the Dead Test+ 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.
Identifying bad chip numbers
The following lookup table should point to the likely chips which generated the fails. The RAM on the original VIC20 is made up of eleven 2114 RAM chips, each providing 1K by 4 bits, so each block is made up of two chips. The VIC20-CR replaced eight of the 2114 RAM chips with two 6116 chips, so the chip numbers are shown for both the original the 2 pin VIC20 and the later VIC20-CR.
Block
VIC20 (2 pin)
VIC20-CR
0123
4567
0123
4567
RAM0
UD2
UE2
UD2
UE2
RAM4
UD3
UE3
U15
RAM5
UD4
UE4
RAM6
UD5
UE5
U14
RAM7
UD6
UE6
Colour RAM
UE1
-
UE1
-
Character ROM
UD7
UD7
BASIC ROM
UE11
UE11
KERNAL ROM
UE12
UE12
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.
