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.
I have been contacted a few times to fixes a particular fault on a Commodore 64. A fault that isn't a fault, but a 'feature' of the design.
The fault report usually goes along the lines of 'when I move the joystick, it also presses some keys'.
This can be seen if you plug a joystick into port 1 and wiggle it around, you will see a variety of keys pressed. Ignore the POKE 53281,0 - that is just to set the background colour to black. We have hit the limit of my photography skills, my camera just doesn't get on with the light blue on dark blue of the default colour scheme and merges them into one.
The phantom keypresses aren't actually a fault, they are caused by the joystick ports sharing the same pins used by the keyboard. Here you can see that part of the schematic in isolation.
The joystick ports are connected to the lower 5 bits of each of the 8 bit ports used to scan the keyboard. The joystick is just a series of switches connecting the up / down / left / right / fire lines to ground, and this is read by making those ports both into inputs and activating internal pullup resistors in the 6256 Complex Input Adapter. Any inputs which read 0 mean that lines from the joystick is active. The others read as 1 due to the pullups.
When the keyboard is read, the rows (port A of the CIA) are set as outputs, with each row pulled low in turn. The columns (port B of the CIA) are read in, any that are low indicate a key on the currently scanning row is held down. If there is a joystick in use in controller port 1, that can cause false readings as that also make one or more of those rows low when the joystick is moved or fire is pressed, giving the false readings above.
That's normally as much as needs to be said as that explains the extra characters on the screen. However, one repair request came in recently which initially looked like this, but proved to be a little more complicated. What was happening here was keys were stopping working after the joystick had been moved, and were staying disabled until the power was cycled.
Here I have typed 1234567890 several times, and after moving the joystick down, you can see that 3 and 4 stop registering. The keys W, A, shift, Z, S, and E also stoped, you can see from the matrix that these are all on the same row.
Those keys remain unresponsive, and when the joystick is moved left, more keys go, this time 7 and 8 (and also Y, G, V, B, H and U).
Again, a full row, and the row that corresponds to the pin on the controller port 1 pin that would have been pulled low by the joystick.
I know the joystick is fine, but I tested in anyway, and also tried several other joysticks including my 'joystick emulators', and the same effect was observed.
There was only one likely culprit here, U1, the 6526 CIA that connects to the keyboard and both controller ports.
The chip was soldered in, so just to make sure, I did try the Commodore 64 Diagnostics with loopback connectors. That initially confused things by saying that both CIAs were at fault, but detected that on the user port test.
That, however, turned out to be down to a bad connection on the edge connector, so I gave that a good clean and got it nice and shinny.
With the cleaned, it passed all tests, and did not detect the keyboard fault, I presume it was testing in the default state after power on when it works, rather than after the inputs had latched up (if that is what had happened).
I still thought the keyboard CIA was faulty, so I replaced it, the ran the diagnostics again to check everything was still OK. That passed OK, and back in BASIC, the fault was gone, no keys were being blocked after moving the controller in port 2.
I suspect that fault could have been caused by swapping the joystick ports when powered, or by static getting to the pins on the port from a carpet. I don't know for sure, just be careful with your controller ports.
If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.
The products and services mentioned within are no longer available.
I have been making VIC20 diagnostics cartridges and test harnesses for a while, and I have decided to change things up a bit, and offer these as a kit.
The test harness is a series of loopback plugs which plug into the VIC20 ports.
A cartridge is then installed which runs Commdore's VIC20 diagnostic software.
The kit version of this requires you to assemble these from the parts provided.
Accompanying the harness is a choice of cartridges. There is a dedicate diagnostics cartridge.
The kit for this comes with a pre-programmed ROM.
The other choice is a ROM/RAM board. This is a simple DIP switch controlled card that can provide 27K or 32K of RAM, or a selection of a few games to test out you VIC, along with the diagnostics ROM.
The kit comes with pre-programmed ROM and GAL.
These cartridges can be fitted into an original Commodore cartridge case.
The smaller board is held in place by the inverted T shaped pillars (which are sometimes removed in brown utility cartridges).
