As part of troubleshooting his Gradius II PCB,
@hoagtech asked me through PM for a summary of my diagnostic procedure when looking at a board. I ended up writing a short essay, and we both agreed that the info may be useful for others so here it is:
Here's the rundown on my process when troubleshooting a board. I don't know what your current knowledge level of electronics troubleshooting is, so I'll try to explain things as thoroughly as I can without getting too far into the weeds.
Tools
At a minimum, you'll want a digital multimeter. Use it to test for voltage levels on chips and for continuity on traces. A decent starting multimeter can be obtained for around $20 from Amazon.
You'll want to have a logic probe - it lets you see the logic activity for each line on each chip. A decent starting logic probe can be obtained for around $20 from Amazon.
I made a tutorial video on using a logic probe to test an EPROM here:
View: https://www.youtube.com/watch?v=2PAtTIAijeA
Eventually, you'll want to have an EPROM programmer - it lets you dump ROMs, program new EPROMs, test logic chips, and test RAM chips. A decent entry-level EPROM programmer costs $200.
Eventually, you'll also want soldering and desoldering tools - you'll need them to remove faulty components from the board to replace them.
Decent entry-level soldering tools start at about $150.
Procedure
1) Make sure all DIP switches are set to OFF, and that the supply voltage is between 5.0V and 5.15V. Some boards need a little more juice than 5.0V to run, but don't exceed 5.15V if you can help it.
Some boards need a DIP switch selected to enable Test Mode. Some boards won't boot up normally if a Test or Halt DIP Switch is enabled.
2) Identify the malfunctioning subsystem.
Is the board not starting up at all? Does it startup but fail a diagnostic check? Does it boot up and run, but have corrupted audio or video? If it does have corrupted video, is it background tiles, sprites, or overlay (fixed) text. If it has corrupted audio, is it music, SFX or speech? How does the malfunctioning board behavior compare to a properly running board in MAME?
With your Gradius II, the board starts up and hangs on the RAM ROM check. The graphics don't look corrupted though, so that's a good thing. It looks like the RAM ROM check normally proceeds to a summary screen where it lists Pass & Fail results. Since your board isn't proceeding to the results screen, one of the two main CPUs is probaby crashing. That points to an issue with either the code the CPU is executing (EPROMs), the CPU work RAM, or the TTL logic chips between the CPU and work RAM - so you'll want to focus on the CPU subsystem.
3) Research the board and identify where subsystems are located physically on the PCB.
Are schematics available for the board? Are there repair logs from other people working on the same board?
Remember that several games often use the same or similar hardware, so be sure to look up schematics / logs on those games as well.
Ideally, you want to be able to identify where each subsystem of the game is physically located on the PCB - CPU, audio, background tiles, sprites, pallette and I/O.
Generally speaking, the subsystems usually "clump" together - control I/O and pallete RAM will be close to the JAMMA connector. The audio subsystem (CPU, RAM, EPROM, music synth) will be located next to the audio amplifier and volume dial. The main CPU and supporting EPROMs, RAM, and TTL logic tend to be in the center of the PCB, and video (usually custom chips fed by EPROMs and TTL logic) are often around the edges on a single PCB.
The MAME driver source code can also be a good source of identifying which EPROMs feed which systems, along with other info.
With your Gradius II, I assume it's a Konami Twin 16 hardware conversion - that hardware is also used for Cue Brick, Dark Adventure, Missing In Action and The Final Round.
Schematics for this hardware are here:
https://usermanual.wiki/Document/DarkAdventureSchematics.3042322519/view
There's some repair logs for this hardware here:
https://www.jammarcade.net/gradius-ii-gofer-no-yabou-repair-log/
https://www.jammarcade.net/gradius-ii-gofer-no-yabou-missing-drums/
https://www.jammarcade.net/vulcan-venturegradius-ii-repair-log/
https://www.jammarcade.net/vulcan-venture-repair-log-2/
https://www.aussiearcade.com/topic/...and-not-booting-properly-has-been-sorted-out/
The MAME driver is here:
https://github.com/mamedev/mame/blob/master/src/mame/drivers/twin16.cpp
It looks like Twin 16 usually has two boards - the top CPU board with two 68000 Main CPUs, the Z80 sound CPU, the audio hardware, the I/O hardware - and the bottom Video board with the background tile generators, sprite hardware, and fixed text hardware. Your problem seems to be CPU related so you'll want to focus on the top CPU board.
There's also a three board Twin 16 variant, but it's rare.
Pay special attention to any repair logs where they treat the same symptoms your board is having - that's a great focus for your troubleshooting.
3) Inspect the board carefully around the affected subsystem.
Look for scratches, loose chips, rust, missing components, bent legs, etc. Check both the top side and bottom side of the PCB carefully for physical damage.
If you find loose components, try removing and then reinstalling them. Rust should be scrubbed off with a fiberglass brush, and the affected solder joints should be reflowed. Battery acid will need to be cleaned with vinegar and Q Tips. Check scratched traces with a multimeter set to continuity check - if continuity is broken for the trace then it can be patched with bell wire.
Physical problems that happen but are harder to spot are cold solder joints on through-hole components, and lifted legs on SMD components. Run a Google Image Search on those topics to learn more about what to look for.
4) If the PCB is a multiple board stack, check the connections between boards.
The inter-board connections can be ribbon cables or inline connectors. Check for bent or tarnished pins in the connectors. Remove and re-seat everything.
In your case, it looks like Twin 16 consists of two PCBs. Disconnect the two PCBs from each other and inspect the connections on both sides. Firmly reattach the boards together, power up, and see if anything behaves differently.
5) If the board checks out physically then test the ROMs appropriate to your glitching subsystem.
Remove the EPROMs for the affected subsystem (if they're socketed), dump them using an EPROM programmer, and compare the checksums of the dumped files against MAME. Also check the sockets while the ROMs are removed - look for dirt, rust or tarnish inside the socket pins.
If a ROM won't dump (programmer gives an error trying to read it) or if a checksum doesn't match MAME, then try programming a replacement EPROM and see if using it resolves the behavior.
In your case, I'd focus on the EPROMs for the two main CPUs and the sound CPU. Lines 1024-1056 of the MAME driver lists the ROMs used for each subsystem of Gradius 2. ROMs 6N, 4N, 6R and 4R are the code for CPU A. ROMs 10N, 8N, 10S, and 8S are the code for CPU B. ROM 10A is the Audio CPU code.
Imagine the board layout as a spreadsheet with letters going one direction across the axis and numbers going down the other axis. So A1 would be the top-left corner, B1 would be the adjacent quadrant to the right of A1, etc. That will help you locate the EPROM locations on the PCB when looking at the ROM filenames in the MAME driver.
Removing those EPROMs and reinstalling them in the sockets may be all that's necessary, but if that doesn't work then dump them and check them against the MAME checksums.
5) If the EPROMs for the affected subsystem are good, then use a logic probe and start testing the lines of the affected subsystem - the two main CPUs in your case.
This is where things get in-depth and time consuming. In a nutshell, you'll want to check the lines on the subsystem's EPROMs, logic routing chips, RAM and CPU (in that order) with a logic probe and make sure they show appropriate activity.
Each of these chips has a 5V supply line (labeled as Vcc on a datasheet) and a Ground (labeled as GND or Vss). For each chip, look up a datasheet for the chip you're examining, and test those lines with the logic probe first. The probe should read solid High for 5V supply and solid Low for Ground. Use the datasheet to probe the additional lines as detailed below.
Let's drill-down on each chip type:
EPROMs
Check the Address line first. The Address lines are set by the CPU and memory mapping logic chips to tell the EPROM what data to read out. The labels for the Address lines on the data sheet begin with the letter A.
Each Address line should show rapid pulsing between High and Low on the probe while the RAM ROM check is processing.
If an Address line doesn't show activity (it's "stuck" Low or High) then follow the connecting trace for that line to the chip that feeds it and diagnose that chip. Also do a continuity check on the trace with a multimeter to make sure that there isn't a break in the connection.
If the Address lines all look good then check the Data lines next. The Data lines output the data selected by the Address lines when the Enable lines are set. Data line labels begin with the letters D, O or Q on the datasheet.
Each Data line should show rapid pulsing between High and Low on the EPROM while the RAM ROM check is processing.
If some of the Data lines don't show activity then change the chip out for a fresh EPROM. If none of the Data lines show activity then check the EPROM's Enabling lines for problems.
Each EPROM has at least one (and often multiple) Enable lines. They can be labeled as Output Enable (OE), Chip Enable (CE) or Chip Select (CS) on the datasheet. The EPROM only sends data out on the Data lines when all the Enable lines are set appropriately. If the datasheet shows a line over the label for the line, that means the line is Active Low and that the line needs to read Low on the logic probe for the line to be enabled.
If all the Enabling lines are being triggered correctly but the Data lines are dead, replace the EPROM. If the Enabling lines aren't being triggered, follow the connecting trace for that line to the chip that feeds it (likely a TTL logic chip) and diagnose that chip. Do a continuity check between the two ends of the trace as well.
TTL Logic Chips
TTL logic chips are responsible for many functions, but especially memory mapping - they handle Address line switching between the CPU, EPROMs and RAM. Sometimes they're used to route Data as well between the CPU, EPROMs, RAM and the subsystems on the board.
Logic chips generally take in one or more Inputs, have one or more Control lines, and then one or more Outputs where the output state is determined by a combination of the Input and Control lines.
Logic chip part numbers for JAMMA arcade boards pretty much all start with the number 74. You should be able to Google the part number and pull up a datasheet for a given logic chip. The datasheet will have a Truth Table that will list out all the combinations of Inputs, Controls, and Outputs.
You'll want to test the lines with the logic probe - look for dead (stuck High or Low) Outputs first. If a logic chip's Outputs are dead (stuck High or Low and not pulsing) but the Input and Control lines are pulsing then it usually means the logic chip has failed and should be replaced. If Input or Control lines are stuck High or Low then trace them back to their source and diagnose that chip.
Note that Fujitsu logic chips have a bad reputation for failure. If your board has Fujitsu-branded logic chips (Letter F brand mark on the chip) then consider it guilty until proven innocent.
Most EPROM programmers have a Test function that will verify the functionality of a 74 series logic chip that you remove from the PCB.
RAM
I won't get too much into details here on the RAM except to say that you'll want to check for "stuck" lines that aren't the 5V supply or Ground. Any dead or stuck Data lines may indicate a failed RAM chip. Again, Fujitsu RAM has a bad reputation. Most EPROM programmers have a Test function that will verify the functionality of a RAM chip that you remove from the PCB.
CPU
I won't get too much into details with the CPU either - like RAM, look for "stuck" Address or Data lines. If the CPU isn't showing any activity on the Address or Data lines at all, check the Clock line. If the CPU doesn't receive a pulsing clock signal then it won't process any data. The probe should read rapid pulsing between High and Low for the Clock line.
The CPU also has a Reset line that should be triggered when the board first starts up or resets. If Reset never gets triggered at power on then the CPU won't start processing.
Many CPUs also have a Halt line that will "pause" processing when the line is enabled. Check the Halt line with your probe and make sure it isn't being held active.
Anyway, that should be enough info for you to make a good start on diagnosing your board.
.
