Information underneath is for emulating the Matra INK mapper.

48KB ROM at $0000-$BFFF (or maybe 64KB with the last 16KB set to $FF, dunno, not gonna open up the cartridge to check), it's got some kind of key protection that sets the cartridge slot area to different values (I've seen this on a NES mapper too, so it's not too unusual). The 3 keys are 19 bits: high part: 8 bits data, low part: 11 bits address, they can be written on the whole 64KB range.

The 3 keys are (in binary so you can see the pattern):
1: 1010101010101010101
2: 0101010101010101010
3: 1001000010101010101

I've tried other obvious patterns, and brute forced #3, but didn't find any other combinations.

It basically works like this:

start:
write to cart slot? if value != key1 then goto start, else continue
write to cart slot? if value != key2 then goto start, else continue
write to cart slot? if value != key3 then goto start, else set the 64KB ROM space (even $C000-$FFFF) to a string of $01, $A4, $00, $01, continue
write to cart slot? any value, set 64KB space to normal, goto start

In other words, to set the ROM space to $01, $A4, $00, $01, etc, it will write $AA to $x555, then $55 to $x2AA (or $xAAA), then $90 to $x555.

Here's it emulated in pseudo C code:

#define INK_KEY1 0x55555 /* 1010101010101010101 */
#define INK_KEY2 0x2aaaa /* 0101010101010101010 */
#define INK_KEY3 0x48555 /* 1001000010101010101 */
static const int ink_key[4]={INK_KEY1,INK_KEY2,INK_KEY3,0};
static const int ink_hidden_mem[4]={1,0xa4,0,1};
static int ink_inc=0;

slot1read(address)
{
	if (ink_inc==3) return ink_hidden_mem[address&3];
	else return normal_read();
}

slot1write(address,value)
{
	if (ink_inc<3 && ( (value<<11) | (address&0x7ff) )==ink_key[ink_inc]) ink_inc++;
	else ink_inc=0;
}

Something I didn't think of before (but won't affect result emulation), it could even be a 128KB ROM, with the 2nd 64KB set to those 4 values, and writing the 3 keys causing a bankswitch
We won't know for sure until dumping the ROM with an electronic reader.

Um, so, how did you find it out?
It seems you don't have a dump to test the implementation, then?

er.. reverse engineered with help from: meisei tracer, blueMSX+Sunrise Gamereader+INK cart, bunch of custom ASM programs, blueMSX debugger. I have the dump, I'll email it to you for openMSX.

Sending a dump of a copyrighted game that is still on sale? Cool, let's post it somewhere and we won't need to buy it.

Don't worry, it won't be spread any further than trusted MSX emu developers.

I don't have Ink to test it, but from hap info I think the cartridge uses a 512K flash memory from AMD (AM29F040B)
Probably it has no mapper, just plain memory in #0000-#FFFF (flash sector number 0 or 7 perhaps)

The hidden memory or alternative ROM is just the flash response to the "Auto select mode" command. So those bytes means:
xxx0 Manufacturer ID: #01 = AMD
xxx1 Device ID: #A4 = Am29F040B
xxx2 Sector Protection Verification: #00 = Unprotected

As you probaly now the "Auto select mode" command is:
x555 = AA
x2AA = 55
x555 = 90

The AMD flash is already emulated in blueMSX and is used in e.g. the MegaFlashRomSCC and Obsonet. But I don't think there is a non megarom mapper with the flash emulation so I probably need to add one.

I suppose the flash in the INK cart is is write protected. Can anyone confirm this?

hah, cool! (Guillian and hap info combined!)

Quote:

I suppose the flash in the INK cart is is write protected. Can anyone confirm this?

Since the flash answers the "Auto select mode" command, it seems the /WR signal is connected. Also, the sector is not protected according the answer it gives. So perhaps the flash can be erased and reprogramed.

Interesting coincidence

The flash is lying It seems to be write protected somehow, I've tried to erase the chip (555 aa, aaa 55, 555 80, 555 aa, aaa 55, xxx 10), and program 1 byte (555 aa, aaa 55, 555 a0, xxx xx), both didn't do anything.
By the way, blueMSX source (openMSX too maybe, haven't checked) masks 12 address bits, it should be 11: xb55 is the same as x555, xaaa is the same as x2aa.

Hmmm... strange.
I think the flash is not lying, so the sector must be unprotected. Also the /WR signal is connected, because the flash accept commands.
So here is my theory:
The /WR or /RD signal is connected to an address line of the flash (A18-A16). In this way, different 64k memory sectors are selected when you read or write.

Quote:

Don't worry, it won't be spread any further than trusted MSX emu developers.

Haha, about the funniest remark I have seen here in a long time

So it is OK to make illegal copies of a game still being sold and limit the spreading to trusted MSX emu developers!

Of course dont trust MSX hardware developers and dont trust game developers and dont trust your girlfriend, for only emu developers can be trusted and then its OK!

This gives an interesting insight into the OpenMSX emu developers mentality. So strong an opinion about not spreading copyrighted material, but internally just swapping the stolen stuff ....

If you are that principal about legality, give at least the dump only to MSX developers who can proof they own the software.

I suppose the MRC crew will now quickly come into action and mod away these scandelous illegal posts!

Even if the sector is protected you can get the "auto select mode". THe protection only prevents writes and erases. I can't remember what happens to the status bits when you try to erase or write to a write protected AMD flash.

Btw, I suppose this mapper would work with all Matra games like Sudoku and others although they don't rely on the AMD flash for execution.

Quote:

er.. reverse engineered with help from: meisei tracer, blueMSX+Sunrise Gamereader+INK cart, bunch of custom ASM programs, blueMSX debugger. I have the dump, I'll email it to you for openMSX.

sigh...

Quote:

I suppose the MRC crew will now quickly come into action and mod away these scandelous illegal posts!

I suppose they won't. Again: sigh...