On some occasions data output can be enabled before data is valid.
This results in needless data line toggling which in turn can cause
coupling into other signals, thereby potentially altering the ROM address
and putting wrong data on the bus, etc.
Use a narrowed output enable signal for SNES read cases to prevent this
effect.
CPU_CLK is substantially shorter than RD# during DMA transfers.
Access cycle end was previously based on falling edge of CPU_CLK.
This resulted in premature yielding of RAM access to the bus and in
consequence incorrect values leaking onto the bus.
To support multiple custom chips the FPGA is reconfigured at ROM loading
time while the menu is running.
After reconfiguration the initial state of all synchronizing shift
registers was 0 which led the FPGA to believe the SNES is actively
accessing the bus, writing to peripheral address $00 (CPU address $2100
- brightness register). This invalid state persists for a couple of FPGA
cycles until the SNES control signals have been clocked into the shift
registers.
The recently introduced brightness patch partly reacts to this pattern,
momentarily forcing the sd2snes data bus drivers active. Depending on
the SNES CPU's current position in the cycle this could cause a crash,
disrupting the game loading handshake. Upon pushing reset the game would
still run but without long reset or autosave features, so one would
inevitably lose their SRAM contents.
This fix initializes the synchronizers for all active low control
registers with 1's (and the CPU_CLK synchronizer with 0's for good
measure) so the FPGA doesn't make up any accesses that do not exist.
This intercepts and overrides writes to $2100, limiting the brightness
written to a configurable value (8..15).
The FPGA feature bitfield is extended to 16 bits to accomodate the 4
additional bits for the brightness limit.
The menu itself does not apply the brightness limit on FPGA level but
"fakes" it by setting the brightness manually. The newly added menu
change hooks are used to reflect the brightness setting as soon as it is
changed during selection.
Significant improvements on the hook's CPU footprint and "stealthiness".
* implicit unlocking by FPGA (and by mapper ID for menu operation)
* automatic return vector filling by FPGA, no more duplicate hooks
* do not perform manual read when manual read in progress by game
* map button combination -> command using FPGA (no costly loop in hook)
* reset hook support
