Irem M92 Gun Hohki / Mystic Riders Repair Log

[ShootTheCore]

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.


Unfortunately, this made no difference - the same diagnostic errors still come up.

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.

I’m out of room for photos on this post, so onto the next…

 

[ShootTheCore]

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!



That’s all for now. I’m going to break out the logic probe next and start checking the chips that feed the Address lines on the RAM chips. Since three out of the four RAM chips I’ve removed so far have tested Bad, I suspect that one or more TTL chips may have also failed. I suspect this board got a good over voltage shock or had the JAMMA harness plugged in upside-down at some point. Stay tuned!

 

[XtraSmiley]

I have a working version of this game, so if I can help in anyway way let me know!

 

[ShootTheCore]

Time for another progress update.

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, but both the palette and sprites are whacky.

 

[ShootTheCore]

I'll be working on the board more tonight, but 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'll take a look at IC21, IC29 and the SRAM lines connected to GA21 next and see what I can find. If GA21 looks unresponsive then I'll reflow the solder joints on it and cross my fingers.

8 dead chips down and who knows how many more to go!

 

[CoolFox]

Sounds like someone overvolted this game lol. Nice work.

 

[ShootTheCore]

Another quick repair update:

- 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’m going to look closer at the GA21 custom this weekend but it's looking very likely that that's the culprit. If the GA21 custom is bad then this board will end up being a parts donor I'm afraid.

 

[ShootTheCore]

Well, 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!

 

[ShootTheCore]

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.

https://docs.google.com/spreadsheets/d/19-0Xd1zvRw1qGPU_QqxbQT6VF1Enyuvl4FngiT0Gcwo/edit?usp=sharing

 

[Mrhide]

I have a Major Title 2 in the "to fix when I know what the hell I am doing" pile ... this will help, thanks.

 

[djsheep]

Nice worklog @ShootTheCore, you really put in some solid work.

Bring on the Repair logs all day every day!

 

[Monstermug]

Great writeup. Love repair logs that describes how it should work rather than if x then replace y because not all symptoms have the same cause and providing information on how it works not only shows you know what your doing but helps more for others to repair thier game.

 

[ShootTheCore]

I've been able to revisit and successfully repair this board, thanks to @Hammy who sold me a replacment Nanao GA21 custom. Here's the gory details - I've also logged them at https://shootthecore.tech/repair/repair-log-irem-m92-arcade-pcb/

Hammy graciously sold me 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:

1. The video output had a blue tinge to it.
2. Four of the SW2 DIP Switches showed as being enabled even though they weren’t.
3. Sprites would randomly flicker and glitch.

The blue tinge culprit ended up being 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.

 

[ShootTheCore]

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!

 

[rtw]

Nice work!

Small tip for the Chip Quik users. It's great to remove components because bismut and low temperature but make sure you clean away the Chip Quik before soldering on a new chip.