Archive for the ‘Retro’ Category

Using a TL866II+ programmer to update GCDual firmware

Monday, January 20th, 2020

I have a GCDual board, which is a modification for a Nintendo Gamecube to give it HDMI output. Firmware updates for this little PCB come out occasionally and to apply them requires attaching an EEPROM/flash programmer to the various pins and rewriting the chip directly.

I got wind of the latest 3.0a firmware update that actually lays the groundwork for future updates to be applied through software instead and figured it would be good have this.

There is a video that shows how to do the firmware update however I had a few issues with that process:

  1. I haven’t actually installed the PCB yet, (it’s in my TODO pile). This isn’t actually a problem as in the video, the 3.3V is provided by the Gamecube PSU instead of the programmer, but the programmer can supply this. In theory it should also negate taking precautions to ensure that the programmer doesn’t accidentally short something on the main Gamecube board.
  2. The process is using a CH341A programmer which I don’t have, and if I did get one it seems to be poorly supported on macOS. The programmer looks like it just needs to be able write SPI flash devices.

I do have a TL866II+ programmer which has a 6-pin ICSP port and comparing the pinout of that and the CH341A programmer looks like both programmers have the same required pins. The TL866II+ comes with an ICSP harness that is terminated as 6 individual female sockets so with a piece of pin header I arranged the pins in the correct order. Here is how the programmer expects the pins to be arranged logically:

So it was just a case of marrying those up to the header on the GCDual PCB. For reference it was 1-3, 2-2, 3-1, 4-4, 5-6, 6-5 for each pin on the TL866II+ to the GCDual respectively, with pin #1 on the GCDual being GND. This is what it looks like:

You can then insert the pins into the GCDual PCB and use a bit of light pressure to make contact without the need to solder anything:

Note that you need to bridge the two solder pads marked JP2 at the top right of the PCB in order to do anything with the flash chip otherwise the FPGA will fight with your programmer on the SPI bus when power is applied and you’ll read and/or write garbage.

Now we just need to flash the chip. For driving the programmer, I use the open source minipro rather than the provided software. The only bit of required information is the make & model of the flash chip; the original video shows it being programmed as an M25PE40 but my PCB actually has an MX25L4006E. The datasheets show these two chips are mostly identical anyway however minipro likes to check the chip ID. Writing the new firmware is as simple as the following:

$ minipro -i -p MX25L4006E -s -w GCDual_ADV7125_3.0a.bin
Found TL866II+ 04.2.109 (0x26d)
Activating ICSP...
Chip ID OK: 0xC22013
Warning: Incorrect file size: 346144 (needed 524288)
Erasing... 1.71Sec OK
Protect off...OK
Writing Code...  5.19Sec  OK
Reading Code...  2.48Sec  OK
Verification OK
Protect on...OK

The flags used are: use ICSP instead of the ZIF socket (-i), choose the correct flash chip (-p MX25L4006E), don’t complain that the firmware is smaller than the capacity of the chip (-s), and provide the firmware itself (-w ...).

Remember to remove the solder bridge with some wick prior to installing the PCB.

Commodore 128 Keyboard Repair

Sunday, September 18th, 2016

My Commodore 128, (a “flat” C128CR), has suffered with a few temperamental keys on the keyboard; the symptoms being that keys are either slow to return after being pressed or don’t return at all and stay pressed resulting in undesired input, i.e. they’re “sticky”.

This can be caused either by spilling something, usually sugary, into the keyboard which leaves a sticky residue, or a failure of the plunger for each affected key. As I’m fairly sure I’ve never spilt anything I assumed it was the latter.

To get at the keyboard the machine needs to be opened up first which is simply a case of unscrewing the six screws on the underside; three along the front edge with the middle one usually underneath a warranty disclaimer sticker, two at each of the rear corners and one in the centre. The top half of the case will pop off with a bit of persuasion which allows you enough clearance to reach in and disconnect the power LED and then the top of the case can be hinged open along the right hand side of the machine which allows you to gently disconnect the keyboard cable and unscrew the grounding cable from the RF shielding of the main board. This should leave you with the following:


You might not necessarily need to remove the keyboard from the case but the size of the case makes it more unwieldy to work on. To remove the keyboard, just unscrew the six visible screws. Note the four black plastic spacers and their orientation for the screws along the top edge:


Once the keyboard is loosened the power LED will likely drop out along with the small plastic part that holds it in place. Keep all of these bits safe, ready for reassembly. You should now be left with just the keyboard itself:


Next the hardest step, which requires the use of a soldering iron. You need to desolder the wires from the three stateful keys; “Shift Lock”, “Caps Lock” and “40/80 Display”. It’s important not to let the soldering iron heat the keys up too much to prevent damaging them and thankfully the wires are not twisted together so with some tweezers and the quick application of the soldering iron the wires should separate easily:


There are now 27 small screws holding the circuit board in place to undo and then the circuit board should just lift away. Don’t miss this tiny spring that is situated above the ‘+’ key on the numeric keypad:


The circuit board can be gently cleaned with something like isopropyl alcohol if it’s dirty. To get at the plungers for each key, you just need to pull off the keycap on the top side of the keyboard, put that and the spring underneath it to one side, and then the plunger should just drop out:


The keycap snaps into the top of the plunger which rides up and down through a hole in the keyboard chassis with the spring making the plunger return and stay up. What happens is that the plunger can develop a split which means when the keycap is fitted the diameter of the plunger grows enough that it doesn’t move smoothly in the hole and becomes an interference fit causing the key to stick. Here’s one of the damaged plungers from mine with my nail showing where the split is:


It’s simply a case of replacing each damaged plunger, (I ended up replacing five along with two springs), and then reassembling the keyboard. Leave the re-soldering of the stateful keys until last and that you’ve checked all the other keys travel properly. You should now have a reassembled keyboard:


Fitting the keyboard back into the case is fairly straightforward, the trickiest bit is keeping the power LED stable while you drop the keyboard in place as it’s just sandwiched in, here’s how it should be fitted:


Reconnect the keyboard cable making sure not to bend any pins, reattach the grounding cable to the RF shielding and finally reconnect the power LED, (apparently it can be reconnected in either orientation), as you close the two halves of the case together. Then it’s just a case of powering on the machine and testing the keyboard. Make sure that you also test the stateful keys work correctly after you’ve de- & re-soldered them.

Reviving a DEC Vaxstation 4000/90

Thursday, August 4th, 2016

I recently powered up my old DEC Vaxstation 4000/90 out of curiosity to see if it still worked and discovered that no, it didn’t. The fans in the power supply spun up, the noisy SCSI hard disk whirred and clicked into life but nothing else happened. Anyone familiar with these and similar DEC machines knows there’s a bank of eight diagnostic LED’s that provide error reporting as the machine initialises and tests its various bits of hardware. All eight were lit and weren’t changing, it looked dead.

A lot of machines of this era have what is known as a timekeeper chip which is some non-volatile RAM with a crystal and battery piggy-backed on top and encased in resin. It keeps time and the battery allows the RAM to retain its contents whilst the machine is powered off. The contents are usually important machine settings, such as which disk to boot from, etc.

The 4000/90 has a Dallas Semiconductor DS1287 which is a fairly ubiquitous part and the batteries in these chips are only supposed to last for about 10 years so given the 4000/90 was introduced in the early 1990’s, chances are by 2016 the battery is flat. Early Sun Microsystems machines are plagued with a similar problem however they tend to still power up, but then report bad values for their host ID, MAC address, etc.

There’s two possible fixes. One, fit a new timekeeper chip which given they’re not manufactured any longer may mean fitting a “new” chip that has sat on the shelf for a number of years and so the battery has already lost much of its charge. Alternatively, and what I ended up doing, is to add a new battery to the existing chip.

The first job is to locate and extract the chip. Here is the DS1287 fitted to the 4000/90:


Note the dot identifying pin 1. Thankfully it’s in a socket so with a bit of careful coercion it should come out. The next step is to use a dremel or file to grind away the plastic and resin above where pins 16 & 20 would normally be, (they’re still present but bent up inside the package and attached to the battery):


Using a multimeter across these two terminals showed there was only 220-230 mV left in the battery so it was almost flat. Now the battery needs to be disconnected by breaking the contact on pin 16 so that the multimeter shows no voltage when placed across the exposed contacts near the base of the chip. With that done add some small wires, soldering them to the same contacts with the aim of attaching them to a battery holder:


Then add the battery holder and battery; I used a standard CR2032 Lithium coin cell. The positive terminal goes to pin 20 and the negative terminal goes to pin 16. I also put some more hot glue over the exposed contacts:


Now reinstall the chip back into the 4000/90 taking care to both orientate it correctly and not bend any of the pins:


At this point it was time to try and power on the Vaxstation and this time it worked and emitted its little warble and dropped me to the SRM console:


It was a bit confused as it had lost all of its settings so didn’t know where to boot from, etc. but other than that seemed fine. After fixing this I figured my DEC 3000/600 Alpha might also have the same issue so powered that up to find yes it did, but it at least boots to the SRM console and reports an NVR (Non-Volative RAM) fault. Here’s the timekeeper chip hidden underneath the middle TURBOchannel expansion slot and bingo, it’s another DS1287:


I performed the exact same steps as before and refitted the modified chip:


The NVR fault has now disappeared. Both machines should now be good for another 10 years or so, although it’s likely the elderly hard disks will seize up, or maybe a capacitor in the power supply will leak.