Out of whatsnew: this driver also has 99% of driver data stored in the struct.
it still misses paletteram16, which currently uses a generic handler(and hence does not fit the struct approach), but I wanted save states so much for this game that I commit it anyway :-)
---------- Forwarded message ----------
From: Oliver Stöneberg <oliverst@online.de>
Date: Mon, Nov 16, 2009 at 7:59 PM
Subject: possible NULL pointer dereference
To: submit@mamedev.org
This pacth fixes a possible NULL pointer dereference in
src/mame/video/dec0.c reported by cppcheck.
-----Messaggio originale-----
Da: David Haywood [mailto:neohaze@nildram.co.uk]
Inviato: martedì 17 novembre 2009 0.44
A: Philip Bennett; Angelo Salese
Oggetto: Konami GX Type3/4 dual output
this starts to add dual screen output to the Koanmi GX Type 3 /4 games.
they're probably missing a sprite base register, because if you turn the
dipswitch for 2nd monitor on they're using the wrong spritelist, even in
Soccer Superstars, but otherwise the games automatically bank the
tilemaps in an appropriate way.
Kale, they seem to trigger extra protection writesi in this mode?
btw, Aaron, is there a way to tell MAME to default to a SINGLE screen
layout, but still give the dual screen layout in the video options, that
would better suit these games than displaying 2 screens by default
(because the 2nd screen only tells you that it's disabled at the moment)
Replaced drw80pkr with older dump from [Team Europe].
drw80pkr:
- Added various graphics improvements and corrected colors. Game boots much farther and cleaner.
Out of credits, I also added:
* save states to adp.c (because part of the struct was already there), but nothing is working => no flag;
* save states to albazc.c, but I don't want credit, since no variable needed to be saved (i.e. save states were already there)
Side-notes (not worth mention):
* I fear we were missing a local static array in 1942 save states (now it is saved)
* I haven't found a better way to configure 1943 banks than to split the 0x4000 bank into 4 pieces. can anyone come up with a better approach?
Not 100% sure this is the better way to implement this (we pass the eeprom tag as parameter of the PORT_CUSTOM), but I haven't been able to find a better solution.
No driver uses this yet, so I'm open to any suggestion before to use it extensively ;)
I don't like too much this solution, but now the code is self contained: hence, better fixes (e.g. no MDRV_DEVICE_CONFIG_DATAPTR(eeprom_config, default_data, &_data) at all for the NODEFAULT eeprom?) could be added without further modifying the behavior across the drivers.
