A user on Discord asked why I haven't yet ported nrom-template to MMC3. My short answer: It's such an open question that I have no idea how to begin.
By the time I made nrom-template and snrom-template (July 2011), I had already completed at least two solo NROM games: Concentration Room and Thwaite. I had also made tech demos for MMC1 (Forbidden Four) and UNROM (Who's Cuter). nrom-template formed the basis of Zap Ruder.
By the time I made bnrom-template (February 2018), I had already completed a few BNROM projects: early prototypes of Action 53, Haunted: Halloween '85, and 240p Test Suite version 0.13.
I feel I lack the experience to demonstrate good practices in organizing an MMC3 program that uses CHR ROM. This is because I have never built a substantial project beyond simplistic emulator tests that uses MMC3 with CHR ROM. I haven't made a solo game that uses MMC3's unique selling points, namely the timer, fine-grained CHR switching, or DPCM bank switching. In particular, the TGROM port of 240p Test Suite is in effect a mapper hack of the UNROM version, made largely for people with MMC3 devcarts or for inclusion on an MMC3 multicart. I have programmed three MMC3 games for Retrotainment, namely Haunted: Halloween '86, Full Quiet, and Garbage Pail Kids, and a fourth was recently shown at Portland Retro Gaming Expo. These use the timer for prominent parallax scrolling but depend on 32 KiB CHR RAM, which isn't reliably emulated on non-desktop devices.
I don't know how opinionated tlrom-template and tgrom-template ought to be with respect to how they organize ROM. These are the dimensions I can think of:
By the time I made nrom-template and snrom-template (July 2011), I had already completed at least two solo NROM games: Concentration Room and Thwaite. I had also made tech demos for MMC1 (Forbidden Four) and UNROM (Who's Cuter). nrom-template formed the basis of Zap Ruder.
By the time I made bnrom-template (February 2018), I had already completed a few BNROM projects: early prototypes of Action 53, Haunted: Halloween '85, and 240p Test Suite version 0.13.
I feel I lack the experience to demonstrate good practices in organizing an MMC3 program that uses CHR ROM. This is because I have never built a substantial project beyond simplistic emulator tests that uses MMC3 with CHR ROM. I haven't made a solo game that uses MMC3's unique selling points, namely the timer, fine-grained CHR switching, or DPCM bank switching. In particular, the TGROM port of 240p Test Suite is in effect a mapper hack of the UNROM version, made largely for people with MMC3 devcarts or for inclusion on an MMC3 multicart. I have programmed three MMC3 games for Retrotainment, namely Haunted: Halloween '86, Full Quiet, and Garbage Pail Kids, and a fourth was recently shown at Portland Retro Gaming Expo. These use the timer for prominent parallax scrolling but depend on 32 KiB CHR RAM, which isn't reliably emulated on non-desktop devices.
I don't know how opinionated tlrom-template and tgrom-template ought to be with respect to how they organize ROM. These are the dimensions I can think of:
- linker configuration files for each combination of PRG ROM size and CHR ROM size
- whether to use PRG windows $8000/$A000 or $C000/$A000
- how to divide PRG ROM into banks, such as pairs of 8K banks ($8000-$BFFF or $A000-$DFFF), 8K banks at $A000, 8K banks at the other window ($8000 or $C000), or the "LINEAR" mechanism that my games for Retrotainment use for roughly the first 5/8 to 3/4 of ROM
- how to divide CHR ROM into banks, such as pairs of 2K banks, individual 2K banks, and 1K banks
Statistics: Posted by tepples — Thu Oct 10, 2024 10:21 am — Replies 0 — Views 110