It reads the entire KDT1 chunk into memory before actually parsing the KDT1 chunk. So you can actually change for example "KDT1" to "XXXX" and it will actually still load it into memory, but it won't play it back (no internal error messages from the game).
Also: totally pointless, but I deciphered how it determines the end offset of the KDT1 chunk:
unsigned int get_kdt1_end_addr(unsigned int offset, unsigned int size)
{
size -= 1;
size &= 0xFFFFFFF0;
size += 0x10;
return offset + size;
}
It of course might not correspond exactly to the original source code, but it's pretty much a "literal" conversion of what IDA shows.
It uses this to check if the calculated size/offset corresponds to the size from the SdDt/sdtr header. The offset argument for the function is an address (which should be the start of the KDT1 chunk), and the size argument is the size from the KDT1 header.
As for how it reads/parses the actual sequence data, I sadly still have no clue :/ What's interesting however, is that it seems like the driver might actually support regular Midi sequences as well, because there are branching conditions for MThd, pQES, MDT1 and KDT1. So guess one could try to replace the KDT1 data with regular Midi data to see if it would play.
There are also traces of a "tvst" signature (similar to e.g. "tvag" and "tmid"), which suggests they were either trying to implement support for VSTs, or some Konami games actually do. Unless the "vst" in "tvst" stands for something else...
edited 5:57 PM EDT October 3, 2014
https://dl.dropboxusercontent.com/u/48454461/misc/sh2-wn-ds.txt
If anyone has any ideas about the other instructions/values, please do tell.
edited 6:14 AM EDT October 9, 2014
EDIT: moved it here: https://dl.dropboxusercontent.com/u/48454461/misc/sh2wnz/wnz.txt
Bonus:
I've attempted to recreate the first part of White Noiz. Here is what it might look like.
MIDI
Sample
Render
It's not perfect, but as you can see there are still a few unknown instructions/values. But we're getting there.. hopefully.
For the render I made, I had to make a custom instrument because VGMTrans refuses to convert the original instrument to SF2. :( Also, I barely tweaked anything (no reverb even).
edited 1:20 AM EDT October 10, 2014
If I had the knowledge, or some instruction on how to use it, I would be happy to help! I guess it requires you to know MIPS Assembly...?
And it really is sad that VGMtrans can't convert it to SF2, along with the SH1 instruments. :(
At first MIPS looked really cryptic to me, and I had no idea how to even begin interpreting anything. But once I learned that it pretty much just stores a bunch of values from/to registers/memory (think of registers as variables really), it quickly became much easier to understand for me, especially after I noticed IDA can show comments for each op (full names of each op basically, which is all you really need). You just gotta keep your mind into it, because you most likely won't be able to directly see changes to registers in IDA (you would need to attach its debugger to something that could run the particular program/module you're disassembling). If you're not a fan of reading 100+ pages of stuff (like myself), all I can say is you WON'T need to (not even half of that) to get a basic understanding of what's going on under the hood.
Some basic things worth noting is that in MIPS world, a "half-word" is 16 bits, a "word" is 32 bits. A "load" operation loads a value from memory into a register, and "store" stores a value from a register into memory. For example
sw r3, 0x0004(r4)
stores a word (32-bit value) from register "r3" at RAM address (4 + address in register "r4"), and
lh r3, 0x0004(r4)
loads a half-word (16-bit value) from RAM address (4 + address in register "r4") into register "r3"
And also that, when branching (conditional jump) or jumping (unconditional) to a location, the operation right after the branch/jump operation is always executed. Most other operations are really kind of self-explanatory if you just know what they stand for. addiu = add immediate (unsigned), subiu = subtract immediate (unsigned), srl = shift right logical, sra = shift right arithmetic, etc. All makes sense right? ...Well, maybe the distinction of logical and arithmetic shifts is new to you (it was for me), but there are C equivalent functions out there if you ever need to check what a certain op does to a value: http://stackoverflow.com/questions/7622/shift-operator-in-c#2463888
Here are some resources that has helped me so far:
http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html (programming-style equivalents of some ops; even if it's not necessarily R3000 assembly, it's still helpful)
https://cgi.cse.unsw.edu.au/~cs3231/doc/R3000.pdf (page 46 and 138-141)
I've started looking into SH1 instead because there are no PS2 emulators with a decent debugger (or at least I sure can't find any!) With the pSX debugger I can set breakpoints (pause the game) when it reads a certain memory address (it reads the whole KDT1 chunk into memory, and then processes it from there), so that's really helpful. Hopefully I'll find something soon...
I'm guessing you may be thinking "okay, but how do you know which address the KDT1 chunk is stored at..." For this you'll need to be a bit clever when using the pSX debugger, since it doesn't offer any way of searching for stuff. I used Memory Hacking Software to search for the physical start offset of the game memory, then I searched for "KDT1" using ASCII search within MHS. Then you take the KDT1 offset minus the start offset (since they're physical addresses and we need a dedicated RAM address). Then in the RAM window of the pSX debugger you can Goto the calculated address via Ctrl+G (remember to prepend "0x" to hexadecimal addresses, because it will parse it as a decimal address otherwise, even if it contains letters). If you've done it right, the RAM window should be at a KDT1 chunk. For example, 0x1F5600 is where the T2.KDT file (the KDT1 chunk of the first boss music) will be loaded.
I also realize now why I had to change lines per beat to 2 for the BPM for White Noiz to make sense. In at least SH1 it seems this is how it would actually determine the BPM.
unsigned char bpm(unsigned char bpm)
{
bpm &= 0x7F;
bpm <<= 1;
return bpm + 2;
}
And the MIPS code?
andi r2,r6,0x007f
sll r2,r2,0x01
addiu r8,r2,0x0002
Pretty simple, right?!
So for White Noiz that would actually mean 142.
Oh yeah, I confirmed the structure of the KDT1 header via the pSX debugger. The correct structure actually looks like this:
struct kdt1_header
{
char signature[4];
unsigned int size;
unsigned short unk1;
unsigned short rsv1;
unsigned short blocks;
unsigned short rsv2;
}
At least in SH1 the (supposedly) reserved values are never even read.
edited 12:23 AM EDT October 14, 2014
PCSX2 just got a new debugger if you didn't know yet: http://pcsx2.net/260-pcsx2-development-picks-up-speed.html
Maybe that can help the process?