I understand what you mean and I have a question: I thought that given that unlike MAME the fpga is a hardware implementation, you would just wire 2x8bits ROM to a 16bits bus... Is it really that much simpler to use a 16 bit ROM instead?jotego wrote:I don't come in a couple of days and what do I find?
A C version.sebdel wrote:By popular demand of slingshot, here's the same sh*t in C: https://github.com/sebdel/mra-tools-c/Great!
C or C++ are my preferred option for this. I think users need executables files, both in linux and windows. I tried once to distribute a Python file and people had trouble with it.
As for the tool, I do need it now as I need to prepare proper ROM files for the CPS1 core. There is one extra feature I need though: support for split data. Let me explain.
Sometimes ROM files match the system bus in odd ways. MAME has a neat way of expressing this with macros:
This means: make one 16-bit memory by using one byte from each file. This is the case because the board uses two 8-bit memories to form a 16-bit memory.Code: Select all
ROM_START( sf2 ) ROM_REGION( CODE_SIZE, "maincpu", 0 ) /* 68000 code */ ROM_LOAD16_BYTE( "sf2e_30g.11e", 0x00000, 0x20000,... ROM_LOAD16_BYTE( "sf2e_37g.11f", 0x00001, 0x20000, ...
This can become more complicated:
This means: make a 64-bit memory by using four 16-bit memories. So take two bytes from the first file, then two from the second file, etc. Note that files are not dumped one after the other: they are interleaved.Code: Select all
ROM_REGION( 0x600000, "gfx", 0 ) ROM_LOAD64_WORD( "sf2-5m.4a", 0x000000, 0x80000, ... ROM_LOAD64_WORD( "sf2-7m.6a", 0x000002, 0x80000, ... ROM_LOAD64_WORD( "sf2-1m.3a", 0x000004, 0x80000, ... ROM_LOAD64_WORD( "sf2-3m.5a", 0x000006, 0x80000, ...
You do get the easy case too:
This just uses one byte from each file to complete the 64 bits. Note that the final memory width is not relevant for the output file as you just output bytes. You just have to take it into account to know how many bytes to take from the files.Code: Select all
ROM_REGION( 0x200000, "gfx", 0 ) ROM_LOAD64_BYTE( "nm_09.4b", 0x000000, 0x20000, ROM_LOAD64_BYTE( "nm_01.4a", 0x000001, 0x20000, ROM_LOAD64_BYTE( "nm_13.9b", 0x000002, 0x20000, ROM_LOAD64_BYTE( "nm_05.9a", 0x000003, 0x20000, ROM_LOAD64_BYTE( "nm_24.5e", 0x000004, 0x20000, ROM_LOAD64_BYTE( "nm_17.5c", 0x000005, 0x20000, ROM_LOAD64_BYTE( "nm_38.8h", 0x000006, 0x20000, ROM_LOAD64_BYTE( "nm_32.8f", 0x000007, 0x20000,
Now, this is a new yet needed feature for MRA's so syntax is a bit free at the moment. Something like this will do:
I think you don't need to express the final memory bit width as MAME does as we just need the straight byte sequence. For 16-bit files, I think we need the option to select endianness. I don't know if there 32-bit files in more modern games. I haven't encountered them yet. It is important to preserve the file order, so if the XML parser loses the order of the statements, we may need to indicate the order as an attribute.Code: Select all
<part> <!-- Merge two 16-bit based files --> <name "file0" width="16" endian="big"/> <name "file1" width="16" endian="big"/> </part> <part> <!-- Merge four 8-bit based files --> <name "file0"/> <name "file1"/> <name "file2"/> <name "file3"/> </part>
What do you think, sebdel?
And for the interleaved parts, ok, I'll do it this week end. My proposal would be to specify evertything at <rom /> level and have the content be whatever. This way we still support every attributes for parts as usual. So, something like:
Code: Select all
<!-- Merge two 16-bit based files -->
<rom index="0" zip="tests.zip" md5="deadbeefl337c0d3badf00dba1dbabe" width="16" endian="big" padding="ff" type="interleaved|merged|nonmerged">
<part name="file0" />
<part name="file1" />
</rom>
<>
<!-- Merge four 8-bit based files -->
<rom index="0" zip="tests.zip" md5="deadbeefl337c0d3badf00dba1dbabe" width="8" padding="00" type="interleaved|merged|nonmerged">
<part name="file0" />
<part name="file1" />
<part name="file3" />
</part>
- type: add "interleaved" type. Could be in a separate attribute if it's a problem for backward compatibility.
- width: width in bit when reading interleaved parts
- endian: endianness when reading interleaved parts
- padding: byte to insert when a part is too short. (we could error out instead)
(I assume this is not the expected MD5 right ?)