PET IEEE-488 diagnostic tool

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

This is something I had made for myself to make testing my PET microSD boards, but several people have expressed interest, so these are now available for sale. 

It is basically a passthrough board that plugs into the IEEE-488 port on the rear of the Commodore PET. The status of all of the signal lines are shown on 20 LEDs. 8 show the data lines, 8 the handshaking lines, one shows power and three are not connected.

Driver chips are used to minimise the loading on the bus signals, so this can be left in place without affecting normal operation. 5v power is connected at the side.

The diagnostic board serves multiple purposes. Firstly, it can be used to test the IEEE-488 drivers on the PET. I have a simple program which sets the signals on the port one by one, so you can watch the LEDs to check they are all coming on in series. The PET can also read back the status of these pins to test both directions.

Secondly, it can be used when testing IEEE-488 devices, as you can monitor the status of the lines. Thirdly, it serves as a port saver / extender, so saves wear on the edge connector.

Finally, in conjunction with special firmware on the PET microSD, I can test the IEEE-488 drivers on there, again by cycling through the outputs.

These will be supplied with a datasette power adapter, available now as PCBs, kit or assembled units from my Tindie store.

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

Commodore 64 Diagnostics Test Harness

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

This is something I've been meaning to get around to for a while, and testing the Commodore 128 has brought it to the front. Last year I built up a couple of Commodore 64 Diagnostic cartridges, the C64 Dead Test and the standard C64 Diag.

They both test RAM, VIC and SID functions, the standard diagnostic cartridge can also test the external ports of the C64. With just the cartridge, these test fail, the keyboard is reported as open, and the cassette, control, serial, user ports and interrupt tests are marked as bad. The chip list shows the two 6526 CIA's are shown as bad these drive the ports. The 6581 SID is also shown as bad even if you can hear it playing the sound test, as it provides two analogue inputs for the control ports.

To test these, most of the ports need loopback adapters, basically sending a single to one pin and reading it back via a loopback connection to another pin. There are a couple of schematics on the net. The first appears to be reverse engineered from an original test harness. This is slightly difficult to follow as all the wiring goes back to a 26 pin connector on the user port adapter, so you have to trace it through that. The second source also includes ROM images and manuals for the diagnostic cartridges. Zimmers.net contains a slightly different schematic and also the ROM image. Credit to all those guys for providing the schematics.

I've been adding bits as required over time. The first was the serial loopback, The red button on the top is wired as a reset switch.

The next was the user port. The Commodore original had a cartridge sized box as part of the user port, which housed the circuitry for the control ports, but that meant a lot of wires going from there to the control ports, The user port tests is just a series of loopback connections, all it got from there was power, which can also be got from the control ports, so I just made this as a loopback.

The cassette port is also looped back, but provides a switching signal to the control port tests, derived from three outputs via two resistors. There is some discrepancy between the two schematics I referred to, the resistors values are exchanges and there is no loopback. I built mine according to the first and it seems to work fine.

These two were given D shell covers (37 way for the user port and 15 way for the cassette port) which fit reasonably well.

I made the keyboard connector loopback form on old keyboard cable. I've also added an LED and resistor to form a power indicator.

The joystick tester uses two 4066 switches to switch the fire button and four direction signals between the two ports. Theses are controlled by the signal from the cassette port. I built these up on a small board. Also on there are the four 120K resistors used to test the X and Y analogue inputs on each port.

This was all housed in a small box to hopefully plug directly into the side of the case. It didn't quite work out as it obstructs the power switch, and also the sloped side of the C64C case.

To get around this, I made a set of extenders for the joystick connections. Just a plug soldered to a socket with some tape wrapped around.

With these extenders, it fits fine, just looks a bit odd.

And that completes the loopback test setup.

Without opening the case, the keyboard tests shows 'open', but all the others now pass.

This board has been removed from it's case, and the keyboard loopback installed. All tests now pass.

I had a productive day going through a small backlog of faulty C64 boards, All but a few were repaired, or at least the faulty chips marked up for replacements. At the end of the day, I tracked down a couple of faulty 6526 CIA's, a couple of 6569 VICs, and a faulty 6510 CPU. There were more 6581 SID's than I usually find (several partial failures), and the usual pile of 906114-01 PLAs. Also fixed but not shown, a couple of 7406's, some 4264 DRAM's and a 74LS257 - most of the memory faults had previously been fixed.

The same cable set can be used on the C64C.

And also on the C128, which is where all this started.