Porchy

Jul 272019
 

Some time ago Team Europe has had success in resetting the security fuse on 8751 MCU’s.
See these posts
Post 1
Post 2
Post 3

While looking for something else among my own hoard of stuff I came across an old Choplifter PCB that has been used over the years for parts but the MCU was still present.
Inspired by the work of Team Europe I decided to give it a go myself.
Removing the cap was a bit tricky because I don’t really have the tools required for the task. I ended up using a small file and making a lip so I could fit a screwdriver under it and pry the lid off.

Adding some nail varnish generously donated by my daughter and we have this familiar sight.

I threw it in the UV eraser for 15 minutes and tried reading.
I got data back but was it good?

Comparing to the one currently in MAME I had 1 byte different at address 0x100.
Now, looking at the MAME source we can see that it applies some software patches.

The byte at address 0x100 is indeed on of the patched areas.
Not sure why address 0x27b is also patched. Without this one applied there is no need to compensate by patching address 0x2ff.
Anyway I removed these patches from MAME and booted with my dump and all seems to work just fine. Hopefully the MAME team will agree its a good dump and add it too.

Thanks to Team Europe

 Posted by at 4:18 pm
Jul 222019
 

One drunken day at the excellent Revival event I offered to look at a Nintendo Space Firebird PCB.
Initially I was given the eBay link which had a few pictures of the fault.

When I got the board I did my usual visual checks and found a few things I didn’t like the look of.
First up both main RAM chips are socketed. I removed these to check out of circuit and found this

I fixed that up by removing a leg from a donor chip and soldering it on

Next up was the 8212 Input/Output port. It too was socketed with a single wipe socket but what really got me suspicious was the state of the soldering

I wasn’t a fan of this so desoldered it. When I desoldered it I found this

A bit of trace has been lifted there. I can only assume this has been removed before.
I fitted a new socket and moved on.

Found a burnt looking resistor on the sound PCB

The resistor still reads 20 ohms but i will replace that once my parts order comes in.

Lastly there were a few areas with the solder mask removed and solder on it. Not a huge problem but it needs addressed.
I cleared the excess solder from these places and covered them using a Chemtronics pen.

Not pretty but it does the job.

Firing up the PCB for the first time confirmed the original fault was still present.
As the fault was with the video I looked there first.
I started by reseating the two socketed RAM chips

To my surprise this fixed up the graphics. Not sure what effects the previous fixes would have had but Im not removing them to find out.

New problem now. The game hangs at the title screen at the same point every time.
Whenever I get issues like this I always think RAM or ROM issues.
I had already confirmed the RAM so went on to dealing with the ROM’s.
All of them were a match for Space Firebird according to MAME’s ROMident but the ROM at location 5J was for a different version of the game.

It should have been this

I erased and reprogrammed the 2716 EPROM and now the game plays fine.

While comparing gameplay against MAME I realised some colours were missing

This should look more like this

I chased this round for quite a long time only to realise that the 74LS04 inverter I was using (as stated in the manual) to invert the colours was my problem. Switching to the proper Nintendo inverter PCB made everything look right again.

All that’s left now if to replace all those capacitors on the sound PCB and that burnt looking resistor and this board is done

 Posted by at 6:18 pm
Jul 072019
 

Today I’ve uploaded the latest version on my BINman software to v4.5.0
The main addition here is the inclusion of Fluke 9010 signatures to the checksum area.
Not only does it have support for the 8 bit signatures it also supports the 16 bit signatures.
For 16 bit signatures, it will only support single files so if your hardware has the files across 2 EPROM’s then these will need interleaved or whatever is required to merge them.

Enjoy

 Posted by at 8:04 am

ESP Ra.De. repair log #2

 PCB Repair Logs  Comments Off on ESP Ra.De. repair log #2
Jul 052019
 

Received an ESP Ra.De. board for repair for my friend Vic.

This was the video I was sent originally

This PCB had apparently had work done before but all we knew was the big 240 pin custom chip had been reflowed. This always makes me nervous because if it was destroyed somehow then all further attempts of repair would be for nothing unless I had a donor.
Visual check carried out of the board in general revealed nothing bad so hooked it up to the test. As expected we have no sync and the game does not appear to be running either. I confirmed this as the watchdog was kicking in.
Using the scope I probed the sync pin at the JAMMA connector and found a low sync signal of 13khz.
I started tracing the signal back but it went to the big custom chip that I already knew had been worked on, I also confirmed the main clocks and signal to the custom chip.
With no other ideas at this point I decided to tackle the game booting issue. The 68000 CPU was already in a socket so using the Fluke 9010 with a 68000 POD (Thanks Caius for the extended loan of his POD) I could start troubleshooting.
First off a BUS check revealed data bit 2 was tied low. In actual fact data bits 2 and 3 were shorted together.

I started tracing all the point where these data lines go and one by one started isolating them from the circuit. Once again my search led back to this big custom chip.
Reflowing these two pins on the custom cleared the fault.

At this point I took a closer look at this custom and found if I got the light in at the right angle I could see a lot of dried flux underneath.
Over time flux residue will dry out if not properly cleaned and it can go conductive.
I cleaned this and the bus test now passes. The ROM check between 0x0 – 0x7FFFF should be 1BBA which also passed.

The main RAM lies at location U39 & U40, 0x100000, 0x10FFFF. The Fluke reported a decode error on bit 1 which basically means there is a problem with the address lines.
Doing some manual reads and writes I could see that bit 1 of RAM U39 did not work. I replaced this and retested which then went OK.

I started my way through the rest of the RAM location as per the MAME driver.
The sprite RAM lies at U43 & U44, 0x400000, 0x40FFFF. Once again the fluke reported bits 5 & 6 tied together and once again I was led back to the same custom chip.
From here I just opted to reflow the whole chip. This cleared the issue with the sprite RAM. All other VRAM passed tests.
Retesting the PCB now resulted in a nice looking game for the most part but there was a strange strobing around test and lines that were white. Going into the test mode made this very obvious.
I couldn’t get a good video of this as it all looked fine on a camera.

To began with I thought this was all to do with my test monitor and the sync being a tiny bit high for it but I tested it on all my monitors and cabs and they all gave strange results.
I eventually went back to that custom chip and inspected all the pins again.
I couldn’t visually see anything but checking continuity on all pins against the adjacent pins revealed a short somewhere around pin 190. A further reflow of these pins resulted in a completed repair

One strange thing about this board is that on boot up it stays in a reset state for around 2 seconds which is the point where the sync reads 13khz. After that the sync steps up to 15.23khz and all OK.

Here is a layout of all the RAM locations on the PCB

 Posted by at 4:38 pm