This is an old post, preserved for reference.
The products and services mentioned within are no longer available.
This is the fourth part of the restoration of a Commodore Pet 'Fat 40' 4032. You might want to start at
Part 1. The story so far: empty 4032 case being filled with parts from a donor rusty 8032-SK. The main board has been cleaned up and using the ROM/RAM replacement board, the Pet has booted, but there is garbage on the screen.
There is a lot you can tell from the garbage on the screen. It's very useful to be able to trace through the schematics at this point, and again I refer the to invaluable resource at
zimmers.net. The pet video uses separate screen RAM, on the 4032, this is 2 x 2114 SRAM, giving 1K bytes. This can be read or written starting at address 0x8000, accessed via two 74LS244 buffers. That is 1024 characters, enough for 25 40 character lines with one byte per character. So no pixel graphics here, just a single character per position. The address lines are multiplexed with the outputs of the 6545 display controller, and it accesses the screen on the clock half cycles when the CPU doesn't. The data is latched into a 74LS373 gate and used to set the address of the character ROM, it's outputs being fed to a 74166 shift register to generate the actual pixel data. This is similar to the way the screen is generated in the
ATMega328P video generator I previously built to drive the Pet monitor. This is running as fast as it can on the 16MHz clock, and isn't fast enough to achieve an 80 column display. To this, they added another set of RAM and buffers and latches and set them to do alternate characters, so whilst the odd RAM is setup for one character, the even RAM is getting ready for the next.
Here the screen shows 80 x 25 characters being generated, just not changing. But the Pet is working behind this, hold down a key until it gets to the end of the line and it beeps. If I had a suitable disk drive setup, it should respond to disk commands. However, nothing seems to change the screen. I found it useful to change to the test ROM, this alternates between a character set and memory test results every couple of seconds. This is useful as it should be writing to the screen RAM every couple of sections. However, when I checked, there didn't appear to be any write signals going to the screen RAM chips. That would explain why it wasn't changing.
The write signal is generated by UC3 a 74LS138 3-8 line decoder. This is a bit odd as one of the inputs is tied high, so it is only working as a 2-4 line decoder.
Also strange is one of the outputs is tied high? Pin 13 is definitely an output, so why is it tied high? I took the '138 out to check and replaced it and I now started to get write pulses to the video RAM. But still no change to the display? Probing further, it looks like the main buffered data isn't changing, and I traced that back to a 74LS00 gate, UE11, which is meant to invert the read / write line to enable the two data bus buffers UB9 and UB10. The output seemed to be stuck high, so I removed that. It's nice to get confirmation when you remove a chip like this, I use the Minipro programmer which has a test function for logic circuits.
Here you can see the 74LS00 does indeed have one failed gate. With that replaced, there was a change in the garbage on the screen.
It is now changing, but it's still mainly garbage, but at least it's different garbage. This should be showing 'gggggg' for the first half of the screen. The second half is expected to be full or garbage as the memtest is designed for 40 character monitors. It then alternates to a character set, so should be 'abcdefg' etc.
So there are two different problems here. Firstly, it seems to be composed of 16 characters ok, 16 characters garbage, 16 ok etc. That looks to be due to addressing, tracing out showed a break in the buffered address line BA4.
Fixing that removed the 16 on / 16 off problem, and I got the screen have full of 'ogogog' this time. Going back to the 80n50 Pet ROM, and we have a boot screen, and the keyboard is responding. Although every other character is wrong. It should say
### commodore basic 4.0 ###
31743 bytes free
ready.
but it is showing
Checking the
PETSCII table, the 'c' in commodore would be 0x43, but it's actually 'k' which is 0x4b. Space should be 0x20, but it's showing 0x28, '('. However, some were right, the 'm' was 0x4d as it should be. Checking the other characters, it seems that bit 3 was stuck on, and due to the Pet's odd/even switching this meant it was the even half. That rules out half the chips and I tracked it back to the 74LS244 buffer UB3. Replacing that, I got a proper display at last.
A few keys weren't working (the keyboard needs cleaning), but there were sufficient to test it in the traditional way.
I still need to adjust the screen, but I'll wait until it's back in it's case. Now the display side is working, lets see if we can get rid of the ROM/RAM board, and
fix the ROM and the RAM....
