What's new
By:
Filters

Netboot Naomi With EEPROM Presets!

DragonMinded said:
and nobody ever documents why things work when they do discover things and everything gets lost to time over and over again. I am once again discouraged from continuing to try
Click to expand...
back in the days it was not hobbie toys, NAOMI was still popular business machines, so I'd suppose some commercial interests was intact when these hacks was made. and, as you may imagine, in such cases devs highly interested to NOT tell all the details ;)

as of patch, iirc it does 2 things:
- disable game code which copy syscalls from ROM to RAM
- inject small routine, which run before game code and do search syscalls RAM area for DIMM communication register address and replace it with dummy address ( = disable DIMM comms, as I've said earlier)
that's all
 
Last edited:
Yes, that looks to be the only patch. Comparing the vanilla GD-ROM dump to the Ikaruga_v3.bin file floating around, the first change is just to jump to the added search function, and the second change is in some unused code which is basically this when decompiled:

1634248365870.png


I am going to write a small test program and execute it on my Naomi to learn more about how this register works. Optimistically I *think* if the control registers are easy enough to understand then I can write a simple polling function which can check for reboot request and execute that manually and then it can be patched onto stubborn games that needed to be patched. At least that's my plan right now knowing next to nothing about how this works. We'll see if I can figure it out, it took me a long time to find the secret DMA enable code to make maple requests work with homebrew code.
 
Okay, I have some very preliminary progress. I replicated the BIOS function that polls for commands and marshalls them out, but did not actually handle any commands. I just acknowledged the right registers the way that the BIOS did it. And wow, the homebrew program I compiled to test this can be rebooted from the net dimm! The next step is to see if this minimal version can be stuck in the vblank handler or a control poll loop in games that do not reboot and have them reboot properly while not freezing/screwing up themselves.

Check it out:
View: https://www.youtube.com/watch?v=LQsmhIoiMZc


Now, I have a crazy idea: If the peek/poke commands that are documented can be put together with a menu program, it should be possible to make a boot menu that runs directly on your naomi for selecting games. I will see if I can make this possible.
 
Okay, a bit of an update before I go to bed. I put up a test program that responds to peek/poke requests from a script talking to a net dimm on a computer. Not only does it reboot properly when you send a new image, but it also can receive data from the net dimm as well as send data back to the net dimm. The peek command does not seem completely reliable, but if I run my peek test script in a loop it has a similar reliability issue with the Naomi BIOS so I am chalking that up to bugs in the net dimm firmware. I don't think they intended peek/poke to be usable for any retail setup anyway. If you want to see the code it is here: https://github.com/DragonMinded/netboot/blob/trunk/homebrew/examples/netdimm/main.c

But the short of it is it will be entirely possible to communicate between a Naomi program and a program running on a RPI/PC, so an on-cabinet menu proof of concept is coming.

I am also still working on a potential patch to restore reboot functionality in Ikaruga. If I am successful I can attempt other games as well.
 
This is amazing!

A menu running on the Naomi has always been the next logical step, and I'd been tempted to write one with your SDK for a while now, but dimm communication was what stopped me from trying. Now that you've managed it, it's definiately something that should be worked on - and hopefully can be made into something really nice.

Excited to see your proof of concept - I'll most definiately be trying to setup the SDK now! I think I had build issues before, so will try it on a clean Ubuntu installation and report any issues I have.

Thanks for all your hard work DragonMinded!

(Also thank you for the post on the Memory Check thread, really interested to see how it all works!)
 
DragonMinded said:
I am also still working on a potential patch to restore reboot functionality in Ikaruga. If I am successful I can attempt other games as well.
Click to expand...
nice, but it's still a shitty quirk. I'd like to see if some competent person able to find out actual cause of problem (i.e. why these games works fine via GD or CF boot but not Net-boot) and fix that properly.
 
  • Like
Reactions: rtw
MetalliC said:
nice, but it's still a shitty quirk. I'd like to see if some competent person able to find out actual cause of problem (i.e. why these games works fine via GD or CF boot but not Net-boot) and fix that properly.
Click to expand...
Agree, as long as we are patching games at this level we might be introducing game behaviour changes (running syscalls from ROM instead of RAM) so a solution which does not require any GD-ROM games to be patched is desirable.
 
Last edited:
MetalliC said:
nice, but it's still a shitty quirk. I'd like to see if some competent person able to find out actual cause of problem (i.e. why these games works fine via GD or CF boot but not Net-boot) and fix that properly.
Click to expand...
I agree. I have a few suspicions. When reverse-engineering the comm messages there are a few that the net dimm constantly sends. It sends an 0x01 packet which pulls some value from the BIOS and returns it, and it sends an 0x06 packet which is a peek 32-bit value message, for address 0x1F040 IIRC. I need to go back and get the actual address it is reading. I don't know if a regular dimm firmware would do such a thing since I don't have any to compare, but its possible that the net dimm is trying to poll for something that causes some games to crash or otherwise detect that they are on an iffy setup. There's also a decent amount of other code handling if a message is received so the BIOS might be calling some other interrupt handler. Do you know if GD/CF version of the firmware sends any of these commands ever?

I was going to try a few things: First, make the patch zero out the command mask so that the BIOS always detects command 0 "NOP" and see if that makes Ikaruga boot. Second, change the patch to point some of the handlers at the NOP handler instead, so that some commands work but others do not and see if that makes Ikaruga boot. I am curious if just the act of reading and clearing these registers in an interrupt handler is all it takes to crash the game or if it is actually something to do with how the BIOS responds.

Word of caution: I am not a competent person so I am trying my best to figure it out but I might lead myself into the darkness and get stuck.
 
I would say you are more than competent :D

I would recommend updating to DIMM version 4.02 to see if it changes the protocol.
 
All my dimms are 4.01 or 4.02, I just did my RE on the 3.17 firmware since it is readily available as an EEPROM dump and I don't have to do a lot of work to extract it from an update. I'm sure there's additions, but all of the info I've gleaned works the same across 3.17, 4.01 and 4.02 so I don't think they've removed or changed much, just added features and functionality.
 
I am running into some weird timing issues with the DIMM communications registers that I've been stuck on for a little bit. I need to investigate further so I don't think I'll have any results this weekend. Too bad :(
 
I've found some really interesting stuff. The net dimm board is sending a lot of peek/poke/control requests constantly to the Naomi which pokes at stuff in the BIOS RAM copy. So it is definitely poking state around, possibly while games are running. This is super most likely why some games aren't compatible, but I don't know what it's messing with yet.
 
DragonMinded said:
The net dimm board is sending a lot of peek/poke/control requests constantly to the Naomi which pokes at stuff in the BIOS RAM copy. So it is definitely poking state around, possibly while games are running.
Click to expand...
right, that's how DIMM->NAOMI comms works

DragonMinded said:
This is super most likely why some games aren't compatible, but I don't know what it's messing with yet.
Click to expand...
errm. I repeat one more time things said by me or rtw couple of times already:

- if you run some of games (for example Ikaruga, or Puyo Fever) from original GD - it works
- if you run same game binary from CF (if having 4.0x firmware) - it works
- if you run same game binary via Net-boot - it does NOT work
using same DIMM with same firmware

the only variable thing - boot method.
so, I repeating (and wtf I was wasting my time ? people wont read it anyway) words from my 1st post in this topic - it smells like in net boot mode DIMM firmware perform additional actions, possible some protection.
this was known since 10+ years ago. but the main question still have no answer - how exactly it works and what makes netboot special (all boot methods does peek/poking all the time) ?
 
Last edited:
@MetalliC makes some valid points, it would be good to know what is really going on because the same hardware supports GD-ROM images without any patching when loaded from a CF. The native netboot games are also supported out of the box.

@DragonMinded I will pm you a link to the original wccf image and the decrypted ROM if you want to take a look at that end.
 
MetalliC said:
right, that's how DIMM->NAOMI comms works


errm. I repeat one more time things said by me or rtw couple of times already:

- if you run some of games (for example Ikaruga, or Puyo Fever) from original GD - it works
- if you run same game binary from CF (if having 4.0x firmware) - it works
- if you run same game binary via Net-boot - it does NOT work
using same DIMM with same firmware

the only variable thing - boot method.
so, I repeating (and wtf I was wasting my time ? people wont read it anyway) words from my 1st post in this topic - it smells like in net boot mode DIMM firmware perform additional actions, possible some protection.
this was known since 10+ years ago. but the main question still have no answer - how exactly it works and what makes netboot special (all boot methods does peek/poking all the time) ?
Click to expand...
You really need to tone it down man. Every time I post on here you show up and get mad at me about how you know about all this stuff already but you don't share or document anything and you expect everyone to just come asking you for information. You did it on the thread with the CRC disable too. I'm doing this shit for fun and don't understand anything and I'm learning as I go and its really damn discouraging to keep having this conversation. This is not working together, it's being an arrogant ass and I don't appreciate it. Like you said, this is a hobby.
 
Yeah, I know about that. I haven't been using it except for to compare debug output messages that appear in the code I've been reverse-engineering.
 
Okay, I spent most of the rest of last night and today looking at optimizations I could make to the base libnaomi stuff that exists in my repo for doing homebrew. I have a dimm comms library pretty much worked out and it can reliably receive peek/poke messages from the net dimm, I have a high-level eeprom parser/unparser for homebrew that needs to read/write settings, I use that to automatically determine rotation for the video library I've written so that vertical setups "just work", I have optimized the video framebuffer routines down to the point where all of my examples easily get 60fps with room to spare, and I've added basic (non-interurpting) timer support which lets me calculate the speed of certain code sections as well as do accurate time-based spinloops. I know this is a bunch of bullshit words to most people but what it means in practice is that a lot of the pieces are in place to make a simple menu.

The following things are still on my todo list before I can present a proof of concept:
- Need a packet-based communication protocol between a running Naomi homebrew and a script that runs on a RPI/mac/linux/windows. This will let me send/receive arbitrary packets of my choosing to homebrew and I'll use it to set up communication like what game was selected and such. I'm going to work on that next.
- Need to compile freetype or another font library to my toolchain and write some glue code so I can display fonts. Right now the only text output that is possible is ugly 8x8 built-in console debugging font. It doesn't support unicode and looks hideous. Having freetype would let me choose a better font and support extended characters with ease. This will probably come in version 2 since it is a lot of work and I would rather get a proof of concept out first.
- Need to work out how Naomi games request the BIOS to enter the test menu. This isn't strictly necessary for such a proof of concept. However it is very nice to have since you might want to go into the test menu and change monitor rotation for the menu for vertical setups. Right now if you want to do that you need to catch the Naomi during the boot logo and hit the test button there.
- Need to come up with a simple menu program that uses all of the above to display a list of Naomi ROMs and then communicates with RPI/PC to report the selection.
- Need to come up with a management script that can be run which handles netbooting the simple menu program, making sure it has the list of ROMs and stuff, takes the selection that you choose and then netboots that ROM to make it all come together.

I have additional ideas up my sleeve. For instance, I plan to support the same patch and settings formats that my web netboot solution supports (and it sounds like @chunksin and @LazerFlux will soon support as well), so when you select a game on the screen you can optionally select a list of patches and settings to apply. This is a bit more advanced but absolutely completely doable. It just means that I will need to design and code some configuration screens on the naomi that talk to the management script. Its possible to do a bunch more stuff with this but I want to keep it "simple" for the proof of concept.

Now it is time to code like a mad bitch.

EDIT: two-way arbitrary data transfer library is finished and tested. I can send random strings too and from my naomi and display them on the screen as well as print them on my console. MetalliC provided syscalls location which enabled me to implement test mode calls in homebrew. I have finished the initial proof of concept of a menu assembler and communications program.
 
Last edited:
You must log in or register to reply here.
Back
Top