Final Fight (Bootleg)

Jacmar

Active member
Feedback
1 (100%)
Credits
698CR
Fresh from the recent resurrection of another Final Fight bootleg (Link Here) I grabbed this one from the fix pile while the events of other one were still fresh (ish) in my mind.
This one is different to that Soon Hwa one in that it has less PAL's and GAL's dotted around and has a daughter board with a 84 pin PLCC which I'm guessing handles graphics addressing, but other than that the layout isn't too dissimilar ... lot less ROMs too but they are all directly soldered as are all the RAM :rolleyes:... Sound section has many more components than the Single OKI Soon Hwa board does, which hopefully will mean the sound quality on this one is better, it surely can't be any worse ...

1.JPG

A few visible issues caught the eye on first look ... with most probably due to poor storage/handling at some point in it's life ... components half hanging off etc

fl4.jpg

Board won't boot without a crystal providing a cpu clock, or solid reset signal (pic above left) so first up was a bit of research ... This board should have 2 crystals - a 24Mhz crystal and a 10Mhz crystal. The missing one near the cpu is the 24 Mhz so that's an easy enough fix - in went one of those. The blown cap is 10uf, again easy swap. but the missing capacitor I have no idea what it's value is so I tried looking for images of this board online and I found a few that are similar layout but none the exact same. Some versions have the PLCC on the main board and no daughter board, and I can see there should be 2 capacitors in that area but none are high enough resolutions to read any cap values. On most the pictures I looked at the 'missing' cap was a bit larger in physical size than the other. The 10uF cap is connected to the nearby LS132 (and GND) and the missing cap connects to the nearby diode (and GND). Haven't come across this dual reset capacitor setup before so asked chatGPT about it and it thinks Cap 1 (missing bigger one) creates the main power-on reset delay, whereas Cap 2 (10µF) filters / stabilises shaped reset. So recommends a 22uF or 47uF for the missing cap. Went with a 47uF ...

The resonator and film capacitor that are both hanging on by one leg (above right pic) are in the sound section so are not on the priority list. Usually tackle sound last.

Next up ... crushed pins everywhere on the solder side of the main pcb, (see below) plenty touching where they shouldn't. Despite this, hardly any scratches to the pcb (a few superficial ones) and cant see any obvious trace damage at first glance. Spent a while straightening them all up and making sure nothing was shorting ...

fl3.jpg

Last thing before first switch on .... corrosion and/or excess dried flux on the daughter board connector pins, this is present on both the daughter board and the main pcb socket soldering. PLCC socket on the daughter board has seen better days too .. scratched and scuffed, some pins in it look to be tarnished or corroded ... see below ...

fl1.jpg

Did my best to clean this up and most of it did clean off in the end. Not 100% convinced this still wouldn't be an issue but it looked a lot better and worth a go to see what we'd get on screen when powered up.. Which was absolutely NOTHING :) not a sausage, screen didn't even blink ..

A quick probe of the CPU did show signs of life, replacement 24Mhz crystal must be all good as have a nice (50%) 12Mhz clock on pin 15 of the 68000 CPU (y) Halt and Reset both HIGH (y) Voltage on the pcb was also fine (y)

But with literally no acknowledgement by the monitor that the board was powered up I suspected a video timing issue, so checked the 10Mhz crystal and got some pretty crazy readings on the scope. Frequency jumping all over the place (see below) anywhere between around 50 - 70 MHz ... weird. OK but if the other crystal was knocked off completely and there are signs other components have been knocked loose or off all together, then it's not out of the realm of possibility this crystal has taken a few knocks and it's damaged inside.
With no new ones to hand, had to take a 10Mhz crystal off another board to put on this, and typically it's 40 year old legs just fell off during the transplant 😣 I've eventually managed to solder it back together but had to tape it down, it's connections are so fragile, it's broke off a few times. Just need it to last until some new ones arrive!

fl5.jpg

But this didn't change much, other than now the monitor was reacting to power on, a flicker, a slight change in the tone of black on the screen. Scope now measuring 30MHz on the crystal. Still weird. But it felt like there was now sync. Thinking now I'm not sure why I didn't just check the sync signal at the Jamma edge at that time (probably because my setup doesn't allow for easy board flip overs to access the underside of boards), but I didn't. Just went back to checking the CPU....
No activity on the address and data bus, but DTACK did show 3 little pulses of signal on power up, then would get stuck high. So seems like the CPU starts, attempts its first few bus cycles… then gets stuck waiting forever. Same was happening on A1 and ROM /enable pins. Bad ROM or data bus behaviour?

What I realised at this point was during this probing I didn't have the daughter board connected (I'd needed access under it, tracing signals /CE's, etc) ... and when I plugged it back in I was getting more activity, some data lines had signal, A1 and A2 had signal ... still nothing on screen. But then I did see a flicker, and it was when moving the daughterboard, it's not got the most secure connection. the pins are in the middle of the board so it can rock around on all corners if you press it. Yes small flickers on the screen when pressing the daughter board.

So I take it off and look at the PLCC, remove it from the socket, there is some tarnishing on some pins and some look a bit pushed back into the rear of the socket. So give it a clean best I can and ease out all the pins to try and get better contact to the chip.

fl6.jpg

This is after I've cleaned it up best I can, you can't see it as well on these pictures but the tarnishing/light corrosion on the pins on the middle of the row is still present. Chip back in the socket and daughter board back plugged in and lo and behold the screen comes to life .....

IMG_6459.jpeg

Rocking the daughter board around gently, varied the garbage on the screen but here in this position I can see the word 'COLOR' and I now have a good idea what's going on... The boot is stalling on the startup RAM tests. I saw this on the other board I fixed. That's why bus activity is minimal and the CPU is hanging shortly after power on.

I just couldn't see it because this daughter board is dodgy as hell with it's connection to the main board and its PLCC socket.
I'm guessing the boot is hanging on WORK RAM test (which comes straight after COLOR RAM) but I don't know for sure, and there's no point chasing a WORK RAM fault if it's not that.

So I decide the best course of action is to sort out the connection issues on the daughter board in the hope that if that's all sorted I will be able to see exactly which RAM is failing the boot test. And when I looked properly at the connection pins and socket I realise I need to just remove it all and replace with new. Which means de-soldering 80 pins from the daughter board a 84 pin PLCC socket. A couple of the pins were loose already. You could tell someone else had identified the connection issues at some point before me and had tried to reflow the PLCC socket, as well as the connection pins, but a few of the via's had already gone so some traces weren't connected. They probably spent a load of time on it and when it didn't work got pissed off so didn't bother cleaning off the 20 gallons of flux they used which is why it looked so bad.

I took everything off, took ages 🙂 repaired broken via's and tiny traces. put in a new PLCC socket and a new connection socket on the main board (Another 80 pins!). Looked quite tidy in the end though ... And thankfully (or I may have not cleaned my flux off either!!) it worked, cleaned up the picture on screen 👊

fl7.jpg

fl8.jpg

So ... COLOR RAM - NO GOOD ... or is it ... tbc
 
Last edited:

Jacmar

Active member
Feedback
1 (100%)
Credits
698CR
Had a couple of sessions on this here and there since the last post but not made much overall progress ...
I had to wait a little while for some 10Mhz crystals to arrive and while I was waiting I couldn't really get anything done because the crystal that was hanging on for dear life (pictured previously) just wouldn't stay attached to it's legs without me pressing them together. Really tried to get a good solder connection to the body but the legs had snapped right at the body and I just couldn't. With one hand tied up holding the crystal together to get a picture on screen, otherwise no sync, I couldn't achieve much else with just the other hand. But once or twice at some point just before the crystal became a nuisance, the board did boot past the 'COLOR RAM' Test ! (Albeit failing on the OBJ RAM test). I think I had cranked the voltage a bit at the PSU to get this because I had a similar issue on the Soon Hwa Bootleg recently.

fl9.jpg

So while waiting for some new 10Mhz crystals to arrive all I did was add a couple of smoothing caps to help power distribution around the board.
New crystals arrived so threw one in and fired her up ... no sync ! just thin green lines rapidly flying up and across the screen. Odd ... A dodgy one in the pack? tried another one and got sync. must've been a dodgy one :rolleyes: (or maybe not, I decide much later) and I'm back to failing COLOR RAM test ... and no amount of tweaking voltage gets me past it. Hmmmm

Not convinced I have a palette ram problem but I have a look and do find some funny looking signals I go chasing ....

fl91.jpg

Trace this back from palette ram A4 back from a LS157 and before that a bunch on LS373's under the daughter board.. And it starts to get a bit of a pain in the arse here because the game won't boot at all without this daughter board plugged in but I can't access the IC's under it when it is plugged in !! But I do notice there are a few TTL's in this area with various hack like fixes like small ceramic caps across CLK/+5v pins of 2x LS373's, and a real oddity (to me and my limited knowledge anyway) the +5v pin of a LS245 has been cut from the PCB, and its +5 V is now supplied only through a diode. And another LS373 done the same except with a resistor rather than a diode! Checked the voltage across the diode hacked LS245 and was 4.1v , and the the voltage across the resistor hacked LS373 measured 3.5v !!!
Now surely that's not right, those IC's won't work at those voltages will they ? I know it's a bootleg but these can't be original surely, I've looked online at pictures of other boards similar to this (can't find any pics of this particular board) and none of them have these 'alterations'
Someone trying to fix this issue before? noticed bus contention and undervolted some IC's to weaken them ?? Will never know I guess. I've removed them for now anyway and reinstated their 5v legs direct to the rail ....

fl92.jpg

So the 3x LS373 (1 with the resistor hack and 2 with the cap hack) that feed the LS157 before the palette ram get replaced cause I just don't trust them and I've snipped a pin or two on them chasing the dodgy signals ...

fl93.jpg

While I'm at it I remove the ROM chip that's in place of a PAL or GAL just above the 68000 CPU ... Because it's soldered direct to the board and I can't get to one side of the LS74 under it. And also I want to replace it with a GAL (if possible) .... I did burn a IC55 GAL form the PLD archive for a Final Fight Bootleg 2 board, which looks very similar to this board except this one has the PLCC on the daughter board, whereas that one has a different type of daughter board and no PLCC. On the picture this GAL is in the exact same location but doesn't work on this board - just gives garbage on the screen on boot. So I've plugged the ROM adaptor board back in to the socket I've installed.

fl94.jpg

I've tried reading this 'ROM' as a GAL on my programmer and re burn the read onto a GAL but that's not worked either, probably not doing it right ... Anyway I could maybe revisit that later ....
Also managed to get under the daughter board while it being 'plugged in' .... crude but it works .....

fl95.jpg

And I did find a LS368 under the daughter board which failed slice badly so changed that out ...
But non of this has improved the overall situation. Still game fails on COLOR RAM .... And I now think it may be due to the 10Mhz crystal ....

I found it weird that this is the 2nd 10Mhz crystal I've put in this board that is oscillating at 30MHz ... And one of the new 10MHz crystals didn't work at all.
MAME driver says Final Fight / Crash bootlegs have a 10 MHz and 24 MHz crystal. When I got this board the 10Mhz was in place but the 24 MHz was missing. Right at the start of this fix I put in a 24Mhz and new reset caps and all was good there. But I'm starting to think this Bootleg is like the Soon Hwa bootleg I have , which has a 24Mhz crystal and a 32Mhz crystal !!! (There is no mention of this in MAME) And maybe someone else put in a 10Mhz crystal here because that's what MAME says and then had these boot issues and chased bus contention issues so threw caps and diodes and resistors on IC's ... but maybe it's fault was in fact down to incorrect video timings from the wrong crystal .....

The crystal oscillator around inverters relies on: feedback gain, load capacitance & resistor values. If those values favour a higher-frequency mode, the crystal can lock onto one of it's other natural resonance modes and oscillate at that instead - for example a 10MHz at it's 3rd overtone = 30Mhz !!!
On this board the circuit has 2 x 330 Ohm resistors and a 22 pF capacitor. Those values are maybe more common for ~30 MHz oscillators, not 10 MHz ones.
If the board was actually designed for a 32Mhz crystal, then when this 10Mhz crystal is oscillating at 30Mhz it was close enough to provide a sync the monitor can lock on to ... but maybe not provide those accurate enough clocks for video timing signals that the 32MHz crystal would. And therefore maybe the boot is hanging on the first RAM test because the video timing signals are out ......

I backed up this 'wrong crystal' theory by trying to force the 10MHz crystal to oscillate at it's fundamental frequency. By swapping out the 22 pF for a 47 pF ... this still gave me sync, and the COLOR RAM fail but it was so unstable the scope was measuring 10MHz or 20MHz and flicking between each ... as soon as you touch the crystal or the cap or the resistors it would lose sync and not come back. Not enough capacitance .... So wedged over another 47 pF capacitor (94 total) and this forced the crystal to resonate at its fundamental frequency - 10Mhz - and it was stable, poking around it caused no changes but the sync was none existent, screen going mental ... So basically this board has been at it's happiest when running at 30Mhz ! NOT 10MHz. So surely this board can't be designed for a 10Mhz crystal ...

fl96.jpg

The frustrating part now is I don't have a 32MHz crystal here at home, my other boards here don't have anything higher that 25MHz (which I did try) on them and my Soon Hwa Bootleg (which does have a 32) is at my storage place which I can't get to at the minute !! So I've ordered some 32Mhz (and some 34) and hopefully they will arrive in a few days so we will see if the theory is right .... whether it means it boots past the COLOR RAM test is another matter, I'm hopeful but ..... tbc
 

sukhbir

Active member
Feedback
45 (100%)
Credits
1,619CR
Amazing work so far,crystals with a specific frequency can sometimes be very difficult to get the correct value.
desoldering that 80 pin plcc socket must of been a pain,great skills,keep it up.
 

Jacmar

Active member
Feedback
1 (100%)
Credits
698CR
What an amazing write-up! I'm in awe of your perseverance!
I know most fixers wouldn't bother spending any amount of useful time on a bootleg like this, but Like @qjuk said on another thread recently, if you keep on persevering and don’t give up, you’ll get there in the end and it will be worth it. I think he's absolutely right. And even if they don't get fully fixed, I'm learning absolutely tons on these kind of boards and they don't cost much so literally hardly anything to lose !

Amazing work so far,crystals with a specific frequency can sometimes be very difficult to get the correct value.
desoldering that 80 pin plcc socket must of been a pain,great skills,keep it up.
I had no idea crystals could oscillate at different (overtone) frequencies depending on the type of inverter, capacitor and resistors it's connected to, thought it was just whatever was stamped on its case was what you'd get :)
 

Jacmar

Active member
Feedback
1 (100%)
Credits
698CR
It's been a while ...

I did do some more on this board back in March ... the crystals I ordered came and I tried 28.224Mhz, 30Mhz, 32Mhz and 33.8688MHz and the only one that would give a sync I could work with was the 30Mhz ... which kind of makes sense because the 10Mhz previously was oscillating at that same frequency .... It's workable but not great, the screen keeps refreshing as the monitor struggles to hold onto the signal, even the HD converter box setup struggles with it ... hopefully when the board is fixed and in the cab the monitor will be able to lock on to it ok .... if not I'll have to look more into it ...

But as far as working out the main problem, the game consistently failing the RAM boot tests ... I was stumped ...
I convinced myself the COLOR RAM wasn't actually the issue because I had seen it pass this test (and fail on OBJ RAM) on the odd occasion and just had this feeling something was corrupting the data bus and the RAM was actually fine. The problem here though being there was a number of potential suspects ... The CPU, the WORK RAMs, the PROGRAM ROMs, a number of LS245 buffers and a couple of some LS373's ... along with the SCROLL RAM, the OBJ RAM and (even though in my head I'd ruled it out) the COLOR RAM ... the fact none of these components were in sockets didn't fill me with excitement either ...

Went over these (and others) with scope and slice looking for anything untoward but nothing major stood out. Did get a few IC's not obviously on the data bus net fail the slice tests (LS368, LS74, LS283) which I swapped out but wasn't surprised when it didn't help with the boot problem.

Had another good check around for damaged traces and on the daughter board came across this missing piece of track !!! .. and looks like it was never there !!! wondering if this was done purposefully I reinstated the loss of continuity with a long bodge wire, thinking I can either tidy it up later with a smaller repair, or remove it easily if necessary, won't know till later if this was necessary I guess until I get this running !!

fl96.1.jpg

Again I didn't expect this to be involved in the data bus and was unsurprised when it made no difference to it not booting ....

Decided to de-solder and check the 2x PROGRAM ROM's to make sure their content was right, which it was, so that ruled them out ... and at this point, envisaging the removal of multiple components to make any progress, I decided to take a break from it and focus my attention elsewhere ...

It was a few weeks ago I got thinking about this again ...
The main issue for me at this point with this board was that the boot would hang if any of the RAM tests failed ... but that doesn't actually help if there is a data bus issue and the fail is not directly due to the (in this case COLOR RAM is the first test) bad ram flagged or even the IC's connected to that ram !!
What I wanted was for the tests to continue no matter the result ... and it was then an idea formed in my head inspired by something @SquidDude did while repairing his Twin Cobra recently ... he had a similar situation (game wouldn't boot if any boot tests failed) and so hacked his program roms to bypass the checks and run the game ...
So I figured maybe I could do that here, change the code, but instead of bypassing the RAM Tests, run the test as normal ... display the result ... but move on to the next step regardless of the result ... that way maybe I could get ALL the RAM tests performed and maybe the game even run then to some extent, which would be even better so I could actually see what kind of graphical issues there are, if any ... just more info of any kind to help narrow down the root of the issue would be great.
I'd already de-soldered and dumped those 2 roms and put sockets in so all I needed was a couple of 27C4001 Eproms and to patch one HEX entry on each file, changing the Failure Handler instruction to continue to the next step rather than hanging on failure in an infinite loop ...

And it worked ... wasn't obvious at first and it didn't lead it to instant results ... but it opened the door ...

fl96.2.jpg

First power up with the hacked program roms booted to the screen above left ... INPUT TEST screen ... not sure why at this point ... some of the inputs were flickering super fast between ON and OFF (you can see on the pic above the ones that look like they say ONF) ... while some where just stuck ON ...
First thought was ok I've got a bad LS245 handling those inputs and maybe this is the dodgy IC corrupting the data bus ... grabbed a 245 and piggybacked each of the LS245's handling those inputs .... the one pictured below left had the effect of stopping the flickering ... just stuck those inputs either ON or OFF ...

fl96.3.jpg

Because this one had that effect when piggybacked, I removed it and socketed in a new one, booted with optimism and got some interesting results ...
At first the RAM tests went a bit further but the game would keep rebooting .... at various points ....

fl96.4.jpg

One time it actually went into the game 😳 And i got quite excited !!

fl96.5.jpg

But was brought quickly back down when it crashed and rebooted after showing the guy sitting in his office 😖 and settled on crashing and rebooting over and over to the same point ....

fl96.6.jpg

I thought I must be getting close at this point and the fact the game now continued to crash and reboot over and over at (seemingly) the same point - during work ram test - made me jump in thinking it's probably one of the two 62256 work/program ram at fault .... it wasn't ... removed and socketed both, no change 😩
I think what I also noticed here was that depending on how long the board had been running I got slightly different results on boot ... when cold I'd often get the INPUT TEST screen (below left), as it got a little warmer I might get this screen (below right) ...

fl96.7.jpg

But as soon as it warmed up a bit more it would settle into the constant reboot pattern during RAM tests ... tbc
 
Last edited:

Jacmar

Active member
Feedback
1 (100%)
Credits
698CR
Just checked my bootleg Final fight, not the same board but it's running a 20Mhz and and 10.245Mhz crystal

Yeah its a bit confusing because this board I'm 99% sure is not like most Final Crash bootlegs ... Looks like all Final Fight/Crash Bootlegs have 2 crystals ...

Crystal 1 - provides a divide by 2 clock to the main CPU (68000) and a divide by 6 clock to the sound CPU (Z80)
This is commonly quoted as being 24Mhz - splitting to 12 Mhz for the 68000 and 4 Mhz for the Z80
I'm pretty sure any crystal value between around 18 - 24 Mhz will work ok here as you'll get values between 9 - 12.5 Mhz for the main CPU (68000) and 3 - 4 MHz for the sound CPU (Z80) which both should be quite happy with ...

I have a 24Mhz installed here in this position and the main CPU is executing code just fine, the problem is the crashing and re-booting which is due to a bad IC on the shared data bus ...

Crystal 2 - this provides the video circuitry clocks and the one causing confusion ... this one is commonly quoted as being 10 Mhz ... but I don't think that value is correct for this particular board ... If I put a 10 Mhz in this spot the sync is beyond bad. I've tried multiple value crystals in this spot and the only one that gives me a stable sync is 30 Mhz. I have a Soon Hwa version bootleg which, like this board (spoiler alert), is a Final Fight (not Final Crash) and that has a 32 Mhz crystal in this place for video, and works. The 30 Mhz I have in this board currently does give a stable picture it's just jittery on my test bench monitor, I think it will be ok in a cab on a more forgiving arcade monitor.

So I'm about 95% sure this particular board uses a 30Mhz crystal for video, but the other problem is I can't find a single photo online of this particular bootleg board, there are some similar ones, but none the exact same, so if anyone has this specific board with the daughter board and exact layout ... please post some pics !!

Either way I'm sure neither crystals are responsible for the current boot loop issue which I was convinced was due to a bad IC on the shared data bus ... it was just working out which one was the culprit, without removing them all one by one, which was proving tricky ... (update to follow when I get time!)
 
Last edited:

Jacmar

Active member
Feedback
1 (100%)
Credits
698CR
So at this point I've convinced myself the problem lies in the main program area, I've socketed the program/work RAM and put known working chips in, I've socketed in new hacked program ROM's ... then I went over the area with the multimeter looked for and marking all the IC's connected to the data bus .. Now that I'm running the hacked roms the CPU is no longer stuck in the small infinite loop and there is more activity on the bus logic ... Slicing the marked IC's I found this LS373 was failing on one pin ...

fl97.1.jpg

As you can see this is one of the IC's that had had it's +5v supply hacked through a resistor which I'd removed a while ago, that output signal connects to the LS245 below it and directly to a CPU data pin, so it came out and got replaced and despite the new chip performing better (much smaller fail on that pin) it made no noticeable difference. The marked LS74 (not on data bus) above that IC also failed Slice quite badly so got changed out but again (unsurprisingly) no marked difference made ... To rule it out I also swapped out the LS245 which was receiving the O4 signal from the 373 ... but again this had no effect ..
I was now just chasing any IC's on the bus in that area and removed another LS245 buffering the palette RAM data .... another IC that had had it's +5v supply hacked this time through a diode ...

fl97.2.jpg

But this didn't help either .... still with a narrow focus on this area but running out of suspects I started to wonder if the CPU was bad ... so I removed it and put in a known worker ... but again no difference ... and at this point I'd replaced and ruled out a number of IC's in the area ....

fl97.3.jpg

But it wasn't until I replaced that 2nd LS245 near the jamma edge (buffering inputs) that I got a breakthrough .... the game booted further than it ever had before ...

fl97.4.jpg

Credits were adding on their own and player 2 character moving on its own ... still got bus corruption !!

fl97.5.jpg

For the first time I could see the probable cause of the issue ... sprites !!! I hadn't really looked in this area at all up to now but headed straight over to the sprite ram with a couple of 6116 to piggyback and got some improvement when on one of them ....

fl97.6.jpg

But then I could not get the game to run again, back to stuck on the INPUT TEST screen , or crashing ... but if I piggy backed and wiggled that same ram chip on the input test screen I could change the inputs that were stuck to ON ... to OFF ... this convinced me to swap out that ram chip which I did but it didn't make too much difference ... it wasn't until I swapped out its LS245 data buffer that finally .... the board now boots and runs the game .... every single time !!!

fl97.7.jpg

OK still got some sprite issues but finally some major progress made ... no more bus corruption ... 👊

tbc ...
 

Jacmar

Active member
Feedback
1 (100%)
Credits
698CR
When you had I/o toggling on there own ..

I was thinking something directly up from jamma edge !

Yes at that point the first thing I checked was the actual inputs, scoping them on the 245 buffer they go into, all pulled high as they should be until you press the button or push the joystick direction then they go low. Once I knew they were working as they should, the only logical explanation was another chip on the shared bus was faulty and talking to the CPU when it shouldn't be !
 
Top