USF lecture series by hcs at 10:43 AM EDT on July 23, 2005
Coming to a browser near you... now!
I've reripped Killer Instinct Gold properly (1b and 20 now work, and probably some others I don't recall, not to mention it's now a little smaller (though it doesn't compress as well)) and I wrote a walkthrough of the procedure.
I read all of it. I hardly understood any of it, but I read it all. I am going to attempt to rip something some time in the near future. I think.
Typo nazi reporting... by Prokopis at 7:46 PM EDT on July 23, 2005
Read through it myself. Pretty interesting stuff; some I expected, some I wondered about, some I was curious about how you dealt with 'em. All in all, quite educating. Also thought I'd keep notes of anything catching my eye as wrong (in any context) and all I came up with, were the following typos:
- Typo: "it's" instead of "its", occurs twice: ("[...]IDA will then run it's analysis[...]") ("[...]can't tell what it does just from it's name[...]") ("[...]it's exception handler[...]") ("[...]it's only job is to create other threads[...]") ("[...]where it will create it's initial save[...]") ("[...]Distributed processing at it's best.[...]") - Typo: "alSeqpSetSet", occurs twice - Typo: "desination" - Typo: "recieve", "recieved", several occasions - Typo: "abstration" - Typo: "adress" - Typo: "recal" - Typo: "it give you" - Typo: "sparese" - Typo: "genereated" - Typo: "[...]which must also contains the programs[...]"
Like I said, good reading. Remind me to ask you some day about why some usflibs end up... well, let's say a bit less sparse than others when it'd seem (to my untrained brain) that all useful info - music function call, tracks table and audio thread - should be cluttered close enough together (F-0 X 9.55MB lib says "hi").
That seems like you need a lot of memory and storage on your HardDisk to decompress open huge files.
At least I can try doing Bomberman Hero sometime in the future. (My old method was to go straight into IDA and using a MIPS technical documentation ot figure out each code and foloowing it. I was mainly look up SEQ and nop jump commands.)
The method I described here worked well in ripping Extreme G 2, though the path to the song select fcn was a bit more complicated. I think I'll put together another walkthrough for that, though it'll be terser. And terser is the proper word, I looked it up.
Remind me to ask you some day about why some usflibs end up... well, let's say a bit less sparse than others when it'd seem (to my untrained brain) that all useful info - music function call, tracks table and audio thread - should be cluttered close enough together (F-0 X 9.55MB lib says "hi").
F-Zero X uses streamed music, simple as that. The idea was to save CPU for the 60 FPS 3D action.
Hopefully this works...later by unknownfile at 3:25 PM EDT on August 10, 2005
I managed to make a savestate for DK64usf, and sparsed it.
It doesn't do anything in 64th note as of now.
[This is an actual miniusf using the sr64 savestate] [made in Breakpoint Software Hex Workshop plz kthx]
I'm working on the new PJ64 1.6-based thingy, and it seems like the USFs I had made for DK64 work in it (as does everything else I've tried, Bust-a-Move '99 included (I don't have the Mischief Makers bits around anymore)). If yours works in the current version then all the better!
How'd you change my approach, or did you use something else?
Well i fif the usual an traced the threads and looked for supicious things, and i think that i found thread 7 necessary (but my thread 7 might be different from yours -0x805FADF4).
Anyway i am trying a method of Terminating the graphcs thread (and all other ones that dont diable music) that i count how many Dlists i need to use before the music starts. Luckily the count for this was 2.
It has come to my attention that i am using the European version of the rom. That would explain why your code didn't do anything to it.
I'll see if i can find an american version, but if i cant i will have to just keep working on what i got - in the dark.
Hmmm. Just a thing that might help, but where is that being called from? It might be able to help me identify it in this version.
Also, i made a nice little thing to compare savestates and search for music variables, and i did a search using 2 roms and the (American) song index table.
I got some nice results from it, but these were misleading as they appeared to change the music,
I've tried to see if I can make a small diff between the european and US version, best I have is 6 MB. If you're on dialup and would rather get that than the 32 MB full version let me know.
If you have a good BitTorrent client like BitComet, you can choose to download individual N64 roms from the above torrent. Each 7zip archive contains every version of the specified game.
(Please remove this post if it's against this site's rules or anything.)
Wewll i got the US rom and used it to locate the song select functions in the EU version (would not make sense to convert ~25 patches to the US).
However i am experiencing several problems with the rip process as you gentlemen have also.
However, further investigation into the problem (and ~150 patches - which to no avail), suggests that what i may be doing is correct and it should work in the batch ripper.
What got me thinking this is that the music will play if a different music plugin will play, and if it is ripped using this method - it will produce a tlb error in 64th Note.
This (for me) suggests that the batch ripper is actually at fault, and it shoudl rip perfectly. What i am thinking is that the problem exists in the modified audio plugin. Another occurance i noted, is that the DList count don't go up, and i cant be sure what this means, but i don't think that it is good. But i will be investigating it further.
If only how i could remember how i got the sample working - i forgot.
hcs, do you think that if a rewrite of the batchripper and logging will help to aleviate this problem - cause the savestates work perfectly with all other versions of Pj64 ive tried, so theoretically a rewrite should make it work.
It only logs the memory and rom used, so if nothing else much is changed nothing can go wrong?
-Game doesn't use standard library calls for loading (though it does use two al calls in memory) -Regardless of how fast the game is going, the music always runs at the same speed -Running an unoptimized savestate and ROM in 64th note has this annoying static
Recompiler CPU for tracing? I don't see how that could be accurate, any compiled memory accesses won't be properly treated and code that is never run is read by the recompiler and would be included.
Let the game run through the logo screens, and then after around 300 dlists have been progressed after music starts playing, the game will quit processing aLists. If you are running on recompiler mode, the emulator will return an error.
So far, optimization in Pj64USF has not been successful due to the sparse rom being 0 bytes when it comes out of pj64usf.
Here's what I tried in pj64usf's batch ripper:
Trace: 8000CC0
Song value offset: anything Song values: 0x2 to 0x2 Spend 4000 alists ripping Do reset on new data read
Hey, I was asking my dad about compilers. As a professional software engineer, he says he has a few different ones lying around. Seeing as I'm getting bored (more acurately that I feel I'm not doing my part), I was wondering where to get the source code I need so that I can start ripping. I have IDA, and the ROM I need, and savestates, and all that fun stuff. What I need, according to the write up in this thread, is source code so that I can add in my own breakpoint where osCreateThread is. That way, I can find out what's inside the N64 savestate so that I can actually start playing around with its inards. Thanks in advance for any help that can be offered. Mouser X over and out.
You should really use the savestate for analysis as it has all the code already in it and it better and quicker to analyze and uses less memory.
Then once its analysis is done find osCreateThread and get the number before it (usually some thing like 80001234) and use that as your breakpoint and use it's value in A2 (GPR[6].UW[0]) to find your thread.
Ive also found that my IDA plugin can usually find all threads as they use the "standard" function structure.
something I just now added: I created a sig file for n_audio (and the debug version n_audio_d), which is a slightly modified standard audio library (al). The USF Central page now links just to that, the archive contains all known sigs. I don't know why I had overlooked n_audio before. A few games use it...