have no core use, they are simply there for the convenience of drivers.
Now that drivers are required to have devices, the data should move there.
[Atari Ace]
---------- Forwarded message ----------
From: Atari Ace <atari_ace@frontier.com>
Date: Sun, Sep 5, 2010 at 4:45 PM
Subject: [patch] Eliminate generic.videoramm generic.videoram_size
To: submit@mamedev.org
Cc: atariace@hotmail.com
Hi mamedev,
This set of patches removes generic.videoram and
generic.videoram_size. These generics have no core use, they are
simply there for the convenience of drivers. Now that drivers are
required to have devices, the data should move there.
The first patch sets the stage for the rest of the patch. It includes
several changes.
1. It replaces all the uses of generic.videoram_size with appropriate
constants.
2. It eliminates the write handlers from pc_video.c. These are
unused in MAME and MESS appears to have a private copy.
3. It splits some drivers:
a. It separates mcr68 from the mcr driver, mostly by dividing
machine/mcr.c.
b. It separates naughtyb from the phoenix driver by introducing an
audio/pleiads.h include.
c. It replaces video/system1.h with includes/system1.h.
4. It fixes some videoram related bugs.
a. balsente, mole didn't need videoram.
b. sbowling has a dangling reference to videoram from an earlier
driver_data conversion
5. It expands some namcona functions to multiple lines so that later
scripted-edits look sensible.
The second patch is generated by vram01_1.pl. It introduces videoram
local variables in function that use videoram read-only and removes
AM_SIZE_GENERIC(videoram).
The third patch is generated by vram01_2.pl. It replaces all
occurances of generic.videoram with state->videoram,
introducing/modifying driver_device classes as needed.
The fourth patch then actually removes the generics, and fixes one
issue the scripts didn't handle.
~aa
Not for whatsnew: This is not complete or well-tested yet, I'm checking in
early mostly so Kale can play with it while I'm at work today. It should at
least function better than current for most images.
for the common case where these are done outside the context of a read
or write handler (it was annoying to pass in the fake address space
for these cases).
Added DEVCB_DEVICE_MEMBER() macros which allow you to specify a
READ8_MEMBER or WRITE8_MEMBER in a device callback (via dynamically
generated trampolines).
Replaced all remaining calls to okim6295_r/okim6295_w with calls to
the new methods, and removed the static functions.
address map case so that updated devices can shed their old-style read/write
handlers in favor of member functions.
Bulk converted all okim6295_r/okim6295_w references in the address maps to
call to the modern member functions.
properly. Hooked the correct TMS9980 CPU, added a preliminary memory
map and some technical notes. [Roberto Fresca]
New games marked as GAME_NOT_WORKING
------------------------------------
Jubilee Double-Up Poker [Roberto Fresca]
debugger do it. This allows the device to start itself up before the
debugger tries to figure out what to do with it. Fixes the problem
where register names were not populated into the symbol table
correctly after I shuffled the initialization order.
work just like required_device<> and optional_device<> for retrieving a
pointer by tag from an address space that specifies AM_SHARE("tag").
Also added templates required_shared_size<> and optional_shared_size<>
for retrieving the size of the AM_SHARE region.
Created a new generic NVRAM device. It can be configured to default to
0-fill, 1-fill, random-fill, or custom fill. In all cases, a same-named
memory region overrides the default fill. The address range where the
NVRAM can be found is now identified by an AM_SHARE() region of the
same tag as the NVRAM device. Drivers can also explicitly configure a
separately-allocated NVRAM region via nvram_device::set_base().
Replaced all instances of MDRV_NVRAM_HANDLER(generic_*) with
MDRV_NVRAM_ADD_*("nvram"). Replaced all AM_BASE_GENERIC/AM_SIZE_GENERIC(nvram)
with AM_SHARE("nvram"). For all remaining drivers that referenced the
generic.nvram directly, changed them to hold a required_shared_ptr<UINTx>
to the NVRAM in their driver state, and use that instead. Removed
nvram and nvram_size from the generic_ptrs.
Comment:
There is still a major issue where this printf shows up when using many of the output commands -listxml, -romident and more. It should only show up when emulating the game, right?
----------
Vigilante (World, set 2) [porchy]
(just a minor random driver clean-up, because I've forgot to write the aforementioned whatsnew string in my previous commit ...)
recently-introduced find_devices() method.
There are two new template classes optional_device<> and required_device<>.
Use these to declare the device pointers in the class. The only difference
between the two is that required will fatalerror if the device is not found.
These new classes are "pass-through" so m_oki can be passed anywhere an
okim6295_device would work, and you can use m_oki->x to reference methods
or variables.
Each of these new classes needs to be specified in the initializer,
passing a reference to the driver_device object and the device tag. So,
for example:
class example_state : public driver_device
{
public:
example_state(running_machine &machine, const driver_device_config_base &config)
: driver_device(machine, config),
m_maincpu(*this, "maincpu"),
m_oki(*this, "oki") { }
required_device<okim6295_device> m_oki;
optional_device<cpu_device> m_maincpu;
};
Given that, the driver_device will auto-populate each device with a
pointer to the device prior to calling any of the initialization methods.
