VIC20 Penultimate Cartridge Testing

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

The first batch of cased VIC20 Penultimate Cartridges are soon to be sent out by The Future Was 8bit. This is a limited run for the early pre-orders. The final version will be darker in colour, and have a textured finish (a 'sparked' finish, I'm told).

This should fit in well the the current range of Cartridges.

The main shape follows the standard Commodore VIC20 cartridge cases, but the styling around the label follows the breadbin case (and the Commodore 64 cartridges).

This is for both aesthetic and practical reasons. One design flaw in the original cartridges was that you couldn't read the label when it was inserted in the VIC20.

The Penultimate Cartridge label is still clearly visible when in use. The labels on the production versions will be die cut to perfectly fit the case moulding, this early sample is hand cut.

There are two buttons on the top of the cartridge. The one on the right is reset, which will reset the VIC20 to restart the current cartridge (if one was selected), or just perform a normal reset.

The one on the left lights up red, and when pressed brings up the Penultimate Cartridge menu.

When I was first building the uncased versions, I was individually testing them with each order. To automate this as the production runs increase, I've written a test program.

This is placed on an SD card, as the first file on there, in an SD2IEC drive. It can be started using the F8 key (shift + F7), which allocates all 35K of RAM and executes LOAD"*",8. The first test is to test the RAM, all bar the block the program is running from.

Once the RAM has been tested, it switches to testing the ROM images. It does this by selecting each one of the 64 8K ROM images in the cartridge and running a CRC check.

If there is a problem with the ROM switching, or the ROM image fails the CRC test, a failure will be reported.

All being well, it will print up 'PASS' in large, friendly letters.

These new cartridges have custom PCBs to make use of all the space within the cartridge case. I even get a name check in the top copper layer.

This looks a lot tidier than the original prototype board.

The case prototype was also very tasty.

The VIC20 Penultimate Cartridge is available to buy now from The Future Was 8bit, the first full run should be happening next month.

It is planned that they will also be selling the new empty VIC20 cartridge cases. The should fit most standard VIC20 cartridges, including those which make use of the rear PCB cutout such as the VIC-1112 IEEE-488 cartridge.

It will also fit the shorter style boards found in most cartridges, should you want to replace a damaged case. You will also be able to buy new 8K and 16K ROM PCBs to fit this case.

The VIC20 Penultimate Cartridge is certainly not the last product you will see designed by Tynemouth Software, produced and distributed by The Future Was 8bit. We have several projects running in parallel at the moment, so there might be quite a few new product announcements coming up soon.

2022 Update: The production version of the Penultimate Cartridge is now available from  The Future Was 8 bit

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.

* that should read 'doesn't run 6502 code yet'. I might add that in future, but probably not.

2024 Update:

The PET Diagnostics modules are available from my SellMyRetro store:

• https://www.sellmyretro.com/offer/details/64158

Spanish Spectrum+ 128K Keypad

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Following on from the previous post about the Spanish Spectrum+ 128K 'Toastrack', this is the keypad that was shipped with it. It came as standard with Spanish models. There was a UK version advertised for a short while, but I don't think it was ever sold.

The keypad plugs into the BT jack socket marked 'Keypad' on the front of the Spectrum+. Not the best position, the cable doesn't really sit right.

The later +2 had the sockets on the back which seems a better idea. This looks like it had a label stuck on the top with superglue or something which has melted the plastic a bit.

Six screws on the back remove a back plate, and inside it is a similar construction to the Spectrum+.

The thick clear membrane is similar to that used on some Spectrum+ models, and those ones are usually still fine, most of the thinner opaque ones tend to go brittle and fail.

Beneath that is is keymat and captive keys, the same arrangement as the plus.

This does not have a separate backplate as the case acts as that.

The membrane is plugged into a small controller board.

Unusually for Sinclair, it's not a Ferranti ULA, but a PIC microcontroller. No Microchip logo on this one, it is GI, General Instruments, Microchip was formed several years later. This is the PIC1652, one of the very early ones, not even mentioned in my well thumbed Microchip 'bible' from the 1990s.

It is pin compatible with a lot of the later 18 pin pics from the 16C54 through the good old 16C84 and later. Here it is used to scan the keypad the feed keypresses back to the Spectrum via a serial protocol.

It is technically an RS232 serial port, with MC1488/1489 drivers, but it was actually implemented by bit banging IO pins on the AY-3-8912A sound chip. Although these signals are at +/- 12V, the keypad uses zener diode / resistor circuits to drop it's supply and data input to around 5V.

The keypad doesn't actually use an asynchronous serial protocol like RS232 (i.e. a clock running at both ends at an agreed speed). It's sort of synchronous (data and clock both sent from a master source), in that the Spectrum initiates all the transfers. There is a lot of handshaking going on, it says hello, waits for the keypad to say hello, the says hello again and the keypad sends back one bit of data. It does this by setting the line low, waiting for the keypad to set it's line low, then setting it high and waiting for the keypad to set it's line high etc.

When reading these, the top row is from the Spectrum, but bottom a reply from the keypad. The larger pulses in the reply are 1, a pair of shorter ones is 0. The protocol is variable length, if no keys are pressed, the keypad returns 1 for each row, 1 1 1 1 1 (as in the first plot). If a key is pressed, it returns 0 for a row, then follows that with 4 key bits, 0 if pressed, 1 if not.  The second plot shows 1 1 0 1 1 0 1 1 1,  that is no keys pressed on the first two rows. The third row is a 0, so is followed by 4 bits of key data for that row, the 0 indicates the 3rd key is pressed down. The final two ones are rows 4 and 5, no keys pressed.

When running, the keypad can be used for various editing functions, moving or deleting characters or words, jumping to the end of the line etc. There is also a menu with options to renumber the code or print a listing. I got those responses using a UK Spectrum+ 128K, since the Spanish Spectrum 128K has not been repaired yet. The keypad seemed intermittent, sometimes returning very long pulses or nothing at all, I tried with a couple of UK toastracks.