Commodore VIC20 2pin PAL vs NTSC differences

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Previously on the Tynemouth Software Blog, I looked at converting a PAL VIC20 CR board into an NTSC one. This turned out to be a case of swapping a selection of parts with someone who had an NTSC VIC20 CR board and was interested in the reciprocal process.

We used the later cost reduced VIC20 boards as the process was a lot easier. They used the same PCB and it was just a case of playing 'spot the difference' and exchanging the parts.

The parts exchanged were a few passive components, a crystal, VIC chip and KERNAL ROM.

The original VIC20 board with the 2 pin power connector is a more difficult prospect as the PCBs are different between the PAL and NTSC versions. The NTSC version has a metal cage around the video circuitry, and within, the VIC chip and a separate compartment for the clock circuitry. This has the same 14.31818 MHz crystal as the later 2 pin NTSC board.

The PAL version has the outline marked, but no shielding can fitted. There are a few component differences, but most importantly though, it has an extra chip, UB10, outside of the box. This is a 74S74 / 74LS74 which is used to divide the clock frequency down. The M53202 chip looks to be a second source version of a 7402.

The crystal is 8.867236MHz, which is divided down to present 4.433618MHz to the VIC chip. The later 2 pin just used a 4.433618MHz crystal. Maybe they couldn't get those when they designed the 2 pin PAL boards? Or it could be they couldn't get it to work reliably. They did add several capacitors to the circuit on the later PAL boards. You can see the 74LS74 really does look like an afterthought on both the PCB and the schematic.

The other difference that wasn't immediately obvious is the 2 pin power connector is actually different between the PAL and NTSC models. The UK version has larger pins, and a divider between them (which makes it really easy to use a pair of crocodile chips to run from a bench power supply with no change of them shorting out).

The NTSC version is smaller and also has a built in switch, which isn't used. This is presumably a socket designed for a cassette recorder type device where the batteries would be cut off when the mains plug was inserted. Rather dangerous then to fit a socket used for a mains plug, particularly when some VIC20's were disturbingly labelled 117V AC on the bottom. What could possibly go wrong?

Both boards have a common mode choke on the input. On the NTSC board, there is a space on the PCB. On the PAL version, this is missing, and the choke has been used to connect the socket to the board as it is actually attached to the metal plate, not the PCB.

Here you can see where the wires of the choke are connected to the pads on the PCB that would have been used for the socket, and the spare pads for the switch which are not attached to anything, electrically or mechanically. The gold coloured sheet is present on the NTSC versions only and is grounded all around the base of the PCB for shielding.

The way this worked out is that I was sent a non-working NTSC board to repair (it turned out to be a faulty VIC chip, the most difficult part for me to replace), and asked if I could send a working PAL board back. The owner had a suitable 2 pin power supply, with the smaller connector, so I swapped them around, as you can see the socket fits perfectly on the PAL board, it just means there is no common mode choke in there (not much of a problem these days as the mains is horrendously noisy already with all the cheap switchmode phone charger power supplies plugged in).

I have ended up with the NTSC board (currently awaiting an NTSC VIC chip to complete it), and have attached the normal PAL power connector, complete with it's choke, so my board is now double choked. I did consider turning the socket around and bending the pins and soldering direct to the PCB, but went for the easier (and more easily reversible) option.

Custom VIC20 Kernal for Cartridge Testing

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

VIC20 cartridge production is now in full swing at The Future Was 8 Bit. With Cheese and Onion already released, and Spaceship Minus One available from today.

Testing these is an interesting challenge. The ROM chips are verified after programming, but it is important to test the final assembled units.

To test the Penultimate Cartridge, I wrote a test program which could be loaded from disk and would test the RAM and then cycle through all the ROM cartridge images and check they were all correct.

This works because when the VIC20 boots up, one of the first things it does is check for a bootable cartridge at address A000. If there is one, it runs it, so the Penultimate Cartridge menu is displayed.

All that needs to be done was to press F8 and the tester would be loaded from an attached SD2IEC drive.

Testing the Cheese and Onion cartridges is a little more complicated, as the game starts up as soon as the machine boots up, and runs the game. Yes, this is a test that it appears to work, and is a good start, but it would be better to get a checksum of the whole 32K of the game ROMs to be sure.

It didn't seem a good idea to modify the game code to add in a test feature, as that would need to be included and updated in all future releases. Another option was to modify the VIC20 hardware to swap around two of the ROM banks, to avoid the right ROM being present at A000 during boot, but that wasn't ideal as it meant cutting some tracks.

I have considered making a cartridge extended type thing, which plugs in and then has a slot to plug the test cartridge in, this would have some test code on it, and manipulate the ROM selectors on the test cartridge to check the ROMs. This might make an interesting project, but it probably a bit too much work.

A simpler option was to modify the kernal code, replacing a few instructions with NOPs, so it skipped the cartridge check on boot and when straight to the standard BASIC prompt. That was fairly easy to do in a hex editor, and burn a new kernal ROM for the VIC20. I used an adapter board, so it was possible to select the normal kernal ROM or the modified one.

On bootup, it then went straight to the ready prompt, and the test program could then be loaded and run. Couple of issues here. Firstly, it's a bit of a faff to have to type LOAD "cotester",8 and RUN each time. Secondly, even the cut down version of the Penultimate Cartridge tester was about 5K, so didn't fit in the unexpanded VIC20.

Briefly considering and rejecting using a multi cartridge setup with a 3K RAM expansion, or internally hacking in a 3K RAM upgrade, time for plan B. That involved building a new kernal. The idea being to integrate the test code directly into the kernal, so it would run on startup. I was hoping there would be enough space in the kernal ROM used by things that were not required that could be used to fit in the tester. That would mean it would run on power on, without the user needed to type anything, and wouldn't run the game from the cartridge (at least not until the end).

I could have found a complete kernal disassembly, then got it to build a binary identical ROM image, then start modifying it, but I didn't want to spend too long on this, so I sort of cheated a bit here. I have a command line program I wrote years ago which takes a binary file and generates asm include or C header files with a binary array of the data in the file. Assembling that file would generate a .bin file which matched the original. I could then change small sections and not have to worry about the other bits.

The first change was bypassing the startup code, so I replaced a section of the binary array with the code from the disassembly. Reassembled it to make sure it was still identical, then I could begin commenting out bits and making changes. I left in most of the initialisation code, apart from the **** CBM BASIC V2 **** message, and added my code at the point where it would have put up the READY prompt.

The VIC20 kernal ROM actually starts with the end of the BASIC ROM, so there is a few K of trigonometry routines, then some IO routines, then more trig functions. The IO routines are still required, but not the trig functions, so in the end about 3K of space I could use in two chunks. Not enough space for the 2K CRC table my original CRC code used, but I found some smaller on the fly CRC code which was still fairly fast and much smaller. That all fitted, with some space to add additional ROM checksums to the lookup table as more cartridges are added to the range. I see now I should have filled the space with FF so that I could add to the table without having to erase the EPROM, rather than 00.

Since I was writing this in raw assembler, the display is quite simple. I have used the same theme of a blue background, white text during testing as the Penultimate Cartridge tester.

As the Cheese and Onion cartridge uses two ROM chips, I have tested these separately, rather than generating an overall checksum, to deal with situations where there is an error on only one chip

Red background indicates a failure (or at least as close as you can get to red on a PAL VIC20). At this point, I jumped to the BASIC cold start code and brought up a ready prompt. In case anything useful could be done from BASIC.

Green background indicates success. If the test is successful, the user can press a key and it will start the game, in the same way it would on bootup.

And then it's packed up and shipped to the eagerly awaiting VIC20 owners.

Cheese and Onion and Spaceship Minus One are available to order now from The Future Was 8 bit.

Arduino EEPROM Programmer

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

I saw this kit advertised on Tindie (Simple EEPROM Programmer shield for Arduino Mega) and thought it looked interesting.

I have an upcoming project where I will need to program some EEPROMs in place in a system. I hadn't looked into the programming algorithm, so this seemed like a good way to start.

The kit arrived, very nicely presented with a clear double sided instruction sheet and a nicely laid out board with all the tracks on the back and a copper pour ground plane. I notice things like that. I like things like that.

Assembly was straightforward. I chose to fit an IC socket (I had already stolen the ZIF socket supplied with the kit for something else), as I wasn't planning to change the IC in it very often.

All that was needed was to plug it into an Arduino Mega. The firmware is available from the author's blog. We've all had fun in the past with Arduino code that doesn't build and needs specific old versions of certain libraries, but I am pleased to say it built and programmed fine.

It uses a serial protocol, over a 9600 8N1 connection. The commands are detailed in the code, but basically V shows a version string, Raaaa reads from address 0xaaaa, and Waaaa:dd writes data 0xdd to address 0xaaaa (can be multiple bytes e.g. Waaaa:dddddd).

You can drive this from the serial monitor, but there are two provided front ends, a command line version and a desktop app.

Testing this with a couple of Atmel AT28C64B EEPROMs that I am currently using a lot to test a Commodore 64 cartridge. Yes, I have put labels on the chips, the etched labels can be tricky to read at some angles. No, of course my eyesight isn't getting worse, of course I'm not getting old.

I was able to read in data from the chip fine, but writing didn't seem to work. I checked with the author and he was using the same chips as me, and they were working fine for him. I checked the chips I was using in my usual programmer, and they were programming fine. It was then I noticed the lines about "Software Data Protection".

Checking the AT28C64B datasheet, it seems there is a sequence of instructions that can be sent to the chip to lock it to disable future writes, and to unlock it again. My Minipro programmer was unlocking at the start, programming and then locking again. A sensible precaution against accidental writes.

I tried removing the SDP (Software Data Protection, not the Social Democratic Party) and was then able to successfully program using the Arduino based programmer. There was no code present in there to do SDP which explains why it wasn't working on chips I had already used with my EPROM programmer. I had tried a chip fresh from the tube, but stupidly checked that it was working first by programming it on my EPROM programmer, which locked it. As there wasn't any provision for SDP in the code, so I tried enabling it using write instructions, W1555:AA, W0AAA:55 etc. but that didn't seem to work.

Checking the datasheet, they specified a series of events, so I took the V0.01 code and built a V0.02 with SDP enable and disable built in, trying to follow this sequence. This didn't work either, I tried a few ways around it, but thought it may be timing related. The exiting code has an overly generous 10mS write pulse, which is actually the maximum the chip can support. The datasheet says the chip can work with a pulse as small as 50nS. I tried a 1uS pulse (using the Arduino delayMicroseconds function), and that worked. I left these are separate commands, as they probably only apply to Atmel chips. P to protect the chip, U to unprotect.

The sequence above show testing writing is working, enabling SDP and writing more. Those writes didn't appear. Enabling SDP and repeating and the writes are now retained. Note the first byte is overwritten with 00 during the lock / unlock operation. Some data needs to be written to any address to complete the lock / unlock process. A future improvement may be to read that byte before lock / unlock and write it back afterwards with the original value. There is also a function to erase the whole chip, but that requires a 12V pulse which is not easily available in this case.

So, I bought this kit to learn more about programming EEPROMs, and it certainly worked. I sent my updates to the author, and he has already incorporated them into the official V0.02 release (available on his blog).