Commodore PET checkerboard and one odd character on the screen

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

When you have a problem with an early Commodore PET, you often see a screen full of random characters.

Less frequency, like this one, you get a screen with a check pattern.

This is made up from character 255, which is four squares, two black and two white, something like a slice of goth battenberg.

That is caused when the video RAM is not reading correctly, and the data lines all read as 1.

That can be caused by the RAM chips, the latches that read out of them, or the enable lines that control all of the above.

This board had one of my PET ROM/RAM boards fitted, but that hasn't fixed the issue, so it had been sent it for repair.

In this case, the problem with the screen was not the main issue, everything was running hot, and the current draw was about 3.2A (this photo was taken a bit later when the initial problem has been resolved).

The 6540 ROM and 6550 RAM chips often run hot (as they have lots of issues with failing enable lines and bus contention), but the CPU and IO chips were also warm, so something was a bit wrong.

Checking around the board, the 74154 is used as the main part of the address decoding, and generates 16 enable lines for each 4K block across the address range. All of the outputs were low. Everything was enabled at the same time. I powered it off immediately and did a bit more checking around, and I thought it best to remove all the ROM and RAM chips at this stage, in case they were still OK.

I had noticed and fixed a couple of chips with bent legs, and one with a missing leg. Not ideal, but not enough to cause these problems.

With the ROM and RAM chips and the IO chips removed, I replaced the CPU with a NOP generator and started probing around to see if the 74154 was at fault. All the clock inputs were there and wiggling up and down nicely in sequence, but all sixteen outputs were low. I would have expected that was a faulty 74154, however, one other thing I noticed was that the 5V pin was also low, measuring 0.6V in fact.

The PET 2001 board has four of these 7805 regulators, but they are not commoned, and run different sections of the board. The regulator which runs the 74154 and the ROM chips was the one that had failed. Often this can be caused by a faulty chip pulling the rail low, so I tried initially lifting the output leg of the regulator and checking it's output, and it was still low.

Just to be sure, I lifted all the legs and connected the output of one of the other regulators to the missing rail (I used the one that powers the RAM chips, since they were currently removed).

Powering that up, the rail was back to 5V, and the outputs of the 74154 were doing the right thing, so I replaced the 7805 with a new one and removed the wire link.

With that fitted, and the link removed, all the rails were back, so I started putting things back.

I fired it up with a ROM/RAM board fitted and it all seemed to be working.

I started refitting the RAM chips, the minimum required is 2K

So far, so good, so I went for the full 8K. I had to fix the bent pins, and the one broken leg.

The full 8K was working, and remarkably, all the ROM chips were also working. 8K RAM and BASIC version 1.

I don't think I've ever actually seen a full working set of 6540's and 6550's as they are so good at self destructing. The current draw with all those installed was just under 3A (the picture from above).

I ran a memory test (having to load from tape since I couldn't use an SD2PET) and it passed, I swapped out two of those chips with the video RAM, and retested, but I was still seeing the odd issue on the screen (more on that in a moment).

However, given their fragility, and as BASIC 1 has some bugs, and doesn't support disk drives, and 8K RAM is a bit limiting. I would recommend putting them away for Sunday best. If you actually want to use the PET, use a ROM/RAM board instead and get 32K and BASIC 4.

Without the 6540 ROM and 6550 RAM chips, the current went down to under 1A, so a definite improvement, less power, less heat, less stress, greater reliability.

With that, the PET seemed to be working, there was just this odd single character that was occasionally showing the wrong thing. Here you can see an asterisk about half way down the screen.

Normally that is down to a bad RAM chip, but here it didn't seem to be related to the RAM chips, as they were passing the RAM tests and the same fault was persisting when both chips were swapped out.

The same fault would come back at other times, but generally in one of two positions, the 32nd character of the 13th line, or the 16th character of the 7th line.

If you add those up, that works out to be the 256th and the 512th characters on the screen. Hmm, powers of two. I had a theory, and to test it, I waited until it was showing the asterisk and then moved the cursor to the top left of the screen, the 0th character, and typed in a letter A.

Well, would you look at that, the 256th character also changed to an A. So what I think is happening is the counter which generates the video address is a bit slow when it comes to read the 256th character and instead is reading the 0th. The address changes from 00FF to 0100, I think it is one of those cascaded counters where each bit turns over slightly after the previous one (I had a similar problem with the Minstrel 3, seen here glitching between 3 and 4).

So, rather than going from 00FF to 0100, it occasionally goes to 0000 briefly between 00FF and 0100, so at the time it is drawing the screen it reads the character at address 0000 rather than 0100.

I spent a while trying to trace this through the schematic, and with a tangle of wires and a logic analyser, but I couldn't see anything conclusive.

There are three counters, the first two bits use the two halves of a 74107, and the last 8 bits use two 74177s.

The video RAM is accessed by both the video circuitry and the 6502 CPU, and the two address busses are multiplexed using three 74157s.

74157s do work hard, switching continually at a very high speed, so they are a bit prone to fail or start switching things slower, so could explain some of the bits of the address being delayed. Unlike the counters, these are still in production and available, so I thought it would be a good bet. I also noticed that two were 74157s and one was a 74LS157, so not particularly well matched.

I replaced the one which switched the higher address lines, and initially it appeared to resolve the problem, but all it did was reduce the frequency of the problem, and it did come back. I thought it was best to replace the other 74157 and the older 74LS157 with new 74LS157s, to make sure they all switch together. That again seemed to help things, but I could still get it to happen occasionally during IO operations.

In the end, it was replacing the 74LS107 counter that fixed it. I've run the board for a long time with the PET ROM/RAM board, 32K BASIC 4 and an SD2PET.

That's all done now, quite an odd problem, but I've not been able to recreate it after several hours testing, and also a cold start the following morning, so that seems to have fixed it.

A ZX Spectrum with 80K of RAM?

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

This ZX Spectrum apparently has 80K of RAM.

The image was posted on Twitter by Claire, ZX Claire, and I was intrigued as I hadn't come across the East London Robotics SP80 upgrade kit before.

The kit is to be used to upgrade a 16K ZX Spectrum to 80K, the base 16K, plus the normal expansion of 32K giving the 48K plus a second bank of 32K accessible via an OUT instruction to take it to 80K.

It looks a little bodged, but that was the product as supplied.

Issue one Spectrums had 16K on board, and two sockets at the back to fit a 32K RAM module, but by the time they got to issue two, the extra RAM had been integrated onto the mainboard.

You could still buy 16K versions, and later upgrade them to 48K, there were sockets where the eight RAM chips and four logic chips required for the upgrade could be installed. Later machines were supplied as 48K as standard and these parts were soldered directly to the board.

The logic chips between the ULA and the Z80 handle multiplexing the address bus for the RAM chips. IC3 and IC4 are for the lower 16K of RAM (present on all Spectrums) and the other four chips are for the initially optional extra 32K.

The RAM used was normally marked 4532, and was a little unusual in that they were 64K x 1 RAM chips that had faults, but at least half the chip was OK, so they were sold as 32K x1 RAM chips so only the good sides would be used. This is sometimes reported as a cost cutting measure, which it was, but also, 32K was all that was left in the address space after the 16K ROM and 16K RAM already present were used, so it was better than wasting 32K of good chips, or fitting 16 16K chips.

There were two types of 4532, one where the top half was good, and one the bottom half. This was selected by a jumper on the board, maked LK3 and LK4 on the schematic. You occasionally see a wire link from pin 10 of IC26 to it's ground pin or 5V pin so the user could install the chips without having to change the link.

I've redrawn the relevant section here, the 74LS157 mux chip is used to set the address to be accessed in two sections, a row and a column. That is how DRAM seems to like it, it keeps the pin count of the RAM chips down.

Here the first part of the address is made up of A8, A7, A14 and A9. RAM doesn't care what order the address lines are in. You read back from the same location you wrote to, so it's not important what order they are in. The second part is made up on A1, A0, A2 and where there forth address would be is either tied high or low, to access only the top or bottom half of RAM.

The upgrade kit was supplied with 4164 RAM chips, full 64Kx1. (pictures of the modified board kindly supplied by Claire). The kit adds some logic which forms a latch, so that the extra line on the mux chip is switched from high to low under software control, and indicates which bank is active with an LED which would shine out of the expansion port.

There is an extra logic chip (a 74LS02) sitting on top of the 74LS157 mux chip, soldered to some of it's pins, with wires going to the 74LS00 and 74LS32 chips that were all part of the upgrade.

Some of the pins of the 74LS00 are bent up. Originally, only two gates were used, so the spare gates are used as part of the logic.

I reverse engineered what was going on from the Spectrum issue 2 schematic and the photos. There's a little bit of guess work going on here as I think there are some links under the chips and the connections between the 02 and the 157 underneath are unclear as one is 14 pins and the other 16 pins, so it's sitting between the pins.

I've redrawn it for clarity, this is what I think is going on. The circuit does indeed drive the extra input to the 157 mux, with the state being shown by the LED. Starting on the left, if A7 is low and /RD is low, then there is a write operation where bit 7 of the address is low, and the output of IC26U.2 is high (that is the 02 which is above IC26). Next if MREQ is high, then it is not a memory request, so it must be an IO operation. If those two are high, the output of the gate goes low. That signal is used as the trigger for the rest of the circuit, it only goes low when there is an IO write operation with bit 7 low.

Anyone still following? That signal going low causes the output of IC24.4 to go low irrespective of the state of the signal driving the LED. This then feeds one input to a flip flop made up of IC26U.1 and IC26U.4. The output of IC26U.1 then goes low and the LED turns on. That then feeds IC26U.3, if A14 is high, that won't make any difference, and the state will be latched with the output low and the LED on. However, if A14 is low when this happens, then the other half of the flip flop is triggered and the output is latched high and the LED goes off. I think the 3K9 resistor delays things slightly to make sure the sequence is followed.

This tallies with the manual, to activate 'page 2', type OUT 65407,0. 65407 is FF7F in hex, or 1111 1111 0111 111 in binary, so you can see bit 7 is low. (the ,0 is irrelevant as the databus is not connected so you could use any value). To switch back to 'page 1', type OUT 49023,0. That is BF7F, or 1011 1111 0111 1111, bits 14 and 7 low.

That's it for the moment, I think the reverse engineered schematic is correct. I need to dig out a suitable machine to try this out on. It is an entirely reversible mod, as all the wiring is between the chips in the sockets that would have been part of the kit. I would also be interested to find any software which can make use of the extra RAM, otherwise it's interesting but essentially pointless. I don't think this was around long enough to gain traction, and as soon as Sinclair started shipping boards with 48K as standard and no sockets, this was no longer an option and so this didn't gain the ground it may have done if it had been available for later machines.

Stop Press:

Claire has found another one, this time buried inside a DK Tronics case, along with a whole lot of other stuff!

This one looks like it has a switch to disable the mod (maybe it caused some issues with software inadvertently writing to an IO address with bit 7 low?). It's not clear how that is connected as it is covered with tape, but my guess would be pulling the end of the 3K9 resistor to ground to stop that half of the flip flop from being activated.