Mapper Features for High Level Languages

[Drag]

MMC3 is easy to make thread-safe: during the main thread, leave the switchable bank at set at 7 (PRG ROM bank at CPU $A000-$BFFF). Switch bank 6 (PRG ROM bank at $C000-$DFFF) only in the DPCM playback routine, and switch banks 0-5 (CHR ROM) only in the NMI and scanline IRQ handlers.

So in other words, the main thread assumes the function select register is a constant, and all of the "threaded" routines will automatically reset it to that constant when finished? That makes sense, that's probably how most games use the mapper anyway; I'm not sure why I thought it was going to be a big hairy deal.

I still think you guys should try your hand at assembly. From the looks of it, you're already moving closer and closer to a low-level language anyway. As long as you comment your assembly really thoroughly, it's pretty workable (if you look at any of my source code, I write comments like I'm re-teaching myself how my code works and what I was thinking). The bonus is that you get to use whatever mapper you want. I'm not sure why 6502 assembly puts everyone off. :\

[lidnariq]

I'm not sure why 6502 assembly puts everyone off. :\

I hate doing math in asm. And find conditional branches too error-prone. Otherwise, yeah, asm isn't bad.

[Shiru]

Programming in assembly takes few times more time to write and debug the code, that's all. C helps a lot to speed up the development, even if most of the code will be manually rewritten into assembly code afterwards.

[tepples]

I wonder what it'd take to write a game in FCEUX Lua and port it to assembly piece by piece, much as one does with a C game.

[thefox]

I wonder what it'd take to write a game in FCEUX Lua and port it to assembly piece by piece, much as one does with a C game.

You can also use NintendulatorDX Lua, where it's actually possible to embed Lua code snippets into the assembly code with ndxLuaExecStr and ndxLuaExecFile macros. From there on out one could fairly easily start translating each snippet to assembly little by little.

[infiniteneslives]

The lines between this discussion and thatone are starting to bleed a little, but based on what Shiru and Rainwarrior are saying a large part of the problem can be resolved by banking game data alone.

Seems within reason that the C generated code of a reasonably complex (a step up from over 90% of current homebrews) could fit well within 32KB of fixed PRG-ROM. If one were willing to depart from a discrete mapper, it would seem that taking the approach of the fme-7 with it's possible banking of PRG-ROM into $6000-7FFF would be the way to go. So if you can limit your C code to within 32KB which isn't that tight of a limit, then you can get off the ground and start running with current CC65 compilation. It could be taken even further and expanded to fixed ROM from $6000-$FFFF with banked data available at $5000-5FFF. That'd give you 40KB of fixed space dedicated to HLL generated code, which is actually a pretty big space to get a lot done. I wouldn't be surprised if it could even fit something on the same level as SMB3 taking into account you'll be able to re-write the assembly where it gets bloated significantly.

The best part about more fixed ROM and fewer PRG banks is the reduction in logic required. Sounds pretty reasonable to fit in that scanline counter within 36mcells, and probably even 2KB CHR-RAM banks if the serial SPI wasn't desired. That comes pretty close to the same level as the MMC3 with a $1 CPLD, but even better since it's more suited for HLL with an arguably better CHR setup than any game released on the NES/FC.

All that power with such simplicity is pretty enticing. Suddenly not being able to bank HLL generated code doesn't sound like much of a restriction anymore.