Added justification comment with sources, for why MAM prefetch can
behave this way. Weirdly, this seems to apply only to MAM1 and not to
MAM2 so obviously the reason is more nuanced than the current condition.
the ARM coprocessor causes the 6507 to run NOP instructions, which
causes the PC to advance. this means that a PC break can be triggered
when the user probably doesn't want it to be.
counting and stretching each cycle as it comes, rather than stretching
groups of cycles at the end of the instruction. the old method worked
fine up to a point but too much information is lost that we need to
factor in the stretching calculations.
still not 100% accurate but closer
clarified disassembly memory model
corrected decision making in blessSequence() function
there will still be instances when executed entries won't/can't be detected statically
fixes#14
unused labels will be removed after blessing, including those added
during loading of a symbols file
blessing will end on JSR. this was preventing some blessed paths from
being detected before committal.
there were clear mistakes in the previous version. these have been
corrected
added rule to ignore decoded bytes that are obviously fill bytes from
the assembler
I based the original strategy on the symbols file created by the flappy
assembly. a new project produces a symbols file that didn't produce good
results using the assumptions I made. the new method works for both
cases.
TV frame will never resize if frame is unsynced
Play-screen FPS counter shows target frame frequency
sdlimgui playscreen: screen will not roll on first couple of non-synced
frames. the screen is tolerant of the odd rogue frame.
gui vsync options renamed to monitor sync to clarify distinction wth
emulated television VSYNC
caused by not releasing crital section lock on error. error caused by
the presence of the "ejected" cartridge. most probably caused by trying
to load a unrecognised file.
in a headless disassembly, this doesn't matter because no other
goroutine ever tries to acquire the lock but in the sdlimgui debugger,
the disassembly window tries to acquire the lock during iteration.
if VBLANK is used by the ROM then non-black pixels are used to size the
screen, otherwise we take the VBLANK as intended (while still obeying
the safe top/bottom values
Thomas Jenttzch's Elite demo is not detected automatically otherwise
moved fingerprintMnetwork() to bottom of list of detection to prevent
false positives (none known but with such a low threshold it's
possible).
