added mam preferences to prefs window. reorganised prefs window.
removed hardware prefs from PREFS command and lazy system. the lazy
system doesn't seem to be required and it makes more sense for the PREFS
command to deal solely with debugging topics.
preferences window visible in playmode on (F8). FPS indicator now on F7
at 100000 for now but there's no reason for that number. however a cap
does seem to be required when we compare some test ROMs with real
hardware (without a cap in the emulator, the PC will run past the end of
cartridge space).
divided N and S cycles into whether the cycle is while a pc address or
an address to data is on the buss
summation of cycles will multiplying required cycles according to
whether address is to flash or sram
cycles sum() function now expects the current pc address and whether the
mam is active. the pc address is used to decide by how much N and S
cycles should be stretched
if mam is active it is assumed that all address access is optimised and
can keep pace with the base ARM clock
*** timings still not accurate
arm7 execution was not pushing all instructiosn to
disassasmebly.Coprocesser implementation. all instructions should be
correctly disassembled now but in case anything is missed, the opcode is
pushed
fixed thumb format 14 cycle accumulation
moved symbols package into disassembly package
Symbols instance lastst throughout the life of the Disassembly instance.
no more race conditioned caused by rereading symbols file.
clarified relationship of symbols instance in the debugger/dbgmem and
the disassembly.
added CARTRIDGE HOTLOAD command
only CDF and CDFJ mappers supported and not fully tested
this version will trigger race errors in the disassembly on HOTLOAD.
needs a bit of thought how best to fix that
F12 without modifiers will create a single screenshot file
Shift+F12 will save a sequence of five files suitable for double-frame
kernels
Ctrl+F12 will save a sequence of five files suitable for triple-frame
kernels
indexes can be out of range momentarily on ROM change. GUI is trying to
display old disasm at the moment the new ROM is being disassembled.
the GUI and emulation could perhaps be better synchronised to avoid this
but these checks should be in place anyway.
reverted to combobox selection
removed brightness option
key shown in dbgscr not in custom combobox
imguiColorLabel() changed to use font glyph rather than imgui drawlist
shenanigans. savekey i2c window changed to match
for one frame CRT is true but the element texture to have been selected.
this resuls in a disconcerting element cropped image while the rendering
settles down.
fixed by forcing the use of the normal texture if CRT preview is true at
render time.
pausing lazy system is way too heavy handed. it upset Log retrieval and
made the rewind system feel sluggish.
pausing everything execpt log and rewind updates was considered but it
was felt things were starting to get messy so the pausing system was
removed completely.
50ms felt too sluggish. I think when combined with the lazyupdate
system, which happens in two half (refresh and update) the delay is
visually a lot longer in some situations (for example, when editing the
PC value and seeing the change in the disasm window)
this caused some uses of it via (imguiHexInput() and others) to fill up
the terminal sidechannel (and consequently the debuggers pushrawevent
channel) too quickly
it was felt that allowing CRT to be combined with debugging guides adds
nothing. however, simply removing the CRT preview option didn't feel
correct either.
in addition, the opportunity to clarify how window scaling works was
taken. in particular the scaledWidth() function and similar functions
were removed in favour of single values which are updated as necessary
every render frame.
new initialisation value means GotoFrameCoords() when pushed from the
debugging screen will not cause an array out of bounds error between
television reset and the first NewFrame()
this helps to keep lazy values when changed via the GUI to keep
synchronised with the real values
currently, this is only employed in the terminal.pushCommand() function.
if values are changed any other way, for example in the TIA window, then
the GUI will momentarily flicker as the lazy system is updated.
two solutions:
1) add PauseUpdates() in front of every change of value that is pushed
to the emulation goroutine (via PushRawEvent())
2) only ever change values via the debugger command system.
note that both these solutions imply that the 'play' mode needs a
PushRawEvent() implemented. currently, it doesn't have that.
