What's new

ShootTheCore

Legendary
Joined
Jan 20, 2016
Messages
3,310
Reaction score
6,572
Location
Utah USA
In for repair is a DoDonPachi Dai-Ou-Jou PCB with Black Label EPROM installed that isn't displaying most text and isn't displaying backgrounds:
Board.jpg
Game1.jpgGame2.jpgGame3.jpg
Interestingly, the game does display the countdown timer text on the Version Select boot screen, and text appears on the high score table.

DDP-DOJ is based on the IGS PolyGameMaster hardware, and the MAME driver shows that the backgrounds and text tiles are supplied by two ROMs - a PGM BIOS ROM located at U18 on the PCB and an art content ROM located at U19 on the PCB.
Screenshot 2024-08-12 at 1.28.35 PM.png

In MAME, filling the "pgm_t01s.rom" file with FF using a binary editor had no affect on the game booting and running at all. But when I fill the U19 ROM with FF and run the game in MAME, the behavior matches the PCB exactly.
1.png2.png

I checked over the board carefully with a microscope and ensured that there wasn't any physical damage to the legs of either of the involved ROMs or to the large "IGS 023" custom in the center of the board they're connected to. For good measure, I reflowed the soldered connections on the U19 ROM, but it made no difference. There is evidence of prior battery leakage with associated prior repairs by another tech in the lower-left corner of the board.

ROM U19 is a 64 meg TSOP 44 mask ROM which doesn't appear to have a direct-fit flash equivalent. Assuming that the pinout for the U19 ROM is the same as the 16 meg TSOP 44 used for the BIOS at U18 would result in this pinout:
TSOP ROM Pinout.png

Breaking out the logic probe and checking the lines on both ROMs, I discovered the following:
- U18 and U19 share the same bus for Address and Data, with only the Output Enable (Pin 14) lines being unique to each ROM.
- Output Enable is generated by the PAL chip at U33. Pin 18 of U33 drives the Output Enable of the U19 ROM.
- The Output Enable signals are generating and getting passed to the ROMs correctly.
- The Address lines all showed proper High-Low pulsing activity.
- The Data lines seem to be holding mostly High.

Scoping out the Address lines versus the Data lines makes the problem even more apparent:
ScopeGood.jpg
Address lines of U19

ScopeBad.jpg
Data lines of U19

So it seems that the Data lines are trying to pulse Low but are being pulled High. I need to check around the board more to see if there's any other shared parts on the Data bus, but I did confirm that U18 and U19 Data lines do connect directly to the IGS 023 Custom in the center of the board.

At this point, I'm unsure if I should proceed directly to replacing the IGS 023 Custom with a donor from a PGM mainboard, or if I should try removing other parts that share the bus like the U18 BIOS ROM to see if they're pulling the signals High. I'm hoping the U19 ROM itself hasn't failed since there wouldn't be an easy way to replace it AFAIK. My gut feeling is that the Custom is bad, but I welcome opinions before proceeding further. Pinging @Fluffy , @iq_132 and @GC8TECH once again due to their familiarity with the PGM hardware.
 
Last edited:
From what I can tell A, B, T and M rom are not visible to the CPU, so should have no impact on booting or operation of the ASIC. (M ROM may be visible - the sound chip can work with DRAM instead of a ROM, though it is ages since I've seen the data sheet, and I have no idea if CPU access is possible when not in DRAM mode.)

So if it runs then the CPU and the cartridge ASIC related logic should be fine.

The T-ROM(s) provide art for the 8x8 text screen and the 32x32 background screen. The motherboard has a T-ROM containing the art for the splash screen animation, some built-in fonts and logos. It is mapped to 0x0000 in tile space. The cartridge contains all the art specific for the game, based on MAME it is mapped to 0x180000.
If you can go into the service menu, that should most likely use the art from U18, if that works then the BIOS T-ROM should work and not do anything totally crazy.

My guess is then the GAL or U19, though the GAL will be much cheaper to replace. :)

The GAL doesn't only generate /OE, but also a "disable" signal for the BIOS T-ROM. It also remaps the high address lines for tiles, so reads from 0x180000 on from the motherboard go to 0x000000 in the cartridge.
Since the game itself runs I assume no other logic is in that GAL, so it should work similar to my U6 code. You will not be able to use the pin assignments directly, you'll have to beep out the connections. The most difficult thing will be the high address lines for the tile data - they'll go to the big motherboard ASIC and the GAL.

Since PGM has only one background layer games do some background or text stuff with large sprites. I seem to remember some title screens are large sprites, and some score animations.
 
The PALs for this game are dumped and available on the PLD Archive (they appear identical to Espgaluda):
https://wiki.pldarchive.co.uk/index.php?title=DoDonPachi_Dai_Ou_Jou

I programmed and installed replacements for both the U32 and U33 PAL but the board behaves exactly the same. The Service Menu seems to be rendered with the U19 ROM in this case - I get a blank display when accessing the Service Menu on both the board and in MAME with the blanked-out U19 ROM.

If the BIOS T-ROM was disabled by the PAL, would it hold the Data lines high?
 
Data lines of a memory chip (RAM, ROM, etc) that is not selected or doesn't have output enabled should be tri-state.
 
I traced out the lines on PAL U33 that connect to the U19 background art ROM:

U33
Pin 12 = U19 Pin 1
Pin 13 = U19 Pin 44
Pin 14 = U19 Pin 43
Pin 15 = U19 Pin 2
Pin 18 = U19 Pin 14

I confirmed that all of those lines are signaling properly on the scope. The U32 PAL doesn't have any lines running to the U18 Text BIOS ROM or the U19 background art ROM. I feel pretty confident that the PALs are not the problem here.

I went ahead and removed the U18 Text BIOS ROM from the board to see if it was responsible for pulling the U19 background art ROM data lines (pins 15-22, 26-31) High.
IMG_1235.jpg

The board still boots up and runs, but now instead of no Text or background layer output at all, the text layer is outputting lines on top of everything.
IMG_1237.jpgIMG_1238.jpgIMG_1240.jpg

MAME mostly matches this behavior if I write all zeroes into the background layer ROM.
Screenshot 2024-08-15 002938.png

Probing pins 15-22 and 26-31 of the U19 ROM now reads no activity on them whatsoever - they all read Low. The text layer on the running game changes colors or patterns when I probe those ROM lines.

So now I'm wondering - are the output lines on the U19 inactive now because the ROM is bad? Or are they inactive because without the U18 ROM the text system doesn't get initialized? If the U19 ROM has failed, is there anything that can be done to replace it? I imagine it would either need a 48 pin 64 meg flash chip adapted to work with 5.0V and the 44 pin footprint. Or could two 27C322 EPROMs be attached to a breadboard and then connected to the 44 pin footprint with patch wires?
 
Update: I pulled the Text BIOS and background art ROM and dumped each as a MX29F1610. I know that part model wouldn’t accommodate all of the data in the background art ROM but at least I could see if the first 16 MBit would read out of the ROM correctly.

IMG_1266.jpegIMG_1268.jpegIMG_1261.jpeg

The BIOS reads out fine but the art ROM is all FF so it looks like it’s toast.

IMG_1270.jpegIMG_1269.jpeg

Is the only option now to source a replacement ROM from a parts donor? What do the Chinese repro carts do for the background art data with this game?
 
The Intel 28F640J5 has been identified as a suitable replacement flash part for the dead background mask ROM. The Intel is a 64 Mbit capacity chip and runs on a 5.0V bus, but it is physically larger than the original ROM and it has 56 pins compared to the 44 pins of the original ROM.

This seemed like a great opportunity to learn KiCad, so I dug into the datasheets and set about creating my first-ever adapter PCB. I need to cross-check a few more measurements before sending the CAD files out for PCB manufacturing but things are looking promising for repairing this board!

Screenshot 2024-08-23 at 12.39.24 PM.png
 
Adapter board is now finalized and submitted to OSH Park for manufacturing. I cut off the edges of the PCB as close to the traces as I could to make room for the SMD caps surrounding the footprint on the DDP DOJ board.

The 0.31mm distance between each pair of castellated pins was a problem for both PCBWay and JLCPCB to manufacture (they want 0.4mm minimum) so I'm crossing my fingers that OSH Park gets it right.

Screenshot_2024-08-25_164519.png
 
I realized that I don't have a way to program Intel 28F640J5 flash chips. Back to KiCad again-this time to produce my own adapter for the FlashCat USB XPORT programmer. I'll have to solder the flash chip for programming-sockets are pretty much unobtainium for 16mm X 23.7mm in 56 pins.

I really hope all of this works in the end... :P

1.png2.png3.png
 
H! :)

Someone has already worked on a repro of the PCB.

I have one to save, the battery has vaporized the tracks and vias, but the rest is ok in terms of chips and the rest.

I say this because people have already worked on pcb reproductions of Nec pcengine, Duo and Neo Geo AES motherboards .

THANKS:thumbup:
 
I wonder if a repro PCB of this game would accommodate only the original mask ROMs or if they would expand the footprints to allow for flash equivalents. Although there’s certainly plenty of these boards with trace damage, that wasn’t the culprit here and a repro PCB wouldn’t have helped if it was a one-to-one clone.
 
I wonder if a repro PCB of this game would accommodate only the original mask ROMs or if they would expand the footprints to allow for flash equivalents. Although there’s certainly plenty of these boards with trace damage, that wasn’t the culprit here and a repro PCB wouldn’t have helped if it was a one-to-one clone.

Hi! :)


This is an original that I want to save :saint:

20220222-153847.jpg


20220222-163930.jpg


20220222-154006.jpg
 
Back
Top