u/hitmanmcc

The Game Boy Player (DOL-017) is the GameCube base attachment that lets you play Game Boy, Color and Advance carts on a GameCube and a batch of them that had arrived a while back finally made it to my bench for a recap.

What made these noteworthy: they are the first Game Boy Players I have ever opened that genuinely had leaking caps. I could smell it the moment I removed them. They use SMD electrolytics which I replaced with new ones from a Console5 GB Player cap kit, and after that everything ran fine.

One unit had a bonus issue. It would not boot anything and just showed the Nintendo logo with corrupted graphics. The cartridge slot had oxidised, so once I cleaned it out the carts booted and the logo came up clean. I ran Minish Cap and Game Boy Tetris through it to confirm.

Do you use a Game Boy Player as your way to play GB / GBA carts on the big screen, or do you prefer a different setup?

I took a batch of GameCube Game Boy Players (DOL-017, the base attachment that plays Game Boy / Color / Advance carts) to the bench for a recap. These stood out for one reason: they are the first units I have ever handled that genuinely had leaking caps, judging by the smell the moment I lifted them off the boards.

They are all SMD electrolytics, so it was a straightforward desolder-and-replace with a Console5 GameCube GB Player cap kit. I tested afterwards, and everything works fine.

One of the units had a second problem: it would not boot games, and instead kept throwing up the Nintendo logo with corrupted graphics. That turned out to be the cartridge slot, oxidised and dirty. Once I cleaned the slot out, the carts booted and the logo rendered correctly. Tested with Minish Cap and Game Boy Tetris running through the player.

Has anyone else found leaking caps on these, or did I just get an unlucky batch? Curious how common it actually is on the GB Player.

Two Japanese NTSC-J Sega Saturns on the bench, a grey Model 1 and a white Model 2. Both worked fine, but a Saturn power supply is not something you want to leave on aging caps, so both got a preventative recap.

Recapped both Yamaha XR258 power boards (Console5 cap kit) and smoke-tested them on a Sony PVM, the Model 1 booting Pseudo Saturn Kai and the Model 2 running Radiant Silvergun. Then the grey Model 1 got a retrobright to lift the yellowing off its shell, the before and after photos are the same console from two sides.

No drama, just a clean tidy service and a shell that looks the part again. Link to log in the first comment.

Where does the grey Saturn shell land for you next to the black US and PAL machines, is the Japanese grey your favourite of the three or does the black one still win?

A pair of Japanese NTSC-J Saturns on the bench, a grey Model 1 and a white Model 2. Nothing wrong with either, this was a preventative pass to refresh their aging power-supply caps before they cause any trouble.

Recapped both Yamaha XR258 power boards end to end with a Console5 Saturn cap kit. Superwick for the old joints, flux, Kester solder, nothing exotic. Reassembled and smoke-tested both on a Sony PVM: the Model 1 booting Pseudo Saturn Kai off a cart, the Model 2 running Radiant Silvergun. Everything checked out fine.

Then the grey Model 1 also got a retrobright to knock the yellowing off its shell. The before and after photos are the same console from two sides, and the more yellowed side came back nicely.

This one is a keeper, so I gave it a preventative service before the old caps could give me trouble later.

In one sitting: full recap (Console5 Game Boy Pocket SMD kit), cleaned the brightness and volume trimmer pots, the power button, the cartridge connector pins and the button membranes. No screen mod, the stock reflective LCD stays, and it runs Zelda: Link's Awakening beautifully afterwards.

It has a Hello Kitty sticker by the Nintendo logo, a Snoopy sticker on the front and pink A/B/Select/Start labels, all left as I found them because they suit it.

Pics are result first, then a screen close-up, the board on the cap-kit box, and the recapped board with the old caps set aside.

Do you keep your Pockets stock like this, or is the reflective screen the thing that finally pushes you to a backlit mod?

My Game Boy Pocket (MGB-001) was working, but I wanted to get ahead of the aging electrolytic caps, so I did the whole job in one sitting rather than opening it up again later.

Recapped the board (fresh caps from a Console5 Game Boy Pocket kit), cleaned the brightness and volume trimmer pots, the power button, the cartridge connector pins and the button membranes. Kept the stock reflective screen, no backlight or IPS mod. Buttoned it back up and it runs Zelda: Link's Awakening nice and crisp.

It is a well loved little unit, so it has picked up a few stickers over the years, which I left exactly as they were.

Gallery goes result first, then a close-up of the screen, the board before the work, and the recapped board with the old caps set aside.

Anyone else prefer the original non-backlit Pocket screen over a modern backlit panel in the right light?

This black Game Boy Pocket (MGB-001) still worked fine, but the electrolytics are old and I would rather refresh them now than crack it open again down the line, so I gave it a thorough once-over in a single sitting.

What I did:

- Full recap: pulled the old electrolytic caps and fitted a fresh set (Console5 Game Boy Pocket SMD kit).

- Cleaned the brightness and volume trimmer pots so both adjust smoothly again.

- Cleaned the power button, the cartridge connector pins and the button membranes.

No backlight or IPS mod here, the stock reflective screen stays. Reassembled, powered on, and it runs Zelda: Link's Awakening crisply on the original LCD.

Bit of a crossover between Zelda and hardware upkeep. These two Japanese Game Boy Color Oracle carts, Oracle of Seasons and Oracle of Ages, store your save powered by a little coin cell inside the cartridge. That battery eventually goes flat and the save goes with it, which is how a lot of old GBC saves quietly disappear.

So before the batteries had a chance to die, I dumped each cart's save with an Open Source Cartridge Reader, replaced the old cell with a fresh CR2032, then wrote the save back so nothing was lost. The final photo is Oracle of Seasons booting to its file-select with the save still there. If you own an Oracle cart (or a linked Seasons + Ages pair) it is worth knowing the save is only as alive as that battery, and that you can back it up before you ever open the shell.

If you played the Oracle games, did you go Seasons or Ages first, or run the linked password quest across both?

Preventative maintenance on a pair of Game Boy Color carts I recently acquired: Zelda: Oracle of Seasons (CGB-AZ7J-JPN) and Oracle of Ages (CGB-AZ8J-JPN). Both are battery-backed, and the save cell in these dies eventually and takes the save with it, so I refreshed them before that happened.

Process, hero shot first:

- Dumped each cart's existing save FIRST with an Open Source Cartridge Reader, so I had a backup before touching anything.

- Opened the shell, desoldered the old tabbed coin cell, soldered in a fresh tabbed CR2032. The board is marked for a smaller cell, but fitting the larger CR2032 is a common upsize for more capacity, so it holds the save for longer before the next swap comes due. You can see the new cell's edge wrapped in yellow plastic on the green PCB.

- Wrote the save back with the reader and confirmed "SRAM writing finished, Verified OK" on its OLED.

The yellow ring of each save battery is visible through the translucent shells, and the last shot is Oracle of Seasons at its file-select on a translucent-black GBC with the save intact.

These two Japanese Game Boy Color carts, Zelda: Oracle of Seasons (CGB-AZ7J-JPN) and Oracle of Ages (CGB-AZ8J-JPN), use a battery-backed save. That coin cell eventually dies and takes the saved game with it, so this was preventative maintenance on a couple of carts I picked up.

I dumped whatever save each cart already had FIRST with an Open Source Cartridge Reader, then desoldered the old tabbed cell, soldered in a fresh tabbed CR2032, and wrote the save back. The reader's OLED confirming "SRAM writing finished, Verified OK" is the moment you actually want to see. You can spot the yellow save-battery ring through the clear shells in one of the photos, and the result shot is Oracle of Seasons booting to its file-select with the save intact.

Do you back up your cart saves before a battery swap, or just accept the wipe and start over?

Spent some bench time on my classic OSSC. The first job was a small hardware mod so it will run the newest firmware instead of being stuck on the old one, just a single wire. Once that was in it flashed the latest firmware cleanly.

I ran Earthion on a Mega Drive in 1440p to try it out, one pic with HDR, VRR and PVM-style scanlines and one with none of it. For such an old device the picture it puts out is genuinely impressive.

The other half was helping a firmware developer test a work-in-progress build for PC Engine: it tries to emulate the composite colour palette while still outputting RGB. I lined the OSSC up next to a CoreGrafx running plain composite on a CRT and compared the same Bonk level on both. Very early days, but a promising idea, and it sideloads straight onto the OSSC on the latest firmware.

Do you prefer the cleaner RGB look on PC Engine, or the softer composite palette these old games were drawn for?

The teal Famicom Legend of Zelda is a lovely cart, and like every battery-backed Famicom title its save lives or dies with a coin cell that is now decades old. So before that became a problem I gave it a service alongside a Super Metroid cart.

The part I want to flag for fellow Famicom owners is the order of operations:

First time around I had lost my coin cell holders, so I soldered in tabbed cells as a stopgap. Once the holders turned up I went back and fit a Maxell CR2032 in a proper coin cell holder, so the next swap is solder-free, just pop the old cell out and drop a new one in.

Tested fine on an AV Famicom afterward with the save intact (dumped and restored).

If you collect Famicom carts, have you moved your battery-backed ones over to coin cell holders yet, or are they still on the factory soldered cells?

If you have old SNES or Famicom carts with saves on them, this is your reminder that the save battery is on a clock. The coin cell inside keeps the SRAM save alive, and when it goes the save goes with it.

I had two on the bench for some light collection maintenance: Super Metroid and the Japanese Famicom Legend of Zelda (teal shell). Nothing was dead, this was just righting future wrongs before they happen.

The sequence:

- Dump the save FIRST with a cartridge reader (I used a Save The Hero Builders OSCR V3; the Famicom Zelda cart read through a Famicom-to-SNES adapter). Skipping this step is how people lose a save they meant to keep.

- New battery, fresh cap, cleaned contacts on each cart.

- Restore the save, so nothing is lost.

I started with tabbed solder-in cells because I had misplaced my coin cell holders, then went back later and fit proper CR2032 holders so any future swap needs no soldering at all.

Both running with their original saves again: Super Metroid on a Super Famicom Jr., Zelda overworld on an AV Famicom.

When was the last time you checked the battery on a save-heavy cart like Zelda or Super Metroid?

My Super Metroid cart (SHVC-R1) was still holding its save fine, but that save sits on a coin cell that is now decades old and will eventually die and take the save with it, so I swapped it preventatively while the save was still there.

The order that matters:

I could not find my coin cell holders at first, so I fit a tabbed (solder-tab) cell as a stopgap, then went back once proper holders arrived and fit a Maxell CR2032 in a coin cell holder, so the next swap is a tool-free pull-and-replace with no soldering. I did a Famicom Legend of Zelda cart the same way alongside it.

Super Metroid came straight back up with its SAMUS DATA save intact on a Super Famicom Jr.

Picked up this 9-inch HR Trinitron multiformat broadcast monitor out of Japan (via Sendico), listed as dead. Symptom on arrival: it powers on, the tube builds up static, but there's no picture.

Turns out it was never dead. It just needed someone to actually press the right buttons and a picture came up. The service menu reads serial 2000661, 150,948 operating hours and software v1.17, so the tube has done a LOT of hours, but it honestly doesn't look terrible. Maybe a lot of those hours were probably on standby?

No heroic resurrection here. The real, still-unsolved problem is this: the screen is very dim, and the on-screen text has a red hue when there's no video signal. Feed it a signal and the picture looks OK and the OSD text goes white, but if you loop the signal through to another monitor the picture goes wonky. A colour-bars test shows the blue visibly weaker than red and green, so there's a colour imbalance on the aged tube too.

What I have done so far:

- Cleaned and greased the whole thing. Unlike my other 9-inch Sonys this one is built like a tank, no brittle plastics.

- A previous owner had already recapped the PSU board (it seems), badly: sticky flux left uncleaned, a missing eyelet on one cap leg, and bad joints. I reflowed the entire board by hand and cleaned up their work.

- Partial recap of the PSU (board 1-674-622-15): replaced all the electrolytics EXCEPT the 3 largest. I didn't have those in stock, and a same-spec replacement for the big main filter cap wouldn't physically fit the case.

- On the D (deflection) board, a previous servicer had obliterated a pad at C1617 and bodged a solder blob across it to keep continuity.

Result, honestly: that fixed the bad-rework problems but did nothing for the dimness. Still very dim, still the red-hue-on-text when there's no signal. The dimness is unsolved for now.

I always put the dimness down to the tube itself but cleaning up cost me nothing. It's a 150k-hour CRT with cathodes oxidised by age, so a rejuvenation would probably give it some more life. The thing I keep going back and forth on is whether something on one of the boards might be contributing too, a capacitor or some damage left behind by whoever did that earlier service (the same person who wrecked those pads in the photos). So on a BVM of this era, dim with a red cast on the OSD text when there's no signal but otherwise fine with a signal: where would you look first, and would you rejuvenate a tube with these hours?

A preventative full service on a NEC PC Engine SuperGrafx, the kind of thing worth doing before the original caps and regulator give you grief.

The work:

- Full recap with a Console5 CoreGrafx / CoreGrafx II cap kit (fits the SuperGrafx), plus a clean of a fairly dirty board

- New voltage regulator

- Jailbar fix: 0805 4.7uF 16V X7R MLCCs at C168 and C169, following the Console5 wiki

- A Krikzz EDFX on the Ext Bus port for clean RGB, composite and audio out (breaks out to a Mega Drive 2 style 9-pin connector, takes an MD2 RGB cable). I printed a mini-IFU styled shell to house it, designed by PointerFunction, so the adapter looks the part instead of dangling off the back

Gallery goes result first (R-Type on a PVM), then the dirty before board, the recapped board with the new regulator, the C168/C169 close-up, and the EDFX in its shell. Tested with a Turbo Everdrive v2.

The SuperGrafx is one of the rarer NEC machines (1989, only a handful of exclusive games), so when this one came across the bench it got the full preventative treatment instead of waiting for a failure.

What went into it:

- Cleaned the board and did a complete recap (Console5 PC Engine CoreGrafx / CoreGrafx II cap kit, which works on the SuperGrafx)

- Fitted a new voltage regulator

- Did the jailbar fix: 0805 4.7uF 16V X7R ceramics at C168 and C169, per the Console5 wiki

- Added a Krikzz EDFX on the Ext Bus port for clean RGB / composite / audio (it outputs to a Mega Drive 2 style connector), housed in a 3D-printed mini-IFU styled shell designed by PointerFunction

Last few photos show it running R-Type on a Sony PVM. With an Arcade Card Duo seated in the HuCard slot and the EDFX in its little shell. Tested off a Turbo Everdrive v2.

Took a working but aging NEC PC Engine SuperGrafx through a full preventative service rather than waiting for it to fail. The board was dirty and still on its original electrolytics, so it got a clean, a complete recap (Console5's kit), and a fresh voltage regulator.

The SuperGrafx uses the HuC6260 video encoder, and per the Console5 wiki you replace a couple of small ceramics to knock down the vertical bar/interference pattern. I fitted 0805 4.7uF 16V X7R MLCCs at C168 and C169 on the solder side. Photos walk through the dirty before board, the recapped board with the new regulator, and a close-up of those two caps.

After that I added a Krikzz EDFX to the Ext Bus port for clean RGB, composite and audio out (it breaks out to a Mega Drive 2 style 9-pin connector, so it takes a standard MD2 RGB cable), and printed a mini-IFU styled shell to house it (model by PointerFunction). Bench-tested with R-Type running off a Turbo Everdrive v2 on a Sony PVM-14L2.

This spice orange DOL-001 is my personal favourite console, so it has had a long arc on the bench. It started life with a PicoBoot, webhdx Raspberry Pi Pico-based IPL replacement that makes Swiss, GBI and the Game Boy Player possible, with a shout out to MachoNacho for the video that got me going.

It also had a dead optical drive with the usual disc read error. On a maintenance day I recapped the optical-drive PCB rather than chasing the laser, which is the part that usually is not actually the fault (credit leonkiriliuk for that), and dot-marked the fresh caps so I could track them. That brought the drive back.

Later it got the upgrade I really wanted: a FlippyDrive SD-card optical drive emulator from Team Off Broadway (thanks ChrisPVille and trevorrudolph), REV6 board on a 3D-printed bracket. The install was quick even with having to pull the PicoBoot first. It threw a game/console region complaint on boot that a firmware update sorted out. Now it loads from SD, tested with Resident Evil 4, Ikaruga, Four Swords Adventures and Wind Waker.

This is my spice orange GameCube (DOL-001), and it had the classic disc read error from a dead optical drive. The usual assumption is a worn-out laser, but on a fleet maintenance day I went through every drive I had and the real culprit was the capacitors on the optical-drive PCBs, not the lasers. I started that day with 4 of 5 GameCube drives dead and ended with all 5 working, this one included.

The recap is the fix: I replaced the caps on the drive PCB and dot-marked each new one with a blue felt pen so I could see at a glance what was done. One drive in the batch had been recapped before but was still dead because a resistor had been knocked off during that earlier job, refitting it brought it straight back. The credit for the caps-not-laser insight goes to leonkiriliuk, who pointed out the laser usually is not the problem.

While I was in there this console also went from a PicoBoot softmod to a FlippyDrive optical drive emulator. Tested it running Resident Evil 4 and Wind Waker.