Not many games actually use malloc. Most of the times you'll see custom allocation methods (both dynamic and static), so it's kinda hard to find out how much memory is available for extra data. A few games, like mine, use the malloc3 set from the SDK, but don't expect to count too much on this one.
Just tried Dewprism. I appended 90kb extra bytes after a file and it was loaded without a problem. So hopefully I can remove the whole bios font thing into RAM. Well, anyway, it needs a lot of test among different maps...
Removing the BIOS font mapping is just a matter of hacking "KromToAddr" (and similar functions) to force it using actual RAM instead of BIOS ROM. Or you can just crush it all and rewrite the whole upscale+rendering routines, which will look a lot better in the end and should give you much more control.
Yeah, I checked the output result and converted it to RAM address if certain condition was met (the laziest way I guess). Just trying to avoid bios hacking.
Another question, is RAM region around 8000b0bc safe to use? It is the starting position of the psx exe, followed by a lot of zeros.
Yes, it is safe to use, but you have to write code/data/whatever you need there AFTER the game is booted. In other words, if you store something there directly from the EXE it's not gonna work on real hardware and it will have 100% possibilities of freezing on a PS2. Instead, memcpy makes it work like a charm.
If the BSS segment is big enough you can store your additional code there and then copy it to the desidered destination before the BSS reset routine is executed. I did that with the mdec subtitles for FFVII International and with several intros.