nesdev.com

It just occurred me that maybe a lua script can simulate this automatic switching in emulators... I might give this a try.

Something like this should work for Mesen:

Obviously this is just a test (for MMC3) but you should be able to tweak it easily enough for any other mapper.

Result:

Thanks for the example, Sour!

If you can admit lost area at the top of the screen and loosing perhaps some CPU time, you could probably pull it off with some DMC IRQ trickery combined with roughly timed code ? Triggering IRQs each 8 lines and even each 4 lines is possible with this method after all. The problem is that it's extremely though to control where those IRQs will trigger, also they won't trigger exactly each 8 and 4 lines but only a non-integer # of scanlines slightly shorter than that. The fact that high timing precision for $2000 writes can be taken advantage of to some extent so perhaps something smart is possible.

Very likely you'll have to have a time-compensating loop on each IRQ whose waiting time will be pre-calculated and variable each time, and you'll lose up to 25% of CPU time doing this.

I've done some work with DMC IRQs to try to have arbitrary splits -- I wouldn't recommend trying this for this many scanlines. Remember that IRQs happen on their own clock, starting up to 432 cycles after you trigger them. Depending on the alignment you could waste a lot of time on many of the scanlines.

All this talk about custom mappers and such is great, but in the end, that's way too experimental for me. Too many places where things could go wrong, from the mapper design and prototyping, to modifying emulators and even manufacturing carts if the game ever gets completed.

I'm contemplating doing something I also consider crazy, but crazy at the software level, which makes me much more confident. I'll try dividing the rendering logic in my raycaster into fixed-time chunks of 4 or 8 scanlines (whatever works best), so I can alternate name tables in software in between logic chunks. Then, after the 3D view, comes the bottom of the screen with the status bar and such, which doesn't need timed code, so the game/object logic can run during that time.

Dividing the ray casting and texture scaling into constant-timed chunks sounds like a bit of a challenge, but they are extremely repetitive tasks, so it just might work. I do expect to lose some processing time simply making the best cases take as much time as the worst cases, but I'd also lose a lot of time with other software-only solutions, such as using DMC IRQs or generating all patterns on the fly.

Good luck having code that is even remotely maitainable... But it's what makes the most sense. If you're already loosing a lot of times to render the screen, you don't want to loose any CPU time waiting for synchronization, even if it is just a little. So I think it makes sense, but you want to make sure your rendering algorithm is set is stone and is not going to be changed once you start coding this... because maintaining it will be a complete nightmare.

You could also aim at constant-time rendering, so that the framerate even if slow will be constant. I think it's a good idea. At least you'll be really pushing the system to its limit.

If you needed to develop a new mapper anyway, you might as well have the mapper doing the ray-casting itself, so I agree it's a bad approach.

Oh, come on. That's wholly unfair. There's a huge difference between a trivial chunk of discrete logic doing something like the Oeka Kids mapper and a coprocessor.

Well, it's just the rendering code, so I don't expect it to change at all once it's working and generating proper results.


The strategy I plan on using is basically to unroll the tasks and do as much as possible in 4 or 8 scanlines, and then decide whether to continue in the same block or jump to another one. For example, there'll be a block of code that just extends the ray and checks the map for collisions with walls, and this will be used over and over until a wall is found. If there's enough time to test, say, 6 wall boundaries between scroll splits, I'll have to include wait loops for when a wall is found before the 6 checks, so that the block still takes the same amount of time to finish. That could add up to a lot of lost CPU time, unfortunately.


Not much worse than an Atari 2600 kernel, I suppose.


With the different amounts of distances rays have to travel, the different heights of the walls, and the varying amounts of enemies and their proximity to the player, I think that'd be very hard, and wasteful. I have to believe that these things are going to compensate for each other (e.g. a longer ray that takes more time to cast will result in a smaller wall that takes less time to texture), and design the levels in ways that avoid too much heavy processing in the same spot.


That doesn't sound particularly fun to me. I want to see the NES do all the work, not just have the PPU pump out the pixels.

I've been giving some more thought to this and the constant-timed rendering chunks will end up wasting much more CPU time than I anticipated. Not only will I constantly have to "do nothing" when the task finishes too soon, but I'll also waste lots of time in NTSC if I plan on supporting PAL consoles, since PAL scanlines are shorter. The most sensible thing to do would be to just bite the bullet and go with the MMC3. If I'm doing something complex, there's no shame in using a more complex mapper, and if I insist in chasing crazy alternative solutions I'll probably just be shooting myself in the foot.

Thanks for all the replies. I particularly liked lidnariq's idea of constructing a simple custom mapper, and I even learned a bit more about mapper design from it, so thanks for the suggestion!

I've been occasionally tempted to make a special emulator build that has all these wacky experimental hardware designs. To keep the scope sane, it'd have to be only hardware that uses a small handful of 74xx ICs.

What with Mesen having a useful debugger and running on Linux I might even get around to it.

That'd be really cool! I really like to read/talk about these cool little mapper ideas, but for someone who's not very experienced with hardware, the idea of physically constructing these cartridges to test their viability is a bit daunting. The very few times I tried, things didn't go well. The possibility of simulating these ideas before actually constructing anything sounds great.

The other option is to write an emulator that supports mappers written in WebAssembly or some other intermediate language that can be JIT-recompiled. Someone in the GBDev Discord server discussed making an emulator that supports exactly this.

I don't think having JIT-compiled mappers is very useful. Mapper development for emulators is easy enough by compiling offline. What lidnariq is proposing (being able to simulate the mapper hardware in an emulator using a predefined set of readily available hardware components) would provide a very simple transition path from simulation to hardware, maybe lowering barrier of entry for people who might be unsure what kind of mapper designs would be feasible on hardware.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

Oh, no, sorry, nothing so sophisticated. I was just observing that Mesen definitely gives me enough rope, its mapper descriptions are succinct enough, and it has a highly-useful debugger, such that I could easily manually make the full set of "what if I attach a latch in this weird place" mappers.