So what I've gathered so far from the wiki is that files are loaded from the ISO through addresses in SCUS 942.21. For example, all the SMD files are listed this way. (http://ffhacktics.com/wiki/Music) I'm not entirely sure what the SCUS file is even after scanning through its massive wiki page, but since it holds the PSX kernel and is also apparently used for file loading, my guess is that it's the entry point for the game and its contents are always in RAM, sort of a "Main" file.
I don't know what magic links the SCUS addresses to the SMD files themselves. I can see here (http://ffhacktics.com/wiki/SOUND/) that all the SMD files are in contiguous sectors in the same folder, which seems significant, but... maybe it isn't? If I were to, say, add a new SMD file to one of the giant free spaces listed in the CD Index (http://ffhacktics.com/wiki/CD_Index), could I somehow add a pointer to that song in SCUS and play it like any other SMD file? Even if the answer is "no" (which I'm guessing it is) it'd be helpful to know which parts of my conceptual understanding are correct and which are off.
Usually, to add more of something, you just expand the table. Though in this case I'm sure you'd have to move it.
It's fairly straightforward in that those file tables are usually just the file sector offset and the file size.
Though you kinda have to edit the ISO to add files to the index to make important new files easier rather than import them directly to sectors.
The SCUS is the main PSX executable, it's specified in the ISO itself at a precise location along with its file size. It's loaded once and can't really be unloaded.
Glad I wasn't too far off. The consistent byte sizes and contiguous addresses probably should've tipped me off to it being a table--I'm still getting used to reading hex. I'm guessing that 00028acc - 00040970 in SCUS is mostly dedicated to misc tables, then, since that's the huge unlabelled block that also contains the music file table. Hard to tell what uses that space at a glance since it doesn't link to anything.
Followup questions:
- Do these file tables typically have headers? Are they contiguous to the first entry? Do they have consistent sizes? I can't think of anything a header would be needed for but I want to make sure that I'm not leaving something out...
- Is there freeable space in SCUS to shove the table off to? Amusingly this was the first result when I googled (http://ffhacktics.com/smf/index.php?topic=11010.0) and I can't decide if that's a good sign or a bad one, lol
- Is repointing to the table after moving it a really involved process, or can it mostly be automated? I'm guessing it would depend on the table...
- "Though you kinda have to edit the ISO to add files to the index to make important new files easier rather than import them directly to sectors." I'm not sure I understand this sentence... which index are you referring to? The index of the associated file table? Or does the ISO itself have an index that would need manual editing?
Sorry, that... looks like a lot more, written out. I really appreciate your help so far!
Headers? Some table with variable row length have pointer tables. Text is particularly infamous for this. World and Event Conditionals also have varying lengths and use pointer tables. This is not something that would ever be the case with tables for file access though.
The bad news is that the SCUS has very limited free space.
The good news is that, AFAIK, BATTLE.BIN and WORLD.BIN are always loaded... you can create a routine to check the new table on either file (in kanji space) based on which one is loaded, making it necessary to store the table in both files. I've done this for many of my hacks in the past... it's just the title screen that worries me, the song COULD be loaded before WORLD.BIN.
There's probably only one routine that looks at that table to load the files, so that would be pretty uninvolved. Quite a bit more to move it on two files as I suggested.
And for that last one I'm talking about files shown by your file explorer in Windows/Mac/whatever. That's a CD-ROM file index. The PSX doesn't need it at all (you can wipe it all, and your OS will think the disc is empty and the game will work just fine), but the programs we use, but with CD Mage/cdprog, they make it easier to import files into the correct sectors.
OK! So having thought about this a little further, the file table having a set number of entries isn't a deal-breaker, as long as higher sector numbers don't somehow go outside the address space; the maximum number of tracks would stay the same, but if the entries in the file table are changed then the songs can be different lengths, in different spots on the disc, and so on. That's a pretty manageable restriction compared to some of the other tables I'm looking at, haha (looking at you, Item Attributes...).
One more question assuming I'm correct so far: are songs streamed from SMDs as they play or is a song loaded into RAM all at once? If the latter, do you know how much space is allocated for it (i.e. is there an effective limit for SMD file sizes)?
The files are so small they'd have to be loaded all at once. The PSX loads by sectors, so in groups of 2048 bytes at a time into RAM. Dynamic loading is more for XA / CD audio tracks.
Sorry, I have no idea what the space allocation is for songs. It's same to assume it's at least the size of biggest song filesize, rounded up by 2048. Of course your biggest hurdle would actually be creating a new song; everything else sounds pretty trivial to me. To keep things simple, I'd vote for you to just overwrite one of the Sound Novel songs; I don't personally enjoy any of them tbh.
Aw, I like some of them... but yeah, I can make choices about what to cut.
Thanks so much! Excited to see what we can manage using the known SMD instruction set. ^^
For bonus points, the Sound Novel songs aren't used in the main game either. Anyone playing the English versions won't notice their loss.
Quote from: Nyzer on May 23, 2019, 05:05:52 pm
For bonus points, the Sound Novel songs aren't used in the main game either. Anyone playing the English versions won't notice their loss.
One is used in game. One of the ones from Diary of Nanai