What's new
Okay, this update is more for the people who implement net boot setups and less for the rest of everyone. I've done a bunch of work on the underlying python code that powers all of this with the purpose of making it easier to integrate into existing projects. At the request of @LazerFlux I have worked to make all of the packages more RPI-friendly. My old methods involved loading the whole ROM into memory, manipulating it with patches and settings enhancements and then sending it to the net dimm. This works great on high-powered computers but the RPI only has 512 MB or 1 GB of RAM depending on the version. When some ROMs are pushing 512MB on their own, that means that this doesn't really work all that well and certainly fails when you use a RPI to manage more than one net dimm at once. So I did a bunch of work creating a "FileBytes" class that you can give to any of the net boot libraries where you previously could only give bytes.

The "FileBytes" class is basically a magic class that pretends a file is fully loaded. It only needs to load parts of the file and keeps track of what changes were made. That means that my utilities can still load a ROM, patch it on the fly, add settings on the fly and send it to a net dimm just as it could before. But this time it only takes a fraction of the memory. Comparing before and after with Monkey Ball, originally it took about 200 MB of RAM to patch, add settings and send to the net dimm. Now, it takes about 25 MB. That's more than plenty of room to run on even the smallest RPI setup. As an added bonus, not loading the whole file to make some minor edits also speeds up many of the utilities. That means that not only are things faster to load but they are easier on the RPI.

If you were using my packages to patch data and netboot, you might have done something like this:

Code:
with open("someromfile.bin" "rb") as fp:
    # Read the contents
    romdata = fp.read()

    # Apply some random patch
    romdata = BinaryDiff.patch(romdata, somepatch)

    # Apply some random EEPROM settings
    patcher = NaomiSettingsPatcher(romdata, get_default_naomi_trojan())
    patcher.put_settings(somesettings)
    romdata = patcher.data

    # Send the patched ROM to a net dimm
    netdimm.send(romdata)
    netdimm.reboot()

Now, you would do something like this instead:

Code:
with open("someromfile.bin" "rb") as fp:
    # Magic wrapper to the file contents, but don't read it
    romdata = FileBytes(fp)

    # Apply some random patch
    romdata = BinaryDiff.patch(romdata, somepatch)

    # Apply some random EEPROM settings
    patcher = NaomiSettingsPatcher(romdata, get_default_naomi_trojan())
    patcher.put_settings(somesettings)
    romdata = patcher.data

    # Send the patched ROM to a net dimm
    netdimm.send(romdata)
    netdimm.reboot()

Basically, the code is identical, you just use "FileBytes" to handle the magic of loading things when needed instead of reading the whole file. You get speed and memory benefits automatically.

I've also separated out and created a "netdimmutils" package that includes a class for net booting. It has all the enhancements and fixes that I've put in from reverse engineering fw 3.17, transfergame.exe, transE.exe and checkoff.exe as well as my experiments. Basically if you saw me talk about a net boot option in this thread its available in this package. Together with "naomiutils" which includes all of the ROM and EEPROM stuff that I made in this thread as well as "arcadeutils" which includes all of the patching utilities and "FileBytes" magic class, these can be used to form the basis of a web-based, console-based or LCD-based net boot solution running on a RPI or even on a computer. Of course, they are all used in my "netboot" project to provide just such a web-based netboot solution that I use on my own setups but that is meant for servers so I don't expect many people to be interested in it.

All of these packages are available in PyPI so you can pip install them or depend on them in your own projects. The arcadeutils package is https://pypi.org/project/arcadeutils/, the naomiutils package is https://pypi.org/project/naomiutils/ and the newly created netdimmutils package is https://pypi.org/project/netdimmutils/. You can see how I use them to make various utilities like the Naomi Menu and the web based loader here: https://github.com/DragonMinded/netboot. And of course, the instructions in the first page of this thread for how to set up the utilities and run all the stuff I've done is on page 1 and can still be used by everyone else.

CC both @LazerFlux and @chunksin because I think that the new layout for a lot of this code should be much easier to consume and integrate. @LazerFlux I know you wrote your code in python so you can just take dependencies on these packages and integrate them. For @chunksin I think you base off of the old python scripts with PHP for the frontend? You should be able to use the https://github.com/DragonMinded/netboot project's "netdimm_send" or "netdimm_ensure" commands in place of the existing scripts as they take the same arguments (save for extra arguments for supplying settings and patches).
 
that menu works like a charm

mrhide@mrhide-MacBook:~/Desktop/netboot-trunk$ ./netdimm_menu 192.168.1.2 roms
Connecting to net dimm...
Sending menu to net dimm...
Talking to net dimm to wait for ROM selection...
Requested -IKARUGA- be loaded...


Very nice again Dragonminded and EXCELLENT documentation !! Bravo
 
Nice! Good to see independent verification that this stuff works. I just pushed a few changes laying the groundwork for settings (selecting patches, editing eeprom) pages. If you want to see a bit of a preview, pull that down. So far the only difference you'll notice is a boot animation, an error screen if communications is detected to have failed, and the cursor remembers your last game selection the next time you boot the menu. Gonna keep working on the settings page now.
 
have not updated but I tried on chihiro:
info works
menu and sending does not:


Code:
mrhide@mrhide-MacBook:~/Desktop/netboot-trunk$ ./netdimm_info 192.168.1.3
Requesting...
DIMM Firmware Version: UNKNOWN
DIMM Memory Size: 512 MB
Available Game Memory Size: 496 MB
Current Game CRC: 0 (0 MB) (invalid)

mrhide@mrhide-MacBook:~/Desktop/netboot-trunk$ ./netdimm_menu 192.168.1.3 roms
Connecting to net dimm...
Sending menu to net dimm...
Traceback (most recent call last):
  File "./netdimm_menu", line 11, in <module>
    runpy.run_module(f"scripts.{name}", run_name="__main__")
  File "/usr/lib/python3.8/runpy.py", line 210, in run_module
    return _run_code(code, {}, init_globals, run_name, mod_spec)
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/mrhide/Desktop/netboot-trunk/scripts/netdimm_menu.py", line 417, in <module>
    sys.exit(main())
  File "/home/mrhide/Desktop/netboot-trunk/scripts/netdimm_menu.py", line 393, in main
    netdimm.send(menudata, disable_crc_check=True)
  File "/home/mrhide/Desktop/netboot-trunk/netboot/netboot.py", line 141, in send
    self.__upload_file(data, key, progress_callback or (lambda _cur, _tot: None))
  File "/home/mrhide/Desktop/netboot-trunk/netboot/netboot.py", line 575, in __upload_file
    self.__upload(sequence, addr, current, last_packet)
  File "/home/mrhide/Desktop/netboot-trunk/netboot/netboot.py", line 415, in __upload
    self.__send_packet(NetDimmPacket(0x04, 0x81 if last_chunk else 0x80, struct.pack("<IIH", sequence, addr, 0) + data))
  File "/home/mrhide/Desktop/netboot-trunk/netboot/netboot.py", line 258, in __send_packet
    self.sock.send(
BrokenPipeError: [Errno 32] Broken pipe


mrhide@mrhide-MacBook:~/Desktop/netboot-trunk$ ./netdimm_send 192.168.1.3 roms/Wangan_Midnight_Maximum_Tune_2B_EXP_512.bin
sending...
Traceback (most recent call last):
  File "./netdimm_send", line 11, in <module>
    runpy.run_module(f"scripts.{name}", run_name="__main__")
  File "/usr/lib/python3.8/runpy.py", line 210, in run_module
    return _run_code(code, {}, init_globals, run_name, mod_spec)
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/mrhide/Desktop/netboot-trunk/scripts/netdimm_send.py", line 151, in <module>
    sys.exit(main())
  File "/home/mrhide/Desktop/netboot-trunk/scripts/netdimm_send.py", line 142, in main
    netdimm.send(data, key, disable_crc_check=args.disable_crc)
  File "/home/mrhide/Desktop/netboot-trunk/netboot/netboot.py", line 141, in send
    self.__upload_file(data, key, progress_callback or (lambda _cur, _tot: None))
  File "/home/mrhide/Desktop/netboot-trunk/netboot/netboot.py", line 575, in __upload_file
    self.__upload(sequence, addr, current, last_packet)
  File "/home/mrhide/Desktop/netboot-trunk/netboot/netboot.py", line 415, in __upload
    self.__send_packet(NetDimmPacket(0x04, 0x81 if last_chunk else 0x80, struct.pack("<IIH", sequence, addr, 0) + data))
  File "/home/mrhide/Desktop/netboot-trunk/netboot/netboot.py", line 258, in __send_packet
    self.sock.send(
socket.timeout: timed out
 
menu is native naomi program. it's like trying to run naomi/dreamcast game on Xbox hardware ;)
Basically this. The menu is only for Naomi systems. I don't have a triforce or a chihiro, nor do I have a toolchain set up to build for either, nor do I have the time really to make a boot menu for them, nor do I think that the communications between the net dimm and the main system are handled the same on either (they have a different path in the net dimm firmware than naomi).

However, simple sending should work on triforce. That is a bit worrisome that it does not. If you have some time later today we can troubleshoot.
 
Basically this. The menu is only for Naomi systems. I don't have a triforce or a chihiro, nor do I have a toolchain set up to build for either, nor do I have the time really to make a boot menu for them, nor do I think that the communications between the net dimm and the main system are handled the same on either (they have a different path in the net dimm firmware than naomi).
fair enough. let's forget Chihiro's menu since it doesn't make sense anyway.
However, simple sending should work on triforce. That is a bit worrisome that it does not. If you have some time later today we can troubleshoot.
I don't have a triforce but 3 Chihiros in 3 Wangan Midnights... and continue the Naomi work! it's more important !
 
Chihiro would have a couple requirements. Must be debug signed, the entry point would need to be changed (iirc? not that this is difficult, would just be a makefile diff), and must have a fatx partition that is exactly 512 or 1G in size (not that you need to send this much data but the chain must be correct).

You could use nxdk to generate a test program. Your next problem would be singing, if you owned a copy of the XDK you could perhaps get the private signing key (then it becomes a problem if you want to redistribute the program...) and resign the game with cxbe (another tool bundled with nxdk). Then of course you'd need a boot.id, trivially stealing this from another game and just renaming the program to be launched. Then creating the fatx partition.

Of course, you wouldn't have JVS inputs out of the box (even if you were to illegally use the XDK). You'd need to extend the USB driver to handle the SC & QC for input handling. Otherwise you could suggest people using the filterboard USB and just attach an Xbox controller (oob this would work, probably).
 
A big update!

There is now a configuration screen in the menu! If you are on the main game list and press [TEST], you will see the configuration screen. It lets you enable/disable analog controls, change the region your cabinet is set to (purely for name display out of the ROMs), change between loading the name of the game from the ROM and using the filename, and analog control calibrations. The calibration screen makes the menu navigation way better on my Monkey Ball cabinet! These settings are saved on the PC or raspberry pi you ran the menu from. So once you set up the menu it should work forever after that.

I also worked on the animations a bunch and optimized the heck out of the text display and as a result the menu is smoother on both vertical and horizontal setups. Vertical setups get a lower framerate because more games can fit on the list on the screen! Oops! But it is good enough for now. I've done a lot of bug fixes and optimizations for the menu to run faster and better and it definitely feels a lot better than yesterday.

I also laid the groundwork for editing game settings (eeprom contents on boot, patches). If you hold start instead of just pressing start, after 1 second it will enter the game configuration menu. I chose this instead of some other button because you might end up on a cabinet with limited buttons. Anyway, there is no code for displaying the game settings so if you do this it will just display "Loading settings..." forever while you get bored. I'm going to work on this feature next however!

Also, the menu can detect if it has suffered a communications failure (you turned off your RPI, hit ctrl-c on the menu, etc). In that case, it will display an error screen asking you to reboot and resend the menu. Hopefully that reduces any confusion anyone might have if they get into a weird state and wonder why its just stuck.
 
fair enough. let's forget Chihiro's menu since it doesn't make sense anyway.

I don't have a triforce but 3 Chihiros in 3 Wangan Midnights... and continue the Naomi work! it's more important !
Does the chihiro take longer to reboot and become ready to receive data than naomi? The timeout is suspiciously in that exact spot after rebooting to set mode.
 
There's a slight delay during reboot maybe 2 seconds or something before it'll continue sending over the net on Chihiro.
 
Another update!

The settings screen (hold start for 1 second on a game) now contains a list of applicable patches that can be applied to a game on boot! Use this to set up what patches you want to apply every time you boot (like free play, character unlocks, JVS bypass patches, etc) and then save that back to the host that is running the menu. That means that the host (either your computer or a raspi) that is running the menu software should be able to remember individual game settings per-cabinet so when you select a game it has all of your options.

I have not yet integrated the eeprom settings feature that was announced at the beginning of the thread, but that comes next! Soon you will be able to launch games which set up their own test menu options and apply their own patches, all on the fly from the menu itself. If you have the tools setup, download the latest version of them (either "git pull" or download a new zip, and the run "python3 -m pip install --upgrade -r requirements.txt" to update dependencies) and give it a try!
 
Just thought I'd post that I successfully installed the toolchain and built a program - so libnaomi is working nicely now, thanks for updating it!

Also another fun suggestion, I'm fairly sure you can upload to the Dimm without first having to reboot the Naomi into the 'upload a game' state. When you select the game with your menu, you could always goto your own custom loading screen, with a progress bar (either calculated based on time/game size so you don't have to further comms through the dimm, or send the progress how you are communicating with everything else if it'll let you do that whilst uploading a file). That way, you'd only then have to reboot the Naomi once at the end of the upload process, and you'd probably save yourself a tiny bit of time (I think it locks out the uploading for a few seconds whilst it reboots).
 
I never tried doing that but there doesn't seem to be any reason why it wouldn't work. My menu doesn't attempt to DMA anything from the DIMM once it's loaded by the BIOS so I think it would work. Having a nice progress bar would be kinda neat actually. I'll give it a try sometime this week.
 
Okay, so unfortunately due to the way I talk to the net dimm (peek/poke stuff), sending games without rebooting first does not work. What ends up happening is that the net dimm freaks out the same way that it does when you enter and leave the test menu (ERROR 22). Honestly, I probably need to get interrupts enabled and service the dimm communication register there and emulate what the net dimm is looking for before I can make this work.

I know its possible. I did get one successful send of MVC2 including a progress bar screen displayed on the Naomi. There's some timing problems so that it doesn't always work however. In fact, it almost never works.

EDIT: HAHA just kidding I got it working.
 
Last edited:
Okay so I just pushed some updates! The following has been added or updated in the latest version:

- Proper centering of text. Centered text used to be eyeballed and now it looks a lot better.
- Bumped the timeouts for various communications by a few seconds, since I was running into a few of them here and there.
- Put an error message in for when your ROM directory contains no ROMs.
- Loading screen! When games load they will display progress on your Naomi now, instead of just sitting on the "NOW LOADING..." screen.

You can pull down the newest code with "git pull" or if you downloaded a zip, download a new zip and unzip it over the old code. Have fun!
 
Must.finish.ChainsawMan.Costplay.Head for Halloween but can't wait to try all these goodies!
 
well now that this is out of the way
IMG_9153.jpg



I was able to (quick and easy) update and man ... nice work. This is really usefull! thank you again!

IMG_9154.jpg
IMG_9155.jpg

IMG_9156.jpg
 
Good to see confirmation that the newest version is working! I have a friend of mine helping me test packaging up some utilities to make a fresh rpi image into a menu serving device and he's been helping me verify that it works on more than one naomi out there but it is nice to see broader testing!
 
Back
Top