What's new
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.
- 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.
I REALLY like where you're going with this.
 
using syscall, can't remember which one, may check it if you really interested

add: it's like:
u32 *syscalls_ptrs = 0xAC018000;
void (*fn) (void) = syscalls_ptrs[0x11] | 0xA0000000;
fn();
It was indeed 0x11, I breakpointed Ikaruga in mame based on the vector and confirmed it before implementing a test mode call in my toolchain. I can see where Ikaruga is also polling syscalls for dimm command execution so I am very curious about how it handles responses, perhaps there lies the key to what protection it has against net dimm. I have yet to dig in and learn however.
 
I can see where Ikaruga is also polling syscalls for dimm command execution
it doesnt, there is no syscalls for polling nor sending commands to DIMM. rather game code write some requests to RAM comms area (somewhere in 0xC01Fxxx range) and then polling there for results.
 
Last edited:
Yes there is. Syscall 0x14 is used to ask if there is a dimm inserted, and is also used by a function at 0x0c01929 in the BIOS which I've called "perform_dimm_commands". This function polls for if there is a dimm at all, then it sets up a handler at 0x0c019acc which is the actual dimm comms register handler (reads the commands, queues them, responds), and then sets up another few functions before exiting. That marshall function at 0x0c019acc is also syscall 0x19. There's also syscall 0x09 which is at 0x0c018e08 and the first thing it does is call the aforementioned "perform_dimm_commands". Once Ikaruga is booted it performs a syscall loop consisting of Syscall 0x09 -> Syscall 0x14 -> Syscall 0x08 -> Syscall 0x08 -> Syscall 0x08. So it is clearly calling the BIOS in a loop. You are right that the net dimm writes in 0x0C01Fxxx range (240 is one of them I observed a lot). It also gets a "command" address to write to and read from using dimm command 0x01 (Which, of note, is also mapped to dimm packet 0x16 which is READ_COMMAND in 3.17 firmware).
 
but there is no! :)
0x14 - simple check if DIMM exists at all (read DIMM comm register and check if value !=0xffff)
0x18 - fire IRQ to DIMM

the rest of syscalls you mentioned not any related to DIMM, they are for coin/credits etc BIOS settings handling
so, there is no any syscalls like "send command/data to DIMM" or "get some data from DIMM", as I've wrote in prev message "rather game code write some requests to RAM comms area", form where DIMM read some data/requests on its own, nothing more besides poke it using IRQ

TL;DR: all the black magic is inside of DIMM firmware, there is nearly nothing (important) at NAOMI/game side
 
Last edited:
Some more progress on the menu: I can send and receive arbitrary packet data between my code and a PC, and button inputs and entering test menu works fine. However, since I provide my own peek/poke handlers and do not defer to the BIOS, I've found that exiting the test menu to go back into the regular netboot menu gives an "ERROR 22". If I simply do not set up or respond to the dimm communication registers at all this problem goes away so it is definitely something I am returning to the net dimm which makes it unhappy and causes the BIOS to report an error when it resumes talking to it on reboot. I will have to examine the communication request state machine in the 3.17 firmware image to figure out if there is a way to trick it (such as, for instance, never responding to the READ_COMMAND command).
 
Check it out! I got the proof of concept running!
View: https://www.youtube.com/watch?v=LrL4q0N6nGc


You can try this right now if you follow the instructions on the first page of this thread for how to get started with my code at https://github.com/DragonMinded/netboot/

It is very basic:
- It has an ugly console font (I want to fix this).
- It has no way of setting up or communicating settings or patches (I want to fix this).
- It does not work with analog controls (I want to fix this).
- Since I don't have analog controls working yet, I could not test scrolling code since all my ROMs fit on my Vewlix screen!
- As soon as it successfully sends a game it exits. I want it instead to wait for game power cycle and send the menu again so you can reboot the cabinet to choose a new game.
- If you go into the system test menu and back out again, you will receive an "ERROR 22" message and you will have to restart the menu script.


EDIT: All of the above have been fixed, and it is ready for use!
 
Last edited:
How cool is that!!

"I am not too competent" :)


somebody-give-this-person-a-cookie.jpg
 
Last edited:
Definitely not competent. I spent all night getting freetype compiling and got font rendering and now it goes at 20fps instead of 60fps. Devestating incompetence on display over here :(
 
I made a ton of progress today! I got rid of the ugly debug font, got some scroll indicators in, built in and tested analog control support and did a lot of cleanup. It is looking good enough that I wouldn't mind seeing it on somebody else's cabinet. I still have a lot of things I want to do with it however. But for now, check out the progress. Sorry, no audio again, my phone was shitting the bed so I stripped it.

View: https://www.youtube.com/watch?v=sg1rT1HFSjY
 
Haha that's the basement, the garage has the games that don't fit through the door ;P
 
fought with a couple of packages but it runs! :

Code:
Mrhide@mrhide-MacBook:~/Desktop/netboot-trunk$ ./netdimm_info --help
usage: netdimm_info [-h] IP


Tools for requesting info from a NetDimm for Naomi/Chihiro/Triforce.


positional arguments:
  IP          The IP address that the NetDimm is configured on.


optional arguments:
  -h, --help  show this help message and exit


it's totally for work training purposes :D

Will try it in a cab after 17h00.
 
Back
Top