What's new
By:
Filters

Netboot Naomi With EEPROM Presets!

Irrelevant to this thread but I figured that it might be of interest to other net boot tool authors like @chunksin and @LazerFlux and I don't know where else to post it.

I dug into both transfergame.exe and the net dimm 3.17 firmware over the weekend and documented the protocol a lot better, as well as implemented a few info retrieving functions. Namely, you can query a running net dimm and it will tell you the CRC of the current game, whether it is checking that CRC right now (showing the CRC check progress screen), if it thinks the CRC is good (should be running or booting the game) or bad (should be on the "NOW LOADING" screen), the firmware revision of the net dimm and the size of the net dimm in MB (auto-detect net dimm including memory size is possible). I use this information to figure out if a cabinet that was just booted is actually running the game I want to send it or if I have to send again and if I need to send again what part of the process is it in. Basically you can synchronize your own state with the state of the net dimm and it even works when running games that refuse to reboot automatically such as Ikaruga. I use this to allow seamless rebooting of my net dimm server without it thinking it needs to reboot currently-running setups to resend games to them. There's also a lot more documentation about how the protocol is actually put together for those who are curious (like I was).

I've been messing with it for a bit, but I haven't yet figured out what makes certain games not accept the reboot hook that the net dimm firmware tries to install when it boots the game. I assume its looking for some sort of vblank handler or something that it can hook with its own check code and some games have different enough code that it can't find a spot to hook into. I am still trying to isolate exactly what it is looking for with the theory that if we know what it wants, we can patch games that don't reboot to make them reboot when sending a new image. The code in the firmware is just too damn convoluted to follow for that function, however. For now, even when you are running a game that needs to be manually power cycled to send a new game, you can still query the running net dimm for info.

The documentation and code in question is here if you want to look: https://github.com/DragonMinded/netboot/blob/trunk/netboot/netboot.py

It gets used to send games like so: https://github.com/DragonMinded/netboot/blob/trunk/scripts/netdimm_send.py and it gets used to display info about the net dimm like so: https://github.com/DragonMinded/netboot/blob/trunk/scripts/netdimm_info.py
 
I haven't yet, no. I don't have a burner that can do chips that size so I've been using the old multibios in my vertical setup and my monkey ball setup. When my next NNC/naomi gets here I'll make that my dedicated horizontal and it's going to have the new multibios. I'll try different configurations and see!
 
DragonMinded said:
Irrelevant to this thread but I figured that it might be of interest to other net boot tool authors like @chunksin and @LazerFlux and I don't know where else to post it.

I dug into both transfergame.exe and the net dimm 3.17 firmware over the weekend and documented the protocol a lot better, as well as implemented a few info retrieving functions. Namely, you can query a running net dimm and it will tell you the CRC of the current game, whether it is checking that CRC right now (showing the CRC check progress screen), if it thinks the CRC is good (should be running or booting the game) or bad (should be on the "NOW LOADING" screen), the firmware revision of the net dimm and the size of the net dimm in MB (auto-detect net dimm including memory size is possible). I use this information to figure out if a cabinet that was just booted is actually running the game I want to send it or if I have to send again and if I need to send again what part of the process is it in. Basically you can synchronize your own state with the state of the net dimm and it even works when running games that refuse to reboot automatically such as Ikaruga. I use this to allow seamless rebooting of my net dimm server without it thinking it needs to reboot currently-running setups to resend games to them. There's also a lot more documentation about how the protocol is actually put together for those who are curious (like I was).

I've been messing with it for a bit, but I haven't yet figured out what makes certain games not accept the reboot hook that the net dimm firmware tries to install when it boots the game. I assume its looking for some sort of vblank handler or something that it can hook with its own check code and some games have different enough code that it can't find a spot to hook into. I am still trying to isolate exactly what it is looking for with the theory that if we know what it wants, we can patch games that don't reboot to make them reboot when sending a new image. The code in the firmware is just too damn convoluted to follow for that function, however. For now, even when you are running a game that needs to be manually power cycled to send a new game, you can still query the running net dimm for info.

The documentation and code in question is here if you want to look: https://github.com/DragonMinded/netboot/blob/trunk/netboot/netboot.py

It gets used to send games like so: https://github.com/DragonMinded/netboot/blob/trunk/scripts/netdimm_send.py and it gets used to display info about the net dimm like so: https://github.com/DragonMinded/netboot/blob/trunk/scripts/netdimm_info.py
Click to expand...
Ooooh! :D That's absolutely perfect, I can plug that into the state machine in my loader quite easily!
I envy the time you have to pursue these passion projects, and am grateful that you are sharing all this freely.

Also, good to know that the new multibios fixes those boot issues. Thanks for the heads up @chunksin
Looks like a Superpro is next on my list of buys when I have regular income again.
 
Looked at some more utilities from a PM with @whatnot and that confirmed my suspicion about a few things and helped me reverse the firmware startup state machine a little better. I pushed a new update with more documentation and functionality. This time, it includes the ability to read the size of the currently installed game, a utility to read back a game from net dimm after you've sent it, and the ability to disable the CRC check screen after sending a game if you want. If you want to try this out, run `netdimm_send <IP> <game> --disable-crc` and it will boot up without CRCing the game! The netdimm_info command has been updated to reflect the new CRC states as well as display the size of whatever game you have loaded. I still can't figure out how to get the net dimm to tell me what type of system it is running on (chihiro, naomi, triforce) but I suspect it might be possible. If there are people with chihiro and triforce netboot setups that want to help me try things give me a PM.

CC @LazerFlux and @chunksin on the CRC thing. I don't disable CRC on my own state machine because I can't tell if the current game is good or not, but you might be interested in it for your tools since it can shave off a decent amount from the boot time! Relevant stuff is in https://github.com/DragonMinded/netboot/blob/trunk/netboot/netboot.py
 
Also @chunksin I can confirm that the 2020 multibios does NOT fix the reboot issue with Ikaruga (and probably other Naomi games). I suspected as much, but it was worth a shot. I believe that the net dimm is looking for a vblank hook of some sort to patch a reboot check into and Ikaruga doesn't have code it recognizes. I am still trying to figure out what the code pattern it needs to find is...
 
DragonMinded said:
I believe that the net dimm is looking for a vblank hook of some sort to patch a reboot check into and Ikaruga doesn't have code it recognizes. I am still trying to figure out what the code pattern it needs to find is...
Click to expand...
it's not like that.
some of games didn't worked via netboot (due to still unknown reason, presumable some protection), to solve this problem there was added syscalls patch which kills all the DIMM->NAOMI comms, including reset command, so...
 
Ah, I was going to spend some time trying to bisect what the net dimm firmware was hooking by CRCing random chunks of code and then running a CRC-checking trojan before the game booted to see what sections were modified by the net dimm. But that's unfortunate. Is there any documentation as to what patches were added for what games and how they were discovered?
 
chunksin said:
Thanks for getting back to me on the reboot issue, that's really interesting about Ikaruga. The removal of the memory check is already in the WiPi image based on the findings we made here: https://www.arcade-projects.com/threads/no-more-pesky-memory-checkings-on-netdimm.14549/ which involved capturing the packet sent by checkoff.exe and replaying via triforcetools, not as elegant as your code!
Click to expand...
It seems that in that thread nobody understood what was going on with the packet at all. I guess that's fine since a lot of the tools for netbooting until now have revolved around copy and pasted python code that was never documented. But I don't like having random blobs of "do this exact thing to make it work" code because it leaves no room for improvement or further discovery, so I have been documenting why this stuff works as it does and finding inefficiencies and missing features in the existing tools as I go.
 
DragonMinded said:
Is there any documentation as to what patches were added for what games and how they were discovered?
Click to expand...
they are output of D.K.'s "DIMMtools" automatic patcher (and in general, the very most of NAOMI netboot images all of you use was created by this person), I'm afraid interested person have to RE it to find out search&replace patterns.
 
MetalliC said:
they are output of D.K.'s "DIMMtools" automatic patcher (and in general, the very most of NAOMI netboot images all of you use was created by this person), I'm afraid interested person have to RE it to find out search&replace patterns.
Click to expand...
Bleh, I feel like I'm wasting my time yet again. I spent the last week pouring over this stuff because its all hidden in threads 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 :(
 
DragonMinded said:
Looked at some more utilities from a PM with @whatnot and that confirmed my suspicion about a few things and helped me reverse the firmware startup state machine a little better. I pushed a new update with more documentation and functionality. This time, it includes the ability to read the size of the currently installed game, a utility to read back a game from net dimm after you've sent it, and the ability to disable the CRC check screen after sending a game if you want. If you want to try this out, run `netdimm_send <IP> <game> --disable-crc` and it will boot up without CRCing the game! The netdimm_info command has been updated to reflect the new CRC states as well as display the size of whatever game you have loaded. I still can't figure out how to get the net dimm to tell me what type of system it is running on (chihiro, naomi, triforce) but I suspect it might be possible. If there are people with chihiro and triforce netboot setups that want to help me try things give me a PM.

CC @LazerFlux and @chunksin on the CRC thing. I don't disable CRC on my own state machine because I can't tell if the current game is good or not, but you might be interested in it for your tools since it can shave off a decent amount from the boot time! Relevant stuff is in https://github.com/DragonMinded/netboot/blob/trunk/netboot/netboot.py
Click to expand...
I have a Naomi and Triforce Type 1 setup, willing to help!
 
DragonMinded said:
It seems that in that thread nobody understood what was going on with the packet at all. I guess that's fine since a lot of the tools for netbooting until now have revolved around copy and pasted python code that was never documented. But I don't like having random blobs of "do this exact thing to make it work" code because it leaves no room for improvement or further discovery, so I have been documenting why this stuff works as it does and finding inefficiencies and missing features in the existing tools as I go.
Click to expand...
Absolutely, which makes your work all the more important to the community and thank you for all of your efforts - we almost need a dedicated thread on here as a Naomi knowledgebase, any useful information gets logged in there so we have one place to go for the definitive answer, or even a Github wiki but I realise that is a lot of work to update and maintain.
 
@DragonMinded I am very impressed with your discoveries and documentation skills.

There is a lot of information out there however it has not been collected or ordered in any fashion.

What you should know is that the netloading was a feature SEGA used to upload code to it's satellites. Code was uploaded using transfergame.exe. This code was adapted to work with the netload solution.

it was discovered that some games would work and others not. DK made a patcher which basically replaces the address of a register with a harmless address. This allowed a lot of games to boot. In order to determine the exact patches applied compare one of the patched games to the original in MAME.

Shortly after this SEGA came out with a new BIOS which supported a CF card adapter. This solution supported all GD-ROM games out of the box. It also worked on the Triforce and Chihiro units. Gcfi was created as a mechanism to copy games to CF cards which could be used on these 3 targets.

tl;dr :
netbooting requires a lot of hacks to get games to work.
 
I got as far as comparing the vanilla Ikaruga binary to the netboot v3 fixed binary last night and saw there were two sections changed. One was in a chunk of 0xff so it was clearly added code for the patch, and the other was in another section so it must be the register changes you're talking about. I have yet to dig into what the actual code changes were to understand them, but I am hoping to figure out some way of partially restoring the register functionality to make rebooting games work properly. Maybe it is possible, maybe it is not, but it's worth a try.
 
You must log in or register to reply here.
Back
Top