What's new

Hatsune Mike

Champion
Joined
Dec 8, 2017
Messages
736
Reaction score
2,122
Location
Tokyo, Japan
I won a Battle Garegga boardset from eBay, described as "no video, you can hear the sounds sometimes".

garegga.jpg

Sure enough, I received it, and was greeted by a black screen. I could coin it up, and hit start, but then after the normal startup sound, I heard a few gun sounds and the game stopped doing anything. No music at any point.

I got this hoping it was just the typical DAC buffer issue, the 74HCT273s near the JAMMA edge. This wasn't the case, and in cruel irony, the '273s were actually completely fine in the end.

Diagnosis

Step one is to do some probing. Obviously the CPU was doing something, otherwise the coin insert wouldn't be serviced, and the sound CPU was doing something, since it triggered the correct coin and start sounds. With Garegga, this means a lot - the main program ROM and all CPU-exposed RAMs are working correctly. We can skip some steps this way.

I took to probing around the board, and first found that the '273s are being fed no data, so the black screen is likely not their fault. We do have a valid sync signal, and palette RAM bus activity looks correct (yet is still outputting no real data during scanout).

I opted to use a Video Probe to determine to what degree the game was working. This entails disconnecting blue from my JAMMA test harness, and connecting it to a probe through a buffer (74LS04 double-inverting the signal) and then a resistor (to handle monitor termination a bit better). I can then probe around the board and see data on-screen with respect to raster timings, overlaid as a blue color. Furthermore, my monitor has the ability to show only the blue channel, rendered as white, which is helpful for highlighting data.

The video probe is great for finding problems with video; sync signals, line counters, and bus access become very easy to read and understand. I ended up probing the 74LS157s to the right of the GP9001, and found that they are responsible for muxing the outputs of the GP9001 graphics IC with the data from the custom discrete text layer hardware in the lower corner of the board. With the video probe, I found evidence that the board was alive!

garegga_life.png

I also saw here that the '157s were electing to always select the text layer's data. However, probing the text graphics ROM's data lines showed they were all zero, and the address lines weren't pulsing. But, since I knew the GP9001 was outputting good data, it was a start. Since the GP9001 and main CPU system were working perfectly fine, and the text section was completely dead, I thought something is probably wrong upstream. I turned to the dreaded areas of the board I'd avoided, hoping that they weren't the problem: the GALs on the board.

We have three GALs: a GAL16V8 in the center called U33, a GAL16V8 in the lower-right near the text layer called U125, and a GAL20V8 near the sound section (for which I forget the designator). My hunch was that all of them were dead, causing our problems. U33's proximity to the GP9001 made me think it was video-related, and since the GP9001 is pretty self-contained, it may be related to the text layer since that is the only addition this board makes for video, or to palette RAM access control. I was ready to blame U125 for the text problems too, since it was near an oscillator and was right by the text area. I thought it would likely generate clocks for the text layer. Finally, I expected that the GAL20V8 was responsible for the sound problems.

I probed the GAL16V8s and found that their outputs were completely dead; just high-Z lines, floating. We need to replace them!

The first step was to desolder and socket all of these with the help of a friend. We went ahead and socketed the sound RAM too, in case it was bad and caused sound issues. The sound RAM was fine, but the GALs were not. Worse than being locked and registered, these seemed completely dead. Their manufacturer ID showed up as 0xFF and device ID as 0xFF, the calling card of a dead device. The GAL20V8 actually seemed okay - it was locked, but it returned valid manufacturer info. We put it back, considering that it might be fine.

I have a working Battle Garegga as well, so the natural next step is to socket that one and attempt to dump the GALs. Bad news - all of the GALs are locked, and at least U33 is registered. Dumping U125 as a ROM and converting the result to equations did not work either. This did allow for a quick experiment: swapping my known good GALs into the bad Garegga board caused it to boot up and work perfectly. It's nice to know that the work is at least now constrained to just these GALs.

With the 16V8s socketed and removed, at least we can do some experimentation. U33 is registered, and is clocked by pin 1. After some probing, I found that I can place a jumper like so:

IMG_5296.JPG

Doing this worked as a cheap hack to get the GP9001's video to show up!

IMG_5295.JPG

It was a relief to see working sprites, backgrounds, and colors after all of this.

GALs Panic

So, we've got two bad GALs on our hands: U33 and U125. What we know from the outset is that the board behaves the same with U33 absent (and can be semi-bypassed). With U125 removed from the board, it hangs and does not boot up. I found that by forcing pin 12 of U125 low at boot, I was able to get it to proceed.

U125


I started with U125, since I thought it might be simpler. Sure enough, probing around the socket I found that the outputs Q1 through Q5 had infinite resistance to ground and VCC on the board, indicating that they were likely unused. Inputs D6, D7, and D8 were also grounded. That reduces the problem surface a lot.

My trump card is that I can look at the working Garegga.

As mentioned before, dumping U125 as a ROM did not work from the good Garegga, but I can at least observe it using a scope and logic analyzer. From the analyzer trace, U125 looked at first like a simple latch, which seemed like an under-utilization of the device. I fashioned a replacement out of a 74LS273 and a simple pin adapter.

IMG_5412.JPG

With this hack fix, I actually got the board to play some music! However, only some tracks worked. Others would play wrong sounds and lock up the sound CPU (which locked the game up) or would even play incorrect tracks. More work was needed.

After doing a lot more capture work on the analyzer, I realized I'd ignored the CLK input (pin 1). On a registered GAL, this is a clock used for latching data on the rising edge of a clock, but for a GAL doing pure combinational logic, this can be used as a general input. On the scope I only saw it at logic 0 so I didn't even consider it. After adding CLK to the waveform on the analyzer, the function of U125 became a bit clearer. There outputs, two pulsing inputs, and three lines that seem to select the functions of each, CLK being one of them.

u125_data.JPG

After a solid amount of experimentation (and re-learning how to work with sum-of-products formulas after almost a decade) I produced a working set of equations for U125:

Code:
; These outputs are not used, and probing the PCB shows infinite
; resistance to ground. They are N/C.
q1 = /d7
q2 = /d7
q3 = /d7
q4 = /d7
q5 = /d7

; D3 acts like an output enable
q6 = d3*d2*/d5*d6
q7 = d3*d1*/d5*d6
q8 = d3*clk*/d5*d6 + d3*/clk*d5*/d6

Great, U125 was taken care of. Now onto the final boss...

U33

I knew U33 was going to be a little harder, because its functions are a little more complex. However, the video probe made understanding the general purpose and relative timing of the outputs pretty easy before I even put it on the analyzer. All its outputs were directly related to various raster timings - events occuring right at the start of Hblank or Vblank, or clock divisions.

I found pretty quickly that one pin output CLK/2, which is the dot clock, and another output /CLK/4, which selects even or odd pixels (getting this wrong looks quite funny). Others are brief precisely timed pulses during blanking regions, which are for negotiating who has mastery of the text RAM address lines.

In order to characterize U33 better, I first eliminated the challenge of learning to program GALs by making a working model in VHDL with an FPGA. I took a capture of the H and V blank events on the logic analyzer, and used the resulting timing waveforms to characterize the outputs in terms of a ripple counter representing the span of a single scanline.

IMG_5346.JPG

With an FPGA hooked up, the text layer worked fine, with one little quirk - if I connected output Q8, it scrambled the screen and made the text RAM test fail. With it disconnected, everything seemed perfect...

The FPGA model can be seen here:

The final task was to consolidate this logic onto a GAL16V8. The GAL will not allow creating a large 10-bit counter like this; at best I can make an 8-bit counter, but that'll eat my outputs. However the LSB and second-LSB of a counter are implied by the clock division outputs. I was puzzled as to how I could make this output given the inputs I have without a counter, but it hit me one night to check the pin for Q8 with the GAL removed. With that, I found that it was actually an input to the GAL, which helped solve the pizzle.

In order to make this work I reframed my problem as a list of transition events in order. That way, I can make every transition dependent on ones that have occurred before it. I had to remember how to form a JK flip-flop using SOP along the way too! This one took a lot of experimentation and timing diagram comparisons, but I eventually did get this to behave perfectly. There is NO room for timing innacuracy; every little mistake scrambled the text raster and broke text RAM R/W. The boot-up self-test was very helpful in making sure things were working correctly.

IMG_5450.JPG

The equations I ended up with:

Code:
; Inputs d3-d8 represent the current raster line / 4.
; D3 is the LSB.

	@define vbl_end   "/d3 * /d4 * /d5 * /d6 * /d7 * /d8"
EQUATIONS

; End of frame blanking; cleared on line 240 and reset when the
; raster counter flips back to line 0.
; If this signal is incorrect or not respected, text RAM errors occur.
; I suspect this is due to a bus conflict with the text RAM address.
q1 := q1*d3 | q1*d4 | q1*/d5 | q1*/d6 | q1*/d7 | q1*/d8 + vbl_end;

; Raster signal event listing
; Validated one by one with logic capture before working on the next transition.
; 1) q3 low			CONFIRMED q3*/q6*q7 + q3*/q7*q6;
; 2) q5 high			CONFIRMED /q7*/q6*/q3
; 3) q4 low			CONFIRMED q4*/q7 + q4*/q6*/q7 + q4*q6*q7 + q4*/q5
; 4) q3 high			CONFIRMED /q4
; 5) q2 low, q5 low		CONFIRMED x*q4 + x*/q7 + x*/q3 ; x = q2 or q5
; 6) q4 high			CONFIRMED q1*q7*q6*q5*q2 + /q1

; These ones are the wild shit.
q2 := q1*/d9 + q1*q2*q4 + q1*q2*/q7 + q1*q2*/q3 + /q1
q3 := q1*/d9 + q1*q3*/q6*q7 + q1*q3*/q7*q6 + q1*/q4 + q1*/q2 + /q1
q4 := q1*q4*/q7 + q1*q4*/q6*/q7 + q1*q4*q6*q7 + q1*q4*/q5 + q1*/d9 + q1*q7*q6*q5*q2 + /q1
q5 := q1*/q7*/q6*/q3 + q1*q5*q4 + q1*q5*/q7 + q1*q5*/q3

; Division of main clock / 4, reset by D9.
; When non-flipped, takes /D2 one cycle after q3 goes high...
q6 := d1*q4*d9*/q7*/q6 + d1*q4*d9*q7*q6 + d1*/q3*/q4*d9*/q7*/q6 + d1*/q3*/q4*d9*q7*q6 + d1*/q4*q3*/d2 + /d1*d9*/q7*/q6 + /d1*d9*q7*q6

; Division of main clock / 2, reset by D9
q7 := /d9 + /q7
With both GALs replaced, we have a working Garegga again, and the repair is (nearly) complete.

Omake

Of course, something else has to come up. After playing Garegga for a while, a friend noticed that it was crashing on occasion, and when it showed the high score table there was sometimes junk data instead of the correct text. I determined that the socket for U33 had gone too loose and spongy after having been repeatedly used around one hundred times during development. I replaced it with a proper machine pin socket and it's been solid ever since.

During this, I borrowed a friend's Kingdom Grandprix board, and saw that there was a chip labeled U33 in the exact same spot. We dumped it and found it was also locked, but swapping it onto Garegga made a working Garegga board, so I'm confident that U33 is the same between both Mahou games and Garegga. Possibly Batrider and Battle Bakkraid use the same logic, since they overlay text as well. Mahou calls this "TWIN-CAM", so I'm calling this chip that from here on.

I'd like to do a follow-up and socket the GAL20V8 just for completion's sake.

Special thanks to @CoolFox, @Phil Bennett @brizzo and spray.
 
Last edited:
Awesome write up, thanks for sharing!

I'm glad I didn't bid against you on this, had considered it! Good to see it went to another AP member. :thumbup:
 
Very solid work from @Hatsune Mike -- solving logic equations like this from logic analyzer captures takes a very high level of mental talent :D
 
Great to read all these good efforts to revive such great game. :thumbsup:
 
A most excellent repair log. I'll definitely have to remember that video probe trick!

Glad to see that Gregga went to someone who knew what they were doing too.

As for the PALs is it possible to brute force them rather than dumping them?
 
sum-of-products
I would literally have to dig out my hand written notes from my Junior year of High School to even remember sum-of-products formulas. Last time I used them was about a decade ago as well working on an Aquatrol Automated system for a Water Treatment Plant lol.

Awesome work!
 
Being a repairer I do like reading others repair logs too.
@Hatsune Mike when you say "that $400 one from eBay" do you mean you actually paid $400 for a faulty board?
If so I can understand the commitment in the repair.
Unfortunately for me I always end up with fucked up custom chips... So my maximum gamble is $10 for a faulty board unless I have a donor for the custom chips.
 
well when a working battle garegga sells for $1600 ... $400 is a low gamble.
 
Being a repairer I do like reading others repair logs too.
@Hatsune Mike when you say "that $400 one from eBay" do you mean you actually paid $400 for a faulty board?
If so I can understand the commitment in the repair.
Unfortunately for me I always end up with fucked up custom chips... So my maximum gamble is $10 for a faulty board unless I have a donor for the custom chips.
Correct, I took a big risk on buying a board that I knew was faulty for $400, but I expected it to be a simpler and more common problem.

However, at this point, the risk factor is now lower. The true custom IC, the GP9001, is a common Toaplan custom and can be found on cheaper donor games if needed. That said, I have never encountered a failed GP9001, which is very fortunate.

As for the irreplaceable GALs, well, here we are - after this, Garegga is now a very repairable board, and through extension of that, a less risky board. From Suruga-ya, I just got another one for around $500, and sure enough the two GALs I RE'd were dead (alongside some RAM). For a $1200 board to be brought back so easily within a few hours, the investment of time in the previous repair has paid off.

However, "untested / broken" with no description wouldn't have been a good gamble. For this PCB, and the next, I paid attention to the described symptoms so I could have a belief that the majority of the PCB worked.

Also very important is the fact that I'm not interested in paying $1000+ for this game! Buying cheap broken ones is the only (somewhat) cheap path towards these games now.
 
Thanks for your detailed answer. You did a great job for sure.

PAL/GAL chips are generally not a problem, even if registered, they are simple enough to make an educated guess on how they should work (reversed the 460A23 PAL found on The Karate Tournament, it's used as a sound latch amongst other things).
Brute force is also very efficient for pure combinatorial chips.

I've also reversed quite simple chips/modules:
- 85H001 sound module found on many Capcom boards from the mid/late 80's
- 315-5298 tile banking chip (PLS153, DIP20) found on some Sega's System 16B romboards
- Altera EPM5032DC (DIP28) security chip found on Sega's System 24 romboards
- 315-6436 custom chip (SDIP64) found on later Sega's System 18 romboards (171-5987 type)
- etc.
There are so many others I'd like to reverse...

Security chips can be reversed or circumvented too (patching/hacking), real problem is only custom chips (I have quite a lot of faulty Konami boards, unfortunately reference crossing didn't give me any cheap donor alternative).
 
Last edited by a moderator:
Awesome repair! I appreciate the work that goes into bringing these boards back to life.

Unfortunately, I've had several PCBs die on me over the last 3 years. To be fair, they were crummy to begin with.

I've since been paying a premium to avoid such situations. Mostly because I don't have your fine skills and the cost to repair ends up costing as much as you would have paid for a nice clean PCB ;)
 
Awesome repair! I appreciate the work that goes into bringing these boards back to life.

Unfortunately, I've had several PCBs die on me over the last 3 years. To be fair, they were crummy to begin with.

I've since been paying a premium to avoid such situations. Mostly because I don't have your fine skills and the cost to repair ends up costing as much as you would have paid for a nice clean PCB ;)
Agreed. If I'm in the position to throw down loot, I usually just hit up Tops/Sophia and pay the price for the peace of mind :)
 
Wow, as a person that does electronic repair fairly regularly now and recently getting more into using a scope to probe things this is very respectable. I would love to work towards this level of repair!!!. Super informative thank you!
 
Congrats on the repair! Very impressive work, Hatsune Mike. If there was ever a game that is worthy of the effort, it's Battle Garegga.
 
Back
Top