Fix Super19 version of Heath H19.

[mgarlanger]

Adds the AM_MIRROR settings which the Super19 ROM relied on. The CRTC ports and the videoram memory were the only ones I saw, which was REQUIRED to get it working, but figured I'd update all the memory and ports to properly reflect the real board in case the ROM used it in other code paths I hadn't tested.

Also added preliminary definitions for the SuperSet ROM, not sure if the current AM_MIRROR options allows a way to properly define how it is configured. My initial attempts to define it, caused run-time crashes. The ROM chip is a 32K chip, of which 16K is used. But the valid data is in the 2nd and 4th 8K blocks of the chip, not the 1st and 3rd. So it would either error with 'mirror touching a set bit' or have the memory reflect the invalid parts of the ROM chip.

[cuavas]

You can load the ROM piecewise to get the effect you want - load the unused parts off the end of useful space:

ROM_REGION( 0x14000, "maincpu", ROMREGION_ERASEFF )
// Superset ROM - although the ROM is 32K, only 16K is accessible
ROM_LOAD( "27256_101-402_superset_code.bin", 0x10000, 0x2000, CRC(a6896076) SHA1(a4e2d25028dc75a665c3f5a830a4e8cdecbd481c))
ROM_CONTINUE(0x00000, 0x2000)
ROM_CONTINUE(0x12000, 0x2000)
ROM_CONTINUE(0x02000, 0x2000)

Alternatively you can use AM_REGION("name", offset) macros in and address map to load from specific offsets in a ROM region, e.g. see this snippet from src/mame/drivers/taito.cpp for an example:

AM_RANGE(0x4800, 0x48ff) AM_ROM AM_REGION("roms", 0x2000)

That maps 0x100 bytes from offset 0x2000 in the ROM region starting at 0x4800 in the address space.

Can you try one of these approaches to get the ROM loading you want?

[mgarlanger]

I was able to closer to the ROM loading properly, but with the AM_MIRROR set for the h19 machine, it was still only seeing the first 4k. I figured I needed to create a new ssh19 machine, so I created another memory map without the AM_MIRROR for the low ROM and a ssh19 machine using MACHINE_CONFIG_DERIVED. But the resulting program just seg faulted (attempting to run any of the h19 systems crashed):

Thread 1 "mame64" received signal SIGSEGV, Segmentation fault.
0x0000000004e19fc9 in device_memory_interface::static_set_addrmap(device_t&, address_spacenum, void ()(address_map&)) ()
Missing separate debuginfos, use: dnf debuginfo-install SDL2-2.0.5-2.fc25.x86_64 SDL2_ttf-2.0.14-2.fc25.x86_64 alsa-lib-1.1.1-2.fc25.x86_64 bzip2-libs-1.0.6
-21.fc25.x86_64 expat-2.2.0-1.fc25.x86_64 fontconfig-2.12.1-1.fc25.x86_64 freetype-2.6.5-1.fc25.x86_64 glib2-2.50.2-1.fc25.x86_64 graphite2-1.3.6-1.fc25.x86
_64 harfbuzz-1.3.2-1.fc25.x86_64 libX11-1.6.4-3.fc25.x86_64 libXau-1.0.8-6.fc24.x86_64 libXdamage-1.1.4-8.fc24.x86_64 libXext-1.3.3-4.fc24.x86_64 libXfixes-
5.0.3-1.fc25.x86_64 libXinerama-1.1.3-6.fc24.x86_64 libXxf86vm-1.1.4-3.fc24.x86_64 libcap-2.25-2.fc25.x86_64 libdrm-2.4.74-1.fc25.x86_64 libgcc-6.3.1-1.fc25
.x86_64 libgcrypt-1.6.6-1.fc25.x86_64 libgpg-error-1.24-1.fc25.x86_64 libicu-57.1-4.fc25.x86_64 libpng-1.6.27-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64 li
bstdc++-6.3.1-1.fc25.x86_64 libxcb-1.12-1.fc25.x86_64 libxshmfence-1.2-3.fc24.x86_64 mesa-libGL-13.0.3-1.fc25.x86_64 mesa-libglapi-13.0.3-1.fc25.x86_64 pcre
-8.40-1.fc25.x86_64 pcre-utf16-8.40-1.fc25.x86_64 qt5-qtbase-5.7.1-10.fc25.x86_64 qt5-qtbase-gui-5.7.1-10.fc25.x86_64 systemd-libs-231-11.fc25.x86_64 xz-lib
s-5.2.2-2.fc24.x86_64 zlib-1.2.8-10.fc24.x86_64
(gdb) bt
#0 0x0000000004e19fc9 in device_memory_interface::static_set_addrmap(device_t&, address_spacenum, void ()(address_map&)) ()
#1 0x000000000109741a in construct_machine_config_ssh19(machine_config&, device_t*, device_t*) ()
#2 0x0000000004f260fd in machine_config::machine_config(game_driver const&, emu_options&) ()
#3 0x0000000004fa0d5b in validity_checker::validate_one(game_driver const&) ()
#4 0x0000000004fa11a3 in validity_checker::check_shared_source(game_driver const&) ()
#5 0x000000000340133b in mame_machine_manager::execute() ()
#6 0x0000000003480a29 in cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::all
ocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >&, std::__cxx11::basic_string<char, std::c
har_traits, std::allocator >&) ()
#7 0x0000000003480c53 in cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<
std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >&) ()
#8 0x00000000033ff7fb in emulator_info::start_frontend(emu_options&, osd_interface&, int, char**) ()
#9 0x000000000149c3df in main ()

[mgarlanger]

@cuavas here is the code I have, both approaches crash, I assuming it is related to the alternate ADDRESS_MAP or MACHINE_CONFIG_DERIVED. As I stated above, if I use approach 1, and the existing AM, it loads the ROMS but it's mirrors the first 4k. When I add in the new AM and machine config, it segfaults, for all versions of the h19.

[mgarlanger]

With no response in 17 days, I removed all of the partials changes for the SuperSet rom, which SHOULD address the concerns of @cuavas. What remains is the fixes needed to get super19 working. Extremely disappointing that PRs are handled this slowly.

[cuavas]

You said the code crashed. That's not acceptable. You can't expect us to have the time to debug/fix your submissions. We've got lots of other things happening in MAME development, and we all have other responsibilities. You're not going to win any sympathy with that attitude.

[mgarlanger]

Had you reviewed at that code, you would have seen both of your suggested approaches were IFDEFed out, so the PR was not crashing. I left them in initially to get feedback on what may be wrong.

[mgarlanger]

And yes we all all very busy. My frustration is that I felt the initial PR met the standard to be merged, instead of requiring changes to partially fix the new 'NOT_WORKING' system I added. After fixing the other 2 H19 variants in earlier PRs, this PR fixed the third H19 variant, all which had been NOT_WORKING for years. It also added a skeleton for a new 'NOT_WORKING' variant which will also requires changes to connect up the 8250 UART to some bank-switching logic for the character graphics rom, as I had mentioned in the TODO list comments. I did try both approaches you suggested, neither worked (most likely to my lack of understanding all the MACROs, which are used in mame that I haven't had time to research very much). I reported that, and instead of ANY feedback (including just a 'ok revert it to the original PR and address the rom loading later'), there was total silence for 2 weeks. Instead of keeping this PR in limbo for weeks, merging the original and suggesting how to fix the issue in a followup PR would have been a better approach (IMHO), since it is not unusual for NOT_WORKING systems to be added to mame.
Anyways enough rambling, the PR is now just the fix for super19 (and I verified both h19 and watzman still work with these changes).