What's new

DragonMinded

Professional
Joined
Jun 2, 2019
Messages
152
Reaction score
598
Location
Chelsea, VT, USA
I've spent the last month RE'ing various parts of the Naomi since I just got into net-booting. There didn't seem to be any existing published research on how the Naomi saves system or game settings, the ROM header format, or anything around making the hacks that exist currently. So, I spent a solid month banging my head against a brick wall figuring out how things work. Why? I mean, you can just press the service switch a few times to coin up right? Well, yeah if you have a Vewlix, Astro or a supergun setup. Just leave the coin door open and reach in. But if you have a NNC you have to open the CP to get to the service switch. Not great for guests, and a huge pain since you can't leave it open! I know, a month of effort to be lazy and not open up the service menu for five seconds. I guess I can't underestimate the amount of effort I'll go to in order to be lazy.

The result is what I think is a semi-universal patch creation program which can force a game to free-play on net-boot, and another which can force a game to be quiet on attract mode when net-booting. They can be applied independently or together, and work with existing hacks that metallic and darksoft put out to do various other things. These patches also work in MAME/demul/nulldc. I've tested on a handful of games, all which work perfectly on my Naomi. However, it would be great if I could get confirmation that others have success. I don't think this will work on converted Atomiswave games, but the method of discovering their secrets should be approximately the same as documented below. The existing patches (as well as a few of the force-unlock patches) are available here if you want to manually hex-edit them into your games that you are net-booting: https://github.com/DragonMinded/netboot/tree/master/patches

I documented basically everything I learned (not much) from doing this RE here: https://github.com/DragonMinded/netboot/blob/master/docs/naomi.md

In the process of doing this, I successfully compiled and ran code on my Naomi hardware, so it is 100% possible to start writing homebrew given the docs. I'm probably not going to myself since the Naomi is CURSED and there are so many issues I ran into with cache in the SH-4 on real hardware that worked fine in all emulators. Most things are similar to Dreamcast so there's gonna be some figuring out to do but all the necessary pieces for how to get your code on the Naomi are documented. I've proven that it works by writing code which dynamically alters the 'Now loading game...' text in MvsC2. This is how I was able to debug various register values on actual hardware without going through the struggle of initializing video myself. Its kinda fun, you see a raw register print hex and then the game loads like normal, completely unaware that you messed with the loading screen to turn it into a debug printf.

Okay so how can you help? The netboot repo I work under is https://github.com/DragonMinded/netboot and if you check it out and install the requirements (its python 3 code) and run the free-play and no-attract patch generators on ROMs I haven't tried yet, you can verify that the patcher program finds an offset to modify, test it on your own Naomi and then report back the verified offsets for that game. I also accept pull requests to add the patches directly to the repo. Known working patches are as follows:

force free-play hack:

- CvS: 0xFF358: 42 84 -> 1A E0
- CvS2 MOTM: 0x116E58: 42 84 -> 1A E0
- CvS2 MF: 0x1161F8: 42 84 -> 1A E0
- Guilty Gear X: 0x72A28: 42 84 -> 1A E0
- Ikaruga: 0x52626: 42 84 -> 1A E0
- Illvelo: 0x620C6: 42 84 -> 1A E0
- Karous: 0x6135A: 42 84 -> 1A E0
- MvsC2: 0x1D8138: 42 84 -> 1A E0
- Monkey Ball: 0x6BE30: 42 84 -> 1A E0
- PowerStone 2: 0x158F88: 42 84 -> 1A E0
- PyuoPuyo Da: 0x44F86: 42 84 -> 1A E0
- PuyoPuyo Fever: 0x37EAE: 42 84 -> 1A E0
- Quiz K QMode: 0x29A58: 42 84 -> 1A E0
- Radirgy: 0x6136E: 42 84 -> 1A E0
- Street Fighter Zero 3 Upper: 0xE8832: 42 84 -> 1A E0
- Tetris Kiwamemiti: 0x7FAB2: 42 84 -> 1A E0
- Trigger Heart Exelica: 0x13E522: 42 84 -> 1A E0
- Trizeal: 0xBE782: 42 84 -> 1A E0
- Under Defeat: 0x43FD6: 42 84 -> 1A E0

force silent attract mode hack:

- CvS: 0xFF3EC: 40 63 -> 00 E3
- CvS2 MOTM: 0x116EEC: 40 63 -> 00 E3
- CvS2 MF: 0x11628C: 40 63 -> 00 E3
- Guilty Gear X: 0x72ABC: 40 63 -> 00 E3
- Illvelo: 0x6214E: 40 63 -> 00 E3
- Karous: 0x613E0: 40 63 -> 00 E3
- MvsC2: 0x1D81CC: 40 63 -> 00 E3
- Monkey Ball: 0x6BEC4: 40 63 -> 00 E3
- PowerStone 2: 0x15901C: 40 63 -> 00 E3
- PuyoPuyo Da: 0x4500C: 40 63 -> 00 E3
- PuyoPuyo Dever: 0x37F36: 40 63 -> 00 E3
- Quiz K QMode: 0x29AEC: 40 63 -> 00 E3
- Radirgy: 0x613F4: 40 63 -> 00 E3
- Street Fighter Zero 3 Upper: 0xE88B8: 40 63 -> 00 E3
- Tetris Kiwamemiti: 0x7FB38: 40 63 -> 00 E3
- Trigger Heart Exelica: 0x13E5AA: 40 63 -> 00 E3
- Trizeal: 0xBE808: 40 63 -> 00 E3
- Under Defeat: 0x4405C: 40 63 -> 00 E3

EDIT: There is a Naomi-supported way to force free-play and no-attract that MetalliC revealed later in the thread. I haven't had a chance to test yet, so I am not generating any patches with this info yet. Also, I removed Ikaruga's force silent attract mode patch since the game already does it. I've updated the above list with more tested working patches.

EDIT again: I've rolled the header information into a ROM header tool and updated the freeplay/no attract patch generators to prefer modifying the header for the "supported" force options. I've stopped updating this patch list, so you should go to https://github.com/DragonMinded/netboot/tree/master/patches to see all available patches.

Final EDIT: Updated with information on how to set up Atomiswave conversions to apply settings on boot that you select in an emulator. With the info and tools linked here you *should* be able to netboot any naomi game and force it to free-play or silent attract mode, and if you are adventurous you could set to different settings as well.
 
Last edited:
@DragonMinded From your docs/naomi.md "why does both nulldc and demul not ship with a debugger? How do the emulator authors debug?" There is a not widely circulated, and now hard to find version of Demul 0.4.9 mentioned here "Added debug version of the emulator. The debugger mode automatically activates the interpreter" https://web.archive.org/web/2018040....com/downloads/dreamcast/emulators/demul-049/

Many claim to have never seen it. But others talk about it openly "I already have Demul v.0.4.9 (unofficial build? I can't find it on the official site), which has a built-in debugger with memory editor, ASM viewer, breakpoint funcionality and all that good stuff" http://www.emutalk.net/threads/55882-Request-Demul-with-debugger


You can just go to github, and clone the public source from here https://github.com/p1pkin/demul


You need to define DEMUL_DEBUG in the source code before you compile so the debugger works. Normally it is commented out.

./Demul.h://#define DEMUL_DEBUG // Allow Debugger.

This will enable the debugger console https://github.com/p1pkin/demul/blob/master/debug.c#L26

More details on the resulting "Dreamcast Console Debugger" can be found here https://github.com/p1pkin/demul/blob/master/win32/Console.c#L25
 
Ah, interesting. When I was starting my investigation, I tried very hard to find demul 0.4.9 with the rumored debugger and failed after a lot of searching. I didn't think that there was a github fork of it. MAME ended up doing just fine for all of the RE I did. I had to desolder my MIE EEPROM once and dump it to verify that things worked the same on real HW and I used the tricks I described in the naomi.md file to debug on real hardware so I ended up not needing demul/nulldc except for verifying hacks.

Did you know that MAME, demul and nulldc all reply to MIE EEPROM commands differently? I think MAME is correct since they're emulating the actual MIE.
 
good work, but I'm not really understand why getting yourself into so much troubles with creating patches for each game ?

there is couple of options to do this in much simpler way:
- (hacky) in all games patch ROM header 4byte ID at 0x134 to same value like 'BAA0', so at new game boot BIOS will not change coin and advertise sound settings.
- in all games patch ROM header so BIOS will force free play and adv.sound=off settings (affair there is special bytes for this)


I spent a solid month banging my head against a brick wall figuring out how things work
that's a lot of time, why not ask some questions here instead ?
you may also poke me via https://discord.gg/EddgXEF


force silent attract mode hack:

- Ikaruga: 0x526AE: 40 63 -> 00 E3
why ? original Ikaruga binary by itself force Advertise Sound -> OFF
 
Last edited:
The repo I linked looks for the library routine and generates the patches for you, so once I figured out that it was an easy patch like this I just wrote that tool which I think can work for the majority of Naomi games to patch in these force settings. I didn't dig into MonkeyBall, Powerstone 2, or Ikaruga, just ran the patch utility on it and threw it on hardware to test that it worked. So once I worked it out its about 30 seconds to generate new patches.

The hacky way you propose doesn't actually work on hardware with NetDimm . That's the first thing I tried. It was tested working on nulldc and demul, works great to patch to "0001" and then the settings stay around. That would be ideal. But it didn't work. My original theory was that the NetDimm had a different serial, but a dig through firmware update ROMs and dumping my EEPROM after it booted into the NetDimm wait for network screen confirmed that it was "0001". However, even when patching games to use the same serial, the settings were still reset upon booting the game. So there might be something in the NetDimm firmware that resets it, or another stage of the check uses a different serial code? Anyway, the hacky version was the first thing I tried and it did not work on real hardware :(

I did not know about the ROM header patch, I didn't find that in my investigation.

I tried making a universal patch that would let you write any setting first, but I could not figure out why my code would not get maple responses so I gave up on that angle. It works on mame, demul and nulldc so I know the theory is sound, but on real hardware it freezes waiting for responses. That would have been fairly ideal since the CRC is now worked out and we could craft whatever settings on the fly before patching it in. Some tool that sends to NetDimm could inline patch on the fly with command-line options which makes netbooting very convenient. But, this approach did not work on hardware. I spent a lot of nights trying to figure out why the maple bus did not reply to any of my commands and eventually gave up since I don't have the best way to debug on real hardware.

I will be very honest about why I dug myself: this forum does not seem welcoming to new people who come in asking questions. Previous requests to hack things have been met with "do it yourself" and "its very difficult so I can't work on this unless you donate". I didn't want to contribute to more taking, and I have had no luck across various arcade hacking forums with trying to get information on making patches and the like. There is also no documentation written down across the internet for any of this so I assumed that a lot of it was closely guarded secrets, much like konami, nintendo and sony hacking behaves. Maybe I would have gotten help, but my experience doing this for many years tells me I would not be taken seriously and will be told by several people to stop wasting time and do it myself if I want it so bad. And probably I would have gotten only the quick fix and no explanation as to how that quick fix was determined. Besides a working free-play patch I also got out of it a lot of knowledge of how Naomi ROMs and EEPROM are laid out which can be used for future homebrew. I don't see anything online anywhere that documents this so having it laid out will hopefully help the next person who wants to get started.
 
I see. well, you went hard path. there is official way to force system settings, its just needed to change these 4 bytes in header at offsets 0x1E0 (for Japan), 0x1F0 (for US) and 0x200 (for Export):
01 02 00 1B (for regular games)
or
01 03 00 1B (for vertical screen games)

bytes explanation:
00 - 1 - enable change system settings
01 - bit0=1 - set vertical screen, bit1=1 - disable advertise sound
02 - coin chute type 0 - common, 1 - individual
03 - coin/credit settings number, same as in BIOS settings, 27 - free play
there is more bytes for manual coins/credits/bonus settings, but I doubt they will be useful.
 
That's the first thing I tried. It was tested working on nulldc and demul, works great to patch to "0001"
valid IDs is 3 characters, 1st is B, and then 1 digit, i.e. BAA0 BCD1 etc
I'd imagine DIMM firmware might be not happy if it's 4 digits ?


this forum does not seem welcoming to new people who come in asking questions. Previous requests to hack things have been met with "do it yourself" and "its very difficult so I can't work on this unless you donate".
this forum might be not welcoming to persons who just looking for ready-to-use solutions with zero efforts from themselves.
but usually quite friendly to people who asking specific tech questions, trying to learn or research something, creating something, etc
 
I have had no luck across various arcade hacking forums with trying to get information on making patches and the like
well, the truth is - there is no any interest to NAOMI internal details, and quite few persons who know NAOMI stuff, most of them is not native English -> it took time and efforts to write even short docs/texts in English, and in general why do this ? if (almost) no one really interested in it, besides of general public entertainment.
 
and in general why do this ? if (almost) no one really interested in it, besides of general public entertainment.
Because when something happens to those people, then what? Everyone who /is/ interested needs to start from scratch?

Documentation is good. Especially public documentation so that things don't get lost in time.

I don't agree with the initial complaint (if something is a large effort, someone should get paid, and if you're not comfortable with that, you probably should learn yourself), but I do think that things should be documented if they're already known. Heck, don't bother putting it in English if that's a stumbling block, let someone else translate it later.
 
I did learn myself, so I'm not sure who that's pointed at :/
The bit metallic quoted made it look like you were upset with those replies. I think those are entirely fine replies though.

But making people re-learn things that are fairly well known, but are not documented anywhere because no one thinks it's worth the time sucks.
 
I did learn myself, so I'm not sure who that's pointed at :/
The bit metallic quoted made it look like you were upset with those replies. I think those are entirely fine replies though.
But making people re-learn things that are fairly well known, but are not documented anywhere because no one thinks it's worth the time sucks.
Are these things fairly well known at all? Seems like it was extracted from the brain of just one person.

The replies can come off as a little terse, with a hint of "it shouldn't have been done that way, but should have obviously been done another way". There are a few linguistic barriers in place, mostly writing through text on a forum, that can make the tone seem more negative than intended. It's all helpful information that wasn't obviously available, so it can be frustrating when it sounds dismissive, even by accident.
 
Are these things fairly well known at all? Seems like it was extracted from the brain of just one person.
Supposedly? Or at least by a number of folks, and not just one. As stated here:


and quite few persons who know NAOMI stuff, most of them is not native English
There are a few linguistic barriers in place, mostly writing through text on a forum, that can make the tone seem more negative than intended. It's all helpful information that wasn't obviously available, so it can be frustrating when it sounds dismissive, even by accident.
I agree, 100%.
 
Are these things fairly well known at all? Seems like it was extracted from the brain of just one person.
I'd say they are mostly too trivial, if look at NAOMI ROM header in Hex editor - purpose of most of fields pretty much clear with no any docs.

anyway, here is a full table I've did:
Code:
ROM header, 500h bytes
--------------------
0000 - 000F	System ID, NAOMI, Naomi2 or SystemSP
0010 - 002F	developer, SEGA ENTERPRISES,LTD. or 3rd party
0030 - 012F	Game Names, 20h 8x (for each region)
0130 - 0131 Year (16bit)
0132        Month
0133        Day
0134 - 0137 Game ID, 3 letters (1st is 'B') followed by didit
0138 - 0139 !=0 = use 8MB ROM mode (ROM board offsets will be ORed with 20000000h)
013A - 013B !=0 = use custom G1 BUS registers init values
013C - 015B G1 BUS registers custom init values, 04h 8x (SB_G1RRC SB_G1RWC SB_G1FRC SB_G1FWC SB_G1CRC SB_G1CWC SB_G1GDRC SB_G1GDWC)
015C - 01DF M2/M4 type ROM checksum entries, 06h 22x, each entry is:
             rom size (16bit) 0 = 512KB, 1 = 1MB, 2 = 2MB, 3 = 4MB, 4 = 8MB, 5 = 16MB, 6 = 32MB, 7 = 64MB (M4 type), FFFF = not populated
             byte sum (16bit)
             word sum (16bit)
01E0 - 025F system EEPROM initial values and flags (coin settings, demo sound, etc), 10h bytes 8x (for each region)
            0 1=apply settings below
            1 flags, bit 0 - vertical display, bit 1 - advertise sound off
            2 coin chute type, 0 - common, 1 - individual
            3 coin setting number 1-28 (27 - free play, 28 - manual)
            4 coin 1 rate
            5 coin 2 rate
            6 credit rate
            7 bonus
            8-f sequence text #
0260 - 035F sequence texts, 20h 8x, "CREDIT TO START" etc
0360 - 03BF game mode executable load entries, 0Ch 8x
03C0 - 041F test mode executable load entries, 0Ch 8x
             each entry is:
             source ROM offset (32bit), FFFFFFFF - no more entries flag
             destination RAM offset (32bit)
             size (32bit)
0420 - 0423 game mode jump address
0424 - 0427 test mode jump address
0428		supported regions bit mask (bit 0 - Japan, bit 1 - USA, bit 2 - Export, etc)
0429		supported players number bit mask (0 = any)
042A		supported display frequency (0 = any)
042B		supported display orientation (0 = any)
042C		1 = check ROM/DIMM board serial number EEPROM
042D		service type, 0 - common, 1 - individual
042E - 04B7 M1 type ROM checksum entries, 06h 23x, same format as M2 type
04B8 - 04FE unused
04FF		!= FF - ROM header decrypt flag (starting from offset 010h)

is it will be useful to anyone ? I'd bet money - it will not, and I've just wasted my time while writing this.
its just several persons making some noise here, but have no real plans to do anything at practice.
 
I hope it will be useful not only for people who making bootleg carts, and want ROM TEST to be all GOOD...
btw, that's the reason why I not liked the idea to make this info public (prior that moment we at least was able to determine bootleg carts on ebay by bad ROM TEST entries).
 
As someone who recently purchased a Powerstone2 cart off YAJ and it turned up bootleg, I understand that mindset.

I have wishful thinking the majority of people on this forum are not interested in that.
 
I have wishful thinking the majority of people on this forum are not interested in that.
I don't think any of the active members you find around here do that, but I definitely know of a few lurkers who have used conversion info here to start churning out bootlegs.
 
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.
 
Back
Top