Yeah i forgot about the 1m limit and you have mentioned again.Sorry 
.
But i guess the division in blocks should be fine.
We can limit the compression of course to only roms that have size >= 1024K(-->or 512K) and simply divide large roms by 512K(-->or 256K).
The buffer can be padded like this :
-----non compressed area-----
[save type]
[block count] --->0 = uncompressed
[rom length]
[cheat count]
-----compressed area-----
[cheat adress / code]
[blocks]
-----end-----------
We should compress all files, not just big ones. If a rom is smaller than the block size, that's fine! It just means it'll be compressed/decompressed all at once. When you compress something in blocks, it just means that if (for example) it's 1MB and the block size is 256KB, that you compress the first 256KB, write that data, compress the next 256KB, write that data, compress the next 256KB, write that data, then compress the last 256KB and write that data.
I'd say leave the cheat header uncompressed as it'll be small anyway. Then follow that with the compressed size of the following block (zero if done), followed by the compressed data. Something like that
By the way , are you going to write the decoder to raw 68K code? If yes then maybe you should pick an easy and effective algorithm
Yes, as I mentioned before, the position independence sort of forces this to assembly, so the decompression code will be assembly too. I was thinking of something like lzh.
