Penultimate Cartridge Repairs

I am currently in the middle of development of something new and exciting, and writing lots of posts about that for my Patreon supporters. I can't post any of them on here until it's complete, so today I am raiding the Patreon archives again. This time a post from January 2023, with some 2024 updates at the end. As the Penultimate +2 Cartridge was being developed, I was sent an interesting bundle of boards from TFW8b.....

Since the Penultimate Cartridge was launched in 2016, there have been very few problems. Most of the ones we have seen have been down to VIC20s themselves, and when the dubious 245s or in most cases 138s were replaced, all was well again.

For example:

• http://blog.tynemouthsoftware.co.uk/2022/11/vic-20-repair-the-vic-that-did-not-like-cheese-and-onion.html
• http://blog.tynemouthsoftware.co.uk/2017/02/vic20-repair.html
• etc.

and also

• http://blog.tynemouthsoftware.co.uk/2018/06/the-ultimate-history-of-penultimate-cartridge.html

All boards are tested at several stages during production, so we can be confident of them working, and I think of the few original Penultimate cartridges returned, none were actually found to be faulty.

A few boards failed programming or testing, or were rejected due to physical damage (we lost a few buttons on the corners of the boards).

And here they are. The entire total of rejected Penultimate Cartridge boards from the millions we have sold*.

* OK, not millions, but still quite a lot.

A total of 9 bad boards over 7 years. That's not bad going is it?

Some have been reworked, or raided for parts already, but TFW8b has sent them all to me to see how many I can actually get going (or ultimately raid for parts for PU+2 prototype boards).

I can rule one of them out at the first stage. It has had it's microcontroller and RAM removed, so it does not appear to be worth investigating further. I'm having those buttons though to fix one of the other boards.

So that leaves 8 boards.

I thought the best place to start was trying to program the microcontrollers, see how many of those were good.

I did make a nice pogo-pin programming jig, but it's been so long since I dealt with one of these boards, I couldn't find it, so I made a bit of a lashup with a cut down ZX Spectrum edge connector (and I have actually been using this since then, never did find the old one)

Of the 8 boards, 7 programmed correctly. One failed to detect the chip.

Not detecting the chip either means a bad connection, bad microcontroller, or possibly a bad crystal.

Straight off the reel, the chips are set to use the internal oscillator, but when programmed, are set to use an external crystal. If the crystal is bad, they will program the first time, but then do not run and cannot be reprogrammed.

That had clearly had some rework done (a previous revival attempt?). I probed around and found the crystal wasn't oscillating. Probing further found no continuity between the crystal pin at the top and the microcontroller.

I carefully removed the crystal and checked underneath, and the trace was broken where it connected to the pad. I lifted it at the corner to make it easier to see. (cleaning the chip has also made it easier to see the 2014 date code, so this must have been one of the very early boards, possibly one of the hand assembled prototypes?)

I scraped away a bit of the trace and soldered it back to the pad and carefully fitted a new crystal in place. May as well since the previous one had been trough several heat cycles.

(you can just see here the edge of sticky tape I had put on the boards to protect them from scratches from the edge connector. That is what I was writing on, I wasn't directly graffitiing on the boards.)

Success, that's now 8 boards that have programmed correctly, so time for the next stage of testing.

I'll start with the four boards with all the parts intact.

I installed known working chips in the sockets on the first board and fired up the VIC20.

That's a good start, so I exited to BASIC and ran the test program (this was before the days of the built in self test)

I left that running for quite a few cycles with no problems. I also ran through several games to test some of the different modes (Cheese and Onion, a text adventure and an Atari game).

And the next two did the same.

Three working boards.

The final one of the four failed the memory test.

I spotted a fleck of what looked like hot glue? on the back, that might have stopped it getting a proper connection on that pin. With that cleared, it passed the test. (the very early "Caramac" coloured cases were hot glued together, the second revision hold together fine without even needing the screw. This must be another early board.)

All of those four are now working, one more needed only a reflow of the pins and a clean up.

Next, two boards with sockets, but with some damage and no buttons.

Both had modifications to the ROM socket for some reason or other, so I couldn't test that, but I was able to run the board with just the RAM enabled. With the correct series of magic POKEs, I was able to enable the RAM.

They both passed the RAM test designed for the Max RAM boards.

Finally, two boards with the sockets removed. The microcontroller had programmed, so these were a potential good source of parts. I decided to fit some sockets for the GAL chips and test those to make sure the microcontrollers and RAM was working.

Again, they both passed, so more chips for harvest.

So after all that. All the boards actually worked, or could be made to work. All the damage was mechanical, either boards damaged in transit, or ones with bits removed.

Goes to show, if anyone does have a problem with a Penultimate Cartridge it really isn't likely to be the cartridge itself at fault.

2024 Update.

The parts from those boards went to make the Penultimate +2 Cartridge prototypes, (this is my development version of the PCB, with thinner traces, bigger parts, no gold edges and a different fonts etc.)

Which as usual, started off looking quite neat.

But it doesn't last long.

And indeed, that mod didn't last long, and later got reverted. I remember being very pleased with the track repair.

And rather disappointed when I turned out I had to undo it again.

One or two other mods on this one.....

Since the release of the Penultimate +2 I think there has been one return which turned out to be a flaky crystal. It would work for about half an hour, then start acting up, but other than that, we can still be very confident of all the production boards that go out.

---

Advertisements

The Penultimate +2 Cartridge is currently at £49.99+VAT

• https://www.tfw8b.com/product/vic20-penultimate-plus-two/

But wait!

Q:Would you like £5 off a Penultimate +2 Cartridge? (or anything else from TFW8b.com)

A:YeahYeahYeah

Well, use the code "A:YeahYeahYeah" at checkout.

See this (sort of) helpful diagram drawn by Rod himself.

There is also my store with the full range of Minstrel and Mini PET kits and accessories, things are on the change there, but best just to contact me using the link top right of the blog page, and tell me what you want and where you are and I can send you a PayPal invoice. Hope to have a better solution soon.

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. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts (they also got an extra post covering the development of this board). This also includes access to my Patreon only Discord server for even more regular updates.

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

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