Current implementation does savestates by telling Hatari to write to a file, then immediately loading that file to pass to RetroArch to make its own savestate.
This bypasses the unnecessary file and just creates the savestate directly in memory.
Also disabled gzip compression on the savestates, which was violating RetroArch's condition that reported savestate size should never increase in size, which with compression can easily happen as the game proceeds and you keep saving. (RetroArch does its own compression of savestates written to disk already, of course, so it was pointless to compress them twice anyway.)
Finally, added a small header with a version number, so that if libretro implementation needs to store any of its own information in the savestate block, there is a way to add new data safely and backward compatibly. (With some relevant stuff serialized, we no longer crash when savestating to/from the hatari GUI.)
Current implementation does savestates by telling Hatari to write to a file, then immediately loading that file to pass to RetroArch to make its own savestate.
This bypasses the unnecessary file and just creates the savestate directly in memory.
Also disabled gzip compression on the savestates, which was violating RetroArch's condition that reported savestate size should never increase in size, which with compression can easily happen as the game proceeds and you keep saving. (RetroArch does its own compression of savestates written to disk already, of course, so it was pointless to compress them twice anyway.)
Finally, added a small header with a version number, so that if libretro implementation needs to store any of its own information in the savestate block, there is a way to add new data safely and backward compatibly. (With some relevant stuff serialized, we no longer crash when savestating to/from the hatari GUI.)
Also includes: #65 / #64