h89bus.cpp: setup io addresses instead of run-time decoding of PROM

[mgarlanger]

@cuavas Based on your comments from my prior PR - #13363, it seemed that doing runtime decoding of the memory PROM had too much of an impact on performance to be accepted. I closed that PR and going to attempt to use address_maps for the memory decoding. As a first step, this PR changes how the IO decoding works, from using the PROM during runtime to using address maps. If this approach acceptable, I will try to get memory decoding using address maps and working with slots and memory views.

[cuavas]

Correct me if I’m missing something, but isn’t this just using hard-coded addresses? Given you know how the PROMs are wired to the chip selects, can’t you decode the content of the PROM image to get the address ranges to install to on start?

For example, you know which output selects the floppy controller, so you can scan the PROM contents to find the combination of inputs that activate that output, and then turn that into an address range given you know how the address lines are wired to the PROM inputs.

[mgarlanger]

There are a few of issues with decoding the PROMs at startup. The first one is related to the MMS floppy controller and how it is selected. Instead of using one of the signals from the bus, it uses a cable connected to a socket on the CPU board to get access to the GPP select line. The MMS PROM selects GPP line for addresses 0x38 - 0x3f (for the floppy controller), and 0xf2 (normal GPP). When GPP is selected, the MMS floppy controller checks the lower 3 address lines (a0-a2) and if that is 0x2, then the GPP is selected instead of the controller. If the value is not 0x2, then the MMS controller is selected.
Another problem, is that not all the selection signals are for a contiguous range. For example, NMI has both 0xf0-0xf1 and 0xfa-0xfb. So instead of just keeping track of a start and end pair, it would need to have a vector of pairs for each select line. All the cards would then need to handle a vector list.
The final issue, I'm aware of, is that some of the IO addresses select multiple select lines, handling that in code to make sure 2 devices don't add themselves to the same range and causes one to not work.

To properly handle the cases above, I think there will still need to be special handling for the MMS PROM. I'm not sure there is generic way to handle all 4 PROMs.

Let me know if I need to decode the PROMs at startup, and I'll try to come up with something that works. And does this - https://github.com/mamedev/mame/pull/13533/files#diff-c18528b917f86f6bc2a8b58c889ac0919a61b93edcba82997c6cfe70bfe1e561R703-R714 need get the addresses from the PROM? I had hard-coded it, since all the PROMs are identical for these select lines and the devices are all built into the CPU board.

[mgarlanger]

@cuavas The code is now using the PROMs to setup the IO addresses for all devices.

[mgarlanger]

Reverting the change to use address_space_installer, since some cards are not working.

[mgarlanger]

Comments have been addressed, can I get another review?