Save/load state - Githubissues

fengb commented 4 years ago

Every other emulator does this. Why can't we?

Questions:

Which format? This should probably be a compressed binary, but there's still a lot to choose from:
```
cpu: [mode, interrupt_master, registers]
mmu: [0x8000-0xffff, mbc state]
video: [screen, caches?]
inputs: *
timer: *
```
- manual
- ~json~ probably not due to needing binary data
- protobuf
- cap'n'proto
What memory needs to be copied? At the minimum registers, MMU, and possibly the screen, but we might need a bunch of other internal states. Should we simply copy everything?
Should we consider rewind semantics?

fengb commented 4 years ago

Format ideas:

Custom binary dump. Let's do a simple "size: u16 - payload: []u8 — size: u16 - payload: []u8" for now. This is intentionally not standardized because Zig doesn't have a prebuilt one and I don't want to build one (yet)
Header magic number:
- 0xDC — busts ascii (high bit) + unicode (0xDC00 - 0xDC7F is illegal as first char for both UTF8 and UTF16)
- 0x00 — version (increment this when the format changes)
- 0x46 — F
- 0x44 — D
- the following are shamelessly stolen from PNG
- 0x0D — CR
- 0x0A — LF (DOS line)
- 0x1A — DOS EOF
- 0x0A — LF (Unix line)
Cart checksum — copy of cartridge cart[0x134..][0..0x18] (24 bytes)
~~Footer trailing checksum~~ decided this is out of scope:
- we have some simple redundancies already
- adds a fair bit of complexity
- compression will have its own (possibly better) checksum

fengb commented 4 years ago

Note: first pass will not do compression because Zig doesn't have a standard implementation yet.

fengb commented 4 years ago

Still iterating super quickly so maybe we shouldn't expose this to the frontend yet.

fengb / fundude