What's new
Here's something to get you started...
I made this for myself a while back but I find it super useful. I printed it out and have had it stuck to the wall next to my monitor for a couple of years now.
ts_eprom_xref.jpg


"on disk" is the size of the ROM file as it would be reported by windows
"in MAME" is the size of the ROM file as reported within MAME source

EPROMs within the same color group mean that you can double the ROM file and write it to the next size down the list.

obviously it's not comprehensive but it seems to cover 99% of the stuff I typically need to program.
I needed a replacement for some C27C202-90V05s and ordered some AT27C4096-90U replacements. Will the ROM files need to be modified to be put onto the EPROM?

EDIT: For reference, it appears each of my 4 binary ROM files are 128Kb and my device reads 4 interleaved EPROMs.
 
Last edited:
today i stumled across something new for me, an answer would probably best fit into this topic so here it goes:

i need to program a m27c2001 with two files, one should go in the upper half, one in the lower half - how do i do that?

i already tried adding them together with
copy /b "rom1.rom" + "rom2.rom" "rom_merge.rom"
also in reverse order, but unfortunately that didn't work.

should i use the offset option of my programming software (Prog-express/ Batronix) , that has the option for memory and buffer...

I also have a split option in the programmer, possible settings are all, odd, even, and first, second, third or fourth of 4...

Thanks for your help!
 
i need to program a m27c2001 with two files, one should go in the upper half, one in the lower half - how do i do that?
that copy command you did should work; HOWEVER the rom files you're using need to be exactly half the size...

Code:
copy /b lower.rom+upper.rom combined.rom

an alternative command is the "type" command

Code:
type lower.rom upper.rom > combined.rom

I tend to do this one as it's a bit easier to remember, however it's technically "slower" and less safe

in either case you can use a hex editor like HxD to confirm that the lower ROM data is at the start of the file and the upper ROM data starts at exactly half way (0x20000)
 
@twistedsymphony thanks got the eprom programmed, unfortunately still stuck even before the rom test - i'm about to test all programmed eproms against the files for a second time
 
I feel bad I never finished this, and do intend to revisit it one of these days... or years....

For now there are lots of great resources including @twistedsymphony 's chart which I use regularly.

One thing I wanted an easy example of was using MAME source to help attempt a repair. For example someone reached out to me that a DonPachi board was missing text. We will have to see if this fixes it, but the MAME source has ROM listings which are really useful for repair.

The first step is to find the driver; if it's a board used by a bunch of games, you're looking for the .cpp or .c file with the right info. I usually search "mame github cpp GAMENAME" or something, not actually in quotes, on google to find it if I don't know.

So for Donpachi, https://github.com/libretro/mame2003-plus-libretro/blob/master/src/drivers/cave.c

Code:
/***************************************************************************

                                Donpachi

Known versions:

USA      Version 1.12 1995/05/2x
Korea    Version 1.12 1995/05/2x
Japan    Version 1.01 1995/05/11

BOARD #:      AT-C01DP-2
CPU:          TMP68HC000-16
VOICE:        M6295 x2
OSC:          28.000/16.000/4.220MHz
EEPROM:       ATMEL 93C46
CUSTOM:       ATLUS 8647-01 013
              038 9429WX727 x3
              NMK 112 (Sound)

---------------------------------------------------
 filenames          devices       kind
---------------------------------------------------
 PRG.U29            27C4096       68000 main prg.
 U58.BIN            27C020        gfx   data
 ATDP.U32           57C8200       M6295 data
 ATDP.U33           57C16200      M6295 data
 ATDP.U44           57C16200      gfx   data
 ATDP.U45           57C16200      gfx   data
 ATDP.U54           57C8200       gfx   data
 ATDP.U57           57C8200       gfx   data

 USA Version
----------------------------------------------------
 prgu.U29           27C4002       68000 Main Program
 text.u58           27C2001       Labeled as "TEXT"

***************************************************************************/

Since the only symptom described is missing text at times, I'll try replacing the 27C2001 first.

Not all games will have that, so the first thing I looked for was GFX region. But that's several roms in this case, so if the TEXT rom fixes it, this is a good demonstration of using MAME source to fix a game.

I also used the MAME source to help @themisterfalcon fix a conversion recently, just by comparing the roms across the games, and finding the faulty sound ROM based on the location of sound ROMS in the driver for the game. Don't be scared to look, is the point. Information is your friend.
 
It's confirmed the above fix worked; we were able to fix this Donpachi board without it ever being sent out by the owner for inspection.

Thanks "Shipwreck" for your trust and the photo of it working (previously, this text was not there).

s-l1600.jpeg
 
No pressure, as what you've shared so far has been a big help to me (being a real beginner here). And I enjoy picking around forums and reading repair logs to learn more.

I have a GQ-4x4 but I'm already finding that the rom types I want to burn aren't exactly listed in the software. Was attempting to burn some B board roms for Mercs and found the closest models I could in the software, but when I slotted in my newly burned roms the screen just showed crazy garbled graphics lol. It's normal again now with the original roms back in, so no issue there. I think it was the program data I was trying to burn, and so maybe it's more sensitive than graphics or sound. Or maybe the chips I got were just garbage, since 7 out of 10 failed to even write (found em cheap on ebay).

Also, it was really tedious, but when I was learning about Mercs I'd use mame, unzip the game file, open up different rom file in notepad and just erase everything, and then load up the game to see what changed or what was missing. I got to see how stuff was organized into graphics, sound, and program data, and it basically confirmed the problem with my Mercs board was not B board rom related since none of the mame results matched what I was seeing on the real board. It's probably an A board issue which I'm getting around to replacing. Anway, now I know I can just check the mame source code first! And, maybe sharing my experience so far will give someone else new like me an idea.
 
Back
Top