Vulcan Venture repair log #2

 PCB Repair Logs  Comments Off on Vulcan Venture repair log #2
Jan 082018
 

Received from Spain this faulty Vulcan Venture PCB (export release of Gradius II on the glorious’ Konami Twin16 hardware) 

This is what I got once powered it up:

Graphics were all corrupted, you could barely recognize the self-test procedure which failed all the time causing the reset of the whole system in an endless loop.I focused my troubleshooting on VIDEO board:

Like the CPU board, also the VIDEO one was almost fully populated with Fujitsu TTLs  but before going thru them I started to probe the various RAMs.I found one 62256 @8L with dead outputs:

This finding lead to no improvement.So I fired up my logic comparators and started to probe TTLs.Sequentially I was able to locate these faulty ones, all of them on VIDEO board and from Fuitsu:

  • 74LS153 @9H

 

  • 74LS157 @2F

 

  • 74LS244 @5W

But the board was still not booting :

Shorting some data/address lines of two 6264 SRAMs @3A and 3B changed the garbage on screen so this was the path to follow, the problem was in the tilemap generation circuit which these RAMs are part of :

Probing the RAMs revealed that the R/W lines (pin 27) of both were stuck high, according to schematics these signals come from a 74LS27 @4B:

 

My HP10529A logic comparator confirmed troubles on two outputs of this 74LS27 which failed when tested out-of-circuit:

Now board succesfully passed the self-test and entered in game fully playable with sound but all graphics had very noticeale jailbars:

Most of graphics data is stored in four 4Mbit MASK ROMs:

While dumping them my programmer reported troubles for the ones @10L and 10M:

 

Replaced them with two 27C400 EPROMs fixed the issue and board completely.

Evil Konami (and Fujitsu) defeated again but war is not over.See you to next battle…

 Posted by at 5:56 pm

Dragon Breed repair log

 PCB Repair Logs  Comments Off on Dragon Breed repair log
Jan 052018
 

Received today from Germany some faulty PCBs for repair, there was this Dragon Breed boardset (on Irem M72 hardware)

Sprites were glitched with jailbars thru them:

Sprites data are stored in four 28 pin 1Mbit MASK ROMs (Toshiba TC531000) located on top board:

Due the fragile nature of these devices I was pretty sure that there was a faulty one but I was wrong since dumps turned out to be good.Analysing them with a logic probe I noticed that data line D0 (pin 11) of the MASK ROM @IC49 was stuck low, measuring its resistance to GND gave me only few Ohms:

Since device was good there was clearly something forcing the pin low, most likely a short (not ‘dead’ though).I traced the involved pin back until I came across to this scenario:

Here’s a close-up under a microscope:

The capacitor @C62 was bended and its terminal connected to GROUND  was accidentally lented on the pad of the trace tied to the data line.I straightened the capacitor, this cleared the short and hence sprites issue, simple but effective!Job done.

 

 Posted by at 7:29 pm

Reader submitted posts

 General  Comments Off on Reader submitted posts
Jan 012018
 

Over the years there have been people asking if they can submit posts of their own.
Aside from friends of mine I have never really wanted to open up registrations for everyone.
I have now finally got around to enabling a frontend to allow people to submit their own posts.
It can be found under the “Contact/Links” menu and is just a trial right now.
If it doesn’t take off or gets abused in any way then it will be removed and we will go back to business as usual.
Hopefully we will get some more diverse content going on as a result of this

 Posted by at 2:49 pm

Happy New Year

 General  Comments Off on Happy New Year
Jan 012018
 

Happy new year everyone to everyone that visits this place and a big thanks to all that have either contributed or made a donation.
Hope you all have a great 2018

 Posted by at 12:48 pm
Dec 252017
 

In the past, every time I’ve undertaken a ROM hacking project i have ended up with a cluster of binary files all at varying stages of usefulness. This simple program is how I will now be working with binary file hacking.

The format of the changes is really simple and can all be put together in a text file or in the program itself.

As you can see, comments are supported.
Using this I can comment the changes I make and just ‘Autopatch’ a binary file after I’m finished and if I make a mistake then I can modify the text file and reapply to the original binary.

I understand that the way I approach things is not necessarily the way most other people approach things but it might be of some use to someone else out there.

The software has a simple HEX viewer in it, can byteswap the loaded binary and also supply an offset.
The offset is relatively untested and is intended to be used if you are loading a ROM file that normally starts at, for example, address $1000 in memory space. You can apply the offset and write values to the correct addresses. If in doubt then just avoid this altogether as it will cause problems and cant really do any error checking.

Merry Chistmas

 Posted by at 3:57 pm