What's new
By:

Universal Naomi Free-Play and No-Attract-Sound Patches

DragonMinded said:
I will refrain from "making noise" here from now on out. Thank you for proving my point exactly as to why I figured this out and documented it myself instead of asking.
Click to expand...
The people 'making noise' that MetalliC is referencing are two people (not you) posting in this thread that have been banned from this forum but continue to keep making new accounts and trying to participate here. I have deleted some of their posts as it just continues to derail any topic related to NAOMi.
 
I think it was a typo and brizzo meant "posting in this thread who have been banned from this forum".
 
Aurich said:
I think it was a typo and brizzo meant "posting in this thread who have been banned from this forum".
Click to expand...
Haha yeah, my bad it was typo.

If a user is banned, a lock appears next to their username on posts.
 
I updated my patch generators to prefer modifying the header instead of the "hard way" and tested it working on several games. However, it looks like the atomiswave loader stub used in the AW conversions does not respect system settings, and I don't know if its worth it to try to reverse-engineer how the AW conversions initialize their settings. Does anyone know how atomiswave games on Naomi store their freeplay/attract settings? I looked at one in demul and it does not seem to use either the EEPROM or the system SRAM but I could be wrong. I'd like to run some of the conversions on my NNC but its a bit of a dealbreaker to have them come up in coin mode so I'm leaving them off the list for now.
 
It looks like I was wrong and the SRAM is where settings are stored. I had a really stupid idea: go into a game in demul, set up the options that I wanted, copy out the SRAM and put it at the end of the rom file, modify the Naomi header to add a main executable copy section for the location/size of the appended SRAM, and set the copy destination to the SRAM location itself. In theory the BIOS should dutifully copy the SRAM contents to SRAM, initializing it for us. Well, it worked. I tried setting Dolphin Blue to free-play this way and it came up in free-play, so I'm going to see if I can't code up a little utility that takes an SRAM file and an AW conversion and creates a new ROM that comes up with that SRAM initialized, and then set up my defaults in demul for the games I care about.

Is there an easier way, or is this good enough?
 
I think @Darksoft did a lot of those NAOMI conversions, you'd probably be best off asking him
 
Last edited:
Is the technical work for the AW conversions documented, or uploaded anywhere? Reproducible and/or improvable results are always a plus.
 
It's not really well documented like in a TXT file so taht someone can take over, but if you take a game and check the original vs my conversion you can easily notice that there are several changes.

*1st of all the files must be merged properly into a bigger bin file
*the loading routines are different in AW and Naomi, so you have to "catch" every attemp made to read a block of memory and translate it for the one used for Naomi
* You need to do the same for the translation of Maple reads to JVS. It's all explained in MAME.
* After that you will notice some attempts made in order to avoid people running it on mame, like i.e. trying to erase a part of the flash memory. If you are in a Naomi it won't work.
* Also you will probably enter into an interrupt race as the timing is different.
* Last but not least, some games use the Virtual memory mode, which is a PITA. You need to make sure that your code doesn't interfere with that.

But for small hacks, just take the binary, change a couple of Checks "by hand" where it cheks if we are on free mode or not and call it day. That's what I would do.
 
@Darksoft if you are converting maple reads to JVS, does that mean you are writing your own maple init/update routines? I tried for several weeks to homebrew code that could talk to the Maple bus and all of my efforts were dead ends. Basically, as far as I can tell I was talking to Maple identical to how DC would work, and instruction-for-instruction identical to how MvsC2 does it (and the BIOS). I set up cache properly, used uncached pages for the buffers, sent the real address to Maple, and even read back registers to verify that I set things up, but I could never ever get the Maple bus to respond by placing the buffer in the response location. It never worked and I don't know why.

https://github.com/DragonMinded/net...0fb08364ad29f10bdc803/assembly/write_eeprom.S This code worked fine in mame, demul and nulldc, but doesn't work on hardware. Debugging shows that the memory at the response buffer just never gets updated, even though its in uncached (0xa0000000) mirror. If I debug in demul/nulldc/mame, I get expected responses from the Maple bus, so I am 99% sure I am setting up registers properly. Do you know if there's some magic init thing I have to do to get things working? Is cache wrong? I don't think the MMU is enabled at the beginning of a cart-based ROM.
 
I updated the main post of this thread, the tools in the linked repo should allow you to generate a patch for any Naomi game that turns on free-play by default, or turns on silent attract by default. For Atomiswave conversions, tools in the repo will let you add a SRAM file that you make in demul so that you can set up your preferred settings in demul and then have them applied when you netboot. You just need to boot the Atomiswave conversion in demul, go to test mode and set up your defaults and exit, and then close demul. Inside the nvram folder will be a file called "dummy.sram". This is the file you should use along with the attach_sram utilty to make an Atomiswave conversion game boot the settings you choose.

I've tested everything on Naomi 1 hardware, but it should also work with Naomi 2. I think it might require updating some of the tools to recognize Naomi 2 ROMs but that's it.
 
DragonMinded said:
Do you know if there's some magic init thing I have to do to get things working? Is cache wrong? I don't think the MMU is enabled at the beginning of a cart-based ROM.
Click to expand...
many games have MMU enabled.

Just take any of my conversions and you will see the routine that enables that. You can launch it in MAME and debug it from there. The whole translation routine is there.
 
DragonMinded said:
I tried for several weeks to homebrew code that could talk to the Maple bus and all of my efforts were dead ends. Basically, as far as I can tell I was talking to Maple identical to how DC would work, and instruction-for-instruction identical to how MvsC2 does it (and the BIOS). I set up cache properly, used uncached pages for the buffers, sent the real address to Maple, and even read back registers to verify that I set things up, but I could never ever get the Maple bus to respond by placing the buffer in the response location. It never worked and I don't know why.

github.com/DragonMinded/netboo…3/assembly/write_eeprom.S This code worked fine in mame, demul and nulldc, but doesn't work on hardware. Debugging shows that the memory at the response buffer just never gets updated, even though its in uncached (0xa0000000) mirror. If I debug in demul/nulldc/mame, I get expected responses from the Maple bus, so I am 99% sure I am setting up registers properly. Do you know if there's some magic init thing I have to do to get things working? Is cache wrong? I don't think the MMU is enabled at the beginning of a cart-based ROM.
Click to expand...
you should read SH-4 datasheets about it's cache. the cache is not 'automatic' in SuperH CPUs, and couple of thigs must be done in manual. here is few 'perfect' workflow examples:

read data via DMA:
- read some data via DMA into 'data_buf' in RAM
- invalidate operand cache of 'data_buf' area similar to pseudocode below
for (int I = 0; I< data_len; I+= 0x20)
OCBI(data_buf+i);
- access 'data_buf' data

send data via DMA:
- put some bytes into 'data_buf' in RAM
- write back possible cached data to physical RAM, similar to below
for (int I = 0; I < data_len; I+= 0x20)
OCBWB(data_buf + I); // here also may be used OCBP opcode, which does both writeback and invalidate cache line
- send 'data_buf' via DMA

you may also try use some tricks using uncached area access (0xA0000000), but you must clearly understand what are you doing, otherwise you'll get in troubles and code will not work as expected.

also make sure your DMA buffers properly aligned, at 32byte boundary.
 
Just looked at your code and I'm mad at myself, I need to git gud. It's way more elegant than mine.
 
Hi! :)

I would like to know if there is a patch to play Guilty Gear's Attract mode in Free Play Cartdrige version on the original hardware.

Because in Freeplay mode the game remains on the title screen X/

For the patch it is on the Eprom IC22 of the cartridge ?

THANKS :thumbup:
 
You must log in or register to reply here.
Back
Top