Battle Bakraid Issues

[Nebula]

Sorry for resurrecting this old topic, but my Bakraid has the same symptom when I plug it into my Egret 2. If the voltage is close to 5V, errors appear in the text layer (only). When I turn it down to 4.70, everything looks good. Seeing Mame source code, it seems that text layer is not managed by the GP9001 Toaplan custom (but by one of the Xilix CPLD ???): https://github.com/mamedev/mame/blob/ma ... aplan2.cpp

I've checked the "Text test" screen that could be selected when booting the game in test mode, where all the text tiles could be seen. It consists of a set of 0x000 to 0x3FF tiles (1024) that when the error occurs is divided into a set of 0x000 to 0x1FF that look good as they are originally, but the other half (0x200 to 0x3FF) is again composed of the same tiles of the first half, appearing duplicates again (the originals of the second half do not appear at all obviously). That is why when game operation is running, where tiles of the second half should be painted, ones of the first appear erroneously.

By lowering the voltage to 4.7 the error disappears. No changes seems to happen by pressing any chip.

[mikejmoffitt]

Bakraid and Batrider both have a lot of custom logic doing anything outside the GP9001 and actual CPU. This includes the text layer. Unfortunately, the CPLD and/or GALs responsible for the text layer have been seen going bad on many occasions, often manifesting in addressing issues. Voltage changes are a "hack" that likely won't last forever as the ICs degrade.

This is one of many cases where a board built out of flashed programmable logic is a ticking time bomb. These chips need to be dumped and/or RE'd before it is too late.

[Nebula]

OMG, I’m totally agree with you. We cannot only see how they are doomed to fail.

I saw your awesome work figuring out the pals of garegga and I’m wondering if I could help to bruteforce those CPLD or something like that similar to what you did for garegga in order to deactivate that ticking time bomb before countdown comes to end.

I know that CPLD are not Gals and they might be several (lot) times difficult to figure out... but just asking...

[mikejmoffitt]

For the CPLDs, I think our best bet is going to be decaps, and protection bit attacks, like what's been going on at caps0ff. That could then let us dump a bitstream from the CPLD. As for the various GALs, those can probably be reversed, or dumped if we are very lucky.

[Nebula]

As far as I check, there is no other gal, pal or any other programable logic chip apart from these 3 CPLD Xilinx chips on the pcb:




I believe that take a current working board to use it as a donor to try to decap those chips is quite risky, more considering there is no suitable spare for them. Maybe using a broken pcb... but it is even harder to find that.

from my total ignorance of reverse engineering these cpld, could it be possible to try to analyze it when running as a regular pal or something like that? Hope it isn’t a dumb question...