Well, I give up. Even after a lot of script optimization, there is simply no way I can get the Samurai Pizza Cats scripts to fit back in the game. Using a combination of Klarth's ScriptCrunch and my own frequency analysis of the script (meaning: Choosing large word sections or phrases that repeat a lot and using them as substrings), I can't get the script any smaller than this:

Script size 9122
Bytes Inserted 7255 (Space the game originally used - the other stuff is substrings and substring pointer data.)
Script Overflowed 1867
Space Remaining 0

The -original- English script was around 12k bytes.

The big problem with this is that it uses LOTS of two byte codes to control text speed and text pauses. And these byte codes mess up any sort of compression I try to use. Bongo` tried his hand at coding a compression routine for the text, but he said that these byte codes made it very difficult for anything he could make to lower the space used. This was a very long time ago, though.

So the only solution I can think of is to use some empty space elsewhere in the ROM and store the final 1.8k of the script there, somehow tricking the game into loading that particular data bank instead of the normal one. Of course, I know nothing about programming the NES so I'm asking for help with that. This is the last thing I need to do before finishing the game. (Well, that and the title screens, but I can handle those.)

So uh. Yeah. Is such a feat possible? Or do I have to doom this project to cancelation? Can anyone please help me out with this?

This is an MMC3 game we're talking about.

IIRC, one of $A000-BFFF or $C000-DFFF is fixed, depending on register state, and $E000-FFFF is hard-wired.
(thus bankswapping is LDA #$06 : STA $8000 : LDA #$bank_number : STA $8001 to swap into $8000-9FFF, or LDA #$07: (same) for the other swappable bank. Though you may have to consider the possibility of NMI/IRQ occuring during the process. Then again, the game probably has a bankswap routine that does that.)

It might be possible with ASM hacking.
Depending on the available space in other banks, it might be necessary to expand the ROM, depending on if there is free space in the fixed bank (there's a block of zeroes near the end of the ROM).

If the script routine is in the fixed bank it might be easier. You (well, somebody, since I don't think Kit knows ASM) could find where the instruction where the pointer table is read, and make it jump to a routine to bankswap if it detects a pointer to the bankswap region of the script. And then swap back if necessary at the end.

If the script routine is in a swappable bank, then it's much harder. At that point, it may be necessary to expand the ROM, and swap to expanded space, read a character, then swap back. Having two-byte control codes doesn't sound like it'd be fun either, since the routine for each code would probably have to be modified.

The control codes are like this:

$F7XX - Text speed. Once F7 is read, the next byte determines the text speed.
$FAXX - Pause. Once FA is read, the next byte determines the length of the pause.
$FD - Begin animation (when characters are talking)
$FE - End animation (ditto)

That's pretty much it when it comes to control codes.

Because the game has cutscenes (like Ninja Gaiden - hell the game IS a Ninja Gaiden clone) and there's no way to change the length of each particular section. The game just advances to the next scene even if the text isn't done being on the screen. So I have to add pauses and change the speed of the text so it can be read, scene after scene.

Someone already changed the game so it uses one byte codes instead of two to call the substrings the game uses to save space. I don't remember who, but it should be in my email.

Here's another solution you could try:

Assuming you can fit the excess script in another bank, you could write a little routine to copy it all into SRAM ($6000-$7FFF) on startup.  Then the data will always be available to you regardless of your current bank.  Update the relevant pointers to point to this data and you're done.  This is assuming your game doesn't already use SRAM, or if it does it has about a fourth of it unused (SRAM is about 8000 bytes total).

SRAM/WRAM, same thing (difference is whether there's a battery). Does the game use $6000-7FFF?
Easiest way to check is to use FCEUX and look at that area in the hex editor mid-game.

It would be really good to see the table though it may be ugly, just to see what ranges you use most (bytewise). Only in that way an effective solution can be built (if you have to keep the space constraint that is)

cYa,

Tauwasser

I know a compression scheme that might be feasible, however, it would involve some ordering in your table as well as asm hacking skills and some ram to work with.

Basically, everything  (including squishy stuff, control codes etc.) will have to be ordered according to usage frequency. Then you can actually encode all strings as a nifty bit stream that is devised to save enough space. It's from Pokemon RGBY, too I only have the docu up in German tho.

Basically, it would involve blanking out half of each byte (lower half first, then upper half, or vice versa). Then compressing the stuff into two streams. When the rom wants a string, it gets the data, decompresses two streams to ram, or's the streams and points the text routine to that or'd data. It sound much more complicated than it really is, but it should save a lot of space (I just tried with your test sentence by hand with my own special table) and it looked pretty good - though only one sample cannot make a good ratio prediction.

cYa,

Tauwasser

Pretty ingenious, actually. It’s almost like swapping out smaller dictionaries on the fly.