Status: Diagnosed from 11/28/2022 – 12/7/2022. Successfully repaired with new Nanao custom on 9/10/2023.
I got a good deal on a Gun Hohki Irem M92 PCB because it booted up with errors.
On M92, the main CPU, graphics rendering hardware, sound synth, sound amp, system RAM are all on the top board. The bottom board holds the sound CPU, primary video RAM and all the ROMs.
First off, I swapped the top board from another fully-functional M92 game over. Gun Hohki booted up and is fully playable and functional with the different top board.
The problem is definitely with the game’s top board. Schematics for M92 is not available unfortunately, so I did some Googling of the error messages and looked over the MAME M92 source. @caius repaired a M92 game with a “Palette Buffer RAM” error once by replacing the IC43 & IC44 RAM chips:
https://www.jammarcade.net/irem-m92-motherboard-repair-log/
I desoldered IC43 & IC44 from the board. Both tested Bad in two different memory testers.
I installed sockets and replaced them with two 6116 series SRAM chips that tested Good on both of my testers.
Coincidentally at this time, I was talking with @wickerwaka on Discord. He recently released a M72 core for the MiSTer and is now digging into the M92 hardware. He shared the following helpful information with me:
IC43 and IC44 are the OBJ RAM
IC37 and IC38 are the OBJ and PALET Buffer RAM
IC15 and IC16 are the PALET RAM
Access to Palette RAM at IC15 and IC16 doesn’t go through any of the custom graphics ICs in the lower-right corner.
CPU access to IC37, 38, 43 and 44 is through IC42.
Video RAM is IC25 and IC26 on the B board.
IC42 copies palette and obj data from IC37 and IC38 to IC43 & IC44 and IC15 & IC16 during the VBlank.
The two PALs close to the CPU manage a lot of the memory access. You could try swapping those between the boards.
With that info in hand, I next decided to swap the two PALs adjacent to the CPU with the ones from my operational testing top board.
Unfortunately this didn’t make any difference. Next, I removed the Palette RAM at IC15 and IC16:
One of the two RAM chips tested bad on the tester. I installed sockets and some fresh 62256 series SRAM chips that tested Good on my tester.
Unfortunately, I’m still getting the same diagnostic errors, although the background is black instead of blue now!
There are three PLD chips on the top M92 board. I previously swapped two of the PLD chips with my working board as a test – now, I went ahead and swapped the third one as well. Nothing changed, and I confirmed that all three PLD chips from the glitching board work properly in the good board.
Time to look closer at the SRAM chips. I used continuity testing to map out where the Address, Data and Control lines go on the two banks of 62256 SRAM chips. I’ll attach the spreadsheet of connections to this post for anyone that needs it later.
SRAM bank IC43 and IC44 is completely driven by the large GA21 custom in the lower-right corner of the board.
SRAM bank IC15 and 16 have Addressing handled by the bank of 74LS153 TTL chips beneath them, while Data flows both left IC 9 and IC10 (74LS273 chips, mislabeled as 374 chips on the board) and down to IC22 and IC23 (74LS245 chips).
One of my new diagnostic tools is SLICE by Aaron Liddiment. It uses a Digilent Digital Discovery USB logic analyzer along with some custom PCBs and software to diagnose TTL and SRAM chips while they’re running on the board. I hooked up SLICE and started testing all of the TTLs that are involved with the four SRAM chips I identified above.
SLICE passed all of the 74LS153 chips used for addressing the IC15 & 16 SRAM bank, but it flagged the two 74LS273 chips at IC9 & 10 used for Data.
I put the oscilloscope on the lines for IC9 and 10 and the signals looked absolutely horrible.
I desoldered IC9 and IC10 off the board. Both tested bad out of circuit.
I installed sockets and two confirmed good 74LS273 chips. Now the board boots up if you let it sit a while on the diagnostic screen, but both the palette and sprites are whacky.
I’m starting to suspect that the GA21 custom that handles the Address, Data and Control lines for the SRAM along the bottom of the board has gone bad. If the custom has died, my only recourse would be to find another one from a parts donor.
I spoke some more with @wickerwaka who is currently examining this hardware and he offered some additional advice:
GA21 basically does DMA and address generation for the GA22.
Cpu read/writes to 37/38 go through it and then it is responsible for copying that data to OBJ and PALETTE ram during the vblank.
IC21 and IC29 are worth checking out too. Those form what the mame code calls the “videocontrol” register. It’s used to control palette bank switching and sprite double buffering during regular gameplay, but it is also used during boot up to give the CPU access to palette ram for memory tests.
I probed the lines on the IC37 and 38 SRAM and they do show activity so the GA21 custom is at least somewhat functional.
I tested IC21 & 29 in-circuit first and got errors, so I pulled them from the board. One of the two tested bad out of circuit. Installed sockets and new replacement chips-still no improvement.
I think I’ve reached the end of the road on this project and the prognosis isn’t good – the GA21 custom that handles SRAM addressing for several chips is bad. I had previously checked for continuity on the SRAM to GA21 lines, but now I checked them with my logic probe – yeah, I probably should have done this earlier….
The probe indicated that several lines were floating (disconnected). Checking continuity with the multimeter on the floating lines to the GA21 still showed continuity, meaning the lines are disconnected inside the GA21 internally. For good measure I went ahead and reflowed the solder joints on the GA21 anyway. The only difference reflowing made was now the diagnostic results show up with a white background instead of blue.
So this board is going to the Parts Donor stash to maybe help revive another M92 down the road. Fortunately, I have an A Board from a Major Title 2 that I can still use to play the game – the B Board is fine.
Oh well – you can’t save them all!
Shoutout to @wickerwaka for all his detailed info on the M92. With his permission, here is a spreadsheet with notes on how the pins of the GA21 and GA22 are used.
September 2023 Update!
Hammy graciously sold me a replacement GA21 custom to repair this board. First, I removed the old GA21 custom using ChipQuik low-melt solder and then soldered the replacement GA21 onto the board.
I’d previously written this board off as non-repairable and had raided some of the SRAM and TTL chips for other repairs. I installed sockets for the missing spots, obtained fresh parts, and installed them. The board booted up with no startup errors and much better-looking graphics than before-success!
It soon became apparent that there were three remaining issues:
- The video output had a blue tinge to it.
- Four of the SW2 DIP Switches showed as being enabled even though they weren’t.
- Sprites would randomly flicker and glitch.
The blue tinge culprit ended up being a IC9 and IC10, which are TTL chips used in palette memory management. The silkscreen on the board calls for 374-series TTL chips but my other M92 boards use 273-series TTL chips in those spots. Swapping in 273-series chips fixed the blue tinge.
The four SW2 DIP Switches all reading enabled was a mistake I made when installing replacement parts – I had accidentally installed a 245-series TTL chip for IC7, which uses a 244-series TTL chip. Installing a 244-series chip fixed the problem.
The sprite glitching culprit was the specific 6116 SRAM chips I used for IC43 and IC44 – swapping them with brand new IDT brand parts cleared things up.
Finally the game was fully operational and glitch-free. I played through the entire game, then left it on for a few more hours to soak test it. The board passed the soak test, so I’m calling this specific project a Win!
