Tynemouth Software LLP - Old computers, New computers, Bespoke Web Design and Software Development, Computer repairs, IT and Media Services - www.tynemouthsoftware.co.uk
Wednesday, 9 November 2016
PET Diagnostics update
I've been repairing a few Commodore PET boards recently, and have been tweaking the firmware in my PET diagnostics boards to add some new features.
I'll start with an important statement, as this board sometimes gets misunderstood. It is not a 6502 emulator, it does not run 6502 code*. It plugs into the 6502 sockets and tests the memory and other devices inside the PET.
The first is an 8032 board, slightly unusual in that it is the German DIN version with alternate edit ROM and character ROM. This is not producing any output, so time for the PET diagnostics board.
With that in place, there was output on the monitor. Not quite the right characters, due to the alternate character ROM.
I temporarily swapped in a standard 901447-10 character ROM for the purposes of the later screenshots, but you can see from that there are three unknown ROMs and one with an inconsistent CRC. The unknown ROMs were the Extended BASIC Level 1 and 2, and the DIN edit ROM. I checked those with references ROM images and added them to the database.
It still wasn't booting, and the Kernal ROM was still reporting an inconsistent CRC - the value is calculated by reading the ROM through and this is repeated several times. If the calculated checksum is not the same each time, it's likely the ROM is faulty and so is reported as 'inconsistent CRC'.
With an EPROM installed to replace the ketnal ROM, that test passed. Back to the original 6502 chip and, the PET booted fine. I ran through the usual tests in BASIC and no other problems were found. That one wasn't too bad, just the one EPROM to replace.
Next was another 8032 board. When powered on, this was dead, no video output, no chirp. This time, with the PET diagnostics installed, there was still no display, and rather than a black screen with nothing on it, this was a case of no video signal being generated, so the machines has not booted up far enough to initialise the 6545 CRTC and clear the screen. Lots of things can cause that, bad ROM, bad RAM, faulty 6545, decoding logic, power supplies, reset circuit etc. all sorts of things
When the video circuits aren't working, I have been pairing the PET diagnostics with my PET LCD board, this also plugs into the 6502 socket. It has all the features of the PET ROM/RAM board (replacing onboard ROM or RAM for repair or upgrade), but also mirrors the video RAM and generates a pixel perfect replica of the PET display on a 2.2" TFT display.
When used together you can take a dead PET board and work out what is wrong with it. I plugged the PET diagnostics and PET LCD into the 8032 and powered it up.
This showed everything was broken. Now it is possible that everything was indeed broken, all the RAM was faulty, all the ROMs were faulty, but it is more likely that something is affecting everything else. This could be a ROM or RAM chip or buffer permanently pulling one of the data or address lines high or low so that everything reads wrong. If it was a data bit. that would normally show up in the tests above as a whole column of errors but the rest OK, an address bit can cause problems across the board.
I've added some tests on power up. The address and data lines are read when floating. These values are indeterminate normally, but if a bit is stuck, will be fixed high or low. The next test was to enable the weak pullups on the microcontroller, so all lines should now read as high. Any that don't have something pulling them low, which is a problem. In this case, several lines read as low.
The oscilloscope showed the horror story that was the databus. In normal operation, this should be high (4-5V in general), or low (0-1V in general). Nothing should be in the middle as this is indeterminate high or low. This indicates that several devices are trying to write to the address bus at the same time, which usually means there is something wrong with the address decoding logic.
I temporarily added a bit of code to the PET diagnostics to work as a NOP generator and alternately to pulse the address and data lines. In this case, a bit of probing around showed the 74154 was faulty. It is fed with the top four address lines, and it's 16 outputs should all be high apart from the 8K block selected by the address lines which should be low. In this case, all the lines were low, all the time. This means all the devices were enabled, all the time, explaining why the data bus was so busy.
With a new 74154, everything calmed down and came back to life. The CRTC initialised properly, and I got output on the monitor, but still not 100%. Back to the normal code in the PET diagnostics board.
The edit ROM wasn't giving the right checksum. I replaced that with an EPROM and all then everything passed. I tested the removed ROM externally and it was indeed bad.
The final test before returning to 6502 control was the character ROM. I've expanded the test pattern so it fills the screen on 80 column systems. The character ROM looks OK, and the usual BASIC test programs loaded from PET microSD ran fine. Another PET board repaired, still not too bad this time, just one ROM and a bad 74154.
The next PET board was different story. This time a 2001N board, slightly unusual as this came out of a 2001 case with the chiclet keyboard and built in datasette - I thought they were all the 2001 style 5V only boards not the later dynamic RAM type, so this may have been swapped out at some point in the past, presumably with the power supply replaced as well.
This one is going to need more work. It's video output was dead, which is unusual on these boards without the CRTC as the video circuits will generally work with no CPU, ROM or RAM on the board as they just scrape data from the video RAM and send it to the screen, giving the screen full of random characters you often see.
A couple of chips have been replaced around the video circuits, the 74165 looks like the original chip which has been removed and then socketed? I'm usually suspicious of any previous repair as there is always the potential of damage under the sockets, lifted tracks or missing through hole plating.
Time for the PET LCD, this time with a real 6502, to see if the board is running and test if it's just the video circuits at fault. No, I got a screen full of random characters on the PET LCD, which is what I would have expected on the monitor if the video circuits had been working, What it's actually showing is the contents of the 1K of duplicate video RAM. Nothing has been written to this RAM, hence it's contents is somewhat random, although mainly '@' which is 0x00.
Back to the PET diagnostics again. As well as checking the stuck pins on startup, I am checking the reset line to see if it comes up, and measuring (approximately) how long it takes to come up (around 1 seconds is usual), and checking the NMI and IRQ lines to make sure they are not stuck.
Here the reset and NMI lines are OK, but the IRQ line is stuck low, as is most of the data bus. Again the scope showed a bit of contention on the data lines.
This board is still in progress, as I need to get to the bottom of the video problems, more about that in a later post. The IRQ stuck was due to one of the 6520 / 6522 chips, I removed them all, I will replace them one by one later to find the culprit. The data line problems were due to a bad ROM, again to be identified later.
Now those problem chips were removed, it still wouldn't boot, so back to the tester to check on the RAM and video RAM.
OK, lots of faults here. The video RAM is only showing faults on one bit, which suggests the data bus is probably OK, and one of the 2114 chips is faulty. All the RAM is failing. These are 4108 chips, so that's quite possible they have all failed. These are 8Kx1 versions of the usual 4116 (16Kx1), and and also very susceptible to failing if all the supply rails are not there is the right order all the time. However, the ROMs are not returning empty (since the sockets are empty), but random values, which suggests there are still some address decoding problems to sort out, something is affecting the databus when the ROM addresses are being read, so the same could be affecting the RAM, but apparently not the video RAM? More on this board later I'm sure.
More to come with PET diagnostics and PET LCD as well, as these are proving very useful tools. I have been working on a USB version with serial output, and I'm currently designing a more compact version of the PET LCD.
The PET diagnostics board is now available with the V0.70 firmware, you can order one below.
If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.
* that should read 'doesn't run 6502 code yet'. I might add that in future, but probably not.