Doubt about developing a 128kb MegaROM (ASCII 16K Mapper)

Page 1/2
| 2

Par albs_br

Master (199)

Portrait de albs_br

02-11-2020, 13:48

I was looking this code (for tniAsm): https://www.msx.org/wiki/Develop_a_program_in_cartridge_ROM#...

And I'm curious with the "Seg_P8000_SW: equ 07000h", as the page 0 uses the addresses from 4000h to 7FFFh, should I to take care to not get over 7000h with my code/data in the page 0?

!login ou Inscrivez-vous pour poster

Par Grauw

Ascended (9580)

Portrait de Grauw

02-11-2020, 13:56

The bank select registers are write-only, when read these addresses return the ROM code and data as normal.

Par thegeps

Paladin (670)

Portrait de thegeps

02-11-2020, 14:16

Yep, I had the same doubt when coding Freedom Fighter. Once you get it right (and trust me, try it and you get it in no time) it is a joke to manage Wink

Par albs_br

Master (199)

Portrait de albs_br

02-11-2020, 14:32

Now I am even more confused: how is possible to write on an address in the ROM?

I mean, the entry point of the cartridge is 0x4000, so the page 0x4000 to 0x7fff is ROM... How can the 0x7000 address be written?

Also, the comment says: "; Segment switch for page 8000h-BFFFh (ASCII 16k Mapper)". I suppose there are other types of MegaROM management. How is it chosen? Who manages this?

I know these questions should sound silly for who learned 30 years ago, but on my first "life" with MSX I haven't get far into these low level hardware concepts.

Thanks for helping.

Par Grauw

Ascended (9580)

Portrait de Grauw

02-11-2020, 15:15

The Z80 signals a read request (/RD pin) or a write request (/WR pin) together with the address on the address bus A0-A15 and the value on the data bus (D0-D7). In a plain 32K ROM the ROM chip is directly connected to these via the cartridge slot (and /WR is left disconnected). However in MegaROM there is a mapper IC on the cartridge in-between the Z80 and the ROM.

When a /WR write signal is received from the Z80 the ASCII16 mapper IC checks if the address is in the range 6000H-6FFFH or 7000H-7FFFH and if so will set the value specified on the data bus into its corresponding bank select register, otherwise the write is ignored. It only checks the address bits A12-A15 so that’s why it spans a range rather than a single address (this reduces transistors needed).

When a /RD read signal is received from the Z80 the ASCII16 mapper IC takes address bits A0-A13 and concatenates them with the current value of the corresponding bank select register to form a 22-bit physical ROM address A0-A21 (max 2^22 bytes = 4 MB). This address is passed to the ROM chip, which will then return the value to the CPU on the data bus.

The differences between different mapper types lie in what addresses they respond to for their bank select registers, and which address bits they use for their banks. E.g. the ASCII8 mapper with 8K banks has four bank registers instead of two, and uses A0-A12 together with the bank select register to form a 21-bit address (2MB).

As for emulators, in absence of a physical cartridge you provide them with the ROM contents + a mapper type to emulate. If no mapper type is specified, the emulator first tries to look up a hash of the ROM in a database. If it is not recognised, it tries to guess the mapper type by looking if the ROM has code that writes to bank select addresses that belong to a particular mapper type. This guessing is not 100% so it can fail under circumstances, so best to specify the mapper type explicitly.

Par mcolom

Master (181)

Portrait de mcolom

02-11-2020, 14:52

albs_br wrote:

Now I am even more confused: how is possible to write on an address in the ROM?

I mean, the entry point of the cartridge is 0x4000, so the page 0x4000 to 0x7fff is ROM... How can the 0x7000 address be written?

It can be written, but of course if you switch the page you're currently executing on it'll probably crash.
Normally what I do is to run in page 1 (0x4000-0x7FFF) and I use page 2 (0x8000-0xBFFF) to load cartridge's segments.

albs_br wrote:

Also, the comment says: "; Segment switch for page 8000h-BFFFh (ASCII 16k Mapper)". I suppose there are other types of MegaROM management. How is it chosen? Who manages this?

It depends on the hardware of the cartridge and there are several standards. How emulators detect which one? To me that's black magic Big smile but normally I use address 0x8000 to switch ROM pages (it's one Konami mapper, I don't remember which one now) when I develop with openMSX.

albs_br wrote:

I know these questions should sound silly for who learned 30 years ago, but on my first "life" with MSX I haven't get far into these low level hardware concepts.

Not silly at all. Actually those ROM mappers were intented to be literally put inside a black box.

Par albs_br

Master (199)

Portrait de albs_br

03-11-2020, 16:00

Thanks, @Grauw and @mcolom, it's indeed an interesting way to solve this problem, cheers to the designers.
Also, it's cool how is required some (at least) basic hardware knowledge to develop in ASM.

Par albs_br

Master (199)

Portrait de albs_br

03-11-2020, 16:57

Related question: if I put a value over 7 in the address with:
ld (Seg_P8000_SW),a

Will it work? What is the limit?
In this link: https://www.msx.org/wiki/MegaROM_Mappers#ASC16_.28ASCII.29 it is stated that 4096kb are possible.
In that case there would be 256 segments x 16Kb each = 4096kb

Is it correct?

Par mcolom

Master (181)

Portrait de mcolom

03-11-2020, 17:29

It depends on the mapper.
For the one I use (I think it's the "Generic8": https://www.msx.org/wiki/MegaROM_Mappers#Generic8), I do this:

set_two_segments_P8000:
; A: segment. It'll also choose segment A+1
ld (Seg_P8000_SW), a ; 0x8000 - 0x9FFF
inc a
ld (Seg_PA000_SW), a ; 0xA000 - 0xBFFF
ret

So, it switches 0x2000 bytes every write. So, a total of 0x2000*256 = 2 Mb.
But actually I'd say that in a real cartridge you're not really much limited. The hardware can could do crazy things to page memory (like ready sequentially bytes from 0x8000 to get a large address, for example). I've never found anything like that, but I don't see why you wouldn't be able to build such a thing. Of course, I mean only with real hardware.

Par albs_br

Master (199)

Portrait de albs_br

04-11-2020, 03:02

Just tested here. Worked like a charm. MegaROM using ASCII 16k Mapper with 256 segments of 16kb = 4096kb (or like they used to say on the old times "32 Megabit cartridge", more than almost all SNES carts).

Only issue was that openMSX can't detect automatically, I had to choose the right mapper. Now I will try to discover how to tell the emulator the mapper type.

Par NYYRIKKI

Enlighted (5691)

Portrait de NYYRIKKI

04-11-2020, 05:49

albs_br wrote:

Only issue was that openMSX can't detect automatically, I had to choose the right mapper. Now I will try to discover how to tell the emulator the mapper type.

mcolom wrote:

It depends on the hardware of the cartridge and there are several standards. How emulators detect which one? To me that's black magic Big smile

Unfortunately I have to tell you that 99% of the time it is not black magic, but just sleight of hand... Practically these emulators just cheat.

In openMSX share-folder there is a file called softwaredb.xml that contain description of each MSX cartridge. If you open it, add your own software entry there, add inside correct mapper type and your ROM-file's valid SHA-1 checksum, openMSX will then "magically" select the correct type.

When this check fails I've heard rumors that it then tries to make some "educated guess" based on pattern search, but at least those few times I've worked with unknown ROMs, that recognition has just failed miserably... I've seen some ROM source codes where people have copy/pasted some dummy, unused mapper select routines here and there around the code, so unless this is pure superstition I guess it may have helped at least someone on some case... but this then indeed belongs to the black magic category where you just try to exorcise emulator to use it's supernatural hardware imagination powers. I don't have any good spells to share for emulators that are currently in use.

Page 1/2
| 2