Commodore PET 2001-8 Mainboard Repair - Part 1

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Here we have a 2001-8 board in for repair.

This is an early model with 6540 ROMs and 6550 RAM.

The first thing you would notice is the power cable, I don't like the look of that. It appears someone has cut off the original connector and soldered the wires onto the board.

At some point later, they wanted to remove the board, so cut the wires and use a screw terminal block to reconnect it. It then got sold on in that condition, and also not working. Thanks to the new owner for the photo of the board in situ.

I'll replace that with a plug and socket later. For the moment, I'll temporarily power the board from a 9V bench power supply, clipped across the reverse protection diode.

The rest of the board looks in reasonable condition, although, the CPU isn't sitting properly in the socket.

The same with some of the other chips - could I be that lucky?

No. I removed and reseated all the chips and tried it, but that didn't help. It wouldn't have helped either if it had be run with the chips making partial contact for any length of time. My usual tests of power, clock, reset were all fine, but the screen was showing what looked like some really complicated version of Hopper.

So, not all that bad, some things are running, but not enough. Time for one of my ROM/RAM boards.

I set that to replace all the ROM and RAM and powered on.

OK, not as bad as it looks, the mess at the top looks like it is trying to show the right thing. A bit of maths and checking with the PETSCI character set, and it appears that the lower 4 bits are stuck high. So,
/?????/O←←O←/O←OO/
should be
 31743 BYTES FREE
The space is 0x20, and / is 0x2F. The numbers are 0x33 etc. and ? is 0x3F. The upper case letters are in the range of 0x40 and 0x50, so are replaced by 0x4F (O) and 0x5F (←).

I verified this using the PET tester ROM image on the ROM RAM board, this was meant to be the full character set, but as you can see, it is mainly runs of 16 identical characters with the odd exception.

The video RAM on the 2001 is a pair of 6550 RAM chips. So the one of these which handles the lower nibble is faulty. I had previously made a board to replace the video RAM, using a modern SRAM chip. It is actually 32K, but only 1K is used. That may be considered a waste, but it is cheaper and easier to find than using a pair of 2114 chips to make 1K. This sits across the two video RAM sockets. I've added a cut out for the decoupling capacitor in between to help with orientation of the board.

I had thought I could get away with only the RAM chip on there as most of the enable lines are tied high on the video RAM, but when I tested this on another board, I found it is going to need some logic to combine the read/write line and the clock, so it only writes on the high phase of the clock. I've designed a new board, but for the moment, I'm stuck with a 7400 bodged on the top, dead-bug style. Not pretty, but good enough for testing.

That did indeed work, so I reinstalled the working 6550 and borrowed a 6550 from the main RAM and tried again. The borrowed 6550 didn't work either. After trying four of the 6550 chips, I got lucky and found another 6550 that worked.

That's not quite right though, It seems several characters seem to have a built in underscore. Here on the full character set, you can see if consistently affects certain characters. Ones where the character code ends in a 5, %, 5, e, u, E, U etc. and only on the last row of pixels?

I puzzled over what could be causing that for a while, but it just came down to a duff character ROM. I did consider building a circuit to blank out the bottom row of pixels on certain characters, but that would be been quite a bit of work to fix the one faulty chip. It could also get worse over time, so best replace it.

That is a MOS MPS 6540-010, MOS produced their own ROM and RAM chips for a short while, but they were quickly abandoned, and a year after this board, they were using 2716 compatible ROMs and 2114 SRAM in the 2001.

There aren't any EPROMs that will directly replace the 6540, but you can get very nice replacements on ebay. I was going to make my own, but this looks a very neat job, so I used one of those. I'll take a point off though, as the label was upside down.

At this stage of testing, the 2001 board has replacement system ROM and main RAM. Replacement video RAM, Replacement video ROM. Replacement power supply. Replacement monitor (composite video out board) and a PET microSD IEEE-488 disk drive replacement. There is also a piezo on the user port to make sounds.

With these modern replacements, the power consumption is just under an amp. With the original chips, it's between two and three amps.

That runs stably now with no other problems showing up. This is post is already too long, so I'll split it up. In part two, I'll finish off cleaning the board and put back as many working parts as I can and sort out the power connection.

In the mean time, more testing required, Tetris this time, since I don't get to test that much as it doesn't work on later PETs.

MOS 6530 replacements

Went working on old computers, there is always a problem with getting hold of replacement ICs. Some are easier than others, WDC are manufacturing modern versions of the 6502, 6520/21 and 6522, and there are still supplies of various types of RAM. One of the more difficult to replace is the 6530.

This is an early MOS chip used in Commodore PET disk drives. It is an RRIOT, so called because it contains, in a single chip, ROM, RAM, I/O and a Timer. So this can be used to reduce chip count. Because of the ROM part, this means it is a programmable part, and so not only do you need to find a 6530 to replace a faulty one, but it has to be one with the right ROM code in it. And just to help things, they are all marked with Commodore part 9018xx-0x part numbers.

This is the controller of a Commodore PET 8250 dual disk drive, the 6530 is the middle of the three 40 pin chips, marked 901885-04.

Inside the 8250, there is no sign of the promised reduced chip count in there. In total, there are:

• 2 6502 CPUs
• 4 sets of RAM - a bank of 2114s (4K), 2 x RIOT (128 bytes each) and a RRIOT 64 bytes)
• 4 sets of ROM - 3 mask ROMs (2x4K, 1x2K), one RRIOT(1K) 
• 4 I/O chips - a 6522, a RRIOT and two RIOTs

So quite a lot on there to go wrong. In the later Commodore disk drives (the 8250LP , 8296D and SFD-1001), it looks like they had been designed to use a 6530, but they all seem to be fitted with adapter boards. These had a 6530 from another drive, and some logic so the ROM on there wasn't enabled, and a separate ROM chip which had the right code in. This was presumably a way of using up the stock of old 6530 chips. I don't have a stock pile of old 6530 chips. But I do have 6532 RIOTs. The 6532 is very similar to the 6530 but without the ROM, so RIOT is RAM, I/O and Timer. This chip is not programmable, so more easy to find. There is one in every Atari 2600, I actually use a 2600 to test 6532's.

New Old Stock 6532s are still available, and is a good place to start to replace a 6530. It has the RAM (actually, it has 128 bytes, the 6530 had only 64 bytes), the same I/O and Timer, so all it needs is the 1K ROM. This can all be fitted on a plug in board. This has been done in various ways before, such as this 6530 replacement, this my interpretation, along similar lines.

There are pins on the bottom to plug into the 6530 socket (annoyingly the pins are in a different order to the 6532), a ROM chip and a 74HCT02 NOR gate to enable to ROM chip as required. 8K is the smallest size ROM I can easily get, so  I've added jumpers to select the appropriate ROM image. I have put images for 5 of the 6530 ROM dumps from zimmers.net, including the one in the adapter board on the 8250LP. With those ROM images, this board will replace the following 6530s:

• 901466-04 (6530-34) - Shugart SA390 drives in 4040, DOS 2.2
• 901483-03 (6530-28) - Micropolis 1006 drives in 8050, DOS 2.5
• 901885-04 (6530-47) - Micropolis 1006 drives in 8050/8250, DOS 2.7
• 901869-01 (6530-48) - MPI 101/102 drives in 8050/8250 DOS 2.7
• 251474-01B - Matsushita JU-570-2 drives in 8250LP, DOS 2.7

It may be suitable for other 6530's, but there is another layer of complexity. There is some additional programmable logic in the 6530 to set the addresses of the devices within the chip. All the disk drive ones are the same, so this board can be used for all of those. Any others would need to be checked to see the expected address map. 

With the ROM and a 6532 installed, and the jumpers set, it's ready to go. That all plugs into the 6530 socket and this 8250 dual disk drive is now back up and running nicely.

There doesn't seem to be any issues with clearance as the 8250 case is massive. Testing that with the 8250 diagnostics, it passes all the drive performance tests fine.

Another good test is using openCBM to write disk images, and the wonderfully literal BASIC 4 'copy an entire disk' command, COPY D0 TO D1.

There's another 8250 back in service. I've got another couple of drives, an 8050 and 8250 in for repair, so there should be more on them soon.

As usual, I've got spare PCBs left, these are available from my Tindie store.

2022 Update: The remaining PCBs are available from my SellMyRetro store - https://www.sellmyretro.com/offer/details/commodore-mos-6530-replacement-pcb-61997

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.

BBC floppy disk transfer

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

I've had a request to transfer some files from .ssd disk images to real 5.25" floppy disks for use on a BBC micro. In the same way as my PET microSD gives the Commodore PET a microSD card disk drive, there are similar things for the BBC. These include John Kortink's GoMMC, and the RetroClinic DataCentre. Unfortunately, most of my BBCs are out of the way at the moment, so I was looking for a quick alternative.

Serial transfer is a good option in this case. The BBC has an RS423 serial port which is sort of RS232 compatible. About 20 years ago at University I had ended up with a laptop (an NEC V30 8088 clone) which had two floppy drives and a cracked screen. I also had a BBC micro and a television set, so I ended up writing up projects and dissertations on the BBC micro in Wordwise Plus and transferring them using a serial terminal program to the PC floppy drive to take into the University library to print out. It was mainly text, although I remember some of the electronics needing dodgy ASCII art circuit diagrams that had to be completed by hand once printed out. Ah, the days before WYSIWYG was at out fingertips.

I still have the BBC micro I used then (but that is also out of reach). I did manage to find the cable I had used though as the BBC's serial connector is the rather odd 5 pin DIN 'domino' pattern, which is not very common these days.

One one end of the cable goes a BBC micro. Here an issue 4 with an 8271 and Acorn DFS, and a 40/80 track switchable disk drive. PC users had it easy with 5.25" floppy disks, they were either 360K or 1.2MB, and you could usually tell by the label on the disk (DSDD or DSHD). Things were a lot more complicated for some of the other machines. With the BBC you had 40 or 80 track, DFS or ADFS, or some other propriety systems. Some single sided, some double sided, and some where you could access both sides as separate disks, but not as a continuous block. It can be very confusing when you pick up a random disks knowing what format it was written in.

At the PC end I am using a program called DFS Explorer, this allows the transfer of .ssd files to and from real disk over serial. In the 90's setup, I had a DOS boot disk in the laptop with a autoexec.bat (or was it config.sys?) set to redirect the console to the serial port, so I could use a terminal program on the BBC as if I was typing on the laptop (the BBC had a better keyboard), and would show the output from the laptop on the TV (since the latop screen was damaged and had been removed). Here is almost the reverse of that.

To begin the transfer process, you type a few commands onto the BBC to set the baud rate (1200 baud) and tell it to listen to the serial port and process what is received as if it came from the keyboard. It is effectively typing in the program you need at the BBC end. Very neat.

The program is transferred over and you save it to a disk on the BBC (or transfer it again next time you need it). When you run it, the BBC becomes a slave to the program running on the PC end.
I initially had some problems, due to a cheap USB to serial adapter. The BASIC program transferred fine, but the handshaking is more stringent on the data transfer and it wouldn't go. The cheap USB to serial adapters are often very implemented and don't follow the RS232 spec very well. Once I switched to a proper serial port it was fine.

At the BBC end, the data is written out to disk. It can also work in reverse, so you can create .ssd images from real floppies. Since I'd found some of my old disks with the cable, I too the opportunity to read archive those. So that's worked out quite easily, no additional hardware required, other than the cable, and no need to even open up the BBC. DFS Explorer, can be used as downloaded, or you can register for £5 to support the author, which I always like to do when I find something useful like that.

This works in a similar way to CBMXfer that I've used to transfer disk images from PC to a Commodore PET and a Commodore 64. Although in the Commodore case, the drives are intelligent, so the PC interfaces direct with the drive, rather than needing to use the computer as a slave. There is also something similar under way for the Spectrum, ZXTrans. The Spectrum is short of a serial port, so I am working on building a modern replacement for the Interface 1, to give a Spectrum a real serial port, or more likely, a USB connection with a microcontroller acting as USB-serial-Spectrum.

All labelled and ready to go. Now I had better test that Repton has transferred over properly, make sure all of the levels work correctly.....

Which PETs support which PET microSD

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

This post has been left for historic information. The PET microSD is no longer in production. The replacement SD2PET is available now, more information on the pre-order page.

Not sure which PET microSD is most appropriate for your PET?

Models	PET microSD Horizontal	PET microSD Vertical	PET microSD Internal
Features	plugs into back easy to access datasette power easily removable sticks out a bit	plugs into back easy to access internally powered no external wires low profile	internally fitted fit and forget internally powered no external wires low profile
2001	✔(B)	✔(B)(P)	✔(B)(P)
2001N	✔	✔	✔
3032	✔	✔	✔
4032	✔	✔	✔
8032	✔	✔	✔
8096	✔	✔(P)	✔(P)
8296	✔	✔	✔(E)
8296D	✔	✔	✔
CBM-II*	✔	✘	✘
8032-SK	✘	✘	✔
8096-SK	✘	✘	✔(P)
VIC20	✔(I)	✘	✘
C64 / C128	✔(I)	✘	✘
C16 / Plus4	✔(I)(P)	✘	✘

(B) - BASIC v1.0 does not support any IEEE-488 drives, so an upgrade will be required - see below.
(P) - Alternate power connection required - let me know when ordering
(E) - The internal board would need an extension cable as capacitor C1 is in the way inside the case
(I)  - IEEE-488 adapter required - see PETmicroSD on a VIC20
 *  - Tested on CBM-II B710 and B720 with DOS 1.25 and CPM 86. Should also work on the B128 and the 600 and 700 series CBM-II machines as long as they have datasette and IEEE-488 edge connectors


If you see the BASIC 1.0 screen when you power on

*** COMMODORE BASIC *** 

and not BASIC 2.0

### COMMODORE BASIC ### 

 or BASIC 4.0

*** COMMODORE BASIC V4.0 *** 

then you need to upgrade to make use of an IEEE-488 disk drive, such as the PET microSD. The easiest way to do this is with one of my ROM/RAM boards. This is a solderless and reversible upgrade that gives selectable BASIC 1, 2 or 4 and 8K, 16K or 32K of RAM to your 2001.

UPDATE: These are current out of stock, click here to pre-oreder a 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

In the style of the table above, this is the compatibility of the SD2PET:

Model	SD2PET
Features	plugs into back easy to access datasette power easily removable sticks out a bit
2001	✔(B)
2001N	✔
3032	✔
4032	✔
8032	✔
8096	✔
8296	✔
8296D	✔
CBM-II*	✘
8032-SK	✘
8096-SK	✘
VIC20	✘
C64 / C128	✘
C16 / Plus4	✘

(B) - BASIC v1.0 does not support any IEEE-488 drives, so an upgrade will be required 

* - The 2MHz CBM II machines do not give the drive as long to reply as the 1MHz PETs, and so the SD2PET does not always respond in time. Consider these unsupported.