The DDR Research Master Thread - UPDATED 2023-04-15 - Minor Addition - SOME DDR GB1 Memory Addresses

That's exactly what I'm thinking 🤔

Out of curiosity, what program in the screenshot are you using?

EDIT: Didn't realize we were on a new page. Anyways, I'm not a programmer (yet) but I'd like to imagine what would happen if we manage to actually pull off what Sesse is hypothesizing.

So, I've been investigating timing, and I'm fairly sure that a lot of what's been said about DDR Extreme is wrong. I won't claim to be 100% right myself, though, but this is my current understanding:

When the software wants to time a step, it asks the MAS3507D chip (the MP3 decoder on the digital I/O board) how many samples it has played, and divides that by 294. Since the MP3s are in 44100 Hz, this means that the timing window resolution is 1 / 150 sec = 6.667 ms. This is the same internal resolution as the DDR Extreme uses in its SSQ files. (Caveat: I don't know whether the step is sampled at the instant the user steps on the pad, or whether the timer is just sampled every video frame. I do suspect it's the latter, which suggests that there would be significant jitter in the timing, which again could be what people have interpreted as “the timing windows are in frames”.)

The judge windows are inclusive and asymmetric, measured in these timing intervals:

* Marvellous: [-2,2]
* Perfect: [-4,4]
* Great: [-13,11]
* Good: [-19,17]
* Boo: [-23,27]

A lot of what I've seen seems to be from people just reporting one of these values and taking it as the total window (e.g. “it says 11, so it's 5.5 frames”). But given the 1/150 sec resolution, this works out to be:

* Marvellous: +/- 13.333 ms
* Perfect: +/- 26.667 ms
* Great: -86.667 ms to +73.333 ms
* Good: -126.667 ms to +113.333 ms
* Boo: -153.333 ms to +180.000 ms

Yes, this means that great and good are kinder on early steps and boo is kinder on late steps. Can't be helped, that's what the table seems to say…

Has anyone else ever actually tried to look at the code here, beyond hearsay? Am I misunderstanding something?

Edit: Of course, given that in-between values are as likely to be rounded one way as the other (ignoring for the moment the truncation behavior of division…), one should probably think of these as adding 3.333 ms (half a judge tick) in each direction, which works out to a marvellous timing of 16.667 ms and perfect of 30.000 ms. But there's significant randomness/jitter here. I've also verified that the MAS3507D is indeed only sampled once per frame during normal play, no matter how much you step on the pads.

XnView

Making a few not too unreasonable assumptions, we can model the rounding as first random jitter to [-0.5,+0.5] 60 Hz video frames and then random jitter to [-0.5,+0.5] 150 Hz ticks, and we get:



To hit the marvellous 100% of the time based on the audio alone, you'd have to be within +/- 5 ms! But you could also get really lucky and get one when stepping 28 ms away. (Even more if you take into account sub-perfect rounding of the step itself to the 150 Hz ticks, and async of the step chart, but that's a different story…)

Of course, the top players will rely much more on the visual cues for precise timing, which makes the real windows somewhat wider and the probability distributions steeper (since you're trying to hit the right frame and not the right sample, the video timing jitter is cancelled out).

Sesse, are you still working on this? I'm curious, there's been radio silence .__.

The project has been put on hold indefinitely. I don't want to go into reasons at this point.

D:

I'm a little puzzled, what hearsay have you heard exactly?



Pardon my absence lately, as things IRL had gotten really busy (which had delayed my efforts to re-start disassembling games, and recover the research I had lost to my HDD crash).

Glad to see another face working on this effort to reverse engineer DDR Games. The more the merrier!


With regards to timing in SSQ Files, I'm puzzled (since it had been a while since I looked at what I had written), what exactly about timing was it I should revert?



Still bummed that the debugging data at the end of the Playstation2 mixes' executables are proving to be a pain for me to figure out, as I feel like creating a cohesive disassembly would be so much easier with all the info it provides, and help us all in figuring out how to reverse engineer the game, and customize the crap out of it. From root's communications with me a long while back, it was determined (by him) that the data used either the DWARF 1.0 and DWARF 2.0 format, but neither of us were sure which one for sure (IIRC of course). Any insight?

I haven't looked at the CS mixes, no.

Looking at the data though, it does lead me to believe that engine code was recycled from arcade to CS mixes - which makes sense, seeing that it would involve code that is the core functionality (and thus avoids re-writing code). Folder structure (seen from the source file paths in said debugging data), as well as leftover strings in the CS mixes that make no sense for a CS mix, but do for an arcade mix (like "INVALID SECURITY CASETTE") being just two things off the bat I can think of that support this notion.

I've got a question, but I don't know if this is the right place to ask. I got my EXTREME data ripped most specially the SSQ's and I'm having a hard time to recognize them. Is there anyone who can help me put up a list of those SSQ's and what songs are they?

Dude is better rip the ssq's with the banners, the ssq files alongside the banners is more easy to know the song name. (if you ripped arcade data)

---

Where do the filenames in your screenshot come from? In the archive, this is what the data structure looks like for a given song (in this case, Tsugaru):

data/mdb/tsug/all.csq
data/mdb/tsug/tsug_bk.cmt
data/mdb/tsug/tsug_nm.tim
data/mdb/tsug/tsug_ta.tim
data/mdb/tsug/tsug_th.tim

So the banners are indeed stored next to the SSQ. The problem is that the filenames are not stored directly in the data file, just their checksums, and the only really good way to reverse that is to guess at likely filenames (possibly from data stored in other files) and see if you find anything matching their checksums. sys573tools in particular does this, although its guessing is fairly slow.

Hmm, there might be something wrong with the way I ripped the data. I used DDR Utility to rip the data. I'll try sys573tools to see if it rips the data better.

Yep. Looks like the way the data was ripped didn't preserve the fact that the banner and static BG are stored with the SSQ file.



Anyways, Sesse, even though you don't focus on the CS mixes, I think it'd be worth looking at the leftover debug data in the various PS2 mixes (from MAX to EXTREME 2 and derivatives of EX2), as I feel like this information can help with producing good disassemblies for BOTH the 573 mixes, and the CS (PS2 moreso) mixes (assuming that we can figure out the format that the data was stored in, and use that knowledge to get the information associated with the file name strings, function name strings, and variable name strings - and there seems to be a fair amount alongside said strings).

I do FIRMLY believe that this would be beneficial to both 573 arcade, and PlayStation/Playstation2 reverse engineering efforts... but can't do it alone. If you wanna take a gander (or if anyone else wants to look at this stuff and give it a whirl), I can upload the leftover debugging data for MAX2 JP, EX JP, etc)

If you wish to look at the CS mixes, go ahead, that's your prerogative. Personally, I think it's neither interesting in its own right, nor especially useful for understanding the AC mixes.

Well, maybe not for very specific components, but I do believe that the core gameplay related mechanics / disassembling them into a readable form would be made easier for 573 AND CS mixes by looking at this data. I firmly believe that CS mixes do use code from the 573 mixes, which (in regards to core gameplay mechanics (menu navigation, scene loading, interpreting step data, etc), at least, makes sense - especially since such code working isn't dependent on whether it runs on the R3000A, or R5900. Not to mention how such recycling cuts out a lot of work in bringing the game from AC to CS).

My hunch seems to be supported at least a bit by the fact that the file name strings in this debugging data reveal a folder structure that includes a "s573" folder that seem to have held the source files for a lot of core gameplay mechanics (like oni mode for MAX2 onward).

Regardless, it'd be killing two birds with one stone, looking at and figuring this stuff out I mean. I'll upload whatever leftover debugging data I can in a little bit.

(Interestingly, looking into MAX2 AC's game memory while running the game in MAME, a lot of data in MAX2 AC (like, for instance, RGB values for songwheel text, positions of menu elements, etc) are stored in nearly (if not the exactly) the same way (data order wise) as in same data is stored in the CS version's executable)

WHAT WE DO KNOW ALREADY, thanks to member root670: Konami used MetroWorks CodeWarrior to work on the game, and the debugging data was most probably in the DWARF format (though whether this data follows DWARF 1.0, or DWARF 2.0 is unclear). Beyond that, work in figuring this out had hit a standstill.

Sure; follow your hunches, beliefs, wishes and desires to get answers to whatever questions interest you. I'll follow mine. OK?

And this is what I've got after ripping the data from EXTREME AC with DDR Utility. I guess I'll be left with more guessing work than figuring out what files and what songs they match with.