- Make the global flipping functions of driver_device protected so as not to be accessible from within subdevices
- Eliminate the flip_screen_set_no_update kludge
* new NOT WORKING
Zone 40 [BeckyRGB]
Wireless Air 60 [BeckyRGB]
it isn't 100% clear these belong here, but it's also possible they do, so until more is known, put them here.
* various leapster.xml software list additions [Team Europe]
(also added some missing 'supported="no"'' lines)
* add some extra Leapster bios sets [Sean Riddle]
* create derived 6502 type for XaviX because it has at least one custom 4-byte opcode that doesn't fit any other type.
treating that opcode as NOP for now.
have a feeling it might be something to do with the other integrated hardware, might be 'execute co-processor code chain at this address' or something similar
It isn't a standard JSL (Jump Subroutine Long) like the SNES cpu opcode in the same place as this, it seems to point at some code-like structures tho)
could also be a secondary operation mode with different encoding like ARM's Thumb mode tho I guess.
We currently only have a single XaviX based dump (taitons1) but there are more on the way. I'm going to see if the code flow makes any sense at all with these missing, or if any of it gives a clue as to what they should actually do.
* xavix - let's call these callf and retf then
after further investigation these are some kind of extra 'long jump' subroutine / task handlers, the 0x80 also being a custom opcode was throwing me off trying to identify them before.
looks like they might have been hacking 65816 features into the regular 6502 core?
* prepare for extra address bits (nw)
* better program flow (nw)
Workable stepstag driver:
-Added fundamental communication between main 68000 and (undumped) Windows PC
-Figured out correct logic of data uploading from main CPU to (maybe an FPGA on some unknown board)
-Discovered proper V-blank frequency of 4 logigal screens(routed to 3 physical screens in real hardware), which effects the communication and synchronization between 2 68000 CPUs, thus affect booting
-Borrowed foreground graphics from vjdash, added proper foreground layer handling, and removed hack code
-Seperated palette and decoding of 3 screens, and added independent 3rd screen decoding/drawing routine, as each screen has their own palette, and may display totally non-related graphics
-Corrected sprite rom loading of step3
-Mapped dancing floor light, spot light, neon light, and key led output, based on some video footage of real arcade machines
-Corrected NVRAM handling
-Adjusted key-mapping of foot step input port, avoided key conflict
-The in-game palettes are in 8-BIT YUV(UYUY) format. Each entry may contains 2 pixels. In the real game hardware, the sprites are to be mixed with a MPEG-1 under-layer, then converted together to RGB
Driver for the recently dumped Vjdash (a 4-monitor game):
-Figured out that vjdash uses similar hardware to Stepping Stage
-Identified graphics roms of fg/bg/rotation layers
-Been able to boot to self-test, thus mapped inputs
-In addition to the currently obtained board, this game also needs a 2nd 68000 board which drives 3 upper screens, and one Windows PC, like in Stepping Stage series.
-This board may have 2 more (missing?) ROM ICs, for sprites
