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

Petdisk clone

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

A few weeks ago, I wrote about building a prototype version of Bitfixer's Petdisk, an IEEE-488 disk drive for Commodore Pet computers, using an SD card for storage. Credit again to Bitfixer, the creator of the original Petdisk. This was the first stage of a plan to build my own Pet disk drive emulator, recreate what has already been done to prove the principle.

That version was built on an Arduino UNO, using the same pins to connect to the IEEE-488 port as the original version of Petdisk. This allowed me to load the original firmware in to check everything was working.

I did get some way along the road writing a version in the Arduino environment. I started from scratch, but followed the general lines of the Petdisk firmware. I was hoping this might come out to be a some nice short simple Arduino code using the SD libraries etc. However testing showed the I/O operations needs to be fast, so I had to replace all the nicely wrapped Arduino DigialRead and DigitalWrite calls with direct PORT and DDR access. I ended up removing most of the serial debug I had added as well. But it did work. I started with an empty directory and a simple hard coded 48 byte test program.

Whatever filename was requested, it would return the same 48 bytes. With that working, I started using the Arduino  SD library to load files. That is working, but is unfortunately limited to 8.3 filenames. I didn't get around to writing the directory listing bit, but that should be possible. So, the new firmware can be written, but probably best not in the Arduino environment.

The next step was making a PCB version of the SD card version. This would again use the same connections to the IEEE-488 port as Petdisk, so it could use that firmware. As with the Arduino UNO, I used the ATmega328P. Not the actual chip used on the Petdisk (that was the ATmega168), but similar enough to allow the firmware to be used.

Rather than the diode / resistor level conversion used on Petdisk, I went for a 3.3V LDO regulator, and a 4050 hex buffer working as a level shifter. I also went for a microSD card socket rather than full size SD. I added a power LED and using a spare gate of the buffer, an activity LED.

The board slides into the pins of IEEE-488 24 way 0.156" edge connector and it is soldered down on both sides. I missed out the pass-through connector and the USB power connector and went for a simple two pin header for the power. OK, it's sounding less and less like a clone now, not quite an emulator, but the only thing in common between this and the Petdisk now are the edge connector and the microSD card.

The pins at the back are the power in, the 6 pin Atmel programming header and the three jumpers. Two for the address setting, one can be used for serial out.

I built a few for my machines and a few friends who have also tried but been unable to buy a Petdisk. I have a few boards left if anyone else is in the same position.

With the Petdisk v2.0 beta firmware loaded, that is working nicely. I am in the process of writing some new replacement firmware, I've gone back to plain C in Atmel studio, rather than in the Arduino environment.

In my version, I'd like to add some new features, BASIC 4.0 disk commands like 'DIRECTORY' and DLOAD, shift + RUN/STOP support, non- PRG files and file OPEN commands.

One of the things I've been looking at is an old text adventure game. I've found a D64 image, which contains a .PRG file and many .SEQ data files. With those transferred to an 8250 disk, it loads and runs. With the Petdisk firmware it gets so far but cannot load the instructions or start the game as these use OPEN and INPUT# commands. The aim is to get that working.

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

Arduino based Pet Disk Clone

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Since it's Arduino Day, here is a project a built up a while ago. There is an Arduino UNO under that lot.

I've restored a number of Commodore PET computers recently (amongst them a 8032 and a 4032), and I've been working on various IEEE-488 devices to plug into them.

It seems every time I mention the PET, someone suggests I should get a Pet Disk. This is a small board which plugs into the IEEE-4888 port and emulates a floppy disk drive using the files on the SD card. The full details are on the Pet Disk website. I have tried a few times to get one of these, but have not been able to. The project appears to be in the public domain, so all credit to BitFixer, the original author.

I've been thinking about building my own Pet disk drive replacement for a while. In order to get going, I thought I'd start by seeing if I could recreate the Pet Disk as a sort of proof of principle. The hardware details are on the Pet Disk website, it is basically an ATmega8 (and later an ATmega168), and an SD card.

So here is my version, it's an Arduino UNO and an Adafruit micro SD card breakout board. The UNO uses the ATmega328P, similar enough for this purpose, just with more available memory and program space. The original schematic used diode clamping to convert from the 5V of the microcontroller to the 3.3V required for the SD card. Here, the circuitry to do the level shifting with a 4050 rather than diodes is on the Adafruit microSD breakout board.

Power comes from the cassette port on the PET - the USB socket on the Pet Disk is for power only. The rest is connections to the IEEE-488 port of the PET. I made up a reusable cable as I'm planning to develop this further.

I followed the same pinouts as the Pet Disk, so I could initially re-use the existing firmware. Here is a table of the various connections.

IEEE-488 Pin	IEEE-488 Signal	ATmega328P pin	Arduino pin
1	DIO1	PB0	8
2	DIO2	PB1	9
3	DIO3	PD2	2
4	DIO4	PD3	3
5	EOI	PC4	A4
6	DAV	PC2	A2
7	NRFD	PC3	A3
8	NDAC	PC1	A1
9	IFC	-	-
10	SRQ	-	-
11	ATN	PC0	A0
12	GND	GND	GND
13	DIO5	PD4	4
14	DIO6	PD5	5
15	DIO7	PD6	6
16	DIO8	PD7	7
17	REN	-	-
18	GND	GND	GND
19	GND	GND	GND
20	GND	GND	GND
21	GND	GND	GND
22	GND	GND	GND
23	GND	GND	GND
24	GND	GND	GND

The SD card connections are shown here. On the original circuit, /CS, DI and SCLK pins have diode clamps to limit the voltage to 3.3V. Power is fed via a diode / resistor dropper. Here I'm using a breakout board which includes the level shifter, so connections are direct.

SD Card pin	SD Card Signal	ATmega328P pin	Arduino pin	Micro SD board pin
1	/CS	PB2	10	7
2	DI	PB3	11	6
3	VSS	GND	GND	3
4	VDD	-	-	1
5	SCLK	PB5	13	4
6	VSS	GND	GND	3
7	DO	PB4	12	5

With that all plugged together, the firmware is loaded via ICSP with a USBtiny ISP. It could probably be rewritten in the Arduino environment, but for the moment I'm using the original firmware.

The Petdisk firmware uses address 9. It should be possible to change this via jumper, but I think there is some problem with that.

Directory listings seems to work nicely. as does loading and listing.

With that working, I can start working on my version. I did some brief testing with a Netduino. This is an Arduino alternative, running the .net micro framework on an Arm processor, I had several left over from a training course I gave last year to a group of software developers who wanted to get into hardware, but preferred to stay with the familiarity of C#. This already had a microSD card built in, and filing system support as part of the .net micro framework. I swapped over the wires and wrote a simple version in C#.

The Netduino is useful for things like IoT devices, you can write a webserver in half a page of code, and for simple I/O such as reading sensors and driving LCD displays. However, it wasn't going to work here as it's I/O was just not fast enough to meet the timing specifications of the bus. So, yes, the 168 MHz Arm Cortex-M4 with code in C# and the .net micro framework couldn't go fast enough for the 1MHz 6502.

So back to the Arduino for the moment. I've written alternative firmware which does basically the same thing as the Petdisk firmware, again as a proof of principal. My aim is something slightly different, rather than the SD card, I have a pair of two megabyte flash chips. The idea being to write what is basically an 8250 emulator. This is a dual floppy drive for the Pet, so the flash devices will be the two floppy drives. That's currently a work in progress. I'm also thinking of getting it to work via USB, so the disk images inside can be accessed via openCBM apps, like the xum1541 style devices I previously built for IEC and IEEE-4888.

In the mean time, I've designed a PCB for the Pet Disk clone, using the smaller surface mount version of the ATmega328P, and going for a 3.3V regulator and 4050 level converter and a microSD slot on the board. Just waiting for those board to come back now. I've kept the original pin out again, so the traces aren't as neat as I'd like.

I normally go for the neatest layout on the board if it's not important which I/O pin is used, so my USB keyboard boards are usually a neat fan out of all the pins, and minimal use of vias.

Update: The PCB version is now complete: http://blog.tynemouthsoftware.co.uk/2015/04/petdisk-clone.html

Update 2: I've now designed a cut down version of petSD running NODISKEMU firmware, in a similar form factor, this is pet microSD.

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