mame
mame copied to clipboard
Encapsulate bus-style slots properly
A large number of systems have slots that are basically just address/data lines and possibly strobes and other control lines. In many cases this maps straight into a CPU space in the host system. For these kinds of setups, MAME should supply an address space and possibly a base address/mask to the cards and let them map themselves.
However, a large number of slot systems are implemented in a very bad way where the host has to know the implementation details of the cards and map their handlers itself. This is a leaky abstraction, it hurts encapsulation, and require changes to all hosts when card implementation details change or new types of cards are added. On top of that, it hurts performance by adding an extra level of indirection via a virtual member function call and stops certain memory system optimisations from being used.
In general, if a slot card interface exposes some kind of “card type” enumeration that the host switches on or an equivalent set of flags, it very likely should be reimplemented properly. The intellec4
bus is a good example showing how to implement a bus with multiple address spaces and shared bidirectional control lines.
- [ ] bus/megadrive
- [ ] PC-98 bus/cbus
If someone decides to work on this, please choose something other than Neo Geo to start with. I'd like to do that one myself.
MAME should supply an address space and possibly a base address/mask to the cards and let them map themselves.
This is an elegant method, but does not play nicely with having configuration switches on cards to determine addressing. An even worse case is cartridges whose buses incorporate priority lines to allow onboard soft switches to map and unmap cartridge memory over the host machine's ROM. These cases may be ameliorated once @galibert implements memory views.
I don't think there are too many real "leaky abstraction" buses in MAME, but those that do exist can get very bad indeed (e.g. bus/nes).
There are definitely too many of them. Most of the consoles are like this. You can't go far at all without finding one (e.g. megadrive
, nes
, snes
, vcs
and vectrex
just to name some well-known consoles).
When those slot devices were written there were no better standards to follow for this kind of stuff (e.g. earlier NES & MD implementations predated bankdev spread across the codebase as well, or I would have tried to use it). There were basically only CBM and IQ151 which passed image devices through the bus, and I started from those trying to come up with the extensions consoles needed.
I regret not having been able to find the spare time to rewrite them to modern standards in the past 2 years, but current job and family keep me really busy
f.
On Sat, Oct 26, 2019 at 6:08 AM Vas Crabb [email protected] wrote:
There are definitely too many of them. Most of the consoles are like this. You can't go far at all without finding one (e.g. megadrive, nes, snes, vcs and vectrex just to name some well-known consoles).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/5800?email_source=notifications&email_token=ACGSVPCDPMJUFSHJTYCY4YDQQO7DNA5CNFSM4JE5AENKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECJ7BQQ#issuecomment-546566338, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACGSVPDI7LHYFJDZNEFKOL3QQO7DNANCNFSM4JE5AENA .
Another pernicious old-MESSism that @angelosa is currently working on removing in the a800_cart branch is installing cartridge memory and control registers in machine_start
handlers (including old-style overrides), based on mapper information extracted during call_load
. This is why driver_device::device_start
includes a call to machine().image().postdevice_init()
: if it were performed any later, the old MESS routines wouldn't be able to detect cart mapper types.
At this point I suggest editing the OP message, breaking down remaining legacy slot systems into tasks.
At this point I suggest editing the OP message, breaking down remaining legacy slot systems into tasks.
Started doing so, PC-98 C-Bus fixups are required by Luna 88k^2 and eventually as a PCI bridge.