6502 Diagnostics Tester

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

I've been building a few more of the 6502 Diagnostics boards to run the PET diagnostics firmware.
It's a fairly simple build, but the microcontroller package is quite small and can be difficult to solder.
Before putting one of these anywhere near a PET, I want to make sure that all the pins are connected, and there are no shorts etc.

Most of the times I use a microcontroller, I would use the internal RC oscillator, or more often a crystal or ceramic resonator. In this case, the microcontroller is driven from the system clock, so it needs an external 1MHz clock fed to one of the pins. Once the configuration fuses are set to use an external clock, it is no longer possible to program it without that external clock being present. In order to program and test the boards, I need a clock and some way to monitor the pins. When testing the first ones, I used a signal generator and logic analyser, but that's not really practical to setup each time I built a batch.

I can't use the built in clock generator, so it needs an external clock. I looked at a few options, using a similar style to the PET, using a crystal and a couple of logic gates to form an oscillator, but I would need to add some more to divide that down to 1MHz. I also considered just using a 555 times, but that wouldn't be fast enough, I think a few hundred KHz is the limit there.

I then had a look around at self contained 4 pin crystal oscillator modules, I had a few, but they were all too high frequency. After looking at various options that were too fast, or too slow, and all involved a few too many parts, I went for an easier option.

This is an ATtiny45, a small cheap (<£1) 8 pin microcontroller. This has an internal RC oscillator and can be set to feed this to one of the output pins. The RC oscillator is 8MHz, but it can be set to divide by 8 internally, giving 1MHz. Perfect. In the end, I didn't actually write any code for this microcontroller. It was all done with the fuses. Set it to RC oscillator, divide by 8, clock out on PB4. For those playing along at home, this was all it took:

avrdude -v -pattiny45 -cusbtiny -e
        -U lfuse:w:0x22:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m

With the clock sorted, I needed to add some way to test the output, lets face it, it was always going to be flashing LEDs. I had some 20 way LED bar modules I use for the IEEE-488 diagnostics board, so I used a couple of those. Nice and simple one LED per pin, LED on if the pin is high.

That fitted neatly on a small prototyping board, but there wasn't space for the usual SIL resistor arrays, I also didn't have enough of those at hand, so I went for adding those resistors on the back, using 1206 surface mount resistors soldered to a common ground wire.

That all worked out very neatly. The microcontroller is hidden under the socket, only three pins are connected, 0V, 5V and PB4 which is clock out that goes straight to the clock in pin of the IC socket.

There are two 0V and one 5V connection on the 6502 socket, these are wired so they will always be lit. The clock output will always show as half brightness as it is a 50% duty cycle square wave. It's a buffered output from the microcontroller, so is more than capable of driving an LED. Time for some testing.

I added various test patterns to the software to check for missing connections, shorted pins etc. Here it spotted two shorted pins on another board, you can just see the two faint LEDs on together. in the middle of the bottom row.

With all that verified and the normal firmware loaded, time to test the newly built 6502 diagnostics model on a real PET.

Working nicely (once I set the DIP switches correctly).

A useful bit of test kit for when I build these boards, and it should be useful for the future USB serial driven versions as well.

If you would like one of the 6502 diagnostics boards (not the LED tester board!) with PET diagnostics software, you can order one below.

PET Diagnostics

System like the VIC20 or Commodore 64 have cartridge slots, so can run diagnostic software from there. The PET does not, so this is my new 6502 diagnostics board, a board which fits in place of the 6502 CPU in systems such as the Commodore PET to run diagnostics checks on a non-functional PET.

It controls the system under test from the CPU socket in order to test RAM and ROM and other system functionality. This version has no external outputs (the 6 pin header is for programming), and instead uses the hosts video circuitry to report the results on screen.

The first application of this is on the Commodote PET, a fairly standard 6502 system with fixed areas of ROM and RAM (no paging is used until the 8296). This is running my PET diagnostics software which makes use of the PET screen and writes to its video RAM to generate a display.

Early Commodore PETs (the 2001, 2001N, 30xx and 9" versions of the 40xx) had no dedicated screen controller chip, and the video output was just whatever was written to the 1K of screen RAM. This leads to a common fault on these PETs of a screen full or random characters, which in many others systems would be a black screen error. These PETs will show this with no system RAM, system ROM and even with no CPU installed.

When the system is powered up with the 6502 diagnostics board in the CPU socket, it writes to the screen RAM and as long as that is working, a display is generated. Even if it is not working correctly, having known text written to the screen can often help diagnose what is wrong with the video circuits, in order to let you then get on with fixing the ROM or RAM or whatever else is wrong.

There are three tests implemented on the main screen. The first is testing main RAM. The PETs have between 8K and 32K of RAM. This is tested in 8 blocks of 1K, 2K or 4K, depending on the amount of RAM selected. The results from each block show which bits were bad within that block, and how many errors in total were detected. On early systems with 6550 or 2114 static RAM, each chip handles a 4 bit wide 1K block, so one bad RAM chip would show up as bits 7654 or 3210 faulty (or parts within).

Later systems used 4116 DRAMs, each a 1 bit wide 16K block. One of these being faulty will show up as errors on that bit over all the sections it covers. I may look at tying these up to IC numbers in a future version of the software. The counts shown are all hexadecimal, so 1000 errors is actually 0x1000 errors, or 4096 errors, or basically the whole 4K block.

The next test actually happened first, before drawing the screen, the video RAM was tested (since testing the video RAM writes the test characters all over the screen). The results are shown as one or two 1K block, for 40 or 80 column PETs. Errors again shown by bit. Here some partly faulty video RAM can also been seen in the occasional invalid character being displayed.

The third test on this page is ROM 7 blocks or 2K or 4K depending on the system. The test is based on a 16 bit CRC of the ROM. I test this multiple times and if the result is consistent, I use a lookup table to show which chip this is. If the CRC is not consistent, this points to a fault chip. There are weak pullups on the databus, so empty sockets give all 0xFF bytes and a consistent CRC.

The 8032 I was testing here had a faulty kernal ROM, which showed gave an inconsistent CRC. So I was able to go straight to that chip, desolder it and replace it with an EPROM and the machine was back in running order.

When there are multiple ROM or RAM errors, it could be data or address buffers or address decoding, or it could just be multiple failures. 4116 DRAM chips don't last well if one of the three supply rails they need fail. If you have multiple failures, it it sometimes a cheaper option to go for a ROM/RAM replacement board, rather than replacing lots of chips. It can also be used to add more RAM or upgrade the version of BASIC.

The socket numbers are displayed next to the ROM results. I have actually had several PET boards in for repair which had all the right chips, but in the wrong socket. All being well, all those test pass and it holds on that screen for 10 seconds to check the results.

It then clears the screen and shows a character map. After a few seconds, the character set is changed and the alternate graphics / business characters can be seen. The PET has two character sets controlled by an IO pin setting an address line on the character ROM, so only one can be displayed at a time.

The original PET 2001 always had upper case characters in the range 00-1F region, and alternated graphics or lower case in the 40-5F range. Later PETs decided to confuse things and have upper case at 00-1F and graphics at 40-5F in graphics mode, but to switch things around and have lower case 00-1F and upper case 40-5F, which is why you occasionally get some software with annoying rEVERSE cAPITALISATION or symbols where the upper case characters should be like \aze or |litz.

After the two character maps, it goes back around and repeats all the tests, so you can just leave this running and check back to see if there are any changes to the ROM and RAM tests once the system warms up.

There are different amounts of ROM and RAM in PET systems, as well as other changes, such as the reversed character sets on the original 2001, and the CRTC initialisation on 12" 4032 and 8032 machines. Rater than having different builds for each machine, I have used a set of DIP switches to select the machine.

Sw1	Sw2	Sw3	Machine	ROM	RAM	Video
0	0	0	12" 4032	6x4K + 2K	32K	CRTC 40 col 50Hz
0	0	1	12" 4032	6x4K + 2K	32K	CRTC 40 col 60Hz
0	1	0	8032	6x4K + 2K	32K	CRTC 80 col 50Hz
0	1	1	8032	6x4K + 2K	32K	CRTC 80 col 60Hz
1	0	0	2001 *	7 x 2K	8K	no CRTC 40 col
1	0	1	2001N-8/3008/4008	6x4K + 2K	8K	no CRTC 40 col
1	1	0	2001N-16/3016/4016	6x4K + 2K	16K	no CRTC 40 col
1	1	1	2001N-32/3032/4032	6x4K + 2K	32K	no CRTC 40 col

If the machines is one of the 12" 4032 or 8032 systems with a CRTC chip controlling the video, this needs to be correctly initialised before the screen will show anything, so 12" 4032 is the default setting.

Most of these are 40 column systems, the 80 column version just uses the left hand side of the screen, other than the border and title.

Using the PET diagnostics is just a case of removing the 6502 CPU, installing the 6502 diagnostics board in it's place and switching on. There is no 6502 processor in this system. The only code running is on the microcontroller on the 6502 diagnostics board.

I have various plans for this, I will be adding a second screen of tests for the VIA and PIA chips and the IEEE-488 port and any other things I can think of testing. I am also looking at adding a serial output to give the results on systems with faulty displays, but the real answer is fix the display first, then you can get on with testing the rest.

If you would like one of these 6502 diagnostics boards with PET diagnostics software, PET diagnostics board is now available from my Tindie store.

PET Diagnostics

UK Orders £42.50 GBP International £50.00 GBP

Update:
The new versions of this board are now red.

There is now a notch at the pin 1 end to ensure you get it the right way around.

Note:
* There appears to be some timing issues on 2001 boards with 6540 ROMs or 6550 RAM, so consider those not supported until I resolving the timing issues.

2024 Update:

The PET Diagnostics modules are available from my SellMyRetro store:

• https://www.sellmyretro.com/offer/details/64158

6502 Diagnostics Update

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

This is a quick update on the upcoming 6502 diagnostics module, and testing with some new toys.

The board is used to replace the 6502 CPU in an old computer system to help with system diagnostics. It plugs into the 6502 socket and will drive the data, and address busses and control lines to carry out various tests including ROM and RAM and address decoding etc.

The first version of this board arrived with an error from the PCB manufacturers, for some reason, they had modified my design and rotated the ground pad of the microcontroller, shorting out many of the pins.

The second version arrived as per the design, so time to build one up.

I started with a simple test just counting up on the IO ports to turn all the I/O pins on and off in sequence. To monitor this, I used a new logic analyser. I'd previously had a cheap Saleae clone 8 bit device, that did they job, but suffered from crosstalk, and all the clips had fallen off.

I did consider buying a proper Saleae logic 8 or Logic 16, but they were a lot more expensive than I could justify. I then found this DSLogic Pro, a $110 16 channel analyser on Hackaday, and thought that was worth a try. Still reasonably priced when you add on the unreasonable import duty handling fees.

It came with a nice set of leads where each one was thin coax with a separate ground and signal connection.

I wired this up to 16 of the IO pins and started counting.

Before I had ordered the Logic Analyser, I had tried out the software and found it easy to use. Unlike the Salae software, it zoomed and scrolled in the way I expected with the mouse wheel.

All looking good,  so I changed over to the next 16 IO pins and reprogrammed it. When I did that, I used the wrong options and set it by mistake to use the external clock, rather than the default internal RC oscillator it has been using. With no external clock, it wasn't running, and I couldn't program it.

In normal operation, it would get a clock from the host system, and I was using that so that all the IO operations would be synchronous with the system clock.

Time for another new toy, this is a FeelTech FY3200S signal generator on Bang good I'd seen a few reviews on YouTube. There were some concerns about the power supplies, every photo I have seen seems to show a different power supply board, they appears to be building these with recycled supplies.

The one I have seemed to be decent enough, some protection and reasonably creepage distance etc.

I set this for 1MHz and fed it into the CPU socket, and we're back in business.

Whilst I was there I tried out the range a bit, clocking it at 1KHz and 16 MHz.

Testing complete, now I can move on to running this in a real system. The initial testing on this had been done on a PET 2001 with 2114 video RAM.

The new board looks a lot neater. I'm still piggybacking on the ROM/RAM board so I can try different ROM images, and also because this PET has the tall sided sockets so needs the long pins.

The 6502 diagnostics board is replacing the CPU and driving the system, the current code is cycling through various tests, including RAM tests and ROM CRC checks. The results are displayed on the PETs own screen by writing to it's video RAM.

When I have tried this on a 2001 with 6550 video RAM, there are some timing issues I haven't resolved yet. The 6550 RAM timing is slightly different as it is synchronous and only writes on a clock cycle. I've tried this with one of my 6550 video RAM replacements but that is also showing the same problems, so it may be down to the memory interfacing differences on this model?

Running the board like this highlights an issue with using the host system video display as the output. If that is not working, you can't use the tool. Whilst waiting for the replacement PCBs to arrive I had already redesigned the board to get around this. V2.0 now uses a larger microcontroller, one with a USB interface.

This will be able to report status via USB to a serial terminal on a PC. Commands can be sent from the PC to change mode and request different tests. I'm thinking of things like pulsing particular address lines, or selecting addresses to see if chip select lines are activated, pulsing R/W lines to check buffering, etc. I should also be able to take analogue readings to monitor the rise time of the power supply and reset line (useful for things like the Oric-1 which had reset problems). More on that when the next lot of boards arrive.

Update:
The new boards are available now.