I thank you for this Jay. I'm going to put a video up on Youtube soon of ghost Squad fully working. I will be giving you credit of course.
Wow, this is awesome news. I really wanna try it, but I cannot get it to work for the life of me. Whenever I end up running one these, my screen goes black (I imagine it is suppose to) but then I cannot do an in game reset. It just stays on the black screen. Can someone help me out? Edit: Okay I got it nevermind. THANK YOU JAYFOX
If you buy EMS TopGun III guns they work on LCD (with sensors), work fine on Virtual Cop 3 but when I tried them on Ghost Squad they worked but in really slow motion....unplayable basically.
So I have played through most of the game now, including mission 3 and everything works great! Except, I noticed that sometimes after you die and hit start, the music stops playing. Have you guys noticed this as well?
You actually don't need to hold Y at all. Works fine by just holding X. just so everyone knows Now hopefully someone can work out how to load the remaining games.
Thank you guy you are the one. One question, someone try with vsg_t.xbe, for use the test mode, needed for example for calibrate light gun (little lag on Virtua cop 3). Doesnot work on Dev kit and Debug kit, crash log: xbwatson: Connection to Xbox successful. xbwatson: Xbox is restarting. VX: INFO TCR verification disabled (use "vxa /reset" to enable) VX: INFO VerifierX loaded VX: INFO Watchdog thread started Xbox image loaded: \Device\Harddisk0\Partition1\Devkit\GHOST_SQUAD\launch-chihiro-7.xbe Exception: 0x00000004 0xC0000005 0x00022F1F 0x00000000 0x00000000 0x0000000C I tried from debug dash, and from XBMC (via phoenix bios loader). From Debug, crash black screen with red/orange LED. From XBMC, freeze on black screen, green LED Dear JayFoxRox do you have a solution? Thanks
If my launcher crashes (before starting the game) on devkits it could have various reasons. I'd need more information when exactly it crashes, what options were selected (held buttons), etc. I also need to know which revisions worked and which don't. Also, to fix the black screen issue and some other problems I really need a proper crashdump for BACKUP DATA CLEAR in VC3. The exception record is not enough. I also need crashdumps and memory dumps during the black screen in other games. Just attempt to dump as much debug details and write down as much information as you can. Crashdumps with / without launcher-7 are also necessary.
OK. didn't know at the time. Figured it's best to just use both hacks to be safe since it may not work for some without holding Y too. Ah. OK. I'll be sure to remember that in the future. Hopefully. My memory is a bit buggy. LOL
I'm collecting the PC tools to do this and hopefully will have some useful crash dumps in the next few days.
I would like to help out with the crashlogs as well, hopefully I can figure out how to generate the crashlogs.
For the life of me I cannot extract data from hotd bin file, every other game worked fine. Any chance of a small tutorial on how to extract this one? I looked at jayfoxrox site and shows tutorial for Linux, I'm running windows.
$ ./extract-fatx hotd3/image.fatx extracted/ Newest version of extract-fatx. Can be compiled using MinGW or Cygwin - compiling is the same as on Linux. I almost forgot about it: did anyone check wether there were any files in the "mbrom" or "mbcom" folders after running these games?
Someone can chage vsg_t.xbe to vsg.xbe to test if option mode run (test for exemple if you can change difficulty or calibration gun). Thanks
JayFoxRox: I almost forgot about it: did anyone check wether there were any files in the "mbrom" or "mbcom" folders after running these games? I checked and after going to dash with the IGR I find nothing. I use the IGR soft reset found on the Xecuter X2 5035 BIOS. I checked with VC3 and Ghost Squad. The folders are empty once the game is shut down.
I got nothing in those folders as well. I did get a log.txt file in the directory E/Chihiro/ though. Is this what the crashlogs are?
log.txt is just what I use to dump random information I use during development. I don't have the offical SDK so I don't have a network connection or anything to the xbox at runtime. Basicly if I want to know anything about my program I dump it in there. I also let random testing code dump to it. It's hard to read as it is not structured. The memory dumps I need will be created by the xbox kernel debuggers crash handler. When something unexpected happens the crash handler will be called and it will send information about what's going on to the connected PC (usually displayed in XBWatson or MSVC Debugger), it will then wait for the PC. The PC then responds what the xbox should do next: usually the PC reads all memory and the current CPU state. That way a developer can see where exactly the program crashed and why it might have gotten into that state. This is exactly what I need - best would be a 128MB Memory dump, a *full* register dump etc. (After dumping all information the xbox is still able to continue execution btw. You could even change the code in realtime and continue with corrected code) The mdmp (minidumps) posted by nonosto are basicly that. However, I don't think these dumps are correct. The addresses of the instruction pointer are not anywhere near xbox code and the stack is broken too. I'm not sure why that is but I would need more dumps to check if it's a problem with the dumps or the tools I'm using (Windows Debugger by Microsoft - IDA doesn't seem to work because it expects EXE files with the mdmp). Even if the xbox does not crash XBWatson and MSVC should be able to pause execution to create a dump. That way we can figure out if the game sits in a tight loop to signal an error state or someting. If XBWatson (or any XDK tool) has the ability to log Kernel function calls I would also be highly interested in that. If not I'd still be interested if some coder could attempt setting breakpoints on the Av* (Video Mode) and HalSMBus* (EEPROM) functions and see what's being done. I tried to create a hook of the kernel debugger for crash-dumps myself now. It's all rather promising. Instead of waiting for a PC to collect all the data or spitting it out via serial, mine does this: Basicly the LED on the xbox can show me already what sort of exception happened. So I can differentiate between hardware failures, memory access violations etc. I plan to add file access so that it can create a crashdump on it's own (without need of a development PC) - possibly attempt to continue execution after an exception etc. - But my crash handler still crashes as soon as my application starts anything else. I guess I'll have to write a proper memory allocator so the handler function stays in memory - that will be necessary for many other things (eeprom emulation, videomode hook, ...) too anway. It's just a crapload of work and really hard to debug The same thing exists in other tools like nkpatcher but it's all in assembler, so I'll have to port that first..
