arcade-projects.com/forums/ind…bad162738fd9c7290c3c66ae3
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!
arcade-projects.com/forums/ind…bad162738fd9c7290c3c66ae3
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:
arcade-projects.com/forums/ind…bad162738fd9c7290c3c66ae3
Doing this worked as a cheap hack to get the GP9001's video to show up!
arcade-projects.com/forums/ind…bad162738fd9c7290c3c66ae3
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.
arcade-projects.com/forums/ind…bad162738fd9c7290c3c66ae3
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.
arcade-projects.com/forums/ind…bad162738fd9c7290c3c66ae3
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:
[h=3]Source Code: BG_U125.EQN[/h]
- ; 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
Display All
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.
arcade-projects.com/forums/ind…bad162738fd9c7290c3c66ae3
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.
arcade-projects.com/forums/ind…bad162738fd9c7290c3c66ae3
The equations I ended up with:
[h=3]Source Code: BG_U33.EQN[/h]
- ; 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
- q6 := d9 * /q7 * /q6 + d9 * q7 * q6
- ; Division of main clock / 2, reset by D9
- q7 := /d9 + /q7
Display All
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.
More...