fixed corner case caused by RSYNC being triggered on the first scanline
fixed some presentational issues (Nan and Inf floats) caused by running
an ejected ROM
possible to switch from playmode to debugger when ROM selector is active
in all situations.
the thumbnailer does the actual emulation in a new goroutine so there's
no lag here but it's necessary to PushRawEvent() so that
rewind.GetState() doesn't race
rewind.String() now produces correct summary in all instances
rewind reset on frequency change (in addition to the existing rule about
number of states). timeline no longer reset on this type of rewind
reset.
adjust coordinates function uses the correct zero value for color
clocks. the error could be seen on STEP BACK FRAME when the execution
would stop near clock 0 rathre than clock -68
execution states are recorded and appended to the history every frame
regardless of the snapshot frequency schedule. they continue to be
trimmed in the usual way. on emulation halt meanwhile, the current
coordinates are recorded which is more flexible and allows for video
cycle granularity.
introduced PlumbFromDifferentEmulation interface. the ARM emulation
doesn't like being moved between emulation instances so the ARM is
recreated when plumbing a state that originated in a different
emulation. not all mappers need to implement this interface.
two issues here: (1) bug in deciding which half of the circular array to
search; (2) how we counted the period between snapshots was wrong. it is
now just a straight "current frame number % snapshot frequency"
rewind.SetComparison() makes a new snapshot, rather than using the
current splice point. the old method worked okay for a snapshot
frequency of one but not so well for anything larger
reoved GotoCoords() tempFrame in anticipation of a more flexible system.
GotoCoords() when snapshot frequency greater than one will be noticeably
slower in the meantime
new counter package added (sub-package of reflection)
this new counting method is fast enough to be run while in playmode,
which means that historical timeline information is immediately
available in the debugger
*.windowSize and *.windowPos preference values replaced with single *.windowGeometry value
prefs package type now have a pre-hook (called before new value is set).
existing hook/callback clarified to be a post-hook (called after new
value is set).
prefs generic type now handles prefs.GenericGetValueUndefined to
indicate that the value cannot be ascertained at this time (the prefs
package should use the most recent previous value instead)
switch between debugger and playmode with F6 or backtick key
pakage debugger remains for now but it will be renamed to emulator or
something like that. playmode package removed.
commandline options for both debugger and playmode are the same
currently, with some playmode features being lost (temporarily)
clarfied that the use of the Emulation type is for passive monitoring of
the underlying emulation. rewind package now monitors the emulation
passively.
Instruction boundaries can be inferred by the debugging input loop,
which is the only place it is requred. reworked GetAdjustedCoords() in
the televsion package (now called AdjCoords()) to cope with this.
ReqState() is totally replaced by GetCoords()
makes it more convenient/clearer when working with all three coordinate
values (frame, scanline and clock)
changed all packages to GetCoords() where appropriate
renamed "last execution" window to "coprocessor disassembly" where
the actual name of the coprocessor is used
coproc disassembly window now shows an enable and a disable button. if
the emulation is paused the previous two frames of the emulation will be
rerun in order to generate a disassembly
coprocessor disassembly and last execution are shown in tabs. if
disassembly is disabled then the last execution tab will show nothing
but the disassembly tab will show what we have, with a note that it is
not bing udpated
legitimate errors include reading cartridge address with no cartridge
inserted. rewind will now check for CPU/Result state before logging and
returning before any recording has taken place
BRK instruction consumes two bytes but records only one. when
video-stepping over a BRK instruction this caused an error because the
adjustment to the number of bytes read value was done too late
if the mouse is over an area of the screen that has no underlying state,
the coordinates are constrained to the area that does have an underlying
state. this feels more natural.
this allows the rewind system to save adhoc frames if necessary. the
functionality was there before we started to refactor the way the
catchup loop was implemented.
sometimes a television frame will be "shorter" than previous frames.
previously the television only sent the signals for the shorter frame,
this could play havoc with PixelRenderers under certain circumstances;
particularly visible under rewind conditions.
this was noticed when rewinding a moviecart over frames between the
attract screen and the beginning of the movie.
to fix this. the television now sends null signals (video black) for
every required signal in the current frame (whatever size that might be)
there doesn't seem to be any performance penalty
this simplifies the sdlimgui/screen type in addition to the NewFrame()
and Resize() functions in the PixelRenderer interface
will allow better overview and summarising of television performance
playscreen F7 window shows "total scanlines" rather than "visible
scanlines"
still not fully working in all situations. not all tia controls are
enabled to use it. funtionality disabled for now
see win_tia_deeppoke.go to enable it
SearchRegisterWrite() now correctly leaves the found state in a usable
state at a CPU instruction boundary
DeepPoke runs from found ultimate found state to the "current" state
updated README
implemented deep-poking of playfield values. there may be pathological
instances where this does not work. not all addressing modes have been
added to the deep-poke function.
to be clear, non-playfield graphic elements (player, missile, ball) have
not had this feature added yet.
will probably also require some way of feeding back information, making
it clear what has actually happened or actually changed. changing of an
immediate value should probably trigger a redisassembly.
TIA sub-components no longer pass values around in return values. it
turns out to be far cheaper computationally to store calculated values
in the TIA sub-types and retrieving them as required.
on my machine this turns out to be around 2fps saving
