multibus: fixed regression on isbc202

[fulivi]

Hi,
this commit fixes a regression on isbc202 emulation caused by cf67936, which removed ownership of multibus slots by multibus bus. By doing so it removed the propagation of clock down to cards.
iSBC202 was affected because it (probably) is the only multibus card in MAME that relies on clock to come from the bus.
Thanks.
--F.Ulivi

[cuavas]

Do you think this is the best approach? Would it be better to change the slot constructor to allow a clock frequency to be supplied rather than always using zero?

[cuavas]

If you turn this into a global variable, it needs to have a constant address across an invocation and hence increases static data size. If it’s only used in a single function, you can make it a local variable.

[ajrhacker]

Aren't constexpr variables implicitly inline since C++17?

[cuavas]

Only constexpr static data members are implicitly inline. A scope constexpr variable implicitly static.

But if the address of a static inline data member leaks out of a function (e.g. by passing it to logerror or something else that implicitly passes by reference), the compiler will instantiate an out-of-line copy, and the linker needs to coalesce the out-of-line copies at link time. It doesn’t actually prevent the increase in static data size.

[fulivi]

Better like this?

[fulivi]

@cuavas May I ask you if you think this can be merged, please? Thanks

[cuavas]

Well there are two issues with it now:

• The slot clock used at construction isn’t used, because it gets the bus clock at start anyway. It’s kind of pointless passing the clock value to slots.
• You still can’t configure slots with different clock frequencies without a separate bus for each group (I don’t know if this can ever happen in real life for multibus, but e.g. PCI systems sometimes have a mixture of 33 MHz and 66 MHz slots).
• If the clock frequency of the bus is changed after start, it doesn’t propagate to the slots.