Software lists cannot be attached to slot devices

[rb6502]

This was briefly discussed on the list a while ago, but there are a lot of potential use cases for it: Apple I and II harddisk images, Sega 32X games if we turn the 32X into a proper slot device, the 2600 Starpath Supercharger cassettes, Game Boy Advance e-reader cards, etc, etc.

[etabeta78]

In my opinion it is best to attach software lists directly to the main driver, because otherwise it is highly probable that many users would not even know about some of the things we support. Case in object is the IQ151 driver: the emulated machine has no floppy drive by default because such drive was not very common (I think due to high price). Most users would thus probably ignore the existence of such extension if it wasn't for the floppy software list being attached to the main system (and thus prompting users to investigate how to load such images). If the software list was "hidden" in the expansion, it would probably be ignored by the majority of users. I can envision a similar situation with apple II, given the large number of slot expansions we support.

In conclusion, while it would be nice to have the option to attach the lists to the slot device, I think it is more user-friendly if the software is connected directly to the system supporting it ;)

my 2c f.

On Sat, Apr 2, 2016 at 4:08 PM, R. Belmont notifications@github.com wrote:

This was briefly discussed on the list a while ago, but there are a lot of potential use cases for it: Apple I and II harddisk images, 32X games if we turn the 32X into a proper slot device, the 2600 Starpath Supercharger cassettes, Game Boy Advance e-reader cards, etc, etc.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/mamedev/mame/issues/777

[startaq]

It works fine for me, or am I misunderstanding something?

For example: https://github.com/mamedev/mame/blob/master/src/devices/bus/svi3x8/slot/sv801.cpp#L41

[Pernod70]

Personally I'd prefer softlists attached to slot devices. In the bbc driver I have various softlists which will only work when various 2nd processor slot devices are emulated, at which point I'd move the softlists to the devices. ie. attach z80 co-processor and it'll add the CP/M software, attached 32016 co-processor (anyone want to develop 32016 core?) and it'll add PanOS installation discs. At the moment these lists are tagged as not supported, as they'll all fail to load due to missing hardware. How is the compatibility value currently used in software items? Could it contain required slot devices, and if not present pop a message to attach device?

[rb6502]

startaq: drivers that do that currently cause MAME's core code to fuck up and it usually ends up crashing on non-Windows builds.

Pernod: thanks for the additional use cases.

eta: we already have it possible that adding a slot device adds more slots (and QMC2 handles it well), so this is simply an extension of that concept. User discovery of software is irrelevant if it can't run due to missing hardware.

[startaq]

Well can you tried on OS X then? Right now I only have Windows to test, and it works fine there. For the SVI-328 you can use mame svi328 -exp sv601 -exp:sv601:6 sv801 -flop1 diskbas. That should load Disk Basic from floppy on boot.

[etabeta78]

On Sat, Apr 2, 2016 at 9:35 PM, R. Belmont notifications@github.com wrote:

startaq: drivers that do that currently cause etabeta's code to fuck up and it usually ends up crashing on non-Windows builds.

I'd just like to point out that it's not "my code" that fucks up ;) softlist loading code has been rewritten at least twice since when it was my code...

eta: we already have it possible that adding a slot devices adds more slots

(and QMC2 handles it well), so this is simply an extension of that concept.

my suggestion about attaching lists to the driver is philosophical, not technical: all the software you are going to include in the list was released for the combo system+extension and thus it makes sense to add it to the system machine config as well. In 0.172 AJR added the capability to add input options when loading from softlist. Attaching all lists to the main driver and (hopefully) add the capability to add slot expansions on demand is simply an extension of that concept...

my 2c

[ajrhacker]

The slot_default feature is not just for input devices. In theory, adding something like <sharedfeat name="tube_default" value="z80"/> to the bbc_flop_z80.xml entries would suffice to automatically install the Z80 into the second processor slot. (It does absolutely nothing now because no such slot has been implemented in the driver.) This feature is not designed to work if an image device designed to load the software itself is not present on the machine as configured; startaq's svi328 floppy example shows how they can be doubly hidden.

The "compatibility" feature of software items really just matches against the filter configured for the softlist device. A slot device could potentially modify the filter even if the list isn't its own subdevice, but I can't think of a good reason why.

It seems to me that trying to load software lists from slot devices is going at it the wrong way around, especially since machines will often have more than one device that can load a given category of software. If the software media wouldn't even fit into the actual hardware that the stock configuration represents (like a Game Boy cartridge and a SNES without a Super Game Boy), I don't think it would be logically sound for MAME to automagically attach slot option on top of slot option in order to get it to load.

[etabeta78]

Good points. I have to think a bit more on the various scenarios...

f.

On Sun, Apr 3, 2016 at 7:45 AM, ajrhacker notifications@github.com wrote:

The slot_default feature is not just for input devices. In theory, adding something like to the bbc_flop_z80.xml entries would suffice to automatically install the Z80 into the second processor slot. (It does absolutely nothing now because no such slot has been implemented in the driver.) This feature is not designed to work if an image device designed to load the software itself is not present on the machine as configured; startaq's svi328 floppy example shows how they can be doubly hidden.

The "compatibility" feature of software items really just matches against the filter configured for the softlist device. A slot device could potentially modify the filter even if the list isn't its own subdevice, but I can't think of a good reason why.

It seems to me that trying to load software lists from slot devices is going at it the wrong way around, especially since machines will often have more than one device that can load a given category of software. If the software media wouldn't even fit into the actual hardware that the stock configuration represents (like a Game Boy cartridge and a SNES without a Super Game Boy), I don't think it would be logically sound for MAME to automagically attach slot option on top of slot option in order to get it to load.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/mamedev/mame/issues/777#issuecomment-204879931

[rb6502]

Which is precisely why it doesn't make sense to put all possible software lists in the base driver, complete with potential daisy-chains of auto-added options. Adding software lists with the adaptor devices follows how real life works, and indeed how such devices are described and marketed in real life: the Intellivision System Changer "makes Atari 2600 games available to you", the 32X "adds the ability to play new advanced 32-bit games", and so on. Going the other way violates the least surprise principle.

Taking eta's argument to its logical conclusion, we'd have to add every softlist we have to the PC drivers, because you could run MAME on PCs. And that would of course be an obvious usability disaster.

[Quench0]

Pernod70: "(anyone want to develop 32016 core?)" We have support for the 32016 in the TMS32010 CPU core, though I'm not sure anything uses it to date.

[rb6502]

The BBC Micro add-on used National Semiconductor's ill-fated 32016 which AFAIK is not related to the TI 320xx family.

[Quench0]

Ah I see, yes it's a different beast. Sorry about that.