Commodore PET 64K / 128K RAM boards

This is a revised and updated version of a Patreon only post from 2020 about a project from 2016 that I might be bringing back in 2024.

Way back in 2016, I designed a board to add 128K paged RAM to a Commodore PET.

It was very much a 'because I can' type project. Not really that much use. The Commodore 8096 / 8296 had an extra 64K paged RAM implemented in the same way. The 6502 can only address 64K, half of which is RAM in the PET, the rest is video RAM, IO and ROM.

These board use paging to add extra RAM, so that is not accessible to BASIC (it lives behind the BASIC ROMs for a start). The machine would only ever report the standard 31743 bytes free, not 97279 as you might hope.

Only specially written machine code programs could make use of the extra RAM. I found a few test programs, a German office suite, an OS extension LOS-96, and a modern version the Infocom Z-machine interpreter (https://petsd.net/petfood.php?lang=en), but nothing else would make use of it.

This was Commodore's version, a 64K RAM board which could be added to an 8032 / 8032-SK to make an 8096 / 8096-SK. In practice, it would just sit there burning about 10 watts of power, with the ever-present threat of 4116 failure. Normally the best thing you can do is unplug them and revert the machine to a more reliable standard 32K machine.

The 64K on there is made up of 32 x 4116 chips, so as you can imagine, all of the 64K RAM boards I have ever seen have had bad chips.

I don't think this one is going to work.

These were controlled by an unusual intel D3243 refresh controller.

The rest of the board is taken up with the logic that controls the RAM board paging.

That board was mounted on top of the standard 8032 board to make an 8096, or in the top of the case on an 8032-SK to make an 8096-SK.

The functionality was later integrated into the mainboard of the 8296 (and 8296D), albeit implemented very differently.

I did find a 1980s third party version in a PET that came in for repair. That was less than half the size.

This was essentially the same, but used 4164 chips, so was less power hungry and maybe a little more reliable.

It looks like it also has space for up to four expansion ROMs.

Like the Commodore board, this plugs into the 6502 socket on the PET via a ribbon cable. Although it looks like it is damaged, these all have pin 8 (5V) disconnected and generate their own 5V on board.

I designed a replacement using two GAL chips and a single 128K RAM chip that would plug directly into the 6502 socket, like the PET ROM/RAM does.

There were also two logic chips, a 245 buffer and a 273 latch hidden under the other chips, and an LED array to display the status of the control register.

This plugged directly into the 6502 socket on the PET board and should do the same job as the Commodore 64K board, (N.B., that is the 64K RAM board from Commodore, and not a Commodore 64 RAM board).

Thanks to a spare bit in the control register, that should be able to provide a total of 128K of extra (pointless) RAM, not just 64K.

Everything is controlled by a write only register at address $FFF0. The status of that is shown on the LED. It controls two areas of 16K, each of which can be one of two banks (one of four in the 128K version). Also write protect of those areas and 'peek through' to the RAM and I/O address ranges which are in the same area.

The only problem was that it didn't work. The initial problem was the register kept getting reset to the wrong values and locking things up. That turned out to be a timing issue.

At that point I was having lots of issues with the GAL chips I was using. Never got down to what the problem was, I was blaming my equations, the compiler, the programmer, the GAL chips, and tried using various different types of each but kept getting inconsistent results (recompiling the same code would make it work, reprogramming the same chip would break it etc.).

I shelved quite a few GAL projects, including a dual GAL PLA replacement, which also sort of worked, but not consistently with Lattice GALs, or Atmel ones, with various different programmers and all sorts of settings on the WinCUPL compiler. (ed. I notice someone has since done one of these)

Roll forward to 2020 and I have designed the Mini PET and have gone into great detail with the RAM timings getting that working with the modern W65C02 CPUs. I've also now got Microchip produced F22V10C GALs. These should be the same as the Atmel ATF22V10C versions, but Microchip have been slowly dropping the AT prefixes.

Time to have another go at the PET 128K board.

I had to make a few modifications to get it working with the new CPU on the Mini PET, as the pinout and timings aren't the same.

Started off fairly simple, but as usual, got a bit more involved.

I hadn't fully understood the way the PET 64K RAM board disabled the onboard ROM and RAM. It is quite neat really. They disable part of the buffered address bus and four resistors pull the address up to Fxxx (I'm not swearing, I just mean any address from $F000 to $FFFF). The lower 12 bits are unchanged, the important thing is to move the addresses into the range of the KERNAL ROM.

This is used in combination with the /NO_ROM signal, one of the spare pins on the 6502 CPU socket which is used to disable all the ROM chips using a second active high enable line on the mask ROM chips which is normally pulled high.

The upshot of that is, when the expansion RAM board is active, it sets the address to somewhere in the KERNAL ROM $F000-$FFFF. The ROMs are disabled, so nothing on the PET board should be active and the RAM board can act.

I couldn't easily implement that solution, there was nowhere on the 128K board to bodge in a 244 or maybe a 157 to disable the address bus. Also, the Mini PET does not support /NO_ROM as that pin on the W65C02S has been reassigned and is now an output of the CPU.

As an alternative, I have gated the read/write signal. When the RAM should be in use, the PET board always sees a read operation each time, never a write. The 245 buffer disables the databus, so whatever is read is ignored, and nothing gets written to when the expansion RAM is in use.

Let's see if it works.

Success, I could see the test programs were running and the extra RAM was detected by Zork. With the extra RAM it takes three times as long to load, but there will be less disk seeking once you started playing. That would make sense if you have a slow disk drive, but with something like the SD2PET it doesn't make much difference when you are playing the game, but the extra RAM actually makes it worse because of the slower load.

Roll forward to later in 2020 and I updated the PCB design for these changes, now in white to match the Mini PET. But as the "your PCBs are in production" email arrived, I realised there was a problem. (normally at that point I just spot all the typos on the silkscreen, rather than design flaws)

I added a jumper to this version to downgrade it to 64K mode, in case there is some software which does not set the unused bit correctly and might accidentally switch to the alternate 4 banks.

The problem means that it works, but is not ideal in practice. Reads are generally safe, but reading some of the registers in the IO range has two problems, firstly reading some of the timer registers in the 6522 VIA causes the interrupt flag to be reset which may affect software using both timers and paged RAM at exactly those addresses (unlikely but not impossible).

But more importantly, the address decoding on the IO chips in the PET is minimal, so there are multiple ranges of addresses where the IO chips will conflict with each other.

I have borrowed this from a post I am working on about PET address decoding. Five of those 16 addresse ranges are safe, but any of the others would cause a bus conflict if you read or write from RAM mapped into that area, so it needs an alternate solution.

Address	Binary	CRTC	VIA	PIA#2	PIA#1
E80x	0000xxxx	-	-	-	-
E81x	0001xxxx	-	-	-	✔
E82x	0010xxxx	-	-	✔	-
E83x	0011xxxx	-	-	✘	✘
E84x	0100xxxx	-	✔	-	-
E85x	0101xxxx	-	✘	-	✘
E86x	0110xxxx	-	✘	✘	-
E87x	0111xxxx	-	✘	✘	✘
E88x	1000xxxx	✔	-	-	-
E89x	1001xxxx	✘	-	-	✘
E8Ax	1010xxxx	✘	-	✘	-
E8Bx	1011xxxx	✘	-	✘	✘
E8Cx	1100xxxx	✘	✘	-	-
E8Dx	1101xxxx	✘	✘	-	✘
E8Ex	1110xxxx	✘	✘	✘	-
E8Fx	1111xxxx	✘	✘	✘	✘

The solution for a plug in board is to do what the 64K board did and move into a safe area of ROM.

There is also the issue of $FFF0, that will always write to the register, so you have to be careful not to write to that in the paged RAM. (Next time I have one of the Commodore 64K RAM board running I need check how that reacts)

I did look at integrating that into the Mini PET. It should be possible to use a single 128K RAM chip to provide the main 32K and 4 or maybe 6 x 16K RAM pages. There would be less to deal with as the decoding would disable the onboard devices when reading paged RAM, so avoiding the above issues.

However, it looks like it would add 6-8 logic chips, maybe more. I only got as far as all of this just to decode the $FFF0 register address.

I could simplify that a bit with a 688 magnitude comparator, or maybe I should just give in and use one or both of the GAL chips to reduce the chip count.

I think I have convinced myself at this point there is no point in adding this to the Mini PET.

If there is any interest, I could respin that as a separate plug in module for anyone who has a need for the paged RAM.

I find it difficult to believe that they made 4 machines with 64K extra paged RAM, the 8096, 8096-SK, 8296 and 8296D, and there were third party versions, yet I can find hardly any software which makes use of it. Am I missing something?

Does anyone have a killer app or any other reasons to persuade me to do anything with the PET paged RAM?

---

Advertisements

If you are happy with 32K of RAM, I do have the full range of Minstrel and Mini PET kits and accessories.

I can ship worldwide, contact me with your location and what you want (or if you are in the UK or US, use the links in the post). Sorry I have to keep saying that. I am working on an alternative.

All the links can be found here:

• http://blog.tynemouthsoftware.co.uk/2023/09/minstrel-and-mini-pet-kit-updates.html

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates and exclusive posts like this one was. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts. This also includes access to my Patreon only Discord server for even more regular updates.

• https://www.patreon.com/tynemouthsoftware

ZX Spectrum +2 Grey Repair - Working but with screen corruption

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Here is a slightly unusual ZX Spectrum +2 128K, the grey model. It appears to be running, but there is noise on the screen when it is working.

The noise doesn't appear to be analogue in origin, it is very clear regularly repeating patterns, and they stop when you hold down reset. Quite strange.

Normally when you see screen corruption like that on a Spectrum it is a RAM fault, it is in the shared memory bank that provides both the screen RAM and the lower 16K. That means the Spectrum doesn't usually work.

This one is a little twitchy, some things aren't running, but running the same thing from a ROM appears to work better.

And indeed this memory tests pass.

As does the other one.

So, I was less inclined to think this is a memory problem. (I was wrong, but please don't judge me). The 128K has a lot more going on inside that the original 48K machine, but still has a lot in common.

I had seen something similar on a 48K Spectrum, there it was a problem with the multiplexor chips which switch the RAM address lines between the Z80 and the ULA (which generates the screen display).

On later Spectrums, and the Grey 128K, the multiplexor chips are combined into a single 40 pin package, here marked PCF1306P. I desoldered and socketed that, and tried a known working MUX chip (a later Amstrad 40058 version), but that didn't make any difference.

I also looked at a few other chips involved in the multiplexing circuitry, before accepting that it probably wasn't there.

Maybe it was the RAM then? Even though it was passing RAM tests? I decided to get a second opinion before starting on the RAM.

Brendan Alford (the author of the ZX Diag software I had been using for testing) confirmed the RAM hypothesis (and referenced an article he had written about ZX Spectrum RAM faults). He even pinpointed the problem chip for me.

IC26 is bit 6 of the lower bank of memory (which is shared between the CPU and the display). You can see for looking closer that all the lines are on the second pixel along on each character. The rest of the characters are fine, although the background brightness changes (which is also controlled by bit 6).

I removed IC26 and replaced it with a known working chip. I didn't have the same speed (150nS) to hand, so I used a faster 120nS chip.

Success. The corruption has gone, so it seems the RAM was woking fast enough when the CPU accessed it, but not quite fast enough for the video RAM. Most of the Grey 128K machines I have seen had 120nS RAM, so maybe they changed to that later on.

This one now has the single 120nS chip, and the rest still seems to be coping fine after a soak test. I wouldn't normally mix speeds, but you can get away with it as long as your replacements are not slower than the originals.

That seems to have fixed it. Can't say I've come across a RAM chips which was right on the edge of failing, but still just about running OK at slower speeds.

Time for some more testing with the built in tape drive, and a divMMC future.

Spanish Spectrum+ 128K Repair

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

A while ago I ended up with a broken board from a Spanish Spectrum+ 128K. The first obvious issue from outside is that the large heatsink which give the 'toastrack' it's nickname is missing.

The first obvious problem inside is the ULA, which was inserted upside down, I corrected that before I powered it on.

Since the heatsink was missing, I borrowed a random bit of metal and bolted the loose 7805 onto it.

On powering it up I got a faint signal on the RF, I could just about make out the copyright notice. (this is actually a later picture after it was cleared up a bit, it was a worse than this before)

Since there were some signs of life, I replaced that regulator with a switch mode version, so no more need for the large heatsink (which I didn't have anyway).

With that replaced I could get on with the rest of the testing. The 12V rail wasn't very good when I measured it, and with the video problems, it seemed a good idea to recap this board. Not something I usually do out of course.

I also replaced the switching transistors, may as well, they have a tendency to fail on Spectrums.

That didn't make any difference to the picture, but at least the supply rails were now stable. I thought about retuning the modulator, but when I opened the case, I found the ferrite core used to tune the frequency was broken.

I could replace that, but easier and more useful to convert that to a composite video output. There is a composite lunimance signal on the RGB port, but no composite video. I did try RGB output, but I was getting odd signals there as well. I didn't have a suitable lead as the Spanish 128K, the UK 128K and the later +2A etc. all had different RGB pinouts.

Checking the signal going into the modulator was a bit confusing. It looked like a sort of composite video signal, but inverted. The noise on the signal is the audio subcarrier, I'll remove that later.

This is from a working 128K.

I tried swapping out the TEA2000 (the colour encoder) and the ULA (for a later Amstrad version from a Grey +2), but was still getting incorrect signals.

The composite video which feeds the modulator comes from a three transistor amplifier circuit.

Checking those parts, all three transistors were working correctly and fitted the right way around (a common fault on +2 Spectrums is transistors inserted backwards). The only schematic I could find was for the later UK version, but it was mostly the same.

Tracing it back, the signal looked a lot better at the TEA2000 output. I tried removing and testing various parts of that circuit, but it just wasn't giving the right output. Eventually I decided the easiest thing to do to generate a composite video output with a simple single transistor buffer. I also removed the capacitor on the bottom of the page which links the audio signal into the composite video which gets rid of the noise on the signal.

I managed to fit the replacement circuit into the board using the existing pads, and fed the signal direct to the composite video output jack on the modulator. There is now only a single transistor, mounted the wrong way around where TR10 was.

I originally had this fed via a DC blocking capacitor, but I was getting a bit of 'wavyness' on the output, which wasn't there on the other side.

Since the output seemed to be biased around 5V by the TEA2000, I used a 5.1V zener diode, reverse biased instead of the 1N4148 originally used in the base drive of the transistor.

The signal from this was a lot more like it, and at last I had decent video output from this machine. Looks good on the LCD monitor.

The Spanish mode has some interesting quirks, it is one that requires you to type keywords in full, and has an interesting way of pointing out errors with a little bug character.

Had to be done.

There is also a bar which indicates mode (uppercase, lower case, extended etc.) which is always at the bottom of the screen, rather than inverse K/E etc.

The Spanish ROM does not have the menu like the UK 128K. Not sure if it's the official way, but typing USR 0 takes you to 48K mode.

I did try switching the ROM for the UK Spectrum+ 128K ROM, and it seemed to run OK,

I want to keep this as a Spanish 128K. so back to the ROM with the 'DERBY SP' label on it.

The original Z80 did not have any output on the M1 line, so I substituted it for another Z80, and M1 is now present and I can use a divMMC future to run some test software. (Update: the Z80 was retested in another machine and confirmed it was missing the M1 line) I also added a heatsink to the ULA.

No startup menu on this one, just the 1985 copyright screen.

Trying out or the ZX Spectrum Diagnsotics V0.33, it didn't detect the Spanish ROM, it's CRC may not be in the table, but all the other diagnostics tests passed

Update, the ROM checksum has been added to V0.35, so now it detects both versions of the Spanish ROM, this one was version 2.

And version 1 from an earlier Spanish 128K machine (using the wrong video lead, hence the bad monochrome picture).

Back to the machine under test. The colour bar looks OK, not perfect, but you're not going to get that much better with composite video anyway. The sound tests show the usual differences in level from the default beep to the AY chip, I need to adjust these at some point.

I ran this on a soak test for a while with only the ULA getting warm, so I fitted that with a heatsink. The board seems to be running OK, I didn't have the original case, so I just had the board.

The case of a 48K Spectrum+ should provide a suitable replacement. They are very similar, just a few connectors in different places.

The large case accommodates the same board which fits the original rubber key Spectrums, but there is space, for the larger 128K board. Note they still have the reset switch on wires. The 48K board in the above photo should have have a wired reset switch, but it was missing.

The power and edge connector were fine, but I had to widen the slots for the modulator connector and the RGB socket (the old ear socket).

I drilled two holes on the side for the new location of the ear and mic sockets.

The Spanish 128K models had '128K' in white next to the rainbow stripes, so I had to add that.

Some of the keycaps are different on the Spanish models, so I may try to get hold of a Spanish 48K Spectrum+ with a more suitable keyboard. Can you tell which one is mine, and which is an original Spanish Spectrum 128K?

Time for some testing.

So far, so good.

All the software I have tested seems to run fine.

Games all seem to be loading, both 48K and 128K versions.

It's hard work having to test all these things.

Finally time for another go of the newly released Pilot Attack from Misfit.