Gameboy payload This update merges CMD_OpenSRAM and CMD_CloseSRAM into the single CMD_ModifySRAMAccess. It also fixes an issue caused by calling CMD_ReloadCurrentBox in gen 2 while the vblank interrupt was still disabled.update
For some reason, the merge broke the Write Cbl Data - CART functionality in the dbg menu.
The main problem is that writing a whole sector of data and erasing a sector is too slow to do in an IRQ handler.
Fix: Move the actual flash writing process to the main loop by creating a function called handleCartIO().
The IRQ handler writes to global_memory_buffer, and the handleCartIO() copies that
data to a local write buffer while the IRQ may still add more to global_memory_buffer.
Then it modifies the IRQ handlers' offset and moves the data that was appended in between to the start of the buffer all while
the IRQ handler is still appending new bytes.
If we end up at a sector boundary, we also do the erase_sector() call.
This was tested with and without the print link and print packets debug options.
Without the print options enabled, we end up occupying about 20KB on the cartridge save. (for 1st stage only!)
Man, this bug sucked. I rate it 1 star!
This commit allows you to use the Write Cbl Data debug option and new Load Cbl Data debug option to dump a link's data to SRAM
or load it from SRAM and pretend like you got it over the link cable.
This is useful for capturing the link process on gameboy and replay + debug it later in an emulator.
text_data_table was very similar in concept to FileContainerReader.
But FileContainerReader is generally more flexible, as it allows you to split up your table into several chunks.
This takes away the worry of these files getting too big to compress.
However, we now have a maintenance duty for the text_tables file, which maps a table index to the list of chunks.
We also need to be careful about every use of FileContainerReader::getPointerToFileInDecompressionBuffer().
Using it is fine when you're dealing with a single chunk or if you're sure the file doesn't span multiple chunks.
But the moment you seek to a different chunk, any pointer obtained from getPointerToFileInDecompressionBuffer()
becomes stale as the decompression buffer gets overwritten.
Still, this function is necessary for high memory pressure situations, such as mystery_gift_builder, because we can't maintain
multiple lineBuffers there.
va args passing was broken in my initial implementation, causing garbage values to get printed whenever you try
to print an actual argument.
Moreover, I also had a bug in the PTGB_MGBA_XYZ macros.
Sorry, I should've tested it with actual arguments.
