removed all references to hotloading. will reimplement in the future
made sure then cartridgeloader.Loader instances are closed when no
longer needed. added commentary where required to explain
information pane in the ROM selector window is not disabled when
animation emulation is not running. the load button is still visible
based on the animation emulation
notifications interface instance moved to environment from
cartridgeloader. the cartridgeloader package predates the environment
package and had started to be used inappropriately
simplified how notifications.Notify() is called. in particular the
supercharger fastload starter no longer bundles a function hook. nor is
the cartridge instance sent with the notification
AudioTick() function in tracker interface accepts TrackerEnvironment
instance. tracker implementation differentiates emulation instances and
records AudioTick() information accordingly
curated package predated the standard errors package introduced in
go1.13
the standard package does a better job of what curated attempted to do
the change of package also gave me a opportunity to clean up the error
messages a little bit
the reset can be done automatically but as an optional operation. it has
been discovered that in some situations more preparation is required
before the cartridge is reset. particularly, ACE/ELF type cartridges
where the ARM may executed before the coprocessor disasm/developer
packages are initialised and attached
the emulation package has been unecessary since the amalgamation of the
debugger and play modes. in order to allow switching between the two
modes it was necessary to remove the playmode package and to move all
playmode loops and other considerations into the debugger package. as a
result the abstraction offered by the emulation package is uncessary
playback/recorder and driven input systems moved out of the the ports
package and into a new input package. how the input systems interact has
been clarified and improved - for example, it is now posssible for a
playback file to be used to drive two emulations for comparison purposes
the debugger startup procedure has been clarified with two distinct
startup functions for playmode and debugger - each of which take
different arguments. the clarity has allowed the reintroduction of
recording and playback to the main play mode
this is now used when passing events and event data around. it also
records the port and time (in TV coordinates) which are required by
driver/passenger synchronisation and playback recording
removed television interfaces from signal package and moved the
interfaces to where they are needed
rewinding the main emulation breaks the strict synchronisation
constraints with the comparison emulation. it should be possible to
maintain two parallel rewind instances *and* to maintain the constraints
but I've chosen not to tackle that just yet.
userinput for two emulations synced by RIOT ports. RIOT port
driver/passenger synchronisation ensures user input is seen by the
emulations at the same time (relative to the emulation's television)
does not yet handle RNGs (randomise on startup or the RNG in the DPC or
DPC+ formats yet). we need to add a context type first
