* stuff from Sean, will credit later (nw)
* (nw)
* (nw)
* some more SunPlus stuff with NAND type roms (gpnandnand strings in them, need bootstrap)
* possible hardware names (nw)
* some kind of ARM based GeneralPlus (nw)
* proper names (nw)
* (nw0
* this is some kind of enhanced chipset, not 100% sure it's VT tho (nw)
* new NOT WORKING machines
---
Lexibook JG7425 221-in-1 [TeamEurope]
* comments (nw)
* acknowledge that there is S+Core code in here at least (nw)
* mapping the code from ROM to RAM at 500000 after skipping the first 0x20 bytes means a lot of jumps go to the word after a 'br r3' so is probably where it gets copied to
ioport.cpp:
* better than 50% reduction in compile time, and better locality for static data
* better encapsulation, const correctness and noexcept usage
* vt1682 alu is now a device (nw)
* prepare to make times devices (nw)
* push timer logic into devices (nw)
* naming fixes (nw)
* useful trampoline (nw)
* (nw)
* hmm timer math, I'm not sure about timer math (nw)
* messing with rasters (nw)
* move zone40 to vt1682, while it definitely isn't plain 1682 I think it's more likely closer to it than it is to SunPlus
* When a switch-type input is selected, show feedback when it's pressed
* If an invalid code is entered (e.g. only negatives) abandon the change rather than cycling default/none
* If an invalid code is entered display a message until the user takes some other action
input.cpp updates:
* constexpr crusade on input_code and input_seq and some very slight optimisation to input_seq
* seq_poll* is a frontend function and had no business being in the core, so it's a utility class now
* seq_poll* now exposes a bit more detail, enabling improved interaction on the UI inputs menu
* global state is reduced a little, but the poll_* functions are still members of the input manager with global state
(nw) The Lua engine has been updated in a way that maintains source compatibility with existing Lua
scripts. This is less than ideal, but it minimises impact. Ideally someone (possibly me) will be
able to expose the input sequence poller helper properly. I tested the changes with the cheat and
autofire plugins and I was able to assign sequences. However I found two issues: it's seems
impossible to assign a more complex sequence than a single key/button in the autofire plugin (i.e.
no AND or NOT conditions, I confirmed this is pre-existing, not a regression), and in both the cheat
and autofire plugins I found it a bit unwieldy trying to enter a complex sequence without live
feedback of the sequence as it's built (this was also applicable to MAME's own input mapping menu
until I added the live display yesterday).
* reference table (nw)
* move some machine specific stuff into different class (nw)
* put things behind log macros (nw)
* add in some controls, that work for the 32-in-1 at least (nw)
* note (nw)
* hide excessive logging (nw)
* dma fix for tetris (nw)
* alu work (nw)
* clean up some palettes
* clean up some bitscanning and indentation in olibuchu
* rename machine/epos.cpp to machine/pacman.cpp as it's unrelated to drivers/epos.cpp
* move epos-on-pacman members from pacman_state to derived epospm_state
