heathzenith/h89.cpp: Update memory map to directly use decoder PROMs #13363
Conversation
How early do you need to use the PROM contents? If you don’t need it before the initial call to |
| @@ -55,6 +55,8 @@ class heath_h17_fdc_device : public device_t, public device_h89bus_right_card_in | |||
|
|
|||
| [[maybe_unused]] void side_select_w(int state); | |||
|
|
|||
| static constexpr feature_type unemulated_features() { return feature::DISK; } | |||
There was a problem hiding this comment.
We conventionally put these at the very top, above the constructor.
| virtual u8 read(u8 select_lines, u16 offset) { return 0; }; | ||
| virtual void write(u8 select_lines, u16 offset, u8 data) {}; | ||
| virtual u8 read(u8 offset) { return 0; }; | ||
| virtual void write(u8 offset, u8 data) {}; | ||
|
|
||
| virtual u8 mem_read(u8 &pri_select_lines, u8 &sec_select_lines, u16 offset) { return 0; }; | ||
| virtual void mem_write(u8 &pri_select_lines, u8 &sec_select_lines, u16 offset, u8 data) {}; |
There was a problem hiding this comment.
These all have extraneous semicolons.
|
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? |
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. |
@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_BIOSandROMX_LOADsince there is only one per device, and these 3 PROMs should be independent.Also added two new left side cards:
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.