PET Diagnostics - Upcoming Project Preview

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

This is a preview of an upcoming project. Not sure if the name will stick, but at the moment it's called PET Exerciser (UPDATE: it didn't, it's now called 6502 Diagnostics). This started when I was repairing a few PETs and was using a NOP generator. This idea of these is the hard wire the NOP instruction onto the processor databus, the end result of that is it just steps through all the addresses sequentially, continually. That is useful to check address decoding, and see if chip enable pins are pulsing in the right way. The trouble is the 1MHz 6502 based NOP generator is a bit slow to check high address bits on a scope (at least one without digital storage), but too fast to check by eye.

I got to thinking, could I adjust the clock rate fed to the 6502 to get the pulses into a more usable range? Before I started looking at that, I thought that it would be easier to just bypass the 6502 all together and use a couple of 8 bit counters to cycle through all the address bus at whatever speed I chose. I did look at a few options for that, but it was going to be a bit messy as it would have ended up with 4 x 4 bit counters and a pulse generator, which was maybe going to be an 8 pin microcontroller. I then thought I could just use a microcontroller. And lo the PET exerciser diagnostics was born.

I then got to thinking, if I had a few more pins on the microcontroller, I could access the databus and some of the control signals as well. Hmm. interesting. The prototype doesn't look as neat as that final PCB will.

Under that mass of wires is a Commodore PET, and on the breadboard is a micrcontroller, the DIP version of the one I will use on the final board. The microcontroller is connected to most of the pins in the 6502 socket. There isn't an actual 6502 involved any more. Before I got around to writing the code for the NOP generator. I was interested to see if I could actually drive the PET hardware to do anything interesting.

This is the first test was a screen of incrementing characters, but as I got the hang of writing the PET video RAM, that quickly grew into a character table. If nothing else than to help me work out what characters to write the the video RAM to show on the screen - it's PETSCII, not ASCII. Since I can now write to RAM, I can also poke things, and one useful poke on the PET is to change character sets from business mode (with uppercase and lowercase letters) to graphics mode (without lowercase but more symbols. This sets CA2 on the VIA which controls the high address line on the character ROM.

Here you can see the PET board I was testing has a faulty character ROM, some of the symbols are not displaying correctly in graphics mode. OK, this is proving rather interesting and should be very useful. What next? Well, let's test the RAM. I'm currently working on a 2001 board, so I've only set it to test the first 8K. I've split it into 1K blocks and tested by bit to help narrow down the faults.

The test algorithm I'm using is fairly simple, I'm just poking various values and reading back. I'm recording any bits that are different from the values written, and here it has picked up 2 errors on one RAM chip. This matches what BASIC was showing when the PET was running, it only detected the first 1K of RAM, so was showing around 800 bytes free. I've removed the chip I think it is, and retested.

Good, it's showing 400 errors (that's 400 hex, 1024 decimal), all in the lower nibble, which is exactly the area served by the 2114 chip removed. I tried to lay the screen out to match the orientation of the chips, so the second row of 2114 chips, right hand side is the culprit.

I replaced the chip and retested and it's now fine, and when I return this to 6502 control, it should detect all 8K of RAM again. The TMS2114L-20NL I have used there isn't an exact replacement for the TMS4045-45NL, but is enough to prove the point whilst I try to locate something better. I'll probably use one of the pair that are the video RAM, and replace both of those with faster 2114 chips.

You can see where I was also starting to test the ROMs. I've gone for a simple 16 bit checksum of the ROMs, and that seems to be working consistently. I've added a lookup table of CRC codes with descriptions for known good ROMs. I've got it plugged into one of my 6502 ROM/RAM boards for testing, so I have been able to get CRCs for most of the standard ROM sets already. This is a good way to identify faulty ROMs.

Here some of the 6540 ROM chips are working (I've given the chip numbers of the good ones), but the others are coming back with different CRCs. The CRCs have also changed on those as I have repeated the test, so I guess they are faulty, or since it is only the x000 ones that are working, there may be a problem with the BA11 line that controls the x800 ones. More testing required.

I've added in a test for video RAM before the screen is drawn, and inserted the results into the memory map. I'm testing the full 2K region, but the second 1K is a mirror of the first, apart from 80 column systems. I've also expanded the address ranges to test the 32K and 4K ROM sets on a 4032 system. These two modes may be a different build, jumper selectable, or maybe by a menu?

I'm getting a bit carried away, there are so many possibilities here, and I think this is going to turn into a very useful piece of kit. There any many more things I plan to add, such as scanning the keyboard to test the keyboard, and also to control a menu system to cycle between various tests. I can also add testing for datasettes, IEEE-488 drives and even printers. I need to look into initialising the CRTC on later PETs so they can be used as well, and also reformat the screen for 80 column use. I could even include a simple BASIC interpreter....maybe not. It would also suit many other 6502 based machines, including the VIC20, BBC micro, and maybe some of the Atari 400/800 series. Anywhere there is a 6502 processor and a display that I can work out how to drive.

So just to recap, this is being generated on a real PET, with the PET exerciser in the 6502 socket. It's a microcontroller with it's own ROM and RAM. No 6502 code is executed. No actual 6502 is used. No PETs were harmed in the testing of this product.

UPDATE: I've decided to go with PET diagnostics. I have also added a reset button and disconnected that from the onboard reset, instead monitoring that to show faults with onboard reset circuits.

UPDATE 2: I've changed the board to just 6502 diagnostics, as I will be looking at other systems to use (KIM-1, VIC20, BBC etc.), I'll keep PET diagnostics as the on screen title for the PET version of the software. I've removed the reset switch, but kept the reset monitoring. I've added some DIP switches to allow screen mode to be set and maybe some other options. The PCBs have now been ordered.

UPDATE 3: The boards have arrived, but the PCB manufacturer has managed to mess up my design and rotated the ground pad of the main IC to short out several of the pins, including the +5V rail. This is what I had designed:

This is what arrived:

Now waiting for a second batch.

UPDATE 4: Still waiting for the boards, in the mean time, I've redesigned it a bit, with a bigger microcontroller. This now appears as a USB device and shows status in a serial terminal. This also has some analogue inputs so I can check the rise time of the power and reset pins (to check problems like I had with the Oric 1 repair recently).

UPDATE 5: I'll write this up properly once I have had time to do further testing, but the V1.1 boards have now arrived, with no pads rotated as far as I can see. The first one is now built up and being tested.

This is how it would be used, plugged into the CPU socket of a Commodore PET.

UPDATE 6:
More on the testing of these new board.

UPDATE 7:
The new boards are available now.

Upcoming Commodore 64 projects

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Here's a quick preview of a couple of upcoming Commodore 64 projects.

Commodore 64 pseudo stereo dual SID

This was inspired by a video from GadgetUK, where he modified a dual SID board to run two SIDs in parallel. Normally the dual SID board is used to add a second SID and a different address, to generate actual stereo from suitable software. The idea with this mod was to place two at the same address, so they could be driven from normal software. You may think that there is no point in doing that, they will both sound the same? Well, there is quite a variation in the sound produced by different SIDs, and the idea here is to exaggerate that by using a 6581 from a C64, and a much later 8580 from a C64C.

I raised the issue of a possible problem with two parallel SIDs when it comes to reading, as both devices will be selected, and both would try to write back to the databus. I suggested adding an OR gate to the chip select of the second device, so it would only be selected when the chip was selected and it was in read mode (or since it's all negative logic, it would NOT be selected if either the chip was NOT selected OR it was NOT in read mode). I said this could be implemented with a simple diode OR, and in the followup video, that seemed to be working nicely once the pull down resistor value was sorted out. To avoid any issues with that, I've used a single gate OR gate here, rather than a diode OR.

There are a few differences between the 6581 and the 8580. The power supply, filter capacitors and audio output amplifier circuit are all different. So what I've done here is to ignore the C64's filter caps and fit these onboard. I also ignore the power supply and have onboard 9V and 12V regulators, with the power to be tapped from the main power supply filter capacitor. I've left the audio from the main SID going to the C64, but both audio signals are also buffered onboard and fed to the audio output jack.

Commodore 64 PLA replacement with EPROM
Replacing the commonly faulty Commodore 64 PLA with an EPROM is something I tried a few years ago, with mixed results. I also tried to make a replacement using two GAL chips, but didn't get very far with that.

Following another video from GadgetUK, he seemed to have more success using the EPROM method and adding a 68pF capacitor to the /CASRAM line. The issue here is that due to what could be considered a design flaw in the C64, the /CASRAM line needs to be delayed by about 25nS to allow the addresses to be ready in the multiplexer before they are loaded into RAM.

I've updated my board to have space to add a suitable capacitor. These probably needs to be tuned to each board, depending on the type of RAM used.

To make this more repeatable, I've added a quad OR gate to add a configurable delay. Each gate has a propagation delay of around 9nS, so with the jumper you can select to tap the signal after 1, 2, 3 or 4 gate delays. This will add 9nS, 18nS, 27nS or 36nS delay to the signal .These timings are approximate, but are typical values. I can also shorten or extend this by using a different logic family chip.

PET microSD V2.0

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.

I've designed some new revisions of the PET microSD, taking onboard some feedback from the original version. One user had a problem with power supply. The PET's 5V rail is a little overloaded on earlier boards at best, and sometimes when the capacitors dry up a bit the rails can take a little long to rise to the appropriate levels. Upping the brownout protection on the microcontroller helped in this case. I've never been happy tapping the 5V rail, so I've added a switch mode 5V regulator to the board, so this can now run on anything from 7V to 22V, which with come from the main reservoir capacitor, which is around 9V DC, or the 18V rail which feeds the 12V regulator.

There are two new form factors, the original stuck out the back of the PET, and to reduce the size, I had parts on both sides. This was quite lot of effort both to design and to build. For these new versions, the size is not as critical, so I've also moved everything onto the same side, so it will be easier to construct than the previous double-sided load board.

The first new version is a vertical board. All on one side, and with the new switching regulator, this plugs into the back like a ZX81 RAM pack. This will take up less space than the previous version, and should be easier to construct.

I've had a few requests for an internal mounting version. Whilst I did have one for an 8032-SK, the 8032 and it's predecessors if more of a challenge. It's not 100% internal, there needs to be a small loopback plug on the back. This has an edge connector to allow connection to external drives as well.

Inside a flat board plugs into the pin header on that board. Again, this is now single sided, and using a switching 5V regulator. It's difficult to picture how this will fit, this boar will sit flat on the inside of the case, just above the IEEE-488 driver chips. It should fit 2001-8032 boards, and also the 8032-SK.

These new versions should be available from the end of the month - UPDATE - these boards are available now. See the new PET microSD range.

Finally, I've built up a litlle IEEE-488 extender with LED indicators showing the status of the various lines. This is mainly to help my testing, and save wear on the IEEE-488 port of my poor 4032, but if anyone else wants one, let me know.

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