Fail Rom flash AM29F040

[retrocant]

Greetings, I am having problems recording the msx-usb flashrom, it gives me the following error:

MSXUSB Flash, (c) 202 S0urceror

M: E5, D: CD M: CD, D: AB M: F0, D: 1F M: FF, D: FF

cannot find slot with flash

I am doing the flash method through the MegaFlashrom

[S0urceror]

Hi Retrocant,

My routine expects to find:

// Am29F040B = A4

// M29F800AB = 58

// SST39SF040 = B7

These are all 4Mbit/512KB flash ROM’s. Could be that you have the AM29F400BB that has device code ‘AB’ in your 2nd line.

To force flashing on slot 1 use:

flash.com /S1 [filename]

Can you confirm it works then I’ll add AB to my identification routine.

Thanks,

S0urceror

From: retrocant notifications@github.com Reply to: S0urceror/MSX-USB reply@reply.github.com Date: Wednesday, 29 July 2020 at 17:00 To: S0urceror/MSX-USB MSX-USB@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [S0urceror/MSX-USB] Fail Rom flash AM29F040 (#1)

Greetings, I am having problems recording the msx-usb flashrom, it gives me the following error:

MSXUSB Flash, (c) 202 S0urceror

M: E5, D: CD M: CD, D: AB M: F0, D: 1F M: FF, D: FF

cannot find slot with flash

I am doing the flash method through the MegaFlashrom

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[retrocant]

Greetings, I already did the flash / s1 NEXTOR.ROM routine and it doesn't work either, it gives me the same error.

Greetings.

[S0urceror]

Which MSXUSB cartridge did you make? The CPLD version? Did you use the latest design or the first design? The first design had two issues that you can easily solve with a couple of wires.

On the other hand what type/version of Flash chip have you installed? The AM29F040?

If you have the RookieDrive make sure you use the flash tool that came with that cartridge because it uses another ROM mapper and other Flash chip.

From: retrocant notifications@github.com Reply to: S0urceror/MSX-USB reply@reply.github.com Date: Thursday, 30 July 2020 at 18:18 To: S0urceror/MSX-USB MSX-USB@noreply.github.com Cc: Mario Smit mario.smit.nl@gmail.com, Comment comment@noreply.github.com Subject: Re: [S0urceror/MSX-USB] Fail Rom flash AM29F040 (#1)

Greetings, I already did the flash / s1 NEXTOR.ROM routine and it doesn't work either, it gives me the same error.

Greetings.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/S0urceror/MSX-USB/issues/1#issuecomment-666501659, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGC6KCOS5NVSOIFTGZYSLTR6GMOBANCNFSM4PLV7PHQ.

[retrocant]

Greetings, I have the CPLD version, I don't know if there were two different versions in that version ... how could I know?

I use FLASH AM29F040

[retrocant]

I just made the two bridges for the SLTSL and RD and it keeps giving me the same error, it doesn't flash me

[S0urceror]

Your PCB is the rev.1 version. There were two flaws in this. One was with RD and SLTSL reversed. The other was that A12 was not connected to the CPLD.

Have you also have created an extra bridge between Flash pin 4 and CPLD pin 17?

From: retrocant notifications@github.com Reply to: S0urceror/MSX-USB reply@reply.github.com Date: Friday, 31 July 2020 at 19:51 To: S0urceror/MSX-USB MSX-USB@noreply.github.com Cc: Mario Smit mario.smit.nl@gmail.com, Comment comment@noreply.github.com Subject: Re: [S0urceror/MSX-USB] Fail Rom flash AM29F040 (#1)

I just made the two bridges for the SLTSL and RD and it keeps giving me the same error, it doesn't flash me

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/S0urceror/MSX-USB/issues/1#issuecomment-667252912, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGC6KC3DYDCCSX43HZXVRLR6MADHANCNFSM4PLV7PHQ.

[retrocant]

Greetings, I already made the bridge in the CPLD and it works, I did not know about that bridge, I have it functional.

Now I have a question, there are two versions 0.5 and 0. release.

I have an 8GB FAT32 USB flash drive, version 0.5 works fine and it recognizes the flash drive, but version 0.6 does not recognize the USB.

[S0urceror]

Hi Retrocant,

Glad and good to hear that you have it working!

Until 0.5 the driver used the built-in FAT32 support of the CH376s chip. Starting 0.6 I implemented a low-level USB storage driver that also works behind an USB Hub. Now I have to rely on the FAT16 support of Nextor instead. If you reformat your drive to FAT16 it will work again with the added bonus it will also work on a Hub together with other USB devices.

That said, I could check what you have connected, if you have directly connected a USB storage device with FAT32, use the built-in driver, or otherwise fallback on my own storage driver that supports Hubs with FAT16. Would be a nice feature for a next release.

Regards,

Mario

From: retrocant notifications@github.com Reply to: S0urceror/MSX-USB reply@reply.github.com Date: Thursday, 6 August 2020 at 20:11 To: S0urceror/MSX-USB MSX-USB@noreply.github.com Cc: Mario Smit mario.smit.nl@gmail.com, Comment comment@noreply.github.com Subject: Re: [S0urceror/MSX-USB] Fail Rom flash AM29F040 (#1)

Greetings, I already made the bridge in the CPLD and it works, I did not know about that bridge, I have it functional.

Now I have a question, there are two versions 0.5 and 0. release.

I have an 8GB FAT32 USB flash drive, version 0.5 works fine and it recognizes the flash drive, but version 0.6 does not recognize the USB.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/S0urceror/MSX-USB/issues/1#issuecomment-670092006, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGC6KEELN3MDLWHQJRXGH3R7LW35ANCNFSM4PLV7PHQ.

[retrocant]

Greetings, the new boards have arrived, I have also tested revision 0.6 and it works with FAT16 on USB, the only thing I see is that it is not possible to mount DSK disks in this revision.

It occurred to me to be able to work with sofarun but I have installed it and my computer restarts every time I run sofarun.

A greeting.

[S0urceror]

Yes on 0.6 you cannot mount DSK’s anymore but you can use Nextor’s built-in functionality with MAPDRV or EMUFILE. This will create another driveletter and does also support switching multiple disk images with a hotkey for multi-disk-games.

On 23 Aug 2020, at 11:15, retrocant notifications@github.com wrote:

Greetings, the new boards have arrived, I have also tested revision 0.6 and it works with FAT16 on USB, the only thing I see is that it is not possible to mount DSK disks in this revision.

It occurred to me to be able to work with sofarun but I have installed it and my computer restarts every time I run sofarun.

A greeting.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/S0urceror/MSX-USB/issues/1#issuecomment-678750089, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGC6KF3S7HUDXRLXKRLOBLSCDM4JANCNFSM4PLV7PHQ.

[S0urceror]

Closing this issue, good that we traced the problem down to the reversed OE (output enable) and CE (chip enable). The latest published PCB with the clearly marked v1.0 on the silkscreen does not have this problem.

[issalig]

I cannot make it work. Tested on MSX1 VG-8020 with a pcb v1.0 and also other people reported similar problem with MSX2 f9s

I use a SST39SF040 which should give id BF B7 and I am getting these values

E5 CD 41, 42 41, 42 F0, 0

I checked the codes on http://www.cnc-lab.com/idcodes.txt and they does not seem to fit any IC.

I see that am29 uses addresses 0x555 and 0x2aa but sst39 uses 0x5555 and 0x2aaa , could this be the reason not to detect It?

Any idea?

[S0urceror]

Hi Issalig,

I made an earlier mistake in my PCB which I corrected in an updated design pushed to GitHub.

SLTSL from the cartridge port should be connected to CE (pin 22) and RD from the cartridge port should be connected to OE (pin 24) of the flash chip. Can you verify this with a multi-meter?

You now get 0x41,0x42 on slot 1 and 2. This means there are MSX roms read. A flash however should respond with the manufacturer codes which it doesn’t do now.

Let me know the result.

Regards,

Mario

From: issalig @.> Date: Saturday, 19 February 2022 at 14:07 To: S0urceror/MSX-USB @.> Cc: S0urceror @.>, State change @.> Subject: Re: [S0urceror/MSX-USB] Fail Rom flash AM29F040 (#1)

I cannot make it work. Tested on MSX1 VG-8020 with a pcb v1.0 and also other people reported similar problem with MSX2 f9s

I use a SST39SF040 which should give id BF B7 and I am getting these values

E5 CD 41, 42 41, 42 F0, 0

I checked the codes on http://www.cnc-lab.com/idcodes.txt and they does not seem to fit any IC.

Any idea?

— Reply to this email directly, view it on GitHubhttps://github.com/S0urceror/MSX-USB/issues/1#issuecomment-1046014088, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGC6KBZEUAGT6FBIHFOHM3U36I2HANCNFSM4PLV7PHQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you modified the open/close state.Message ID: @.***>

[issalig]

pcb is ok. CE nad OE are connected to SLTSL and RD

I tried to change bytecodes AM takes 0x555 and 0x2aa

and SST 0x5555 and 0x2aaa

Results are different now, but still does not work E5 CD FE, 5E <---- this was 41,42, the others are the same, and it changes from read to read ??? 41, 42 F0, 0

[S0urceror]

You’re on the right path.

Can’t test it here but if you:

• Change the at 0x4000 statement to at 0x0000 at line 30.
• Update all places where flash_segment is used with the right addresses.
• Write 0xAA to flash_segment[0x5555]
• Write 0x55 to flash_segment[0x2AAA]
• Write 0x90 to flash_segment[0x5555]
• Read manufacturer from flash_segment[0x0000]
• Read device from flash_segment[0x0000]

Then it should show you 0xBF, 0xB5 respectively.

Also the erase and flash routines have to be updated with the other addresses.

P.S. would be great to have all this governed by #defines and -D arguments in the Makefile. This way we can make multiple versions of the flash.com program each for every flash chip.

From: issalig @.> Date: Saturday, 19 February 2022 at 18:28 To: S0urceror/MSX-USB @.> Cc: S0urceror @.>, State change @.> Subject: Re: [S0urceror/MSX-USB] Fail Rom flash AM29F040 (#1)

pcb is ok. CE nad OE are connected to SLTSL and RD

I tried to change bytecodes AM takes 0x555 and 0x2aa [image]https://user-images.githubusercontent.com/7136948/154811944-6538cb52-a2f3-424a-99b8-54dce4acbc05.png

and SST 0x5555 and 0x2aaa [image]https://user-images.githubusercontent.com/7136948/154811965-dfe65dfc-1b24-4990-92ec-df4e47f2e548.png

Results are different now, but still does not work E5 CD FE, 5E <---- this was 41,42, the others are the same 41, 42 F0, 0

— Reply to this email directly, view it on GitHubhttps://github.com/S0urceror/MSX-USB/issues/1#issuecomment-1046066845, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGC6KGSNBVDLJIMKJVNKDDU37HMXANCNFSM4PLV7PHQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you modified the open/close state.Message ID: @.***>

[issalig]

Changing to 0x0000 and new adresses does not help. It prints the first 2 slots, then hangs for a little bit and restarts system without detecting msxusb

F0, D3 F0, D3 ...

I was having a look at fbelavenuto's update tool https://github.com/fbelavenuto/msxsdmapperv2/blob/2487b3fc9aec44cc669d92146a523a81c66d7061/SW/Updater/src/sdmapper.c#L84 and he is doing similar but writing to IOFW (0x5F that should be a particular register for his card)

Also took a look at the timings if that could be the problem, TIDA and TAA which should be 150+70 = 220ns . if clock is 4Mhz, one cycle would be 250 ns, and I guess that's why there are the dummy readings. And inserted some dummy readings after 0x90 but with same results. I will keep on trying.

[S0urceror]

Just remember that the select_slot_40 maps the flash into the range 0x4000 to 0x7fff. Not in the range 0x0000 to 0x3fff. As a result a read to 0x0000 returns just the data of the current subslot mapped in that range which is were the DOS program runs.

I think to do this successfully we have to move the entire program to the 0xc000-0xffff area. This allows us to map page 0 and 1 to the flash memory. Then we are able to access all addresses from the flash being 0x0000, 0x0001, 0x2aaa, 0x5555.

This is easiest by changing the program in a bload-able binary to start at 0xc000. For this we have to change the C setup a bit.

I can take care of the latter. If you can continue to check with your hardware based on the SST flash.

From: issalig @.> Date: Sunday, 20 February 2022 at 19:32 To: S0urceror/MSX-USB @.> Cc: S0urceror @.>, State change @.> Subject: Re: [S0urceror/MSX-USB] Fail Rom flash AM29F040 (#1)

Changing to 0x0000 and new adresses does not help. It prints the first 2 slots, then hangs for a little bit and restarts system without detecting msxusb

F0, D3 F0, D3 ...

I was having a look at fbelavenuto's update tool https://github.com/fbelavenuto/msxsdmapperv2/blob/2487b3fc9aec44cc669d92146a523a81c66d7061/SW/Updater/src/sdmapper.c#L84 and he is doing similar but writing to IOFW (0x5F that should be a particular register for his card)

Also took a look at the timings if that could be the problem, TIDA and TAA which should be 150+70 = 220ns . if clock is 4Mhz, one cycle would be 250 ns, and I guess that's why there are the dummy readings. And inserted some dummy readings after 0x90 but with same results. I will keep on trying.

[image]https://user-images.githubusercontent.com/7136948/154857865-4ec8d2c3-8683-4125-b693-21a6863cc5fc.png

[image]https://user-images.githubusercontent.com/7136948/154857904-79a62aa4-5ef4-4552-8a05-338075b518f8.png

[image]https://user-images.githubusercontent.com/7136948/154857927-5b2799c9-2941-4803-9dda-2c6002dada5b.png

[image]https://user-images.githubusercontent.com/7136948/154857773-281fa8aa-b422-4412-b814-63b6f9935251.png

— Reply to this email directly, view it on GitHubhttps://github.com/S0urceror/MSX-USB/issues/1#issuecomment-1046295704, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGC6KB3X4CUTNCPKQMQTVTU4EXSRANCNFSM4PLV7PHQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you modified the open/close state.Message ID: @.***>

[issalig]

I still do not fully understand the memory map in MSX, I will check this https://www.msx.org/wiki/Slots From the makefile I see that code is being generated for these addresses --code-loc 0x0180 --data-loc 0 which I assume is the normal MSX start address for programs.

Then, I have seen that this code changes to slot i and page 1 which I guess it is 4000h-07FFFh,

    ld a,(iy)   ;slot
    ld h,#0x40  ;01 00 0000  -> page 1
    jp  0x24 ; ENASLT  jp

I have seen that fbelavenuto https://github.com/fbelavenuto/msx-upd accesses to 9555 instead of 5555, so it seems he is adding the page base adress as an offset. But as you place the pointer of flash_segment to 4000 that would be the same.

I will keep on exploring what's happening.

[S0urceror]

Yes code-loc is 0x0180. Before that for 0x0100 to 0x017f is the $(FUSIONLIB)/$(CRT0) library which is kind of the bootstrap for the C application. MSX DOS applications always start at 0x0100 and can address up to 0xF380.

In MSX-DOS you cannot change the slot for page 0 (0x0000 to 0x3fff) because that would map the running program out of the address space (no good!). If you instead sit in page 3 (0xc000 to 0xffff) you can freely change page 0 to 2 with the ENASLT call.

Don’t know the SD mapper but it is possible that the ROM pages are mapped to page 1 and 2 and form kind of a shifted memory range. The Konami SCC mapper I made in the FPGA can work in all pages with a separate page selected. Including selecting ROM page 0 to MSX page 1 and ROM page 1 to MSX page 2. Maybe we can use that mechanism to do something similar to fbelavenuto.

From: issalig @.> Date: Monday, 21 February 2022 at 09:01 To: S0urceror/MSX-USB @.> Cc: S0urceror @.>, State change @.> Subject: Re: [S0urceror/MSX-USB] Fail Rom flash AM29F040 (#1)

I still do not fully understand the memory map in MSX, I will check this https://www.msx.org/wiki/Slots From the makefile I see that code is being generated for these addresses --code-loc 0x0180 --data-loc 0 which I assume is the normal MSX start address for programs.

Then, I have seen that this code changes to slot i and page 1 which I guess it is 4000h-07FFFh,

ld a,(iy)   ;slot

ld h,#0x40  ;01 00 0000  -> page 1

jp  0x24 ; ENASLT  jp

I have seen that fbelavenuto https://github.com/fbelavenuto/msx-upd accesses to 9555 instead of 5555, so it seems he is adding the page base adress as an offset. But as you place the pointer of flash_segment to 4000 that would be the same.

I will keep on exploring what's happening.

— Reply to this email directly, view it on GitHubhttps://github.com/S0urceror/MSX-USB/issues/1#issuecomment-1046572450, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABGC6KFGWP4PILMYV2XXAQLU4HWO7ANCNFSM4PLV7PHQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you modified the open/close state.Message ID: @.***>

[issalig]

I have been trying different things, but I do not get a clear picture of the RAM/ROM setup.

Slot 0 is for Main ROM 0000-7ffff and RAM 8000-ffff Let's say I have the msxusb cartridge in slot 1. In which page resides the msxusb rom? Page 1? In such a case, access to the first byte of the rom would be flash_segment[0] or flash_segment[4000] ?

I interpret that ENASLT changes the pointer to an specific device, and when we ask for an address instead of RAM we are accesing to ROM. But for example, where are the manufacturer and device variables stored? do they reside in cpu registers?

[S0urceror]

Yes the MSX memory system is fairly elaborate. Luckily on the MSX1 it is still simple. You have 4 primary slots with each 4 subslot. System BIOS is always in 0-0 (primary-secondary) RAM is in your case in 3-0 or 3-2. (VG8020)

In MSXDOS all 64KB RAM is mapped in when the program starts from 0x0100h. In my current flash program I first scan where the flash sits. It cannot be 0 or 3 but I scan then nevertheless out of simplicity. When it maps in slot 1 or 2 it tries to interrogate it if this is flash memory.

Flash chips normally always return the byte in memory when you read it. And when you normally write it nothing happens. But flash chips do something special if you try to write a series of bytes in a specific order. Then suddenly you don't get the original memory location returned but the information from the chip itself.

This way it knows it's flash and not a normal ROM or RAM.

To complicate matters further our Flash is not a normal 64KB chip but a 512KB chip. I put a SCC compatible mapper in FPGA that detects writes to 0x1000,0x5000,0x9000,0xD000 (flash_segment[0x1000]). When you write a 0 it selects flash page 0 and when you write a 1 it select page 1.

What needs to be changed in the program to make it compatible with your chip?

• change the __AT flash_segment line back to point to 0x4000
• copy and paste the select slot 40 routine into a select slot 80 routine and change ld h, 40h to ld h,80h
• do the same with the select ram slot 40 routine
• in find_flash under select_slot_40 you add a call to select_slot_80(i)
• in find_flash under select_ramslot_40 you add a call to select_ramslot_80(i)
• insert at the beginning of flash_ident two statements to have the right flash pages selected, it now assumes the default
• this is: flash_segment[0x1000] = 0 and flash_segment[0x5000] = 1
• update flash_ident to address addresses + 0x4000.
• So 5555 becomes 9555 and 2aaa becomes 6aaa.

[issalig]

Thanks for the explanation. I am getting a better picture of the situation and I did the changes but the code does not still work and it hangs when scanning slot 2.

Let's try to understand it, flash_segment points to address 0x4000 (page 1, after system rom). Next, select_slot_40 selects page 1 on slot i, that means we have access to flash chip on msx memory addresses 4000-7ffff The same is done for slot_80 and msx addresses 8000-BF000

So flash_segment[0] points to 0x4000 that itself points to 0x4000 in slot i (aka our cartridge).

We need to access flash address 0x5555 which resides in the page 1 (4000-7fff) and flash_segment points to 4000. Would not flash_segment[0x1555] be the indirect address to arrive to internal 0x5555 ?

If this is correct, then 0x2aaa could not be reached but I am almost sure I misunderstood sth.

[issalig]

I did a sketch of the idea above

[S0urceror]

I am commenting below:

Let's try to understand it, flash_segment points to address 0x4000 (page 1, after system rom). Next, select_slot_40 selects page 1 on slot i, that means we have access to flash chip on msx memory addresses 4000-7ffff The same is done for slot_80 and msx addresses 8000-BF000

That is correct.

So flash_segment[0] points to 0x4000 that itself points to 0x4000 in slot i (aka our cartridge).

It points indeed to 0x4000 to slot i. But what ROM page is mapped there? That depends on a previous write to 0x5000. This triggers the FPGA to select page 0 which is address range 0x00000 to 0x04000. So from now on a write to a CPU address of 0x6aaa is actually targeting flash address 0x02aaa.

We need to access flash address 0x5555 which resides in the page 1 (4000-7fff) and flash_segment points to 4000. Would not flash_segment[0x1555] be the indirect address to arrive to internal 0x5555 ?

If as stated above the CPU address range 0x4000 to 0x7fff points to page 0 being flash range 0x00000 to 0x03fff and we make sure that CPU address range 0x8000 to 0xbfff points to page 1 being flash range 0x04000 to 0x07fff. Then we need to write to CPU address 0x9555 to write to flash address 0x05555.

I'll try to test the above theory out and report back. This would enable you to address 32k of the flash and reach all the addresses the flash-ident and flash-write routines need to function.

[issalig]

Looking at the verilog scc code I see that when a write is detected, the values of a15,a13,a12 establish the following addresses. | A15 | A14 | A3 | A12 | | 0 | ? | 0 | 1 | 1XXX, 5XXX | 0 | ? | 1 | 1 | 3XXX , 7XXX | 1 | ? | 0 | 1 | 9XXX , DXXX | 1 | ? | 1 | 1 | BXXX , FXXX

In a similar way a read gives

| A15 | A14 | A3 | A12 | | 0 | ? | 0 | ? | 0XXX, 1XXX, 4XXX, 5XXX | 0 | ? | 1 | ? | 2XXX , 3XXX, 6XXX, 7XXX | 1 | ? | 0 | ? | 8XXX , 9XXX, CXXX, DXXX | 1 | ? | 1 | ? | AXXX , BXXX, EXXX, FXXX

(*) the ones for write.

So for example a write to 0x5000=0 will put mem0 into address_upper and data into mem0 address_upper are the pins A18-A13 and data will be 0 in this case.

case(a15_a13_a12[2:1])
            2'b00: address_upper = mem0;

case(a15_a13_a12)
   3'b001: mem0 = data;

I checked the addresses below with the ones in https://www.msx.org/wiki/MegaROM_Mappers#Konami.27s_MegaROMs_with_SCC and I am lost at this point. I must find some documentation for dummies because reverse engineering this from code will take me years.