The mode A 8k dump does contain some byte every 0x2000 bytes. A register?
The zeroes could just be the empty RAM.
@RetroTechie I mailed to what seems to be the email address in your profile. If you didn't receive, please inform.
@Manuel RH overwrites the Konami SCC mapper? I could not hear the sound difference between the original and RH dumped rom so it doesn't affect the SCC part.
To think of that I am wondering what happens if a SCC Konami game is forced to run without SCC. Simply crash?
RH overwrites the Konami SCC mapper?
This is what I said above. Also RH switches pages of ASCII8 mapper at launch. That's why I thought that only the mapper is supported because it's easier to convert the SCC mapper to the konami mapper. If RH have also Konami and ASCII16 mapper modes, ASCII8 is the default mapper. I asked you to check that with SHEM. RH uses 60FFh, 68FFh, 70FFh and 78FFh as addresses to switch the pages. Bits 7 to 4 are probably used to remove the 8kB internal rom and maybe other things like RAM write protect or mapper mode.
To think of that I am wondering what happens if a SCC Konami game is forced to run without SCC. Simply crash?
No crash. SCC sound is just missing.
I made some mistakes in my previous debugging session.
This is what the ROM does when it starts up:
Wrote to ROM address: 0x3fff, value: 00
Wrote to ROM address: 0x60ff, value: 00
Wrote to ROM address: 0x70ff, value: 00
Wrote to ROM address: 0x4000, value: 00
Wrote to ROM address: 0x8000, value: 00
Wrote to ROM address: 0x8001, value: 00
Wrote to ROM address: 0x8002, value: 00
The latter 3 are (probably) writes to RAM.
And when loading a Konami game from tape:
It just loads the file and writes the first 16kB to 0x8000-0xbfff.
Then it writes 1 to 0x7000. This could mean there's an ASCII16 mapper, because this is compatible with switching in the 2nd block of an ASCII16 mapped ROM into page 2.
Then it loads the 2nd block to the same locations, writes 2 to 0x7000, etc.
After loading the last block:
Wrote to ROM address: 0x7000, value: 0x8
Wrote to ROM address: 0x6010, value: 00
Wrote to ROM address: 0x6810, value: 0x1
Wrote to ROM address: 0x7010, value: 0x2
Wrote to ROM address: 0x7810, value: 0x3
Wrote to ROM address: 0x3fff, value: 0xd
Wrote to ROM address: 0xffff, value: 0xf0
Wrote to ROM address: 0xbf00, value: 00
Wrote to ROM address: 0xbf00, value: 0xff
Wrote to ROM address: 0xfe00, value: 00
Wrote to ROM address: 0xfe00, value: 0xff
Can someone explain the other writes?
For other mappers this happens after loading:
ASCII8 (A Life M36 Planet):
Wrote to ROM address: 0x7000, value: 0x8
Wrote to ROM address: 0x6010, value: 00
Wrote to ROM address: 0x6810, value: 00
Wrote to ROM address: 0x7010, value: 00
Wrote to ROM address: 0x7810, value: 00
Wrote to ROM address: 0x3fff, value: 0x9
ASCII16 (Jagur):
Wrote to ROM address: 0x7000, value: 0x8
Wrote to ROM address: 0x6010, value: 00
Wrote to ROM address: 0x6810, value: 00
Wrote to ROM address: 0x7010, value: 00
Wrote to ROM address: 0x7810, value: 00
Wrote to ROM address: 0x3fff, value: 0x8
So, Konami was:
Wrote to ROM address: 0x7000, value: 0x8
Wrote to ROM address: 0x6010, value: 00
Wrote to ROM address: 0x6810, value: 0x1
Wrote to ROM address: 0x7010, value: 0x2
Wrote to ROM address: 0x7810, value: 0x3
Wrote to ROM address: 0x3fff, value: 0xd
For Moonlanding (plain 16k ROM), the story goes differently:
During loading I see this:
1. write of 1 to 0x7000 (i.e. block 1 mapped into page 2?)
2. write of 2 to 0x3FFF
3. writes of 0xFF from 0x4000-0x7FFF (apparently they are read from the tape)
4. ROM data is written from 0x8000-0xBFFF (also read from the tape)
5. write of 0xA to 0x3FFF
For a 32kB ROM step 3 just loads the first 16kB of the ROM image and step 4 the 2nd 16kB.
For an 8kB ROM, the 32kB of data just contains 4x the 8kB ROM.
So the exception is the 16kB game, where the first 16kB are 0xFF.
Just tried with Athletic Land, another 16kB game. This one goes as expected: the ROM is written twice to the tape, so that one would be OK.
Takamichi: can you make a 64kB slot dump of the slot in which the ROM Hunter MK2 is? You can use saverom.com for instance.
Also: can you run MSXMEM2.BAS (with the cartridge inserted of course) and make a screenshot?
I think it will detect the RAM in page 2 at least.
Sorry I sent my MSX for repair. And, I am going to send the RH cart to RetroTechie for further investigation.
BiFi discovered that the tape file contains a byte identifying the mapper type:
D1 is normal up to 32K
D4 = ASCII8
D5 = ASCII16
D6 = KONAMI
D7 = unknown
D8 = ASCII8 with SRAM
D9 = ASCII16 with SRAM
DA = KONAMI with SRAM? (GM2 doesn't get dumped strange enough)
DB = unknown
BiFi and I come to the following conclusion:
3FFF is a configuration register:
bit 1: 0: ROM hunter ROM in page 1 for READs, writes ignored. 1: writes go to
RAM in page 1, mapper switching disabled
bits 2 and 0 is a mapper selector:
00 = ASCII16 (default),
01 = ASCII8,
11 = Konami,
10 = unknown (some kind of Konami 16 like variant?)
bit 3: RAM write protect: 0 is write enable, 1 is write protect (default 0). 1
also set reads in page 1 to RAM.
Implementing this in openMSX right now. With this, the software seems to work fine. But I noticed that not all games run on all MSX machines with ROM Hunter Mk2. A simple machine like the Panasonic FS-A1F worked best so far.
UPDATE: You can find the device implemented in openMSX in the next development build (334). Enjoy!
By the way, on a real MSX with a 256kB ROM dumped to tape at 1200 baud, loading will take about 40 minutes. Enjoy not having to really wait for that!