* Use I8255 or MSM6253 devices for most non-JAMMA inputs
* Separate service and test inputs in Multi-32 and twin-unit sets
arescue: Four coins are recognized, not just two
ga2: Use MB8421 device for V25 communications
orunners: Assign keys to some 2P inputs
-----------------------------------
coco_cart: Added Super LOGO and removed all Dragon cartridges
dragon_cart: Moved all Dragon cartridges from coco_cart
dragon_cass: All known cassette dumps
dragon_flop: All known floppy dumps
dragon_flex: FLEX System and other Compusense FLEX releases
dragon_os9: OS-9, BASIC09, C, Dynacalc, Pascal, RMS, Stylograph
dgnalpha_flop: OS-9, NitrOS9, C, Dynacalc, Pascal, RMS, Stylograph, etc.
- Added joysticks to all machines
- Added floppy sounds
dragon200e: Added chargen ROM, not working (possibly mc6847 issue)
- Demoted to MACHINE_NOT_WORKING
d64plus: Added crtc with chargen ROM and second screen output, not yet hooked up
- Demoted to MACHINE_NOT_WORKING
dgnalpha: Added older Boot v0.4 ROM
- Replaced 5.25" floppy drives with 3.5", and added sounds
The NeoGeo driver exposes a number of different memory regions as vectors. Accessing the pointers was done through a '&vector[0]' pattern. This caused problems when the region was size zero; I changed the code to return null pointers in these scenarios.
This was reported by Robbbert in response to recent regressions (the command line was 'mame aes bjourney'), but it seems to be present in MAME 0.184.
* Made a number of device_image_interface members private
This also fixes a number of get_default_card_software() implementations that were accessing m_file incorrectly
* Remove duplicate prototype
* Revert entries(), indirect_entries(), shadows_enabled() and hilights_enabled() to return the configuration parameters instead of accessing the live state. The thought behind the implementation change was that palette devices could potentially determine the number of entries from the sizes of devfind objects. The regressions caused by this have been worked around, but it was probably a bad idea in the first place.
* Zero-entry palettes are no longer valid. The code that tried to support them was basically left over from when every running machine had a single global palette.
This should address outstanding concerns with PR#2231. I'm trying to turn emu_options into a self contained structure that encapsulates behaviors related to options, including the gymnastics pertaining to image/slot loading and interactions with get_default_card_software() and "just works".
When the MAME 0.186 development cycle starts up, I hope to take this further. I want to make core_options::entry an abstract base class so that the entries associated with image options and slot options can derive from it. This will eliminate the current need for emu_options to directly expose maps for image and slot options.
For now, I'm in stabilization mode, and I hope to get things working for a stable 0.185 release.
-----------------------------------
ibm5150: Golden Axe, Home Alone [ArcadeShadow]
ibm5170: Gods, Indiana Jones and the Fate of Atlantis, The Legend of Kyrandia [ArcadeShadow]
* Changed validity_checker to keep a fresh emu_options for validation purposes
This seems to solve the performance problems introduced by PR#2221 while keeping with that PR's goals of not using the "runtime" emu_options for purposes of validation.
* Sorry, I can't spell apparently...
This fix really doesn't go far enough. I added hooks so that options specified at the command line can also be responded to when parsed from INI files, but in the long run much of the logic that is currently in mame_options should go into emu_options so that when an option is specified, all of the wacko logic around slot/image specification "just works" because it is encapsulated within emu_options.
We have a release 11 days away; I want to be in stabilization mode.
