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
projects / s573compress / commitdiff