Atari-Forum

This looks really nice. After you've built that small batch, are you considering releasing your schematics for hardware sellers to provide it?

Re-create the ROMs and ARC files from tha MRAs (and don't forget to rename the rbf to jt1943.rbf). As a bonus, you'll get 4 versions of the game. However sound/music is missing for me from this release. +there are some too long settings in the MRA, they break the OSD (2 Player Coins). +rotate contr...

slingshot wrote:I think the most interesting would be the 315-5364. Precise bus timings are still not well-known.

I agree.

This is a great iniciative. Please go on with it

Sorgelig wrote:"part" node has parameters "offset" and "size". So i don't see a problem.

Can you specify the attributes in any order?

That sounds exactly what I needed! Thank you.

For the game Pang 3 the interleaving is done in an obscure way: ROM_REGION( 0x400000, "gfx", 0 ) ROM_LOAD64_WORD( "pa3-01m.2c", 0x000000, 0x100000, CRC(068a152c) SHA1(fa491874068924c39bcc7de93dfda3b27f5d9613) ) ROM_CONTINUE( 0x000004, 0x100000 ) ROM_LOAD64_WORD( "pa3-07m.2f", 0x000002, 0x100000, CRC...

sebdel wrote:I wanted to say, I answered the call for help from Jotego without knowing what he was going to do with it...
I also got a very nice gesture by regular mail.

So... Thank you Jotego !

Thanks a lot for answering my call. You've made life easier for both users and developers!

sebdel wrote:Sorry, took me a while but I think it's fixed now. Why would anyone use windows anyway

Of course, agree on all this. What I meant was: you're the only one that develop cores (and mra) for both Mist and Mister. So the question for you was: is it a problem that interleaving is not achieve the same way on mist and mister (group vs. interleave)? It is, yes. Because I'd like to distribute...

I see, you don't really need interleave. I'll see with Jotego then. Still, I'd like to try to generate a valid rom with interleaved video, just for testing purpose. Hi Sebdel, I'm not sure of what you need from me. Interleave or group XML elements are vital for me. For other arcade cores I have bee...

<interleave> node on MiSTer does several tasks. It's not only for interleaving several parts, but also can be used to swap the bytes in a single part. map="21" will swap the bytes of the part. The <group> node does that too. It looks like we implemented the same functionality roughly at the same ti...

sebdel wrote: I'll port it though... it's just that how do you read this? I don't understand map.

I don't understand it either. Maybe it'll be easier if you port the group element to the mister code!

I think I can ommit the md5 sum if all files are referenced to by CRC. I don't know about that merge|unmerged thing. I think it is safe to ignore it. How about the interleave element? I'd like to do things in a compatible way with MiSTer so there is a single .mra file for both MiSTer users and other...

I also need the dual zip feature to load unmerged rom sets. For instance: <misterromdescription> <name>Ghouls'n Ghosts (USA)</name> <setname>ghoulsu</setname> <year>1988</year> <manufacturer>Capcom</manufacturer> <rbf>jtcps1</rbf> <rom index="0" zip="ghouls.zip|ghoulsu.zip" md5="b3d6ca2a35aa8702e361...

Sebdel, did you add support for recognizing the files inside the zip by the CRC code? I am already running into trouble with my own MAME romset as the names do not match those in MAME source files.

If you could add the patch element Sorgelig told us about, that'd be great.

Thank you

I think we may have deviated from the MRA DIP syntax: <switches default="FF,FF,C9"> <dip bits="15" name="Cabinet" ids="Cocktail,Upright"/> <dip bits="16,17" name="Coinage" ids="2c/1cr,1c/1cr,1c/2cr,Free Play" values="3,1,2,0"/> <dip bits="18,19" name="Lives" ids="1,2,3,5"/> <dip bits="20,21" name="B...

Each character in the pattern attribute means "read 1 byte at that offset", so here, you're reading byte 0 and byte 1 (16bits) from each part, effectively interleaving them. For the next 64 bits, it will go back at the start and continue reading the files, again, using the offset in the pattern. If...

I have been able to render the first image out of simulation with the rom file created with your MRA tool. Thanks a lot! Now, I'm not sure why you need the pattern attribute for first 64-bit group parts. I remember you told us it was a way to interleave files but I don't see how it is relevant there...

My point was, should we stay compatible with Mister or not? If not, we may consider renaming the file (if it's not compatible with MRA, it's not MRA right ?) or at the very least we can have an attribute "version" at the root of the file. like: <misterromdescription version="2"> The idea is that us...

If I understand correctly you would want to add padding in the destination file to accommodate for empty regions in the ROM definition. This should be completely covered by <part repeat="xxx">ff</part> imo. Sorry, I didn't know about the repeat attribute. That is enough. I was also wondering about ...

I don't understand fully your last example yet, but for me it looks like going overcomplicated. Missing pieces cannot be just filled with something? What is too complex the TOC? Maybe you're right and we can get by with just the fill element. Let's do the fill first and I'll try to make a few files...

Sorry, I didn't notice before. There is a need for some sort of table of contents (TOC). The problem is that some CPS games miss some components or have unusual ROM lengths. For instance, Ghouls'n Ghosts is missing the ADPCM rom (256kB); and Street Fighter 2 has 6MB of graphics ROM, which is not the...

sebdel wrote: Here's my proposal...

I like it!
Don't mind about the md5 number in the MRA file I sent. It wasn't correct. Let me try using your tool to run some simulations.

... I have successfully cloned and compiled the tool. I tried it with the 1942.mra and it seemed ok. I have created the MRA file for Ghouls'n Ghosts . There is a pull request for you to incorporate it to the tool project so you can try it. I copy it here too: <misterromdescription> <name>Ghouls'n G...

I like the group idea, we could set the destination width on the group. Then we can have variable width on source parts (that addresses your point 2) A question, in the link you posted, I see offsets for each part. How would you translate this: ROM_REGION( CODE_SIZE, "maincpu", 0 ) /* 68000 code */...