Commodore PET ROM/RAM replacement boards

A while ago, I built some 6502 ROM and RAM placement boards to use on 6502 based computers such as the Commodore PET and VIC20. I have since been contact by a few people who were also after these boards, so I used up the few spares boards I had originally made up.

There has been a recent resurgence in interest in these, and I've had several requests in the last month, so I've ordered more boards, and taken the opportunity to redesign the board based on the experience of using it. The concept remains the same, these boards plug into the 6502 socket, and the 6502 is plugged into the board. All of the pins are connected directly though, apart from the databus, which can be isolated over certain address ranges using a 74HCT245 buffer hidden under the CPU socket. 

The board has it's own ROM and RAM, which can be enabled when the computers original RAM or ROM is disabled. This means the computer's original RAM or RAM can be disabled and substituted with known working replacement without having to be desoldered. This can allow a dead machine to boot up and faulty ROM or RAM to be identified. It can be used just for fault diagnosis, or as a permanent replacement. The modern single ROM and RAM chips use a lot less power than the originals, so it can reduce heat and improve reliability. The addressing is controlled by a GAL16V8 PLD, with options set via DIP switches.

I have used these boards to diagnose and repair number of Commodore PET and VIC20 computers, as well as a couple of 1541 disk drives. The addressing logic on these V2.0 boards has been rearranged, and I've added a reset switch. I tried a few different layouts, but ended up back with the same orientation as the V1.0 boards as this was easier to layout.

The original design included options for using a flash ROM chip, but I wasn't able to locate the software or the particular type of flash chip, so hadn't used it. There was also a secondary ROM address selection via a multiplexer to allow the options ROMs to be selected separately from the main ROM. I've removed that and the associated 273 and gone for straight blocks of ROM. There was also a jumper to change one of the address lines for use with a 1541, I found that wasn't required when I worked on 1541 drives, so I've removed that as well. In the new simplified and expanded design, the upper address lines to the ROM socket are controlled by the higher DIP switches, so any EPROM from a 32K 27C256 to a 1M 27C080 can be used, giving up to 16 32K ROM images. It's not 32 as one address line is used as the VCC pin on 28 pin EPROMs. I may add an onboard link to change that, but I can't see that many being required.

There is 32K RAM available as a single 62256 SRAM chip. On the Commodore Pet 4032/8032 versions, these can be enabled and disabled as two separate 16K sections. This allows you to test the lower and upper 16K banks of RAM in the pet in isolation. I was hoping to be able to selectively disable each of the 5 system ROMs, but I ran out of logic terms on the GAL decoding logic chip. I may look at cascading some of the logic to allow this in a further revision of the board, or upgrading the logic chip. I have ROM and address logic images for Commodore 4032, 8032, VIC20 and 1541. It should be possible to use this on other 6502 based systems. The only exception would be system such as the BBC micro and Commodore 8296, where the video RAM is shared with the main RAM. This board could be used to replace ROMs on those systems. Replacing the RAM would not stop the machine booting, but the display would be blank (or random). I'm working on a separate 'plug into the CPU board' which will replace the video circuitry on a the pet, and can drive the original monitor as well as a composite video output. That's still in the prototype stage.

The V2.0 ROM/RAM boards are available now for £50 + postage, contact me if you would like one. The first of these new boards went out yesterday, and I've already had a message back from a happy customer with his 4032 up an running 'within a few minutes'.

UPDATE: Hot on the heels of the V2.0 boards, I'm now shipping V3.1 boards. These have an additional LED, which I have set to show activity, currently on for reading, off for writing, but I may also look at on for ROM access, off for RAM access etc.

These boards are available to buy from my Tindie Store, alongside the new smaller PET ROM RAM board.

2024 UPDATE

These current updated version of the PET ROM/RAM boards are available to buy from my Tindie Store

• https://www.tindie.com/products/tynemouth/pet-romram-board/

Commodore 4032 Editor ROM for Business keyboard

After fixing the RAM fault on a 4032 recently, there was another request to deal with.

The owner plans to install the board in an 8032 case. It should fit fine as boards are identical barring a few missing chips on the 4032, as are the cases, power supplies and monitors. Other than the screen size, the other important difference between the later 4032 and 8032 models is the keyboard.

There are two of mine. The one on the left is a slightly older model with a taller 'shoulder', but the 4032 and 8032 appear with both heights.

This is the 4032, it has the 40 column screen and the 'normal' or 'graphics' keyboard, a direct ancestor of the chiclet keyboards on the original 2001 series pets.

It is unusual in that the top row has only symbols on it. No numbers. There is a 16 key numeric keypad on the right, and these are the only source of numbers. It can be tricky to use if you are switching between using this and any other keyboard on the planet.

This is an 8032, it has an 80 column screen and the 'business' keyboard. This has an 11 key numeric keypad on the left, and the the top row is a the standard arrangement of numbers with symbols above.

This keyboard is the only one available on later 8032-SK models, and the basis of the ones used on CBM-II etc. The 4032 was the last one to have the graphics keyboard.

Early VIC20's actually had what look like pet business keyboards with the function keys using the middle row of the keypad keys and the other two rows taped up.

These keyboards are not interchangeable though, so the key matrix on the PCB must have been changed. The black keyboard at the top is the CBM business keyboard (from an 8032-SK). The bottom is an early VIC20. The square font and the key shape is the same. Some keys have been moved around, TAB becomes CTRL etc. I need to refurbish this VIC20 keyboard, so I'll try to do a pet business keyboard at the same time for comparison.

So back to the problem. The repaired 4032 board is expecting to be connected to a graphics keyboard, and the 8032 case the owner has is fitted with a business keyboard. The keymap is one of the things set by the editor ROM in the pet, other things being the screen size and refresh rate. So it is just a case of locating the appropriate editor ROM image. All of the known versions are available on the zimmers.net Commodore archive. The various combinations of keyboard and screen are there, these are the ones available for BASIC 4 machines with a CRTC (the later 4032 and 8032 machines).

• 901498-01 - edit-4-40-n-50Hz (40 column, normal keyboard UK)
• 901499-01 - edit-4-40-n-60Hz (40 column, normal keyboard US)
• 901474-04 - edit-4-80-b-50Hz (80 column, business keyboard UK)
• 901474-03 - edit-4-80-b-60Hz (80 column, business keyboard US)

These are the 4 versions Commodore originally produced, the 9014xx numbers are the Commodore part numbers, so the standard UK 8032 has the 901474-04 chip in the UD7 socket.

The one that would be required for the 4032 with a business keyboard would be edit-4-40-b-60Hz (he is in America, so needs the 60Hz version). Commodore didn't make a machine with this combination, so no ROM image appears to exist. Steve Gray has a project to generate new editor ROMs, that adds all sort of nice features, but unfortunately, the 40 column version is currently incomplete. As part of this project, he has disassembled and annotated a number of editor ROMs, including some ones with N and B keyboards. He kindly made those available and I was able to compare the relevant sections. The main change is a 64 byte block at the end which is the 8x8 key matrix lookup table.

Copying the matrix from an 8032 ROM into the 4032 ROM gave me an almost working keyboard. The numbers and some of the symbol keys were incorrect. Comparing the code further, I found a section which deals with the shift key. Here I've disassembled the relevant sections of the 901498-01 4032 ROM and the 901474-04 8032 ROM using CBMxfer viewer. There any many differences between the two ROMs, mainly to do with the screed editing.

The sections in blue are the same. The code on the left is the 4032 ROM disassambly which as two sections of NOPs. The code on the right is from the 8032 ROM, and has some code in there which is checking for certain key ranges. If it is a number key (ASCII / PETSCII 0x31-0x39), and shift is held, it subtracts 0x10, giving codes 0x21-0x29 (symbols !"#$%^'()). Some other keys get 0x80 added (right arrow = 0x1D, + shift = left arrow, 0x9D etc.)  The section of code is in a slightly different location, but the jumps are all relative, and the replacement code turns out to be exactly the same size as the NOPs, so I overwrote the NOP instructions with the code copied from the 8032 ROM and it is now working perfectly. I presume there was some common ancestor to both these ROMS with a business keyboard.

I've burned the image onto a 28C16, and tested the board with a business keyboard and all seems to be working well. There are a few programs which seem to bypass the editor ROM and access the keyboard directly, and example being space invaders. This doesn't work on an 8032 either, so it is expecting a graphics keyboard and scanning it directly.

Whilst I had everything to hand, I also generated an edit-4-40-b-50Hz version. I have submitted these to the zimmers.net archive in case anyone needs this combination again in the future.

Commodore PET 4032 Repair - only 16K reported

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

I have repaired and restored several 4032 and 8032 boards in the past, and here we have another Commodore Pet 4032 main board for repair.

This is one of the later Universal Dynamic Pet boards (8032089). It looks to have always been a 4032 as the extra screen RAM and associated buffers and links that would be required for 80 column mode are untouched. It also has 16 matching 4116 DRAMs (Commodore's own MOSTEK brandered MK4217N-3 / 4116N-S), so should be a 32K machine.

The problem is, it is showing 15359 bytes free, so is only detecting 16K RAM. I quick first check would be jumpers Y and Z. Z should be set for 32K and Y for 16K, But the board was correctly set for 32K mode with link Z fitted.

As usual, it's good to check the voltages first of all. I found the 7905 voltage regulator was outputting -6.5v, rather than -5v. Replacing that the rail now measured -5v as it should, but it didn't resolve the memory problem. As the -5v rail is only used by the DRAM chips, and they are sensitive to voltage problems, it may explain if any of the DRAM chips are damaged.

A good diagnostic tool at this point is a ROM/RAM replacement board, I've had a few requests for the 6502 ROM/RAM boards I built previously, and have now run out. I've designed a new version with a few changes, these will be available soon (UPDATE: available now). Installing one of those in the processor socket and enabling it's RAM, The pet boots and detects 32K, so there appears to be a fault in the upper bank of RAM.

A fault in the upper bank still leaves the system usable, using just the lower 16K. If the fault had been in the lower 16K, it wouldn't have booted up. With a non booting system, it is sometimes worth swapping the ends of resistors R10 and R11 (as I did in the DRAM repair on my 4032). This is all that is required to swap the upper and lower banks. In this case, with the banks swapped, the machine did not boot. This pretty much confirms there is a fault in the upper bank. If there is only a fault in the lower bank, this is an easy way to get the machine to boot.

If you have the lower 16K bank working, and the machine is running, you can still access the top 16K of RAM, it just won't be used by BASIC. A quick way to check which of the 8 DRAM chips in the upper bank are at fault, is to poke a number to an address in the upper bank and read it back. So for example, the first address in the upper bank is 16384, so poke 0 there and read it back, it should be 0.

POKE 16384,0
PRINT PEEK(16384)

Then try poking 255 there and read that back, and you should get 255.

POKE 16384,255
PRINT PEEK(16384)

If either or these responses are wrong, you can work out which chip is stuck high or low by converting to binary, so for example if the response is 8 and 255, one bit is stuck high. That is 0x08 in hex, 0000 1000 in binary. So it looks like bit 3 is stuck high. You would get 252 rather than 255 if it were stuck low. From the schematics at zimmers.net archive (pages 5 and 6), you will see that bit each bit is provided by a single chip, the 4116 being 16K x 1 bit. In this case, bit 3 is UA12.

Value	Bit	Lower bank	Upper bank
1	0	UA19	UA18
2	1	UA17	UA16
4	2	UA15	UA14
8	3	UA13	UA12
16	4	UA11	UA10
32	5	UA9	UA8
64	6	UA7	UA6
128	7	UA5	UA4

Once the chip is identified, remove it and replace it and see try again. I've talked a few people through this process, including in the comments on one of my previous RAM repairs, Dave Stevenson wrote up the repair of his 8096. In the case of this 4032 board, it's going to be more complicated as this initially showed no errors. Checking other addresses, I got an error at address 16420 (0x4024 hex).

Further testing with my memtest program showed a pattern, with multiple bits failing at addresses in hex always ending in 2 or A then 4 or C.

• 0x4024
• 0x402C
• 0x40A4
• 0x40AC
• 0x4124
• 0x412C
• 0x41A4
• 0x41AC
• etc.

This repeated all the way up to 0x7FAC. It seemed unlikely that the entire bank of upper RAM was faulty, so I spent a while looking at various addressing issues that could case this, but given the bank swap had shown there was a fault, and that only the DRAM chips are involved after those resistors, it had to be the RAM chips. The error pattern had only bits 3 and 7 changing, so I took a punt on bit 3, since I'd already seen it appeared to be stuck high at some location. That reduced the number of errors, so I replaced bit 7 as well. Replacing those two DRAM chips and the Pet booted up and reported 31743 bytes free, as it should be. It appears the addressing was being messed up by UA4, and there were some faults in UA12.

I managed to find some spare 4116 chips which were a good match for the originals, the same make and model and the date code 6 weeks later. If I was keeping this board, I would have been tempted to remove the sockets and solder the two replacement chips to the board, but I've left the sockets in place in case the board's owner has any problems in future.

With the new RAM in place, the system was up and running and detected 31743 bytes free as normal. Running memtest again, it passed with no problems.

It's a hard life for me, I had to test this again thoroughly with things like space invaders and down.

Also, at the request of the owner, I tested Colossal Caves adventure. We had spoken about this a while ago, he had remembered playing this on a Pet, but couldn't find a version of it. I finally located a D64 disk image of Colossal Cave, this was actually a port to the pet by Jim Butterfield.

To load the D64 disk image, I used my prototype PET microSD drive - this will soon be available, register your interest now if you want one of the first batch.

PET microSD - Commodore Pet SD card disk drive

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

There has been a lot going on in the world of Commodore PET disk drive replacements, following a number of years where there were no options currently available, soon there should be a number of new products on the market. In the absence of anything currently in production, I had looked at the petdisk design and built a board with an improved processor and SD card interface, but which could still run petdisk firmware. I wasn't keen of the use of diode droppers to attach the 3.3V SD card to the 5V microcontroller, so I had used a 3v3 regulator and a level shifter. I made a few of these and they worked, but the petdisk firmware limited what it could do, so I started writing new firmware for it.

In the comments on my posts about the PCB version of this, several people suggested I look into PetSD. Pet SD is no longer in production, but was a SD storage system based on SD2IEC, the SD card IEC disk drives that are very popular on the Commodore 64. This gives it support for various commands and file types not supported on the petdisk, and .d64 disk images etc. The original Pet SD had proper IEEE-488 bus drivers, an ethernet interface, USB-serial interface, real time clock, LCD display etc., I had ruled that out when looking around initially, and started instead with the simpler solution. It seems several people were interested in bringing that back, and had been working on new versions. PetSD+, a respin of this, without the ethernet and USB, and PetSD duo, an even more ambitious version with a larger LCD display and an IEC interface for Commodore 64 computers. So I'm now looking and producing a cut down version of Pet SD, in a similar form factor that the ones I've previously built.

Announcing the PET microSD. I wanted to keep it the same sort of size as my previous board and also attached directly to the edge connector. The new design does have a lot more going on, and the original board is considerably larger. I've replaced the components with surface mount version, which reduces the size quite a bit, but I have had to go for a double sided load, and moved some of the parts to the back of the board. This has got it down to a similar size, the final version being 50mmx35mm.

The PET microSD does not have the ethernet or USB interface, although serial is there for debugging and possible future use. There is no display or real time clock, but it does have the level shifter SD card interface and proper IEEE-488 bus drivers, so can be used with other IEEE-488 disk drives attached. There is a pin header which can be used for internal mounting in 8296 and early 4000 and 8000 series computer which have a 24 pin IEEE-488 header on the board.

I've also designed a riser board which will allow this to be installed inside an 8032-SK or an 8096-SK. This will plug into the pet motherboard, the PET microSD will plug into that, and the original IEEE-488 edge connector will plug into the top. There is also a version with the drive connector reversed which will allow a passthrough on the rear or a 4000 or 8000 series. These can also be used to mount the PET microSD vertically on the rear of a PET rather than sticking out horizontally. I'm also trying to source connectors that will allow you mount the PET microSD on the back of any thing with an IEEE-488/GPIB connector, rather than an edge connector.

The prototype is built and tested and is working well, so the boards have been ordered and I'll be building up the first versions later in the month.

Dave Stevenson has product a chart showing the range of Pet SD card products currently planned, and which features they support. It is expected that all the new PetSD based products will be able to tick all the boxes on his CBM DOS compatibility chart. Also on the list is an updated version of the boards I original built with my own firmware, now called TS-SD to avoid any confusion.

Update: pet microSD is now available:

2022 Update: I have since designed a much nicer SD drive for a PET. The SD2PET is available from The Future Was 8 bit: SD2PET