What's new
But on type3 chihiro even with a 0 key I have to leave the time limit hack running.
This is not the case for me. I have mostly used transfergame.exe and it has no ongoing connection. I don't have issues with any Chihiro games giving an error. The Chihiro does stay connected to a router, though, so not sure if that has any impact on this issue.
If you're using transfergame you should be all good. The physical connection to the router doesn't make an impact. Did you program your PIC yourself or did you buy it? I can't boot at all without one, but even with what I'm told is a type 3 netboot PIC I still have to leave the script running (When I know I shouldn't have to).

@kevindg86 yes that's it
 
Are you guys sure the netboot port remains open on the new ip address once the game has started?
I was under the impression that it closed and that there was no option to connect to the dimm once the game has started, not even on the new address assigned by the game.
On a dual setup, shouldn't both game boards get a different ip from the game?
Maybe the master gets the one hardcoded in the game code and the slaves get one 1,2 or 3 numbers higher depending upon their slave address.

I also know for sure that our outrun 2 SP changed the ip addresses once the game had booted. It's strange it doesn't seem to happen in your case.
I even intended to use that feature to check if reloading a game was needed. If you still could ping it after a minimum elapsed time, it hadn't started a game.
The dimm with good batteries seemed very stable and hardly ever needed a new upload of the game. (It only was powered down 10 hours / day)
 
Are you guys sure the netboot port remains open on the new ip address once the game has started?
Here are a couple of tests I just did:
-In anticipation of the IP getting reset to 10.0.0.1 when booting WMMT2, I manually set the Chihiro's IP to 10.0.0.1, set up my router as 10.0.0.99 and set that as the gateway on the Chihiro. The game boots and I can ping it at 10.0.0.1 with my laptop connected to the same router. I can even push a new netboot game to it at this address when WMMT2 is booted into attract mode. Since I have no FFB hardware plugged up on the bench, I have to go into settings and turn off FFB and card reader to get the game to boot to attract mode. Once it booted, I pushed OR2SP.
-Since OR2SP is being booted on the bench, it boots to an error screen about the force feedback board, so I had to go into settings and set it to upright mode. I can ping it at 10.0.0.1 and pushed WMMT2 to it.
-WMMT2 boots and I can push OR2SP to it, rinse and repeat. :)

Now, on my bench testing I don't have the capacity to set up 2 Chihiros, so I will have to get to where I can test this on my cabinets to see what issues multiplayer adds to the mix, but so far if I know what the IP is going to be and have my router configured appropriately, it seems like I can still ping and push netboot games.

Pending multiplayer testing, my conclusions are that the games do not end up locking the system out of netbooting (need to test during actual multiplayer) and OR2SP is not reassigning the IP. I think for Chihiro I might be good to go because OR2SP and WMMT2 are the main games I want to swap between (and CTHR, which shouldn't cause any networking issues and isn't multiplayer anyway). I think I can get everything on Chihiro working for me in the 10.0.0.X IP range. The 2 Mario Karts are my main interest on the Triforce, and I think I can probably get them working in the same range.

Edit: Since I've never booted for multiplayer, it's now occurring to me that that each time games are swapped, there's probably going to be some test menu configuration needed to assign the right ID to each cab. Perhaps things won't be as automatic as I was originally expecting, but that's ok.
 
Last edited:
On WMMT2 the assigned IP corresponds to the PCB ID that you set in the game settings menu. When I assign PCB ID 2, I get IP 10.0.0.2. I'm guessing there's no dynamic logic associated with it, it just gets the IP for the one you selected and pings the others at boot.

I'm guessing WMMT works the same, but it appears to only be 2 player rather than up to 4.

I'll test, but I'm going to guess that MKAGP1/2 work similarly.

In any case, this means when swapping games it's definitely going to be necessary to configure at each cabinet to get them set up for multi-player. Otherwise they'll all default to PCB ID 1.
 
Good findings. The game settings are likely stored on some of the eeprom chips of the base board (chihiro again).
It's known for instance that the region of it is stored there.
An exception is the OR2SP game. That one uses a special partition in the dimm called mbsys: It's a partition that is writable from the gameboard.
So, if the dimm memory loses it's contents (when it's battery gets flat), OR2SP loses it's high scores and game ID. The other game specific settings are lost as well.

The baseboard has a CR2032 coin cell and a small super capacitor. Those are for the real time clock chip on that board. They could keep the sram powered as well, but I haven't tested this yet.

If we could restore the base board eeproms and the mbsys partition, you could switch games without manual intervention. Still a long road ahead.
 
For some reason I was having issues posting this earlier, but here's what came up in the saved draft:
MKAGP2 seems to handle changing the IP in the rom file a weird way. For some reason it's assigning 8.0.0.1 when I save the value as 010.000.00.01.

It appears to be treating the first part as octodecimal (in an ascii representation of the digits), because I have to change it to 012.000.00.01 to get 10.0.0.1 assigned for PCB ID 1. Very weird!

Anyway, it looks like I can assign the ips as needed for the Mario Kart games. I can ping it at the reassigned addresses. Transfergame seems to refuse to send a new game during attract mode, but the triforcetools reset command works and it also has no issues sending a new game. I'll be using triforcetools anyway, so should be good to go with this.

Additional testing on both platforms needs to be done with multiple systems linked up to see if netboot commands still work.
 
If we could restore the base board eeproms and the mbsys partition, you could switch games without manual intervention. Still a long road ahead.
This would be really cool.

I had experimented with pulling saved data out of NAOMI with some of the built-in triforcetools commands, but I didn't have much luck. It may be a method better suited to the Triforce, so perhaps there will be a saved data restoration solution there.
 
If you could figure out where the triforce saves it's highscores? Maybe it also uses a partition in the dimm board memory.
If you disconnect the dimm board battery, does it reset it's high scores and game settings?

Most chihiro games use the memory chips on the base board. Those are connected to microcontrollers that interface to the main board using usb.
It's obvious that triforcetools can't access the contents of those memory chips directly.
 
If you could figure out where the triforce saves it's highscores? Maybe it also uses a partition in the dimm board memory.
If you disconnect the dimm board battery, does it reset it's high scores and game settings?

Most chihiro games use the memory chips on the base board. Those are connected to microcontrollers that interface to the main board using usb.
It's obvious that triforcetools can't access the contents of those memory chips directly.
I'm not sure on high scores. I was hoping to be able to restore test menu settings which are stored in NVRAM and get wiped out when a new game is pushed out.

I'm really not sure where the read4 and read16 commands are pulling data from. The comment in the source for HOST_Read16 states, "Peeks 16 bytes from Host (gamecube) memory." I'm not familiar with the architecture. Some quick tests haven't yielded anything. I'm not sure of the address range to aim for and trying to read at random addresses gets me either nothing or an error response in the script. The command seems to indicate it is pulling from somewhere other than DIMM memory and there are separate methods labeled that make me think they handle reading from DIMM.
 
I only experimented with the methods that read from dimm memory.
It was possible to load an encrypted game into the dimm and to replace the pic with a zero pic afterwards.
If you read the dimm sectors back, you could rebuild an unencrypted image.
I stopped those experiments when it didn't work for outrun 2, probably due to the reassignment of a new ip.
It also wasn't possible to figure out the correct size of the image.
The Host_read could have been a debugging aid. If the nvram is in a separate memory region, you might not be able to access it using the triforcetools commands.
 
I was wrong about OR2SP. None of my testing so far has been done with multiplayer mode turned on! It totally reassigns the ip address... I haven't gotten to test if it accepts a new game or reset commands when booted.

Also, the version of Crazy Taxi High Roller that I'm booting, while it doesn't reassign the ip address and I can continue to ping it when booted, it does NOT seem to allow a new game to be pushed and ignores reset commands via triforcetools...
 
I assume if you press the test button, it will enter the global test menu and might accept a new game over netboot in that mode.

It's been a while, but on HOTD3 you could reset the system and reload the game using netboot. I only tested on chihiro 1 which might act differently.

Did you perform the Crazy Taxi test on a chihiro 3 setup?
 
I assume if you press the test button, it will enter the global test menu and might accept a new game over netboot in that mode.

It's been a while, but on HOTD3 you could reset the system and reload the game using netboot. I only tested on chihiro 1 which might act differently.

Did you perform the Crazy Taxi test on a chihiro 3 setup?
I'm not sure about netbooting or reseting from test menu. That's where I'm seeing media board settings to verify the changed IP in the games that reassign it.

My Crazy Taxi testing is on a type 3 Chihiro. It's the only kind I have. I notice it has a media board test that gets skipped, but not sure how relevant that is.
 
The other thing I tried with OR2SP was to edit the IP in the rom file like I was able to do with Mario Kart, but it does the same thing as WMMT where it just boots to the generic test menu. It looks like in OR2SP it just stores one hard-coded full IP and modifies it per the choices in game settings.

It's odd to me that it doesn't throw an error and just boots to the test menu. I'm wondering if it's some kind of checksum issue.

At any rate, it's feeling like I might ultimately have to rely on a relay per cabinet to the physically cut power and hard reboot the motherboards if I want to automate as much as possible. I'm not sure how much it's going to be worth the effort. It seems like games are mostly going to require changes to settings at boot anyway, so if netbooting can be done from the test menu, that might just be good enough for me. I'll see what I can figure out with Crazy Taxi and OR2SP.
 
A chihiro game image usually contains 2 xbe files and a boot.id file.
That boot.id has the names of the xbe's that it should boot in normal game mode and "in game test" mode.
So, if you have altered the game xbe, it goes into test mode. Would that be the "in game test" mode or just the main segaboot.xbe test mode.
(The one you get when you press the test button the first time.)

Sega has it's own copy pretection mechanism with the security chip, but likely it verifies the hash of the xbe's as well to ensure the xbe hasn't been tampered with.

You can reboot the system to load a new game, but it's a time critical operation. You have to wait till the unit becomes pingable. (knowing that dimm board and network board are ready) and you need to start the download shortly after, since the system will launch it's game if it finds a valid game in dimm memory. Further, if you switch games, they will likely use the same eeprom memory chips on the baseboard to store their "game specific" settings and high scores. (OR2SP might be an exception as that one uses the mbsys partition on the dimm board)

If I remember well, you have the different "Force Feedback" systems covered and you are able to emulate a card reader setup using an arduino?
I read about doozer who was able to use a Lindbergh on a chihiro Force Feedback board. Slowly the pieces of the puzzle are falling together.
Keep up the good work.
 
Would that be the "in game test" mode or just the main segaboot.xbe test mode.
It's booting to the main segaboot.xbe test mode when I alter either of the Chihiro games I've tried.

So for additional testing, I went through the hassle of rigging up 2 motherboards and 2 i/o's for a mutliplayer bench test. In this setup, I have made use of a network switch and have the 2 Chihiros wired to it. Multiplayer OR2SP and WMMT link up fine when settings are correct on each unit, so I'm glad that multiplayer is still going to be possible.

An observation on OR2SP linking: The game appears to boot into a linking mode where it searches for all expected linked games. You set the current unit's ID and the number of units within the settings, so each game knows its ID and how many units should be connected. This at least means that I don't have to do any synchronized resetting to get OR2SP paired. I also noticed once I entered the test menu on one unit while paired, the other unit rebooted and went back to the linking search screen, so that's kind of nice.

I don't think WMMT behaves this way. The linking screen for it looks like it will just timeout and go ahead and boot without linking. Fortunately this game does allow pinging and resetting via triforcetools, so it will be easy to reset them via netboot commands to get them to sync up. My network settings are all aligned with what WMMT assigns as the IPs, so no issues there.

I can't seem to get around my booting issue when trying to edit the OR2SP ip in the rom file. I tried to make a neutral change by tracking my changes to the IP bytes and doing the opposite elsewhere, but that won't beat a more complex checksum, if that's what's in use.

Making use of the network switch and a router, I'm not sure how to doing any advanced routing so that my PC at 10.0.0.X can ping a Chihiro at 192.168.14.X. If I set my PC to a static IP of 192.168.14.99, I can ping the 2 Chihiros with OR2SP booted and I can both send reset commands and send new games.

Edit: Wait a minute... maybe the router is completely unnecessary in this scenario. On my windows PC I can set up some advanced IP settings with multiple IPs so that my PC can ping one Chihiro at 10.0.0.1 and another at 192.168.14.2 when they're all on the same switch. I assume my RPi can have the same type of settings.
 
Last edited:
Ok, so with some fussing about with IP settings on my RPi, I can get it to ping Chihiros in the 192.168.14.X (OR2SP) and 10.0.0.X (WMMT) ranges! It can send netboot commands and new games to motherboards in both ranges. So once a new game is pushed to a Chihiro that currently has OR2SP booted in multiplayer mode, that Chihiro reverts back to 10.0.0.X.

The remaining issue is one that just has to be dealt-with in the settings once a game is booted and that's the fact that newly booted games have to be set up again. Otherwise 2 instances of WMMT will have the same IP (and default to not being multiplayer). I expected to have to do this anyway, so it's no big deal.

I also confirmed that Crazy Taxi allows new games to be pushed from test menu, so that means I get to avoid more complicated reset mechanisms in my solution.
 
I've got the basics of my netboot server in place. I have it all currently running on a clumsy mix of PHP and python with a very basic/ugly UI accessible via web browser on a connected device such as a phone. I have a set of 10.0.0.X and 192.168.14.X that are pinged, and based on successful pings, am presented with buttons for resetting or pushing out specific games.

At the moment I'm using a WiFi router to connect a phone to the server, but will migrate away from that and have just the RPi be a WiFi host so the phone can connect to it directly. This would be similar to a couple of the netboot projects currently out there, but the goal of those seems to be one server to one motherboard, whereas I wanted one server to many motherboards.

I think I've successfully worked around the changing IPs, too, so the subject of this thread should be pretty well wrapped up.
 
Back
Top