so is it possible to run chihiro on xbox (modded or debug...) how to in theory? why nintendont work and we cant find same for xbox?
- Thread starter Darksoft
- Start date
got a link?
please don't make any accusations. How do you know that? How do you know that for example it was me who gave him the files?
That's why I added the strike-thru text, I don't know for certain, I don't know that it's that person doing it - I only say his name as you suggest going to him to get this done (meaning he has prior knowledge of what's going on). What I do know it's legally sketchy as it contains the evox footer.
I wont link it here but obcd should know what I'm talking about RE: the modchip discussion.
The more I look into it this kernel is weird - it's 2 different kernels 4 * 256K, 0 & 1 are the same and 2 & 3 are the same.
interesting that this just popped up in my feed: https://www.reddit.com/r/originalxbox/comments/ho3mem/fixed_a_dead_10_xbox_with_a_raspberry_pi_4/
That's just reading the eeprom over SPI.
read AND WRITE: https://github.com/grimdoomer/Piprom
Good to know. Now people can fix their dead chihiros in an even easier way.
It's not SPI. It's connected to the SMC bus which is basically IIC. An arduino can do the trick as well, but the eeprom voltage levels are 3V3 and not 5V (like most arduino's)
As I already explained before, the wii has an arm processor that is doing most of the io stuff and a PPC processor that runs the game code. Nintendon't modifies the arm code so that the triforce games work with wii controllers. The chihiro only has one x86 processor that runs the game code and does the io handling simultanously. So the code that queries the JVS io board is a library that is linked to the game xbe. It accesses the usb hardware directly so it's more difficult to reverse and alter.
cxbx-r uses a technique of finding function footprints and redirecting them. It's a pretty good base to find out what is missing to run chihiro games on xbox hardware. Adding that in software that runs simultanously with the game on xbox hardware is the next hurdle.
As I already explained before, the wii has an arm processor that is doing most of the io stuff and a PPC processor that runs the game code. Nintendon't modifies the arm code so that the triforce games work with wii controllers. The chihiro only has one x86 processor that runs the game code and does the io handling simultanously. So the code that queries the JVS io board is a library that is linked to the game xbe. It accesses the usb hardware directly so it's more difficult to reverse and alter.
cxbx-r uses a technique of finding function footprints and redirecting them. It's a pretty good base to find out what is missing to run chihiro games on xbox hardware. Adding that in software that runs simultanously with the game on xbox hardware is the next hurdle.
I know but, Darksoft maybe not...maybe if he want to run Chihiro game on XBOX...
I will try to debug step by step cxbx-r, so only virtua cop 3 run and only the vc3.xbe, not vc3_t.xbe (with test menu). What's use about cable from mediaboard to Xbox LPC port?
The LPC signals aren't used on the base board. They are just passed trough to the dimm board. On the dimm board there are a number of io ports at address range 0x4000 - 0x40FF. Not all of those ports are documented. You can read a port to figure out if the chihiro is a type 1 or a type 3. Another port will tell you how much memory is installed in the dimm. Some ports are used to upload the firmware that is ran on the type 3 dimm asic embedded softcore. Others are used to control the network functionallity of the dimm board.
Do you have any bug when the LPC unplugged? The chihiro BIOS is required ? Or like Virtua cop 3, Crazy taxi or Ghost squad other game could run without? (except missing hardware) So if I/o is in game code theorically game could run whitout Chihiro BIOS.
Other things firmware.bin inside game is loaded? what's use.
THX
As far as I remember, the chihiro bios checks the type register as it initialises the ide port differently for a type 1 or type 3. It also checks the dimm ram size as it assumes a game image is partitionned for that specific size. (the fatx table size doubles for a 1Gig image)
Next, there is segaboot.xbe which also checks the chihiro type register. If it's a type 3 it will upload the firmware.asic file to the dimm board.
Chihiro games can run with an xbox bios, but they expect a 640 x 480 vga video signal. They also will try to communicate with the expected base board microcontrollers on gameport 3 and 4. segaboot.xbe will result in a hardware error 2 when this communication fails. I have no idea what will happen with network enabled games (like or2) if the network hardware isn't there.
A type 3 dimm board uses udma5 on it's ide connection. A type 1 uses a slower protocol.
Next, there is segaboot.xbe which also checks the chihiro type register. If it's a type 3 it will upload the firmware.asic file to the dimm board.
Chihiro games can run with an xbox bios, but they expect a 640 x 480 vga video signal. They also will try to communicate with the expected base board microcontrollers on gameport 3 and 4. segaboot.xbe will result in a hardware error 2 when this communication fails. I have no idea what will happen with network enabled games (like or2) if the network hardware isn't there.
A type 3 dimm board uses udma5 on it's ide connection. A type 1 uses a slower protocol.
I am pretty sure about res, just component cable detected is sufficient, this the chihiro upper box encode to VGA.
So for you what's the main bug generator? I assume that is the missing JVS i/o board. We have maybe a solution with JVS emulator. Connect with a USB to xbox. i will try it with maybe something.
what's use about firmware.asic?
It's not the missing JVS board, it's the missing base board. That board has 2 micro controllers that handle the jvs io and force feedback serial io. They also interface to an eeprom memory chip, a real time clock chip and a 128 Kb non volatile ram chip.
The xbox kernel only run's one xbe. This makes it difficult to add code that runs in the background. So, you could patch a game and redirect it's jvs communication, but you don't have an easy way to store the subroutine with your new code. You will need to create a xbe with it that has it's own embedded "xbe loader" to load (and patch during load eventually) the game xbe.
firmware.asic is the firmware that makes the dimm load a game partition from either gdrom, compact flash or using netboot. firmware.bin and firmware2.bin are the firmwares for the 2 microcontrollers on the base board. Without a dimm, I don't think firmware.asic has much interesting.
The xbox kernel only run's one xbe. This makes it difficult to add code that runs in the background. So, you could patch a game and redirect it's jvs communication, but you don't have an easy way to store the subroutine with your new code. You will need to create a xbe with it that has it's own embedded "xbe loader" to load (and patch during load eventually) the game xbe.
firmware.asic is the firmware that makes the dimm load a game partition from either gdrom, compact flash or using netboot. firmware.bin and firmware2.bin are the firmwares for the 2 microcontrollers on the base board. Without a dimm, I don't think firmware.asic has much interesting.
If we assume that the flat large ribbon from base baord to XBOX mobo is dedicated about game loading, and the multi color cable from BB to USB plug on the mobos dedicated for specific BB hardware. So with external modul like PI plugged via USB front panel port of XBOX, could replace the BB.
Firmware.bin and firmware2.bin are specific for each game?
Firmware.bin and firmware2.bin are specific for each game?
Firmware.bin and Firmware2.bin are not game specific. It looks like they do a revision control and update the baseboard microcontrollers to the newer firmwares if the ones from the game are more recent than the running one. In test menu info it shows you the QC and SC firmware rev. that is on the board.
The ribbon cable is also just transferred from the base board to the dimm. The dimm is seen by the xbox motherboard as an ide harddrive with multiple partitions.
There is a partition that points to the flash containing the chihiro dashboard and one that points to the game code. Their also is one that is used for networking.
And there is one that is used by OR2SP for it's high score and settings. That's why that game loses it's settings if you don't have a battery to keep your dimm powered.
You can simulate the base board microcontrollers, but you need an usb client device. The pi usb ports are host ports. So you would need something like an arduino leonardo on each port to simulate it's functionality. The mame chihiro code gives a good idea of what endpoints are used by the 2 microcontrollers.
Maybe we should start a separate topic about this. It's off topic for the conversion of a xbox mobo into a chihiro one.
The ribbon cable is also just transferred from the base board to the dimm. The dimm is seen by the xbox motherboard as an ide harddrive with multiple partitions.
There is a partition that points to the flash containing the chihiro dashboard and one that points to the game code. Their also is one that is used for networking.
And there is one that is used by OR2SP for it's high score and settings. That's why that game loses it's settings if you don't have a battery to keep your dimm powered.
You can simulate the base board microcontrollers, but you need an usb client device. The pi usb ports are host ports. So you would need something like an arduino leonardo on each port to simulate it's functionality. The mame chihiro code gives a good idea of what endpoints are used by the 2 microcontrollers.
Maybe we should start a separate topic about this. It's off topic for the conversion of a xbox mobo into a chihiro one.
just to finish with that when you ask about hardware solution with Jayfox (chihiro launcher coder) thinks it's not a good idea. He prefer patch solution GHYDRA and code from HLE CXBX (XbSymbolDatabase class/library) with downsize about 3D texture, same with 128 mo.
