That's a great point. -- I wasn't consdiering the ramifications of multiple bank switching registers...Joe wrote: ↑Wed Jan 11, 2023 12:52 pm If you have more than one bank register, you need to select which one of those registers will drive the ROM's upper address lines according to the cartridge bus upper address lines, and those ROM address lines have to be driven quickly enough for the ROM to produce the correct data within the time limit.
I guess it could still work with some extra glue logic in a GAL (i.e. address lines and mcu bank control lines go into the GAL, and the high address lines come out), but I really hate it...
I was wondering if anyone would do that. Neat that someone is working on it! -- I saw that the NES re-reads the palette info each scanline.
For me it was about getting more colors into the same 16x16 block. -- I find it really limiting, and I saw that Nintendo made a chip that "fixes" it, so I wanted to use it. -- But yuck, this is just getting really muddy.
To check my understanding the 16x1 could be accomplished by just bank switching on every hblank, right? -- and for 8x1 it would have to bank switch after every palette read (outside of vblank), right?
How hard is it to get a custom mapper accepted by the emulation community? -- Like if someone puts a custom mapper chip in their game that doesn't exist anywhere, can they just share it with the emulator authors? -- Or what is the best way?
I don't follow why, for example, it couldn't accomplish everything the MMC3 does (aside from multiple bank switching registers without some extra glue logic, as Joe points out)?
I would have to look a the other m19 and m69 though to understand where the shortcomings are; I think you could build something really neat out of that layout. But there's probably some other dragon in the details that I haven't spotted yet.