What's new
By:

chihiro outrun

"FAKE", or simply "inaccurate" will do... *shrug*.

I believe that is a Wiki, maybe you should go correct the info with something that you can verify?

"In dev kit document" you have the Chihiro specific one? As I understood it was not proper leaked? Which could also be inaccurate info.

Alas: "So, the JVS found on the rear of the DVT3 was presumably used in early development of the Chihiro system.... On the DVT4 the JVS port is covered", you said you had a 4? I was talking about the 3... (probably splitting hairs at this point)
https://assemblergames.com/threads/xbox-xdk-usb-port.25198/#post-388133

None the less if anyone is bored. This is NOT fake... go pull down the old leaked XBOXKRNL source (xbox4044originals.rar).
https://mega.nz/#!zR8RHIQR!COKLbkk1rGXAtF8yHKRa6Ouzv5kBFRF6tAQQAFIQPFo

If you grep for "arcade" in a case insensitive fashion you'll see a few things.

"#if !defined(ARCADE) || defined(DEVKIT)"
and
#ifdef ARCADE
are what you'd want to look for.

For example if the Arcade kernel is used, the drive locking checks are not performed. There is a check that allows the extra memory use to be requested (by the title). The executables also run with a "no setup hard disk" flag.

There also seems to be a check ensure that the DVD is NOT "DVD-X2" authenticated, as well as a specific check for a file "loaded from the media board".
 
Chihiro JVS is a baseboard thing. Development was likely done using that board as well. Some components are unpopulated like 2 usb A connectors and 1 DB9 connector. Some diagnostic leds and their driver chip are also missing. So, initially, they could connect that board to 2 pc usb ports and start programming it. On the chihiro, it also occupies 2 gameports (3 and 4)

Jvs controls are not converted to gamepad data. A new static library was created that handles the communication with the base board over gameport 3 and 4. As you can see in the mame sources, the base board microcontrollers have 1 control endpoint and several bulk endpoints. They don't have an interrupt endpoint like an xbox gamepad.

Every chihiro image comes with 2 xbe's. One is the game program and the other is the in_game test menu. In this case, or1.xbe is cannonball ported to xbox and later on chihiro and the other is the menu that was initially based upon the asyncwrite xdk sample.

The game initially still loads it's settings from the xml files but overwrites some from a structure it reads out of the baseboard nvram memory.

My biggest concern was that it might eventually overwrite the gamesaves or settings from other games you previously used. That's where the "use at your own risk" comes from.

Another thing I couldn't figure out is how you can jump directly into the chihiro test menu (what happens if you press the test button while you are in an original chihiro game. In this case, it will just return to the chihiro splash screen and you have to press test again to get into it's setup screen. It's only a minor issue.
 
This is amazing :)

So to get some thing clear; in the future it may be possible to run other racing games simply on my Outrun 2 SP cabinet with a compact flash solution?

Right now I have a chihiro with Outrun 2 SP on SSD.
 
This indeed might become possible in the near future.
If you happen to know a good xbox racing game you would like to play on chihiro hardware, I am open for suggestions.

There still is a difference between homebrew games and official releases.
In homebrew games it's possible to add the jvs controls and use them directly. Official releases expect a gamepad or steering wheel. I am pretty confident it should be possible to create a firmware for the baseboard so that the microcontrollers emulate a xbox gamepad, but that work hasn't been done yet. I will now focus first on a multi game solution for the existing chihiro (racing) games. Adding some xbox titles might come after that.
 
  • Like
Reactions: DLX
obcd said:
... A new static library was created that handles the communication with the base board over gameport 3 and 4. ...was initially based upon the asyncwrite xdk sample.
Click to expand...
"c:\Program Files\Microsoft Xbox SDK\Samples\Xbox\Misc\jvs_test\Release\AsyncWrite.pdb" would seem to imply that no one created it, rather it was simply supplied in the XDK, eh?

I recall XDK-1.00.5344.01 was used to compile "Chihiro GBA", I also know XDK is notoriously hard to find... maybe someone here with various versions of it can confirm or deny the existence of the "jvs_test" folder in the Samples directory?

Maybe we need to talk to "Borman", he seems to have quite a bit of info on the XDK.
http://codeasm.com/xbox/Kernel_Dash_versions.htm

"I suggest you head over to assemblergames.com and ask for Borman."
https://gbatemp.net/threads/xbox-debug-kitinfo-needed.492080/
 
Last edited:
@obcd do your magic :)

I like the need for speed underground 2 or most wanted.... but Chihiro games only is also fine.

Good job :)
 
The asyncwrite folder was copied and given a new name jvs_test. It's framework was used to test the created jvs static library.
Later on, that was extended to create the game test menu xbe. You wan't find jvs_test in any of the xdk packages.
The only thing you have is an ezusbdef folder in the dd\usb folder of the leaked 4400 kernel sources.
That shows firmware upload and download of an unprogrammed ezusb microcontroller.
 
You must log in or register to reply here.
Back
Top