[PAD-RH]

Hello all ~ new member here, so please go easy on me!   

I have bought an original board set for the upright Defender arcade game on eBay. I have the emulator (MAME) ROM files from defender.zip, an EPROM burner, and the HxD editor.

Can someone share the general steps for extracting Intel Hex files from the emulator ROM files, which I assume are needed to program the individual ROMs? 

I would like to program a complete set of replacement ROMs for the 1x ROM (Decoder on CPU board), 11x ROMs (11 used on ROM Board), and 1x ROM (Sound Board) since I have no way of verifying the ROMs in the boards are good. (The boards were all sold "as is" or "not working").

I've searched this forum (and other sites) yet have not found "step by step" instructions on Programming EPROMs from the emulators files.

Perhaps no individual file extraction and reformatting to Intel Hex is needed, but it's not clear to me where to begin.  Any help or advice would be most appreciated.  FWIW, I am an electrical engineer and can help others with hardware questions and will be sure to share my experience with programming the EPROMs / EEPROMs once I'm done.

thanks for your help or suggestions in advance!

Phil

[FAST6191]

"Intel Hex files"?
Is that a way of saying leave your big vs little endian arguments at the door and just roll with how it comes naturally? I don't know that I have ever heard the term before (though it is possibly ringing a bell for some export option in Hex Workshop), certainly not one in common use around here. Granted it is usually interleaving that troubles things whenever I have had the misfortune of playing with old gear and EPROMS, EEPROMS or worse but that would have presumably been mentioned.

Equally I don't know how many around here would have got their hands dirty with real arcade boards, indeed it is often tricky to find someone that plays MAME game ROM hacker (though that is usually a fault of MAME/MESS not being so receptive to modded games and arcade stuff not being as prominent as console games).

Most MAME source code tends to also document the files quite heavily (it is something you can afford to do when a given board rarely has more than a few games total). With that you could probably ID things happily enough, and there are usually some nice dat files containing hashes for what it thinks are the correct files. https://github.com/mamedev/mame/blob/ee1e4f9683a4953cb9d88f9256017fcbc38e3144/src/mame/drivers/williams.cpp
https://github.com/mamedev/mame/blob/ee1e4f9683a4953cb9d88f9256017fcbc38e3144/src/mame/machine/williams.cpp
Though https://www.robotron-2084.co.uk/techwilliamshardwareid.html#defender also looks like it might note something useful in this.

I don't think MAME games have dumper added headers similar to NES stuff, or some Scene groups doing intros/trainers/fixes for various things, but I could be very wrong as again not something I really deal with.
To that end if it is one big file I imagine it is going to be more just copy-pasting (or playing with something like filecutter https://web.archive.org/web/20180904103414/http://min.midco.net/cracker/filecutter.zip ) to slice off the relevant portions to feed to the individual eeproms, the source code above hopefully noting where a given portion might be, and how large it might be.

[Jorpho]

since I have no way of verifying the ROMs in the boards are good.

Well... wouldn't dumping the chips and comparing them to known dumps be an excellent way to start?  That would also probably at least give you a good clue as to how to format other dumps for your purposes.

If the board is kaput I would kind of expect the ROM chips would not be one of the things to be most likely at fault, but that's mostly wild speculation on my part.

[PAD-RH]

Thanks FAST6191 & Jorpho for your quick replies.

FAST6191 ~ Intel Hex is a standard data record format in ASCII (so human readable) for defining the contents of EPROM/ROM, etc. The format looks like this:

:0600000002006A02011675
:03000B000200935D
:0300130002015196
:01001B0032B2
:100023003200002A2A2A2A2A20444F574E454E2DB1
:10003300534F465420534F465457415245204E493F
  *
  *
  *

and continues on with each line indicating the number of Hex Bytes, starting address, and a checksum as the last byte on the line.  You can read all about it here: https://en.wikipedia.org/wiki/Intel_HEX

Intel Hex (and .bin) are the only formats I'm familiar with when it comes to programming individual EPROMS, thus I thought it might be a solved problem to extract the .hex / .bin files from the MAME ROM files.

I'll study the .cpp files and (at first glance) these seem to be the C source code for a series of Williams games (Defender among them). I see the memory maps, which may help me figure out the ROM partitions (starting addresses) when considered in conjunction with the electrical schematics which also reveal the memory maps (base addresses for each accessible part of the entire addressable range).

Jorpho ~ I received my ROM board today and it is missing several ROMs, so I'm a bit stuck and can't do the comparison to known good dumps. This is a bit of a chicken-and-egg problem, i.e., how to get the known good dumps in the first place?  If I had them, I could burn new ROMs directly.  But, I agree it would be good to read the ROMs I have and make a record of them. I could then eventually compare them to other image sources I may come across.  Finally, I think you're right about the DOA boards - the ROMs may not be the first thing that fails unless some DC voltages were ever hooked up incorrectly. Chips don't like that and they won't last long under overvoltage or reverse voltage conditions.

I'm hoping a few other members will chime in with links on the ROM .hex or .bin images (or how to convert them from the given defender.zip file, which holds these 15 files: decoder.2, decoder.3, defend.1 ~ defend.12, and defend.snd).

Thanks again for your quick replies and help!

Phil

[Jorpho]

how to get the known good dumps in the first place?

Didn't you say you already had "the emulator (MAME) ROM files from defender.zip"? Are these not dumps of the original ROM chips?

Of course, there are probably several different ROM revisions in MAME, and if the chips are missing entirely, it may be difficult to tell precisely which ROM set in MAME corresponds to your particular board – but I wouldn't expect it to matter so much.

[PAD-RH]

Thanks Jorpho ~

I have the downloaded ROM files for Defender, but need to determine their format and whether or not they are directly suitable for PROM burning or require a conversion first. I will use an editor to open each one and determine how the contents are organized. I suspect they may be in .bin format.  BTW, I've started to read out the physical ROMs that I do have using my PROM Programmer. I am saving those content files and will compare them to the Red Label files from the MAME download. I'll get there.
September 06, 2021, 01:12:12 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Ok, so I figured out the 15 files in defender.zip (decoder.2, decoder.3, defend.1 ~ defend.12, and defend.snd) are all raw binary files; i.e., they hold the raw bytes of the ROM images (just like the filetype *.bin). I didn't know this before.

I was able to use my PROM reader/programmer to read the contents of the ROM parts (the few I have) and verify they match with the .bin files from defender.zip.

So, now I can begin programming my new UV-EPROMs using the data extracted from defender.zip and end up with a set of ROMs ready for testing in the hardware.

I used the program HxD to open and view the raw hex values from the MAME file set; used the IntelHex Python library to convert these to Intel Hex (.hex) files; then used Notepad++ to view and compare the .hex contents to the raw hex .bin contents in HxD.

Thanks for your initial comments, folks!