Is there any info on CNROM, MMC1, and limited MMC3/FME7 mapper conversions with CHR-ROM yet?
You mean, have I done anything with them? I did one MMC1 game, but it was originally UNROM. All other conversions I've done are UNROM so far.
Like to see that if so, Otherwise good luck,
Reason for Asking: I tried redoing your NES code in SNES ASM, But the comparsion with 65816 instructions (like used in your PCE version of $2002) needed have no equivelent!
The instructions themselves could probably be converted over to 65816 itself. But that's not the problem. The problems is the system architecture. You'd pretty much have to re-write the video and audio emulation core for the SNES, among other things. Though you could probably use some of the same techniques. I dunno. My emulation core is writing to VRAM during active display. I'm not sure that kind of approach is gonna work out on the SNES. You might have to do something like a 1 frame base delay or such, to keep things/updates in sync (NES is updating vram during vblank, the realtime conversion/emulation to SNES side is going to take it out of vblank range. So you could just convert it to ram and then DMA it on the next frame. That complicates things though). That, or completely re-write all the tile/sprite/map routines to be native SNES format. That also means it'll be game specific. I purposely didn't take that approach, so that I could reuse my emulation cores for other games and gettings results very quickly (getting the game up and running within a few days work).
I've traced, RE'd, and documented quite a bit of MM object/tile/map routines. I started adding a few hooks. Bisqwit's doc helped quite a bit, but it wasn't easy enough just to follow along by itself. I used it as a reference point to look at the code running in the game. But it was a big help. Many thanks to him and his doc.
After going back and forth about how to implement the sprite upgrades, I've decided to do it on an emulation level. That is to say, I upgraded the original NES OAM table since there was three unused bits:
NES OAM attribyte byte:
||||||++- Palette (4 to 7) of sprite
||+------ Priority (0: in front of background; 1: behind background)
|+------- Flip sprite horizontally
+-------- Flip sprite vertically
D2 = High palette bit
D4-D3: Sprite size
00b = 8x8 NES flipping based on 8x8
00b = 16x16 Native PCE flipping (if upper palette bit set)
01b = 32x16 Native PCE flipping
10b = 16x32 Native PCE flipping
11b = 32x32 Native PCE flipping
So now normal NES sprite behavior can co-exist along side extended sprites. This also means you can show more sprites on screen since the OAM table will be more efficient with the new sprite sizes. There's also 8 subpalettes now instead of 4. Using any of the upper subpalette automatically puts you in extended sprite mode (i.e. no 8x8 cell size relative to flipping X/Y. If the sprite cell is left as 8x8, it'll be flipped as if it was in a 16x16 cell - whether you see the extra data or not). You don't need to use the extended sprite cell format to use 4bit pixel mode either.
As for 4bit sprite cells (15colors VS 3colors), that support was always there just no NES equiv function. I'll make a pseudo sprite DMA command for transferring sprite pixel data to tile banks (for both 8x8 in 16 colors and native 16x16 cells in 16color format).
Basically, making it so that you don't need to know any
PCE hardware. Just hack it as if it were an normal NES game, just a with extended functions and graphics.