Note: I assumed that writes would be in the 0x4000-0xC000 range, but perhaps that's wrong.
Forget about this, I did record all writes in the whole area of the slot. So the writes I wrote about are the writes seen.
From 0x1100-0x1268 is some code (looks like a bunch of helper routines)
The last 5 routines are calls to WRSLT with different addresses. HL contains 77F0, 7FF0, 67F0, 9FF0 and BFF0 for the 5 versions of that routine. So apparently these addresses are also relevant.
Oh, I missed the last part of that code of which the sources are in the ROM image:
420B ld a,(ix+#01) DD 7E 01 420E ld hl,#4000 21 00 40 4211 call #000c CD 0C 00 4214 cp #41 FE 41 4216 jr nz,#423a 20 22 4218 inc hl 23 4219 ld a,(ix+#01) DD 7E 01 421C call #000c CD 0C 00 421F cp #42 FE 42 4221 jr nz,#423a 20 17 4223 push hl E5 4224 ld hl,#5000 21 00 50 4227 ld bc,#0025 01 25 00 422A push bc C5 422B ld a,(ix+#01) DD 7E 01 422E call #000c CD 0C 00 4231 pop bc C1 4232 cpi ED A1 4234 jr nz,#4255 20 1F 4236 jp pe,#422a EA 2A 42 4239 pop hl E1 423A ld a,(ix+#01) DD 7E 01 423D ld hl,#8000 21 00 80 4240 call #000c CD 0C 00 4243 cp #41 FE 41 4245 jr nz,#4252 20 0B 4247 inc hl 23 4248 ld a,(ix+#01) DD 7E 01 424B call #000c CD 0C 00 424E cp #42 FE 42
So the source code in the ROM is actual code as it appears from 0x41BB to 0x424E.
According the article and the Rom dumps with RHx extension. The RAM of Rom Hunter mkii use ASCII 8k mapper only. Roms from cartridge with another mapper are patched.
I wonder if the internal RAM and ROM are each in a secondary slot or if it is configured otherwise.
Screw(s) covered by the label is also common. Usually you can feel this by going over the label with your fingers. If used, you have the choice between break things, damage label, or not open it up.
And yes, failed RAM chips is always a possibility. Pretty common actually. No reason this cartridge would be an exception to that rule even if unused most of the time.
Note that failed RAM chips don't prevent you from running test software & check what response you get. If eg. a RAM providing 1 bit failed, that leaves 7 bits that do behave like RAM. Garbage coming out != the usual FFh of 'empty' space. And mapper mechanisms are easy to detect as well.
Thx for the advice, I noticed seemingly two screw heads below "-" and "II" below the label on top of the cart. See if I can peel off the label without damaging. Photo No PIN.
gdx: I see no writes to 0xFFFF so there doesn't seem to be a SSR. There must also be some way to switch from RAM mode to ROM mode.
1. The fact that the SCC Roms have a different extension may mean that the loader applies a patch to the load. For Quarth or Metal Gear 2, I think the auto-detection of Rom mapper is not effective.
2. testRAM not support the Rom mappers. A "MegaRam" is not a "Memory Mapper".
3. Do not force! There are probably clips like Konami's cartridges.
5. Try with a Konami megarom without SCC sound or a megarom with ASCII 8k mapper
I decided to test with something simple as 16KB Moon Landing from ASCII. The dump became 32KB, 0 to &H3FFF filled with FF, but still ran fine on emu. Tried to play with the utility disk and real MSX. Disk is reading, a few moments passed, and MSX rebooted but instead of the Rom Hunter rom tape menu, MSX-DOS booted from the diskette in the disk. Whatever, there must be a reason all the dumped files that failed/modified from the original has .RHT extension. Files PIN: lowgravityadds16kb
Note that it looks like the program does all writing via the WRSLT call. Does that even make sense?
Is that slowing Rom Hunter? Another followup; Rom Hunter can't dump Game Master 2. Only initial 32KB was dumped. No wonder given GM2 didn't exist at 1986. Result PIN: globalwarmingkilledpenguin I looked at other failed dumps and it looks RH could dump only the initial 32KB in all cases.
You can manually check the RAM and Rom mapper with SHEM.