Apr 232017
 


Its hard for me to believe that i’ve been maintaining this program since 2011.
I’ve added to this as I needed extra functionality and for the last 12 months or so its been untouched but for the last few weeks I’ve been rewriting some parts I wasn’t happy with and changing a few things around.
Its now got to the point where I think its pretty much complete (although i’ve said that before) so though it was about time I did a proper post on some of the things it does and how to use it.
I wont go into everything as I dont think I need to but let me know.

What does it do?
Back when I started this program I wanted a quick, easy and no fuss way of quickly interleaving, deinterleaving and byte swapping files. That’s exactly what it did but that’s all it did.
Take a look

What it does now:

  • Create a new files filled with recurring byte or word values
  • Analyse a file (8 bit or 16 bit) – check for stuck bits, upper and lower halfs matching, etc
  • Bit manipulation – simulate stuck bits in a file & swap bit order of address and/or data bus
  • Byte swap
  • Deinterleave
  • Invert the whole file
  • Manipulate – XOR, swap bits, simulate fixed bits
  • Reverse the file
  • Split the file in to smaller files
  • Swap the upper and lower half of the file
  • Concatenate up to 4 files at once
  • Interleave in 16 bit, 32 bit  or 64 bit format
  • Compare 2 files – checks how many bytes match
  • Display CRC32, SHA1 and MD5 hash values

Creating a new file
Click the ‘Single File’ menu and select ‘Create a new file’
You should see this

You can fill the new file with a byte pattern or a word pattern.
To fill with a specified byte pattern you can enter something like this

This will fill each byte with a value of 0x55
To fill with a word pattern you will enter

This will fill the file with the word value 0x55AA

If the slot is empty you can also load a file by double clicking on the slot.
You can overwrite any loaded file by dragging and dropping a new file onto the slot.

Analysing a file
Analysing a file check for a few things.
First you will need to select from the menu whether the binary file you loaded is from an 8 bit or 16 bit source.
The output from the analysis will be displayed in the Log window.
In this example I have created a new file filled with 0x0

As you can see it has flagged up all the bits (8 bit) as being stuck LOW. This means that throughout the file non of the bits changed from logic state 0.
It also shows that the upper and lower half of the file are filled with 0x0. If the file (or half the file) was filled with 0xFF then this would be flagged instead.
Finally, we have flagged up that the upper half of the file is identical to the lower half of the file.

Viewing the file contents
There is a basic HEX viewer built in to the program. Just double click on any of the loaded slots to view it.

Checksums
There are 3 different checksums that the program can show you.
The default is CRC32 but by clicking on the “CRC32” box you can cycle between CRC32, SHA-1 and MD5.

Compare files
If any loaded file is the same as another file that is already loaded you will get an instant notification in the Log window that is matches

If however the files are not a match, its sometimes nice to see how much of the file actually does match. For example, if you have a a new revision ROM dump of a game you might want to see how much has actually changed. If its just 1 byte different then it could be bit rot or a region code change.

I think the rest of the functionality is self explanatory so wont go into it.
The program is in the software section now.
Please do let me know if you find this program useful, find any bugs or maybe want to see something added or changed (no guarantees though).

 Posted by at 2:21 pm

Flicky repair log #2

 PCB Repair Logs, Repair Logs  Comments Off on Flicky repair log #2
Apr 222017
 

Quick repair this one.
Game booted to a black screen, sometimes garbage on screen and could see/hear the watchdog doing its thing.
This board was running the encrypted version of the game with its custom Z80 CPU.
As the CPU is socketed I just plugged the Fluke straight in and ran the usual tests.
All the ROM’s passed but work the RAM failed

The schematics are the same as for Star Jacker and the RAM could easily be located

Tested the RAM out of circuit and sure enough my tester flagged up address pin A8 as being disconnected so it matched the Fluke’s output too.
I replaced the RAM and fire up the game

The sound and controls both work fine and my work here is done.

 Posted by at 3:26 pm

Mach Breakers repair log

 PCB Repair Logs  Comments Off on Mach Breakers repair log
Apr 212017
 

Received this Mach Breakers PCB from a friend for a repair (it turned out to be an undumped World revision, I alread submitted it to MAME)

Game was released by Namco in 1994 and runs on a powerful hardware platform called ‘NB-2’.Here is ovrview:

  • Main CPU: Motorola 68EC020 32-bit processor @ 25 MHz
  • Secondary CPUs: C329 + C137
  • Custom graphics chips: GFX: 123, 145, 156, C116 – Motion Objects: C355, 187, C347
  • Sound CPU: C351
  • PCM Sound chip: C352
  • Control chip: C16

The board was faulty, most of sprites had jailbars:

Sprites data are stored in ten 16Mbit MASK ROMs (Fujitsu MB8316200B in SOP44 package) located on the MASK ROM daughterboard:

Probing them with a scope didn’t help much since each column of devices has shared address and data busses.So I proceeded in this way.I created some empty binary files (2MByte each one) and loaded them one at a time in MAME in order to reproduce the issue and pinpoint which devices were bad.When I did it for the ones @8A-8B-8C I got pretty same artifacts under emulation:

So I went to remove these MASK ROMs starting from the one @8A of the column :

And I hit it since I was not able to get always same CRC when dumping it so device was really bad.Replacement for the MB8316200 is a Macronix MX29F1610 Flash EEPROM which has same pinout (except for pin 1 and 44 which are used for programming)

Luckily I was able to find among my spares a donor board where to take the devices from :

Time to program it using a SOP44 to DIP adapter:

After soldered it on board I got a big improvement, jailbars were gone away but there were still dots on sprites:

Again I went to corrupt the MAME ROM files and I could pinpoint which was the involved device: the one @4C.I removed it :

I dumped it several times and obtained different CRCs at each reading, it was really bad.As further proof I loaded one of these bad dumps in MAME and I was able to reproduce exactly the issue:

I programmed a new MX29F1610 EEPROM as replacement, this fixed completely the board:

Not only bad TTLs from Fujitsu!

 Posted by at 9:19 pm

Zupapa! (Neo-Geo MVS conversion) repair log

 PCB Repair Logs  Comments Off on Zupapa! (Neo-Geo MVS conversion) repair log
Apr 202017
 

Got for repair this Neo-Geo conversion cart of Zupapa! a platform released in 1994 only for MVS system and not on the Neo-Geo AES home console :

Most of graphics were blocky:

I opened the cart:

As I said, the cart was a conversion from a donor hardware, this requires the ROMs to be replaced with game code and data plus some other modifications like adding some ICs and jumpers.Doing a visual inspection on work done I found nothing of abnormal until I came across this:

One of the zero Ohm resistors used as jumper required by the conversion was badly soldered.I put it in place and magically all the graphics came back:

A simple but effective fix!

 Posted by at 11:21 pm

Wild West C.O.W. Boys of Moo Mesa repair log #2

 PCB Repair Logs  Comments Off on Wild West C.O.W. Boys of Moo Mesa repair log #2
Apr 162017
 

Received this Wild West C.O.W. Boys of Moo Mesa PCB for replacing electrolytic capacitors on the infamous ‘054986A’ audio module although sound was still perfectly working :

As usually I opted for tantalum capacitors, this was the final result:

But when testing the PCB I noticed coin input of player 1 was not working, this was confirmed by I/O check which showed this input as stuck:

As workaround somebody put the game into free play:

This is a common issue on the all Konami boards that share the same hardware design.The input signals from JAMMA edge are first routed to some some custom resistor arrays marked ‘005373A’ then to four 74LS257 which multiplex them :

Checking the involved part revealed that input of the 74LS257 @Q3 was almost shorted to ground as well as obviously the output of the resistor array @S15 connected to it:

So the problem was in either of them.Using an audible milliohm meter I was able to locate the point of less resistance with ground in the 74LS257:

So confident I removed the IC:

It failed when tested out-of-circuit:

Replacing it cleared the issue, input was no more stuck.End of job.

 Posted by at 4:22 pm