heathzenith/h89.cpp: Update memory map to directly use decoder PROMs

[mgarlanger]

@rb6502 I've implemented the memory decoding PROMs, the only thing I'm not happy with is not being able to select which version of the primary and secondary PROMs to use. Details of the earlier PROMs have been added, but are currently commented out. The newer PROMs allow the systems to all work. For the primary memory PROM, Heath's manual actually states: "All users should upgrade to this part regardless of configuration. There are no negative consequences connected with this upgrade." (444-42 -> 444-62). But for the secondary PROM, the original one (444-41) should be used with the MTR-88 and MTR-89 2k PROM, and the newer one (444-83) should be used with the MTR-90 4k part. There were no functional problems with using 444-83 and the 2k ROMs, but it may not respond to some unused addresses the same as a real H-89 would.
I wasn't able to use the ROM_SYSTEM_BIOS and ROMX_LOAD since there is only one per device, and these 3 PROMs should be independent.

Also added two new left side cards:

• WH-88-16: 16k RAM upgrade
• Micronics Technology's WIN89: a parallel port/hard drive interface board

The WIN89 had an alternate ROM that defaults on power up, this necessitated the passing of the memory select lines by reference so that when the board is using it's ROM, the CPU ROM will not be accessed. On the real card, the user would move the ROM from the CPU board to the card, but I didn't see a good way to handle that, since the ROM could be any of the 4k ROMs supported on the H-89.

[cuavas]

the only thing I'm not happy with is not being able to select which version of the primary and secondary PROMs to use

How early do you need to use the PROM contents? If you don’t need it before the initial call to device_reset, you can load both PROMs, and have a fake machine configuration input to select the one to use. Unfortunately you can’t read inputs at device_start time, so it doesn’t help if you need the PROM contents before the initial reset.

[cuavas]

We conventionally put these at the very top, above the constructor.

[cuavas]

These all have extraneous semicolons.

[cuavas]

Besides the formatting stuff, this seems to be a very high-overhead way of implementing this, as you’re decoding the PROM contents on every memory access. Could you instead analyse the content of the PROM ahead of time and set up an address space based on the effective mapping it will produce?

[mgarlanger]

Besides the formatting stuff, this seems to be a very high-overhead way of implementing this, as you’re decoding the PROM contents on every memory access. Could you instead analyse the content of the PROM ahead of time and set up an address space based on the effective mapping it will produce?

That was how it was implemented in the h89.cpp code, with mem_views prior to this PR. But I didn't see a way to handle user selectable boards, like the win89, taking over the system ROM at power up and the being able to swap back to the regular ROM. Or handling memory boards. The basic Heath 16k board was handled by the original code, but there is another memory board, the MMS 128k, which used it's own PROM (a larger 512 byte one), to handle bank-swapping. I don't have that PROM dumped yet, but want to add support for that board too. With the larger PROM, there will need to be code changes too. The MMS 128k consists of both the add-on board that goes in a left-slot and a smaller board taking over some sockets on the main CPU board and have additional wires between the two boards. One option I considered, was to have additional h89 clones, but it the board was not restricted to just the current h89mms clone, it would need additional clones for each of these existing h89, h89mms, h89cdr, and z90. And to allow selection of none, either, or both of the win89 and mms 128k boards, it would expand the clones by 4x.

This issue is similar to the h89sigmasoft clone. I initially implemented it as a clone since the io mapping was different. But the board could work in any of the existing systems. Once RB's slot implementation for the H89 was completed, I expanded on it and made the SigmaSoft IGC board selectable across all the other clones and removed the h89_sigmasoft clone.

With benchmarking on my system I'm seeing the benchmarking go from ~3750% to 3170%. About a 15% hit.

Maybe there is a better way to handle the different soft-sectored controllers and the differences in the interrupt controller and PROMs needed by them, we could remove those clones, and only have clones for different memory maps needed. There may still be some increase due to permutations, the win89 and mms 128k could be in the same system, the increase in the number of clones won't be nearly as bad. Any other suggestions how to better handle this?

[mgarlanger]

the only thing I'm not happy with is not being able to select which version of the primary and secondary PROMs to use

How early do you need to use the PROM contents? If you don’t need it before the initial call to device_reset, you can load both PROMs, and have a fake machine configuration input to select the one to use. Unfortunately you can’t read inputs at device_start time, so it doesn’t help if you need the PROM contents before the initial reset.

Selecting it at device_reset time should be fine, but looking closer at what the MMS 128k device would need, means that the memory reading and writing routines would need to be updated since the PROM is 512x8, instead of the 256x8 for both of the Heath's PROMs.

[mgarlanger]

@cuavas Any suggestions on how to better handle this?

For the primary memory decoder PROM (U517), Heath had 2, the original 444-42 only supported up to 48k, the 444-66 added support for 64k with the add-on board. Both were 256 x 8 PROMs. MMS first offered a upgrade to 64k, their PROM was 512 x 8. They also offered a 128k RAM board that brought the system up to 176k total. It also uses a 512 x 8 PROM. From documentation, it looks like MMS also offered some other replacements PROMs, but I'm not sure the details other than they were named 42A and 42B.

The secondary memory decoder PROM (U516) was 32 x 8. Heath also offered 2, 444-41 and 444-83. The 444-41 was used with 2k ROMs (socket U518 - Heath's MTR-88 and MTR-89). 444-83 was for their 4k ROM MTR-90 ROMs(444-84 and MTR-142). The 444-83 seems to work with the 2k ROMs, but it won't allow for a second 2k ROM in socket U519. I'm aware of a CDR configuration that uses it, but CDR also had a 4k ROM option and the CDR controller is not working yet. I'm not aware of any other PROMs for the secondary memory decoder.

Is there a way setup address spaces based on which add-on card selected? Or another option would be to have clones for each of the various options, but the number of clones needed to support the various combination would be large. And since the current clones for the different floppy controllers and which interrupt controller each need, that would multiple the number of clones by 3. Is there a better way to the floppy controllers and interrupt controllers?

If we changed the interrupt controller socket to not be fixed, we wouldn't need all the clones, but I think it would be more confusing to users trying to match up a working combination of floppy controllers and interrupt controllers. If there was a way when selecting (or removing) a floppy controller board for a slot, the interrupt controller slot could be changed, users would not need to understand the inter-dependencies of the sockets.