ZSNES board

May well be replicating graphic packs, although, it won't be depending on them anymore. If the cache were deleted, it would just redecompress the data again. The cache would just be a big time speed boost.

Compressor code is completely BIT-PERFECT.

Okay, I now totally automated the process, and ran it against the same raw gfx pack data as I ran the decompressor code against, and I declare the compressor to be absolutely BIT-PERFECT, for Mode 2 data. Now just mode 1 and mode 0 to be written for. (how long will that take?)

Tested one single raw entry, and the compressor seems to be matching byte for byte exactly to the original data. The specific is raw entry 000008/00, 32768 bytes uncompressed, 14269 bytes compressed. I may just automate this testing to see how bit-perfect the compressor is.

Mode 1 has been cracked now.

IIRC, the BRK opcode is basically a soft interrupt. The Vector for it, is located in the same place as one of the TCall vectors, (can't remember which one though). Returning, requires an RTI, since it pushes not only the Return address, but the PSW as well.

Also, SPC2ROM loads its own program inside the SPC file in unused space to be executed before the song you want to play. This way you can restore the register values. If you can somehow make that part of the main program loop, you'd be set. You transfer all control to the SPC. Unless you modify tha...

Not only that, some of that data that is defined, will actually be code executed in wram, or the spc700, and there is no reliable way to tell, except to follow a disassembly by hand, and manually add in to the code/data map, and even then, for wram code, you have to specify region, then get the emul...