A second generation design could add work RAM and expand the program ROM to a fixed region below 0x8000 and a banked region up high.

ROML's boot sequence would move the VIC-II to point at the ROMH chip, make it display something, and then enter an idle loop.

Pure proof-of-concept.

Your boot code is actually in the graphics ROM, in bank 0 offset 0xFFFE: the reset vector. That has to point to 0x8000, the bottom of ROML.

So you get your ROM chips. One of them is for code, one is for data. Use the '040 512KB flash chips for shits and giggles.

We can start with the same basic design as Magic Desk: a latch to set the bank for program ROM, and then add another latch for video ROM. Those latches set the high bits of the ROM addresses, and get written to using I/O addresses.

The mapper itself needs to be able to remember banking state, though. So a CPLD would be appropriate here, if you didn't want to use external latches.

The "mapper" is a PLD, which takes in A0-A15, and outputs select signals for the chips on the cartridge.

It comes down to designing the mapping to match the needs of the game, or rather, designing different mapping arrangements for different kinds of game.

Decoding the address bus directly also makes it trivial to overlay RAM on the screen matrix where we need to - for example, we might want a modifiable header or footer.

That means we have two banked regions for graphics ROM: 0xC000-0xCFFF, and 0xE000-0xEFFF. We probably want to bank switch program code, too; so why don't we ignore the /ROML and /ROMH signals completely, decode the address bus directly, and stick "static" ROM from 0x2000-0x9FFF, and banked ROM from 0xA000-0xBFFF?

We can put banked ROM from 0xC000-0xCFFF, and use that for storing sprite bitmap data.

We need the ROM space from 0xFFF0-0xFFFF for IRQ/NMI vectors, so we want to bank switch our ROMH from 0xE000-0xEFFF; we can point the VIC-II at that for charset and screen matrix data, and still have room for the matching pre-allocated colour RAM data to copy to real colour RAM.