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

I've noticed that the entire SSQ file, in the PS2 games at least, is in fact loaded into memory in certain cases at least (for example, edit mode, and training mode) - and that in a game stage, the non-stepdata chunks pertaining to everything else in the song are loaded into memory along with the chunk for the correct stepchart..

Actually, I've noticed that this happens in the 573 AC titles too - overwritten when a new song is loaded.


Specifically, I noticed that the values for individual arrows are powers of 2 (1 for left, 2 for down, 4 for up, and 8 for right), and that pairs (or even groups of 3 arrows, or even having 4 arrows) are just the sum of these values. For example, 1+2+4+8 = 15 (0xF), which shows up as all 4 arrows at once. 1+4+8 gives you a value a value of 13 (0xD), which shows up as left + up + right)

@Wan BEAUTIFUL writeup on the SSQ format btw, thank you very much for that - I learned a lot.

Most of the info I posted is thanks to pkgingo's investigation. If you're in youknowwhich tracker lemme know.

There is one thing that confuses me though - the assertion that the entries before the step values are all pure metric values, multiples of 4096

I am confused because if we go to an excerpt of the excerpt I posted before

00 01 04 00 // Measure 16 Beat 4
00 01 08 00 // Measure 16 Beat 8

These are not even multiples of 4096 - which means I am missing something clearly (not your fault of curse )

Maybe it's also my fault for trying to analyze this shit just after waking up / before having my coffee.

Side tangent... just realized that I've been registered here for 14 years and 10 days exactly... 0___0 Gotta love having ADHD... )

I think there's a mistake there - these values are written as big endian, right? They should be the 2nd and 3rd beats of the 17th measure (beat 65 and 66, if the start is beat 0), as 1 measure = 4 beats = 4096 units, and 1 unit is therefore 1/1024 beat.


Interesting info, didn't know that the "timing resolution" was only 1/75 sec in the MAX2 era. Do you know what it was for the early mixes (1st to 3rd)?

Incidentally, it's well known that 12ths and 24ths were rounded to the nearest 64th for a long time (e.g. bag). Based on my previous understanding of SSQ files I'd assumed that the format had changed to allow proper 12ths, but this seems to suggest that there was no such change, is it possible to check?

Just got IDA reinstalled on my computer (at home - am at work now) so I am finally able to get back to work on my disassembly of MAX2 JP. Hopefully the info Wan et all provided will allow me to document the routines that actually handle stepdata.

Not to mention being able to get back to work on trying to do disassemblies of 573-based AC mixes (and perhaps others in future).

I never said that the measure value has to be an integer number

00 01 04 00 = 66560 = 4096 x 16.25.
The arrow is right at the 1st quarter of the measure. Converting the SSQ to SM and opening it in ArrowVortex, it's this arrow (the position being confirmed in the status bar):

Fun fact: using Burning Heat's decrypted audio from Extreme AC, the song is offsync by 0.06 secs but with the audio from MAX2 it's only by 0.03


1.- Sadly nope, as the step format used is different. IIRC it's 1/75th as well.

2.- It's not that the format didn't support 12th/24ths/48th, it's the game engine that didn't.
So it's not that bag's steps were "rounded", the chart was made like that. That's why they didn't have problems in purposely adding the old Extreme chart in DDR X2 after they fixed the quantization in DDR X.

Have in mind that DDR STILL uses SSQ as of A20+

I might be doing something wrong OR overlooking something (been bouncing between this and juggling a dozen other projects + work, so I am not as focused as I can be/should be), but it doesn't seem like these values adhere to the IEEE 754 floating point representation standard...? that and from my observations at least, it seems like the literal stepdata processing doesn't even touch the PS2's Floating Point Unit (as opposed to the drawing of the arrows on screen - which does seem to touch the FPU (at least in my observations). If those observations are correct, I am a bit more confused about how we are looking at this through the lense of non-integer values, and feel like a total duncecap for admitting it... XD

Is it possible that they (being Konami - and within the purview of the SSQ format) went with a completely unconventional route to do the equivalent of decimal values? Or am I REALLY derailing myself thought process wise? Holy crap, I feel stupid.

You're definitely derailing yourself and thinking it too much xD
It's much simpler: the decimals are relative to the position IN THE MEASURE, forget about the PS2 FPU.
A value of X.5 is the middle of measure X.

Another example

In this case, the arrows are (in order) in measures:
4.000
4.375
4.500
5.000

So I started an additional disassembly project in Ghidra to see if I can glean insight from the decompilation functionality it has.

This is the function where the player's earned DP is calculated, and a percentage is gained:


Now, I bet in actuality they used a for loop to go through this process of processing the earned DP, and that was just unrolled upon assembly (and this decompilation is the interpretation of said unrolled loop) - that is, the original code wouldn't look this ... horrid, for a lack of better terms. That said, it is still useful, IMO, for understanding the game engine, and its inner working. For example, the parameters look correct for this function (param_1 being a pointer to an array that holds the step counts for each judgment, param_2 holding the number of non-freeze steps in the chart, and param_3 holding the number of freeze steps in the chart).

It does leave me to wonder: Why didn't they just calculate the max earned DP when the stage began / store it in RAM? I mean, once the stepchart is loaded, the number of non-freeze steps, and the number of freeze steps doesn't change (and the multipliers are constants hardcoded in the game ROM anyways).

Actually, that's another question I have ... why if they are getting the max DP earned do they go about multiplying (non-freeze-steps * perfect_multiplier), but use a 2nd definition of the OK multiplier for calculating the max freeze step DP, rather than just using the existing one? This multiplier is in the game ROM twice.


ER OK, 3rd quandry that comes to mind: What are these other 3 things in the array that are multiplied together ( param_1[5]+ a value at 0x26D684; param_1[8] + a value at 0x26D694; param_1[9] + a value at 0x26D698 From what I see, in a normal stage, at least, those elements are all 0'd out (the values in array, and the values at 0x26D684, 0x26D694, & 0x26D698 that said values are multiplied by, I mean)

_______________________________________________________________________________________________________________________________

Began putting in pages for DDR data structures onto the GitHub I set up (Thanks to Root760's debugging data extraction efforts! ):
https://github.com/travelsonic/Dance-Dance-Revolution-Game-Engine/tree/master/DDRMAX%20ENGINE/Data%20Structures

Right now, it's mostly just structure definitions (aside from music_info, for which I began the process of flushing out a detailed explanation for each struct member data field), but I will - like with the music_info struct page, work to flush out information about each member data field of each data structure.

If anyone has any corrections for the structure definitions provided on each page, definitely let me know, as accuracy matters to me when it comes to this information, and any information I make public on REing DDR games.
_______________________________________________________________________________________________________________________________
So apparently a month and a day ago, a prototype of Dancing Stage Fusion was dumped by Hidden-Palace.org

And, according to TCRF, the FreeZe! graphic that went unused in prior versions was actually translated into French, German, Italian, and spanish:





Huh. Interesting.

I think I just re-enabled that FreeZe! graphic in MAX2!

Please tell me I actually did it.... holy crap!

System 573 emulation was recently improved in MAME thanks to Windy Fairy (Github, Twitter). Lately it seems that they've been doing some hacking on DDR Extreme arcade.

In particular, they found some leftover code for Solo mode, and wrote out cheats to enable it in 5th, MAX, MAX2 and Extreme. 6-panel can also be enabled, but it seems that the arrows show up in the wrong place.

Also, they've hacked the game's autoplay to hit all Marvelouses, after some effort:

Dude, that's fucking sick!

You know, call me crazy, but between finding the 5thMIX song select BPM font/hud graphic (which I added on the TCRF page recently), between these awesome dudes finding SOLO mode leftover in 5th/max/max2/extreme, and whatnot, I think it actually gives legitimacy to this screenshot from a prototype of DDRMAX AC:

Which many here, in another thread, dismiss as a mere mockup. I mean, I had my doubts about it being a mockup before - between leftovers, and old graphics being used as placeholders not being too odd in game dev, from what I saw in the development of other games like Sonic the Hedgehog ... same with successive games using and modifying an existing engine (CS DDR games using code from AC mixes, for instance - and, to go back to Sonic for a second, Sonic the Hedgehog 2 being built off of Sonic the Hedgehog 1, Sonic the Hedgehog 3 being built off of Sonic the Hedgehog 2, and so on), and the like.

Which makes me wonder what other leftovers can be found in previous titles.

IMO, this screenshot from the development of DDR EXTREME AC proves the legitimacy of the above MAX AC prototype screenshot in so far as that they'd use assets from previous mixes. Look at those garbled MAX2 graphics, and all those ABSOLUTE slots. 😂😂😂😂😂

Seeing all of these findings made me wonder something, is it possible to force the game to run at 480p all the time? I know it lowers the resolution to 240p during gameplay but I wonder if there's a way to make it run at that resolution? Or even run it at 60fps through overclocking?

---

Not only that, but the dude also found leftover source code from earlier builds of DanceDanceRevolution4thMIX (in 4thMIX itself, ofc)


Hm, that is an interesting enigma. Definitely worth looking into.

There's not much you can do. The gameplay graphics are made for 320x240.
They were redone for the PS2 games (where gameplay runs at 640x480)

From looking at the leftover code fragments in 4thMIX, I realized that I'm gonna have to restructure my entire github repository AND my initial post on this thread - as it became clear that what I dubbed the "MAX engine" really is much older (though IDK if it goes back to 4thMIX, or even earlier - though the latter is absolutely possible). Variable names, of data types whose definitions could be ascertained from Root670's debugging data, all present (down to specific member names, and types).

So apparently, the fact that the music_info structures have entries that reference things like the title screen, how to play instruction screen, name entry screen, etc, is no accident - and they actually DO something.

Even the operator menu Sound Scale Test has a music_info struct, and you CAN change what is played from the chime to game music.

Because 2ndMIX and back was all analog audio, the indexes for what audio could be chosen could include the full BGM tracks for each song. I suspect that changed in 3rdMIX onwards BECAUSE of the use of mp3 encoding for the song BGMs.



Welp, I was WRONG - EVEN IN Digital 573 mixes, the full song tracks seem to be index in such a way where you can make the Sound Scale Check play full song BGMs!

So I was wrong - the playing of full BGMs through the Song Scale Check is doable in system573 Digital mixes too!

Here is it being done in Dancing Stage EuroMIX 2



the g_game_w structure which holds/tracks game information (player score, scoring, combo, diet info, relevant game flags, etc) is 701,844 bytes, or 701.844kb in the E3 demo of EXTREME - and 708,752 bytes, or 708.752kb in EXTREME U.S' retail release. I wonder how, or why, it gained that 6,908 bytes/6.908 kb of data.

Modifying the source code that came with PCSX2Dis to make things just a bit better - more space to make comments alongside each line, more space in the respective textboxes to allow bigger struct sizes and more struct data member definitions in a struct, bigger font size so one's eyes don't ache like hell from trying to read the text, and more than 10 breakpoints (seriously, that's not enough!) - maybe once I've gotten that done I can try to work on the stability issues it has.

Yes, PCSX2's debugger has improved a lot in recent years, but there is something I like about PCSX2Dis' UI, even if it means running an older version of PCSX2 alongside it.

So I had been looking at the DDR EXTREME 2 2005-06-222005-05-10 prototype and noticed that, unlike in the retail release, the DWARF debugging data had not been stripped.

Interestingly, I think this is the first PS2 DDR title whose debugging data leftover includes a massive amount of functions for edit mode, and handling SSQ format data (at least in the context of edit mode) - which is actually, IMO, rather monumental for ANY REing effort of Ps2 DDR titles.

Dwarf2CPP has been rather good at getting the data structures out of the DWARF data, along with the function declarations ... putting that stuff into GHidra will absolutely go a long way (even if in the context of edit mode)



STUPID QUESTION: why would an address be passed as a void pointer? Is it DWARF2CPP messing up with the parameters, or was it actually done that way on purpose? I'm so confused. (been a hectic while since I looked into any of this stuff)

Huh, the only context I've ever seen void* is when we used it as a sort of pointer to any type of data that then we'd have to parse to see which type it really was, but the context in which we used that trick doesn't seem to apply here as it seems to be expecting a concrete thing as opposed to a pointer to data of unknown type

Same here - and it doesn't seem to match up with the coding styling I've observed from looking at the decoded DWARF debugging data from other DDR PS2 titles, and from looking at the PSX BM 5thMIX source code) in terms of how they handle passing addresses... then again, there ARE things D2CPP doesn't seem to do - like preserve variables and function parameters being declared with signed explicitly (signed int, signed short, etc instead of int, short, etc) and so on and so forth.

IF I can get an install of MetroWerks CodeWarrior (the one from the Internet Archive) installed and working, maybe I can run Root670's DWARF debugging data script to get a readout and see if this was accurate, or a foul up on Dwarf2CPP's part.

(Yes, I am aware that these mixes were coded in C, but IDK if that matters much)

Looking at debugging data for other functions that handle memory addresses, it seems that in all cases the addresses are passed as unsigned ints.... maybe Dwarf2cpp fucked up?

OK I am an idiot, looked more carefully and apparently it is something that is done, passing an address as a void ptr (at least in the BM 5th Source)

I just made a quick, probably very rough-around-the-edges, outline if you will of how the dance_level (your letter grade) is calculated

OK, so ... I now understand why the PERFECTs DP, and OKs DP multiplier multiplier are repeated in the game:

In calculating the percentage used to calculate your dance_level, it pulls from the data structure g_each_w where the song's total_notes - the total non-freeze steps, and total_freez - the total number of freeze steps, are stored, in order to calculate the maximum possible DP that a player can earn.

It multiplies total_notes by its respective multiplier, adds that to the product of total_freez * its respective multiplier.

But it makes me wonder, why not just use the existing multiplier constants for PERFECTs and OKs?

Does anyone how to convert a SM to an SSQ or what program to use to do so?

---

Please help me out Wan, I'm feeling like a total derp-ass... searching through the GAME.DAT for multiple games (MAX AC, MAX2 AC, EXTREME mainly), I've noticed multiple PSX-EXE headers, which point in the GAME.DAT is the actual game's aout.exe? (And why are there multiple headers at different points in the file?)

(Also, anyone got a decent tool for converting .TOC to .CUE? If I use chdman to convert some game CHDs (1st and 2nd MIX for instance), there are all sorts of errors that result in WinCDEmu being unable to mount the resulting BIN/CUE outputs, so I thought I'd extract the CHD data as a BIN/TOC combo and convert the TOC to CUE... as god do I REALLY want to dig into the various versions of 1stMIX, and 2ndMIX.

OK never mind on the executable question - I found it was the latter header that belonged to the executable proper it seemed (just searched for the DP multipliers in the GAME.DAT and did a backwards search from that physical address, looking for the PSX-EXE text, truncated the bytes before where the header was found, and now IDA shows me its disassembly of the game proper.

Converting the SSQ to SM and opening it in ArrowVortex, it's this arrow (the position being confirmed in the status bar):


Just curious how ssq files get converted to sm.
mean much more accurate data across the board for simfiles, and general preservation.

---