From: Steinar H. Gunderson Date: Sat, 7 Dec 2019 12:52:25 +0000 (+0100) Subject: Rewrite the limitations section. X-Git-Url: https://git.sesse.net/?a=commitdiff_plain;h=0c029360ee7a1843c86cc73adc98bf9a6d01b293;p=s573compress Rewrite the limitations section. --- diff --git a/README b/README index dcf929e..3035606 100644 --- a/README +++ b/README @@ -83,33 +83,79 @@ something like Limits ====== -How many songs can you add? There are certainly limitations, but nobody knows -exactly where the true ceiling lies: +How many songs can you have? It appears that without fairly large binary +modifications, the effective limit in the EXTREME engine is 248. Let's look +through the list of known limits: - - An ISO9660 (CD-ROM) directory can not be larger than 0x6000 bytes, + - An ISO9660 (CD-ROM) directory can not be larger than 0x6000 bytes (24 kB), or the files past that will not be found (this is of course a limitation in Konami's code, not the standard). /DAT/ is very close to this limit, - but you can get around it by putting shorts somewhere else, such as flash - or a second CD-ROM directory (the latter requires patching aout.exe, - or perhaps being creative with naming). + but there's a little trick here: Nothing stops you from using a slash + within the filename in mp3_tab.bin, so that if you use a filename + such as e.g. “M2/BBBBB” (instead of the default “M6XBBBBB”), the game will + look in /DAT/M2/BBBBB.DAT (and /DAT/M2/ will have a separate 0x6000 limit, + so you can put lots of files in there). Optionally, of course, you can put + shorts in flash, or modify the unused third path in aout.exe (by default + c:/tmp/). - There seems to be a limit of 0x130000 bytes (19 922 245), give or take a little, for the sum of all menu music (E*.DAT), shorts (S*.DAT) and single biggest song (biggest M*.DAT in bytes). If you go above this limit, only menu music will be loaded. This is probably since the I/O board - has 24 MB RAM. You can get around this by simply marking shorts as - not loaded on startup, although it will probably cause lag in the - songwheel. - - - There is a limit of 500 entries in mp3_tab.bin. You can increase this - somewhat by patching (the instruction is at 0x800af604), but it's not - clear by how much until you start overwriting neighboring data and - corrupting memory. - - - Finally, it seems there's a limit of 256 songs, including the system - sounds (of which there are nine), so you can only have 247 in the - songwheel before they get truncated (possibly ordered by song_number). - This one has not been investigated thoroughly yet. + has 24 MB RAM. (There is also a limitation of 300 preloaded files, since + there's a fixed array that holds them.) You can get around this by simply + marking shorts as not loaded on startup, although it will probably cause + lag in the songwheel. + + - There is a limit of 500 entries in mp3_tab.bin (loaded at 0x801cc948); + 10 or 11 are used for the system, depending on whether you include the + trailing zero entry. This would indicate you could only have 244 or 245 + songs, but you can increase this somewhat by patching (the instruction + is at 0x800af604). The dword immediately after the array (address 0x801cf828) + is used for some status (seems to be 0xff000003), which means that this + entry will be corrupted, but after that, it _seems_ to be clear up to + 0x801cfedc, indicating that there would be room for 570 or 571 entries, + ie., 279 or 280 songs. Anything more than this, and one would need to + relocate the MP3 table. + + - Finally, after loading, the songs in the music database are indexed + mostly by song_number (starting from 1 and going upwards; create_mdb.py + will re-sort them by title for you). A number of places test this index + against a limit of 247, 248 or 249; for instance, a common utility function + (at 0x800a886c) will simply refuse to return the pointer to any song number + above 248. This limit is hard-coded in a number of places; an incomplete + list of instructions that seem to be relevant (checking such limits or + setting end points, sometimes multiplied by four or plus/minus 1) include + + 0x800698a0, 0x8007f084, 0x8007f090, 0x8007f224, 0x8007f298, 0x8007f2ac, + 0x8007f478, 0x80081868, 0x80082538, 0x80087094, 0x800873a8, 0x80089208, + 0x80089ad8, 0x80089b94, 0x8008becc, 0x8008c128, 0x8008def0, 0x8008e88c, + 0x8008ee74, 0x800a79d4, 0x800a79e0, 0x800a7a24, 0x800a7dbc, 0x800a7fcc, + 0x800a886c, 0x800a94d0, 0x800ba5a8 + + Note in particular that the function starting at 0x8007ebc4 (which seems to + be sorting and building the song wheel) stores sort keys for each song in + an array that is 250 entries long, so you will easily overrun the stack + if you increase the limits by too much. There are also some special song_number + values; e.g., one of the high 0xF* values seems to be the roulette entry. + + +The latter barrier seems to be the hardest one to change. For those who wish to +experiment with moving data to other places, these parts of the RAM seem to be +unused (based on simply dumping the memory and looking for zeros, then setting +watchpoints in the MAME debugger): + + 0x800f5b70 57 kB + 0x80109df0 57 kB + 0x8012abe0 96 kB + 0x80210010 159 kB + 0x802e23e0 119 kB + 0x80368930 128 kB + 0x803e7cc0 75 kB + +These would all be reasonable places to try to relocate data to. The bootloader +(loaded near the top of the RAM) also seems to be unused after the game has +booted. License