Explicit regions in address maps (AM_REGION) are now looked up relative to the
device rather than as siblings when in an internal address map (similar to
devices and shared pointers) Besides being more orthogonal than before, this
allows internal ROMs of MCUs and similar devices to be hooked up in a nicer
and more foolproof way. Updated the m37710 and m5074x (m6502 derivative)
to take advantage of this.
Divided the M37702/M37710 into specific models, with each model having its own
internal address map containing the correct amounts of internal RAM and ROM.
M37702 MCUs found on various Namco PCBs are now all unique devices and have
their respective internal ROMs loaded as device ROMs.
(nw)
Also did some spring (fall) cleaning in addrmap.c/memory.c/dimemory.c
m_devbase (the base device used for tagmap lookup when late-binding handlers and
finding memory regions and shares) is now a reference rather than a pointer,
since we know what it is when the address_map_entry is constructed and it
doesn't change (it depends solely on whether it's an entry in an MCFG-provided
address map or an internal one) And for the same reason, there's now only one
m_devbase per address_map_entry rather than individual copies for
read/write/setoffset/sharedptr.
Removed mysterious unused address_map_entry member "m_region_string", along
with a silly assert probably left over from when Aaron was replacing AM_BASE
with AM_SHARE years ago.
Added a comment noting that "make sure all devices exist" in
device_memory_interface::interface_validity_check() actually does nothing,
like the proverbial goggles. The reason there's just a comment and not a fix
is I haven't figured out how to fix it yet
(is it possible to extract the original device tag that was given to a
proto-delegate? Sorry, the template hell in devdelegate.h and
lib/util/delegate.h makes me want to run screaming like a little girl)
to eliminate device().machine().scheduler() chains all over the place (nw)
This change has been sitting in my local tree for months, from when I was
(mostly unsuccessfully) working on c64 performance. It gives a small speedup
to drivers with many tightly-interleaved executing devices (i.e. Commodore
drivers) I didn't think it was worth making everyone do a clean build for
such tiny gains but I didn't have the heart to chuck it. Since I'm already
making another core-touching, clean-build-needed commit tonight, in it goes.
homebrew. Also allowed bankswitch writes to get to the TIA for this and
mapper 3F. Finally, included a couple of demos in the softlist so to be
able to test the code in future. nw.
Loopback: tx goes high and data is clocked at the correct rate instead of appearing instantly
Modem status register: don't lose track of external signals when starting, resetting, switching loopback off, writing to register
Handshaking: active low for consistency (RS232 port now defaults handshaking lines high and serial mouse dtr/rts handling has been adjusted).
(I think at this point we should go over the source and flip the flag to GAME_NO_SAVE for drivers lacking support, rather than having to flag it when it works, also maybe add the ability to tag devices so if a driver is using a device without support it will automatically inherit that state)
softlists (like gbcolor games in gameboy, and viceversa, msx1
carts in msx2, etc.) by using the syntax
mess system -media list:gamename
You can now for instance use again "mess gbcolor -cart gameboy:sml"
to play "Super Mario Land" with the custom palettes of the Game
Boy Color. [Fabio Priuli]
basic allocation and access handlers, and converted a few
drivers to use this instead of code from cartslot.c [Fabio Priuli]
out of whatsnew: the RAM socket part is just a proof of concept,
and the natural extension of the line of thought which lead me
to this generic socket/cartslot. it might allow to convert current RAM
device to be a slot device as well (after some refactorization, of
course, since current code lacks many of the necessary features),
or be removed soonish, depending on consensus.
-----------------------------------
Sengoku Basara X Cross [darksoft, Guru]
Kinnikuman Muscle Grand Prix 2 [darksoft, Guru]
Gundam vs. Gundam Next [darksoft, Guru]
Raiden II (US, set 2) [farzeno]
also attempted to identify regions / rename sets to fit.
interestingly the 'easy' sets do not show a JAPAN message even when the region is 0x00 (or when the region is 0x04, which is the Korean region on RDX)
New games added or promoted from NOT_WORKING status
---------------------------------------------------
Raiden 2 [Angelo Salese, Olivier Galibert]
Raiden DX [Angelo Salese, Olivier Galibert]
Go-Stop [system11]
might be playable, button mappings need looking at (bet etc.) but definitely uses unemulated ST0016 tile modes (bg should be 16x16 tiles)
moved some of the Raiden 2 cop emulation to a new device (just the memory DMA stuff, including private buffer copy code) and started sharing it with legionna.c in order to avoid code duplication. We can slowly move other duplicate code over too and eventually kill the old seicop.c
