Re: Feature in planning stages: Sands of Time

[BLuRry <brendan.robert@gmail.com>]

On Monday, December 10, 2012 11:32:07 AM UTC-6, D Finnigan wrote:
> Sounds like a good idea to add checkpointing.
> 
> 
> 
> Here are some ideas after reading your notes:
> 
> 
> 
> - Aren't your disk writes atomic? Then you can make your checkpoint only
> 
> after a write is completed, and never in-between.

That is do-able.  Floppy disk changes are tracked per-track and a separate thread updates the disk after one second.  If any additional writes occur, the thread resets its time and waits another second.  In this manner, I can tell if there are pending writes.  I can also implement mechanisms to reverse writes to floppy disks later on, such that you could undelete something.  Or if playing an RPG that updates the disk the moment you died, you could still turn back the clock and thumb your nose at the grim reaper.

> 
> - Concerned about too many checkpoints stored in the JVM heap? Why not use
> LRU and discard the oldest checkpoints, or allow the user to write some of
> the oldest ones to disk.
> 

Not sure if writing checkpoints to disk (automatically) is worth it.  LRU is the way to go, but I want the checkpoints to be deltas and not full copies.  Since the memory model is based on 256-byte pages, it is possible to just copy the changed pages and not have to invent something more complicated (like a full delta change tracker).

> - Allow automatic checkpointing after a certain interval, say every 5
> seconds, or every minute.

The plan is 30 times a second.  Maybe 15.  I'll make it configurable.  Capturing less frequently would let you capture a wider expanse of time.
> 
> - It seems like the amount of state you'd need to keep track of is
> 
> essentially just: CPU and flags, RAM, soft-switches, and peripheral cards.
> 
> If these are all Java objects, they should be fairly simple to serialize for
> 
> storage.
> 

Serialization is possible, but it is bulky.  I already have a mechanism for managing configuration, and the configuration itself is serializable.  As for state information, the goal is to keep track of all objects and fields that correspond to necessary state management so that in the runtime I'm not performing a lot of introspection.  Most cards don't have much to track.  For example, mouse coordinates might be worth tracking but super-serial input might not.  Disk II state information is necessary to track, but Mass-storage is block-driven and therefore a stateless controller.  I might one day add support for stateful sound capture so that you hear sound play backwards, but right now I'm not considering it because it would be a real pain to implement.

When the computer is reconfigured (which happens at start, and also any time you change any configuration) then I can use that hook to scan the object model of the emulator looking for @Stateful objects and object members.  I take a similar approach for configuration so the good news is that I won't have to re-invent the wheel to write the @Stateful object scanner.

Once I identify the @Stateful items, I will store them in a set so they can be more quickly enumerated as needed.  Whenever a state is captured, the computer is paused and all stateful items will be recorded.  I have to come up with a way to indicate ram that has not changed.  Probably an array of booleans or something.  Anyway, the state will be captured in a hashmap so that it can be serialized to disk if needed.

The contents of the framebuffer are also @Stateful so as you rewind time you'll see things move backwards.  I might make an interface that has a scrollbar so you can scrub forward/backward.  I will have to think about it... :-)

> 
> 
> -- 
> 
> ]DF$
> 
> Apple II Book: http://macgui.com/newa2guide/
> 
> Apple II Archive: http://macgui.com/vault/
> 
> Apple II Web & Blog hosting: http://a2hq.com/