Apr 292017
 

JEDutil is a program included with MAME.
While MAME doesn’t directly use PAL dumps for emulation it does look to load them if they are available. As each programmer has its own output format when reading these chips (some are really different, other not so much) there arose the need to have a standard.
Read here for more information

What can JEDutil do?

It can convert a programmer usable .jed file to a MAME usable .bin file
It can convert from the MAME usable .bin file back to a programmer usable .jed file
It can be used to view the equations of any support .jed or.bin file

To see a list of supported devices you use the “-viewlist” argument

To view equations use the “-view” argument

These equations show exactly how the outputs works in relation to any given input and I believe is self explanatory to those who are looking.
Here is what the file im using for this example looks like in a text editor

You can clearly see it was created using WinCUPL.

Here is what a JEDutil created .jed file will look like opened up in a text editor

It looks very similar to the WinCUPL created file and most programmers i’ve encountered can load these without issue. One exception to that (and there are certainly others too) is the Needham EMP-20 which seems to use its own binary format that is not compatible with the MAME format.

Here is what a MAME usable binary file for a .jed will look like in a hex editor

There are clear difference between the binary and jedec files and should be easy to spot if you are not 100% sure what you have got.

Converting a MAME binary to a Jedec file
If you want to use the PAL dumps found in MAME on real hardware then you MUST convert them from their binary format back into .jed format.
You need to use the “-convert” argument

Note the filename extensions used here. The output file must be .jed (or .pla) or the conversion will fail and you will see this useful message

Converting a Jedec file to a MAME binary
To convert a .jed file into a MAME .bin file you simply use the same command but swap the filename extensions.

This will create the binary file. The original .jed file will remain untouched.

The only time I can really think of anyone needing to convert to a MAME binary is if you are submitting your dumps for inclusion to MAME
I’ve yet to ever find a use for the Berkeley PLA conversion so I haven’t covered it in here but if required it should be straight forward enough to work out.

Other Errors
Occasionally you might see some more cryptic error messages when using JEDutil. While there are things you can do to try and get around these they might also be a sign of a corrupt file or one of incorrect format.
The Jedec file format has two checksums both found at the end of the file.
The first is the fusemap checksum and the second is the transmission checksum

In the example used above the fusemap checksum is “3E71”. I believe the “C” part is always present.
The transmission checksum is “D5F0”

The fusemap checksum is the 16bit sum of all the 8bit fuse values.
The transmission checksum is a little more. Using the same example as before

The transmission checksum is a 16 bit sum of all the ASCII characters between (and including) the STX and ETX markers.

If the fusemap checksum if incorrect but the transmission checksum is correct then you will get this message

If the transmission checksum is incorrect then you will get this message

I believe you will get this message even if there is a fusemap checksum error as well.
You can disable the transmission checksum by changing it to “0000”.

In the past if I got stuck working with a strange .jed file I have loaded it into my programmers software and saved it back. This rewrites all the checksums to be correct. Your milage may vary!

There may be other errors, maybe not. I’ve not come across any other to really bother myself about.

 Posted by at 3:03 pm
Apr 262017
 

Another faulty Truxton PCB on the bench:

These were the issues: sprites were totally absent, sounds was loud and screen was disturbed by some wavy lines

Interferences on video are a common issue on this board, usually they are caused by electrolytic capacitors with increased ESR (especially the filter ones connected to +12V line).On my board the capacitor @C1 connected to +12V was previoulsy replaced:

But who replaced it managed to break the internal connection to GND of its negative terminal, you can see in the below picture that pads (and internal rivets) were ripped off:

The capacitor lost its GROUND reference hence it was not operational.This also explained why sound was loud: the amplifier was oscillating due the missing function of this capacitor (the role of these capacitors in audio circuit is indeed to avoid dangerous oscillations of components) and this affected the video too.I restored the connections, this cured both loud sound and video interferences so I moved on to troubleshoot the lack of sprites.Object data are stored in four 1Mbit 28 pin MASK ROMs :

Probing  the address lines revealed they were all stuck low and hence data lines too.Address lines come from outputs of some 74LSALS163 but they resulted good when tested in circuit by my logic comparator.Probing around revealed nothing abnormal until I came across this custom chip (DIP 42 package) marked ‘TOAPLAN-02 M70H005’:

All the pins from from 1 to 21 ( not counting  pin 21 which is GND) were toggling but all the ones from 22 to 42 on the other side (except pin 29 GND, and 23-42 VCC) were stuck, these were most likely the outputs.I compared the behaviour on a good board and had confirm that the stuck pins had to be active hence the custom was dead.I desoldered it and I found a ‘GXL-02’ silkscreening under the chip:

I remembered I had a couple of other Toaplan boards I harvested (Hellfire and Out Zone) with same silkscreening on PCB but different marking (”FDA MN53007T0A’)  of the custom chip:

Power supply pins were the same so was worth a try.And I was successful, sprites were back:

Later I found that this custom is used on many other Toaplan boards but under different labels.For example, it’s  ‘T.T-2’ on Twin Cobra :

‘WT2’ on Wardner:

‘L-02’ on Sky Shark:

‘12.02’ on Rally Bike:

 Posted by at 12:01 am
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
  • 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 or 32 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
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
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