Commodore 16 64K Upgrades

The Commodore 16 was always the nicest looking of the TED series of computers, and had the best case, a black version of the VIC20/C64 breadbin case, and best keyboard, a grey version of the VIC20/C64 keyboard. But it was the weaker of the two main TED machines in that it lacked several things. It didn't have a user port (although that wasn't used much it would have been nice), it didn't have the built in software suite (again, would be nice, but I'll manage without it), the main issue was it only had 16K of RAM.

Many game developers aimed for the lower common denominator and produced 16K titles that would run on the Commodore 16 and the plus/4, but there were quite a few titles that only ran on the plus/4 with it's 64K of RAM. It would seem the best combination you can have then is a Commodore 16 that has been upgraded to 64K (by the way, I've checked, and a C16 upgraded to 64K doesn't make a C64). I've seen many ways of doing this, and have tried to find the best one. The aim was to find a nice easy way that a C16 could be upgraded, in a plug and play sort of way.

First off, I've been through this all sorts of different ways, and concluded that it's just not going to be possible to do this as a cartridge without modifying the C16 board internally in some way. That's rather disappointing, but it boils down to this, the TED chip generates the RAM select lines, and this is the same chip used on the plus/4, so it generates these over the whole 64K range. The RAM chips themselves are wired up to know nothing of the upper two address lines, so the 16K RAM is mirrored four times in the 64K address space. No getting around that. The 4416 RAM chips are soldered to the board on every C16 I've seen, and are enabled over the whole address space. So as far as I can see it, there's no way to add a full 64K of RAM to the C16 without somehow disabling the onboard RAM, which is going to have to involve a soldering iron or something sharp and pointy.

But there are C16 64K RAM cartridges, how do they do it? Well, unless I've missed something, I can't see how it can be done without disabling the internal 16K RAM. I did find one cartridge from the 80s that had instructions (in German) which included a diagram instructing you to cut a track, this is the RAS line from the CPU, so will stop the RAM being selected.

Another cartridge (also in German) suggests cutting pin 9 of the two RAM chips, that is the 5V supply (yes, I know it's in an unusual place on that, carried over from the 4116 pinout), which should also disable them (although parasitic power could still be a problem, I wouldn't recommend that method). It also means you always have to have the cartridge installed as the internal RAM doesn't work any more.

Those seems to have been lost in the mists of time, and various clones of the C16 64K cart are on sale at the moment that don't appear to mention this. Without that, you get the internal 16K and the first 16K in the external cartridge running in parallel. That's not great, but both should be writing the same data to the bus. The problem comes when you access above 16K. The onboard RAM is mirroring the lower 16K, but the cartridge has different data, so both try to drive the data lines. The one closest the CPU wins, but eventually bad things happen to the other RAM chips, things get hot, things fail. It's not a good idea.

The technical bit

The TMS4416 RAM chips used are 4 bits by 16K. These are dynamic RAM, and so are addressed in two parts, a row and then a column. The row is setup first using the eight address inputs, A0-A7. The column then follows, but this only uses the A1-A6 pins, switched using 74LS257 multiplexor chips to A8-A13. This gives it a 14 bit address range, 0000-3FFF or 16K in total. A14 and A15 are not referenced, so the same RAM will also appear in the memory map at 4000-7FFF, 8000-BFFF and C000-FFFF. This means if you try to add any RAM to the system in the 4000-FFFF range, it will conflict with this onboard RAM. And that's the issue really. It may pass memory tests and appear to work, but it really shouldn't.

The plus/4 has a similar arrangement (although the style of the schematic is a little different). The key things to note here, is the 4164 chips used here (1 bit by 64K) have A0-A7 on the RAS selection, and A8-A15 on the CAS. These chips are driven by the same RAS and CAS signals from the same TED chip, so are active over the whole address range, but in this case, provide valid data over that range with no mirroring.

It may be clearer to look at the last version of the Commodore 64 mainboard. That used two 4464 RAM chips rather than eight 4164 as the earlier versions and the plus/4. Here you can see it is pretty much the same, other than the address lines are A0-A7 and A8-A15 and the RAM chips are 4x64K instead of 4x16K.

Here is the relevant area on the Commodore 16 board. The two RAM chips, bottom right are U5 and U6, and the two multiplexor chips are U7 and U8. So to upgrade the Commodore 16 to 64K, we need to remove the two RAM chips and replace them with 4464 chips, and rewire one pin on each of the 74LS257 mux chips, disconnecting 5V and attaching A14 and A15 (it doesn't actually matter which way around they go as long as they are both connected up).

This is where it gets to the choices. There are several ways this can be done, and I present here a selection of those. Each have pros and cons. All involve desoldering the chips, so should not be undertaken without suitable experience and equipment.

Method 1 - Permanent install

This is the way I normally do these modifications, it is permanent in that tracks have to be cut, but that's fine if you don't plan to go back to 16K at any point. Step one is to remove U5-U8. I use a desoldering gun and lots of flux, going slowly and carefully trying not to damage the board or the chips. If done properly, the chips will just drop out. No levering should ever be required,

Time for the modifications, first is U7.

Pin 2 is connected to 5V, this needs to be cut and connected to A14.

To do that, cut the track on the top of the board between pins 16 and 2. See later for alternatives if you don't like the idea of cutting tracks.

Next is U8.

Here pin 14 needs to be disconnected from 5V and connected to A15.

That is under the board, and the track is cut between the large 5V rail and pin 14.

That could have been done without removing the chip, but the 74LS257 (and particularly the MOS version of the 257, the 7708) are all common failures in machines of this era, so as I was removing the other three, it always seems a good opportunity to replace both 74LS257 chips.

A14 and A15 can be found in various locations, pins 36 and 37 of the TED chip, pins 21 and 22 of the 7501/8501 CPU, or I use two vias near by, just check for continuity with the above pins.

You can test first with the original RAM chips, just to make sure everything is OK, they should still operate as 16K.

Yes, still working. Time to fit the 4464 RAM chips.

And switch on.

Excellent, you now have a 64K Commodore 16 (which you are not allowed to call a Commodore 64). It's usually a good time to give the machine a bit of a test, one of the new Diag 264 cartridges with shinny gold plated edge connector. (2023 update - these are no longer available as the author has revoked permission for pre-programmed cartridges to be sold)

I left that running for a while and all the tests passed (other than the ones needing human input or loopbacks which I wasn't concerned about).

And now, time to try out some of those plus/4 only titles on my new Commodore 64 64K Commodore 16.

Method 2 - Mod board

This was a machine that was sent in for repair. The owner had problems installing this 64K upgrade. Have you spotted the problem yet?

It is an alternative way of doing the same thing as above. The board plugs into two sockets fitted where the 74LS257s chips were and connects two new 74LS257 chips in their place, apart from the two pins that need to be redirected. It connects those via a switch to a two pin header, and a short cable connects that to another two pin header installed on the board where there are convenient A14 and A15 vias next to the modulator.

To install this, the four chips need to be removed and sockets fitted, and this is where the problems had happened. Cutting chip pins and then pulling them out one by one is not a method I would recommend, and in this case, had done a bit of damage. The repairs on the back, well, I'll let you judge.

I thought it best to remove the sockets to see what the board was like underneath, so I could repair the two missing tracks (you did spot those on the first picture didn't you?) and any other damage.

With the sockets removed and the board cleaned up, it wasn't that bad, and I was able to repair the places where the through hole plating had been lost, the two tracked that had been pulled up and lost, and the one that was hanging on by a thread.

With new sockets fitted and the tracks repaired on the back of the board, the module could be reinstalled and tested.

It's quite a neat solution, but not for the novice solderer. A nice feature of that board is the switch which returns it to a 16K machine by switching the two address pins back to 5V.

Method 3 - Reversible version

Whilst using a board like that above does give a neat solution, I did try a third method, sort of a combination of both of the other methods.

Remove all four chips, U5-U8 and fit sockets.

At any point, you can reinstall the original chips if you want to go back to the original Commodore 16. You could maybe use less good sockets that would look more like the type they may have originally fitted if you like, but I prefer to stick with the turned pin versions.

No tracks have been cut, so to connect the higher address lines to the mux chips, I fitted new 74LS257s and bent up the two legs, pin 2 on U7 and pin 14 on U8 and attached some wires.

Those two wires then needed to be connected to A14 and A15, so I used the same trick the plug in board had used and fitted a two pin header to the leftmost two vias in the row of six by the modulator.

That gives a fairly neat install, it is fixed as 64K, but no tracks have been cut, so you can go back to 16K if you wish using the original chips you carefully removed before (you did carefully remove them didn't you? no cutting legs or prying out here please).

This last one is the Commdore 16 I recently fitted an internal SD2IEC to.

So there's a few different ways to do a 64K upgrade to a Commodore 16. Sorry there isn't a solderless method, address all complaints to the marketing division of Commodore in around 1984.

---

Update

I have designed a new version which plugs into the sockets of the two RAM chips and two mux chips and gives 64K or 16K switchable. Available form my SellMyRetro store.

• https://www.sellmyretro.com/offer/details/64324

More info in a blog post

• http://blog.tynemouthsoftware.co.uk/2024/06/new-commodore-16-internal-64k-ram-upgrade.html

---

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts.

This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware

VIC20 Dead Test+

This is an old post, preserved for reference.

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.