cartridges and implemented the IntelliVoice expansion and
the Entertainment Computer System expansion as passthru
devices. The official syntax to launch games requiring the
speech expansion is now
mess intv -cart voice -cart2 gamename
which corresponds to mounting the IntelliVoice and plugging
the game cart in its subslot. The official syntax to launch games
requiring the ECS expansion is now instead
mess intv -cart ecs -cart2 gamename
and
mess intv -cart ecs -cart2 voice -cart3 gamename
if the game requires both expansions at once. For additional user
friendliness, we also offer intvecs (which emulates an Intellivision
unit with both expansions added) and intvoice (which emulates
an Intellivision with Intellivoice expansion added) drivers, where
games can simply be mounted with the -cart media switch. [Fabio
Priuli]
cartridges, removed The Voice add-on from the main system
and emulated it as a passthru cart instead. Now, if you want to
enjoy speech in odyssey/videopac games, you must launch
emulation with
mess.exe odyssey2 -cart voice -cart2 gamename
(the -cart2 switch becomes available when "voice" is mounted
in the first cartslot) [Fabio Priuli]
---------------------------------------------------
Vegas 1 (Ver 2.3 dual coin pulse, shorter) [any]
Vegas 1 (Ver 2.1 dual coin pulse, longer) [any]
Vegas 1 (Ver 1.33 single coin pulse) [any]
This is a coin pusher machine from Spain. Your guess on how to work it is as good as mine ;-)
their carts. this allows to remove on-cart RAM from the driver class (since it
does not belong there). also added (partial) support for Channel F multicart.
nw.
scsi: sync rest of lines with input buffer (nw)
---
The 9801f will read the hdd but appears to not like disks without 256 byte sectors.
The ux and rs don't even attempt to access the sasi controller and seem to have no driver in their firmwares, are they supposed to have an external rom?
a general workbench list and an application list for testing. Images in
those lists are either verified good or best available currently. Many
images are still missing.
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)
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.
