I think originally, after the debugging loop refactor, I was planning on
implementing this as STEP OVER and allowing a regular STEP (even in
instruction quantum) to advance to the next clock. but it proved to be
annoying and confusing
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.
this means that playmode now uses the lazy system. it's only loading
what it needs so as not to use too much memory. the good news is that it
doesn't seem to take any significant CPU time
tracker reset on debugger/emulation reset
piano keys window is now part of the tracker window
updated README indicating new hotkey
added -fpscap to emulate() function (used by both playmode and the
debugger) making it a good alternative to the -display option
getting performance mode to work with an increasingly complex
gui-emulation communication just isn't worth it. it would make the code
too complex.
this paves the way for removing the Emulation interface and using a
straight-forward Emulation type, which will be current Debugger type
renamd. the Debugger type is currently handling the playmode, performing
well and allowing tighter integration of the debugger and playmode.
added terminal.UserQuit sentinal error to better handle quit events.
future versions should probably remove 'running' variable and rely on
this error and filter accordingly
double-click in ROM selector loads the cartridge. cartridgine
information below thumbnail. save ROM selection to preferences.
automatically select previous ROM on next session.
although playmode always stops on an instruction boundary, the
RewindNFrames() function left the debugger's input loop in the video
cycle input. this is okay but it led to instruction information saying,
for example, "3 of 3 cycles" instead of "3 cycles". this was confusing
and misleading
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.
resetting the CPU when a new cartridge was inserted left the Defn field
of the LastResult type in a nil state. the CPU now checks for nil and
returns a sentinal error. error is caught in Start() function and
discarded
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
two reasons:
1) to keep performance acceptable playmode only checks halting
conditions on a CPU instruction boundary. however a CLK changes many
times during an instruction meaning it will never match.
2) a CLK breakpoint will always match within 228 emulation ticks so
there is no point entering playmode at all because it will definitely
drop back to the debugger (within microseconds)
added a range change check to SCANLINE and CLK targets in
breakpoints.parseCommand(). we know what the possible values are for
these targets so we can be helpful and inform the user the some values
will never match
this prevents thumbsticks from interfering with rewind/pause when it is
in the deadzone but not perfectly centered
correct icon is shown when rewind reaches beginning of buffer. was
showing pause ||. now showing the rewind/pause |<<
this allows more elegant handling of unpause on controller input - no
unpause unless the controller is plugged in. ie. paddle input won't
cause the game to unpause unless the paddle controller is "plugged in"
added gamepad bumper (rewind in playmode) and guide button
(debugger/playmode switcher)
Initialising can be used for cartridge loading / hotloading but
EmulatorStart is the setup state of the emulator and gui. it is useful
for preventing some gui operations while emulator is starting up
reflection resetting on NewFrame() *before* NewFrame() in rewind has
completed. rewind timeline relies on reflection
I managed to ignore a comment stipulating this requirement during the
refactor
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)
halting check performance efficiency
less string manipulation in disassembly package. disassembly entry.Label
performance efficiency
reflection gatherer performance efficiency
overlay plotting efficiency. small performance improvement in overlay
plotting. color lookup table is now a straight array not a map
SDL polling efficiency for debug mode
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
stepping back previously was "correct" but was confusing when looking at
the disassembly (rather than the debugging screen)
introduced the concept of a catchupQuantum. distinct from the existing
stepQuantum (renamed from 'quantum') but having the same underlying type
the catchupQuantum makes sure that the inputloop is left in the correct
state. in other words in an 'isVideoStep' version so of inputLoop(), or
not depending on how the catchup was initiated
halting conditions are checked every video-cycle. this reverts a
temporary change made in a73dcae6dcc61e4ced03f23fe4df504cb966fb36
renamed files in debugger package for clarity
stepping by video does not now check for halting conditions. in some
cases halting on a target is confusing. for example break PC will break
too early if checked every video cycle. we could perhaps reintroduce it
but only when targets are aware of the current state of the machine
(ie. mid-CPU instruction or not)
similarly, halt on video-step will no longer decode the next instruction
at the current PC. the current PC will be in a misleading state between
CPU instruction boundaries
STEP OVER button. not finished yet just a placeholder really
