Atari - Proms to Eproms

orion3311

Well-known member

Donor 2013
Joined
Nov 25, 2008
Messages
5,217
Reaction score
30
Location
Blue Bell, Pennsylvania
So I want to verify the roms on my Video Pinball, unfortunately mame only has the fileset from the original board with 16 proms on it. Mine has 4 9316B roms. Since I believe the B roms are pin compatible with 2716 eproms, that means I can easily burn a replacement 2716 if need be.

Manual: http://arcarc.xmission.com/PDF_Arcade_Atari_Kee/Video_Pinball/Video_Pinball_TM-130_1st_Printing.pdf

Now, page 67 shows the table of 16, 8, or 4 proms/eproms, but it mentions MSB and LSB files using the same addresses. Either way, basically 4 proms per 9316. Thats fine, but does the MSB/LSB stuff mean anything (I know it means most sig bits and least sig bits). Do I just combine the 4 image files and compare to the chip? Do they have to be in a particular order?
 
Wow what the hell was I smoking when I wrote that? Anyway...long story short...

If you have 16 files that need to go on 4 roms, I know which 4 files should be merged into one, but do they have to be in a particular order? I'm assuming they do.
 
You have to assemble the 16 nybble wide-files into 8 byte-wide files, then concatenate the 8 1k byte-wide files to get the 4 2k byte-wide files to burn 2716s.

I did this a long time ago to fix a board for Funspot, but all the data's on my old work computer. All the info you need to figure out what goes where is in the mame source.
 
So if I understand this correct (my brain is about to explode)

A nybble is 4 bits, or half a byte. High nibble to the left, low nybble to the right

So...in the Mame Code...

ROM_LOAD_NIB_LOW ( "34242-01.e0", 0x2000, 0x0400, CRC(c6a83795)
ROM_LOAD_NIB_HIGH( "34237-01.k0", 0x2000, 0x0400, CRC(9b5ef087)

If the first nybble of 34237-01.k0 is 04, or 0100
And the first nybble of 34242-01.e0 is 0c, or 1100

Then the first byte of the resulting file would be 01001100, or 4c in hex, correct? Is it that easy or is there some rocket science routine?

Question is finding a program or a way to combine the files, maybe excel, or maybe I can get a programmer friend who has a utility or two for this.
 
Then the first byte of the resulting file would be 01001100, or 4c in hex, correct? Is it that easy or is there some rocket science routine?

Question is finding a program or a way to combine the files, maybe excel, or maybe I can get a programmer friend who has a utility or two for this.

Yep, that's all there is to it...
I may have posted the C source code when I wrote it... I don't remember....
It's pretty trivial to write, and you can romident the results to make sure you did it right.
 
Well I've spent an hour looking for a utility, and at best I can find a code sample, but I'm no C programmer. I used to program in qbasic but found out you can't deal with bits in qbasic, at least not for file i/o.

Downloaded a few hex editors and nothing seems able to combine these.
 
Well I've spent an hour looking for a utility, and at best I can find a code sample, but I'm no C programmer. I used to program in qbasic but found out you can't deal with bits in qbasic, at least not for file i/o.

Downloaded a few hex editors and nothing seems able to combine these.

HHD Hex Editor. I did the same thing with something else once and didn't feel like writing a program for it. I forget what HHD calls it, but you can save your steps so that you can repeat the operations over and over although you won't be doing that.
 
Well I've spent an hour looking for a utility, and at best I can find a code sample, but I'm no C programmer. I used to program in qbasic but found out you can't deal with bits in qbasic, at least not for file i/o.

Don't need to treat the data as bits...
Convert chars to ints
byte = high nybble*16 + low nybble
 
HHD Hex Editor. I did the same thing with something else once and didn't feel like writing a program for it. I forget what HHD calls it, but you can save your steps so that you can repeat the operations over and over although you won't be doing that.

Sweet I'll check those out - thanks guys! I also found out my buddy (who started out in Qbasic) has now gotten pretty good as assembler and said he could write a utility to do the merge in his sleep, so he's going to try it.

(I wanna try my qbasic program again too because it'll be the first one I've made in like 8 years). Yeah...I'm a geek.
 
HOLY CRAP I got it to work! (Not the game but the rom merging program)

Romident not showing the resulting CRCs though, not sure if if the bigger roms would even be in there.

CLS
INPUT "MSB/High File Name? "; file1$
INPUT "LSB/Low File Name? "; file2$
INPUT "Output File Name? "; out$
fileh$ = "c:\qbasic\rom\" + file1$
filel$ = "c:\qbasic\rom\" + file2$
PRINT fileh$
PRINT filel$
DO: LOOP UNTIL INKEY$ <> ""

OPEN fileh$ FOR INPUT AS #1
OPEN filel$ FOR INPUT AS #2
OPEN out$ FOR BINARY AS #3
bit1$ = "": bit2$ = "": test1 = 0: test2 = 0: test3 = 0
DO
bit1$ = INPUT$(1, 1)
test1 = ASC(bit1$)
bit2$ = INPUT$(1, 2)
test2 = ASC(bit2$)
test3 = (test1 * 16) + test2
PRINT HEX$(test3)
test4$ = CHR$(test3)
PUT #3, , test4$
LOOP UNTIL EOF(1)

CLOSE

(EDIT - IF anyone ever tries to use this, just change the c:\qbasic\rom part to whatever the path is to the rom files you're dealing with. THe output file will be in the same folder as the basic file.)
 
Last edited:
More Holy Crap...and then just some crap...

Holy Crap: Not only did the program work, its now verified!! I was able to successfully merge the prom images together and verify/compare my 4 roms.

Crap: All 4 roms are good. No dice there :-(

However, out of this, comes 4 new rom images for Mame or whatever, and 4 new entries for RomIdent...

--CRC--- -Atari Pt #-- --Game Name--------
981B5986 34253-01.m0 Video Pinball (Atari)
C3EEBF23 34254-01.h2 Video Pinball (Atari)
5565AE42 34255-01.j2 Video Pinball (Atari)
9F24428C 34256-01.k2 Video Pinball (Atari)
 
Back
Top Bottom