XboxHardwareInfo flags: 0x00000008 for ARCADE which is normally set in the arcade bios. It's also the flag checked on boot to change the prefetch limit. Simply adding the flag doesn't change anything though because you'd still be missing the prefetch limit which was set on boot (I believe). 0x00000100 prevents the Virtua Cop 3 Test menu from remapping the DVD Drive to the D drive (?). I never saw this before (at least I don't remember) and the code for it was pretty weird. Note that it should still get a name collision if "D:\" was mapped previously The Cihiro bios normally links \Device\CdRom0 to the same Mediaboard Partition (DIMM) as "mbfs:\". So mounting "D:\" to "\Device\CdRom0" should make "D:\" and "mbfs:\" equal. I tried to recreate that by unlinking "\Device\CdRom0" and relinking it. However, on xbox the actual device is not considered a link (and the device doesn't seem to handle the "DeleteDevice" callback). So you can't create a new link called "\Device\CdRom0". I realized I could remap "D:\" to the same partition as my custom "mbfs:\" and it will look the same to the game. There are some more differences between Chihiro and xbox though. Sorted from hardest to easiest: - MmAllocateContiguousMemoryEx will not support as much memoy (?). Would need to figure out the variables and change them, then cause a reboot? - PFN Database is in center of memory I believe, so we can't supply more contiguous memory(?). Probably very hard to change, bios (?) change would be the easiest? - Videomode might be different. Hook Kernel or patch calls with HLE. - EEPROM might be used differently. Hook the EEPROM API like nkpatcher etc. - All of the LPC stuff is missing from xbox and games will probably look for that (using "in" / "out"?). Exception handlers or patch with HLE. - JVS_SendCommand also seems to do something evil (Using kernel functions / objects?). Exception handlers or patch with HLE. - The Cihiro loader will ignore the flag to setup the utility drives. Change XBE in memory or patch kernel? - The ac* Library should be looked at.
One idea, it's very easy to load a bios on debug kit with phoenix bios loader custom I have upload (see old post), I use it for format bigger HDD (over 137 g). I try one time to load chihiro bios but freeze black screen certainely due about missing card (media board , dimm board). Why transform chihiro bios for launch games without missing board from Chihiro arcade system.
What checks for the XboxHardwareInfo 0x008 bit and sets the prefetch size? I figured out the "don't mount utility drive" thing on Wednesday. The Chihiro version of the kernel sets that bit of the XBE header at the end of XeLoadImage at the end of a success XBE load. Yes, hacked debug BIOS is best way to handle very large contiguous blocks. Without modifying to be dynamically determined at boot, the BIOS would become incompatible with 64 MB machines at all (which of course can't run Chihiro games anyway). This'd be much easier with the kernel source, but also harder in some ways. The video code I've seen so far in the Chihiro kernel - which by no means is anywhere near all of it - looked the same as the video code on a late-generation retail kernel. It supports all three TV encoders, but the ROM header indicated that it was an Xcalibur. If I remember correctly, ExQueryNonvolatileSettings looked the same. However, there was no support in Idex for locked hard drives. The Xcodes of the Chihiro ROM almost entirely match those of an "xblade" debug kit's ROM.
The XboxHardwareInfo is just different for ARCADE builds. - It's hardcoded for different compiles. It's an entirely different kernel and set at startup of the kernel (cold boot ~ initialization I believe). During initialization of the PCI devices that flag is checked (This is not hardcoded! So you should be able to flag your xbox and reload your bios, then you should have another prefetch limit). This seems to be the only time that it's not hardcoded but the flag is checked. We don't know about the title libraries though. So to patch a retail xbox, the most logical thing to do, is to extend the prefetch size manually and then set the flag in case the title libraries check it. I'm not sure if a hacked debug bios will even allow large contiguous blocks. The devkit is still similar to the retail xbox I believe: It will basicly allow 2 seperate memory regions: One in the lower 64MB and one 64MB region above that. The problem is that devkit systems are not meant to have GPU access in the upper region. They are only meant to use that space for debugging tools and extra game code. That's why you are still limited to 64MB RAM. Not only does this seem to be a theoretical limit, but also a technical restriction. I believe this has to do with the PFN Database using the space at the back of the lower 64MB. So it's probably impossible to have one contiguous block of memory which is larger than 64MB RAM! All pagelimits are therefore hardcoded to the lower half of the memory Chihiro on the other hand moves the PFN Database to the highest possible page. The GPU instance memory is also moved with PFN Database. Moving this is certainly possible, but it's not too easy probably. Especially with so many different kernels around. There are 4 kernels I'm aware of: Retail, Debug, Arcade, Arcade Debug (this is probably the same as a devkit with a moved PFN Database and CdRom0 instead of the mediaboard). So if we should try to get one to work it should certainly be the Arcade Debug kernel. It probably doesn't require the mediaboard and was probably used at Microsoft before the Sega hardware was ready. Possibly I should also try flagging the system as DEVKIT? Running a hacked bios / kernel is probably not too easy too for the same reason: The chihiro kernel does a lot of things we don't necessarily want. And changing everything would probably mean a lot of work. And even then you'll still run into problems with the code in the title libraries. I'd say we are halfway there anyway with my launcher. All we need is a proper kernel hook and a lot more information why the games even crash (crashdumps and proper documentation of what's going on / wrong). The AV code is the same, yes. But the Chihiro is not connected using a standard video cable, so the AV code doesn't depend on what cable is plugged in - chihiro can do anything because it has access to all video pins. It might set an invalid mode we can't see with our normal cables. There is also no specific video region for Chihiros probably. Also, it appears that Sega had access to the entire xbox codebase. At least they were able to create a custom XAPI flag. They also were allowed to work around the TCRs because they use "in" and "out" to access the mediaboard. Seeing how xbox/chihiro is ran in kernel mode, it's not too unlikely that Sega moved some code from the kernel to the games or their own libraries (which are staticly linked). That way they'd have much greater control over the system and it would have allowed them to get better control over the system. Hence it is posisble that they support some video encoders better than others. What puzzles me most is why Sega has a custom Xcodes (Listed in MAME). I always thought the chihiro bios is exactly the same as a retail one.. Not 100%ly sure about anything I said though..
For exemple, outrun 2 beta run with standard and HD componment cable (not widescreen support), ghost squad boot too with two cable; But Virtua cop 3 run only with HD componment cable (NTSC U or NTSC J). I think it's not a problem, use componment cable run some thinks automaticly. I already said that, but quadforce (run triforce game on wii) had the same issu, a console hardware with more ram (gamecube) with dimmboard for stock game. I think the best way it 's quadforce but crediar dosent want to help us.
That's odd.. Virtua Cop 3 also works with my composite cable (But crashes on the Sega logo). Also you can't compare Gamecube and Xbox at all from a technical perspective. The mediaboard message doesn't appear to be a problem - unless it crashes on that screen. But seeing the reports that Virtua Cop 3 works makes this hard to believe. That's the problem with the unorganized nature of this thread. - Nobody seems motivated enough to properlly document their findings. The thread is too long now and things get lost. Important information is not present and half the posts repeat what was said already. Anything which is not related to memory management can be HLE'd too. It worked for Cxbx/Dxbx, it will certainly work on the real hardware.. However, unless there is an actual infrastructure around chihiro (and more specificly chihiro on xbox) I won't be putting any more work into it. It's too much work for just one or two persons. Also, the system is 10+ years old. There is really no point in wasting that much time on it for anyone. As I said before, I'd rather help with the emulators for PC (MAME and xqemu).
http://ultracadefans.com/wiki/tested_games Please click "edit this page" to add your game test information to the wiki. Thanks! Notes: Wiki moved to new site because the table we were using got too big for wikia to handle.
only other game im aware of that loads to anything other then a black screen is Crazy Taxi High Roller which loads to a screen saying something like 'crazy taxi high roller is starting' and locks up.
The Chihiro does not have custom Xcodes. Compare a Chihiro ROM dump to xboxrom_xblade.bin for debug kernel 5455 to see what I mean.
I hope that the 128mb ram Xbox motherboard I send you will give you some incentive to keep trying Jayfox. I'm sure many people appreciate the work your doing. If I knew how to help, I would definitely do it. If you need a game tester or anything, let me know.
I know that I appreciate the work and help he's done. I'd contribute more if I could but the levels of Xbox understanding needed to be of use here go beyond what I know or are capable of. I can get a basic understanding of how it works but when it comes to talking address locations I might as well go drink a beer. I can still help out with the testing since I have the hardware to do that. Debugging and dumping crash logs are beyond me at this point in time. Perhaps the debug I have coming would be useful in this endeavor? Probably not since the hardware is a bit different. MCPX2 chip on debug versus MCPX3 on target retail based systems...
Dear JayFoxrox Thanks very much for your work, unfortunaly I can help you. But I can say that: I tested with all cable for Xbox, on debug (it's true only for Virtua cop 3) VC 3 works only with componment cable. It 's explain somewhere on the thread but I don't remeber where. Not hardware but software: For example in this website we can see : http://mamedev.org/source/src/mame/drivers/chihiro.c.html this file and all chihiro dumps availlbale here: http://uptobox.com/zzyz7ku25fe9
That's really great so there is another option to run this on other av cable, not only on the component. When I run VC3 I always have black screen, tested on scart rgb cable.
Vitural Cop 3 always works for me, with either composite or component cables. @Jayfox and everyone else, here is our log on Chihiro games on the original Xbox that Tkeahi started http://ultracadefans.com/wiki/tested_games Thanks a lot for starting that Tkeahi.
I saw that. We (developers / hacker without access to actual hw or tools) really need proper debug logs and crash dumps though. I do have a debug bios, but I don't even have Windows right now, so I can't run any tools at the moment to see what's going on. Last one for now: http://www.jannikvogel.de/scratchpad/xbox/launch-chihiro-7.xbe First an advice: This will write to the Chihiro I/O space for the testing lulz. So you should not run this on an actual chihiro. - You have been warned.. This is an insane release.. crazy poor code. If it crashes on startup your xbox doesn't handle writes to the Sega I/O space very well - mine handles it fine. If it crashes on game start with the memory hack (Hold X) enabled.. - you probably don't have 128MB RAM - you just had bad luck with timing of other threads: try again - there is still some issue with the PFN: use a debug bios - should blame me for poor code I don't really know what exactly I'm doing or how it works (it's a combination of trial and error, nkpatcher source and mixture of functions I had written previously). Basicly I try to patch the highest available page for contiguous (e.g. GPU usable) memory. As my xbox freezes as soon as I access the kernel, even after unprotecting it I decided to brute force it in by flushing TLB, messing with interrupts (including IRQL) and the cache. This might still crash. Sometimes it works - sometimes it doesn't. Not sure why. Note that this actually modifies your kernel (in memory). So once you quick reboot / IGR your console the limit will still be in the kernel. Basicly the GPU stuff could end up in memory which is not meant for the GPU anymore and your console will freeze. Also, this will only work if you are running a debug bios / bios which is meant for 128MB from the beginning. Otherwise your PFN will end up in the middle of the memory. The next process to allocate GPU resources > ~50MB will overwrite the PFN and you'll be screwed. Patching the kernel at runtime is done by searching for the instruction "mov edx,0x3fdf". So if your kernel was compiled different from mine (optimized or another compiler version) it's possible that you will end up without any match. The memory hack indicator (red / green) will be missing and the button message will show "Error!". If you are using a custom kernel with too much memory between MmFreeContiguousMemory and MmAllocateContiguousMemoryEx or if they have been switched in order this will probably create a black hole. The devkit fake (Hold Y) is pretty dumb and stupid. It shouldn't do much - but the games might check the flag. It will probably also disable the USB driver in the kernel so you are left without any input unless you are running it on a real devkit. At least it either froze or disabled input for me. The Testmode really seems eeprom related, I can't reproduce to start it all the time. I should probably do some eeprom dumps - but I'm too lazy to do it. //Edit: Just to make it clear: The memory hack (Hold X..) is basicly what *SHOULD* make the GPU part complete on 128MB kernels. So Ghost Squad *SHOULD* work. But then again.. it might be broken. But I'm not in the mood to add extra checks or precautions. Also we still don't know if this is the real reason why it's not working (but I guess it is).
Let me be the first to THANK YOU, Fox. YOU FIXED GHOST SQUAD! I'm running a retail box upgraded to 128MB, 4981 BIOS, UnleashX dash. I ran your launcher with X and Y pressed and just played Ghost Squad (with guns and all). YOU ARE THE MAN.
My trouble would be finding a cathode-ray tube television so I could connect guns. I haven't had a CRT TV since the mid-2000's.
