Mapper idea: hardware DMA: has this been discussed before?

A recent thread prompted me to ponder something:

A limiting factor I keep seeing people encounter on the NES, specifically when working with CHR-RAM, is chewed up CPU time when copying data from ROM into CHR-RAM/pattern table space. Sacrifices have to be made in general (and I take no issue with that), but there are cases where people basically want the best of both worlds: the benefits of CHR-RAM (RAM-based pattern table data), but with the large expansive capabilities of CHR-ROM (e.g. 512KBytes). There's even a wiki page discussing the pros/cons to both.

As such, I'd like to ask a hardware-related question: given that several homebrew-oriented mappers have been created in the past several years, why is it nobody has added basic hardware-based DMA capability to their mapper? I'm not talking something as complex as what the SNES has (especially not HDMA), nor an identical implementation, but rather a simple MMIO- and hardware-based mechanism for linearly copying data from ROM space to PPU RAM.

It's been a very long time since I've partaken in such discussions, but going purely off of (my now old and failing) memory, I can't recall this ever being proposed as a possibility. I imagine it complicates the PCB circuitry depending on how its implemented. Is this why it never came up? Or maybe it has and was shot down due to the fact that the pre-existing CHR-ROM vs. CHR-RAM methodology as they stand today work for most things?

Food for thought.

I think the main problem is the mechanism for getting that data across to the CHR-RAM.

The "easy" way is dual ported RAM, but that's extremely expensive compared to regular RAM.

There was another thread that discussed looking for space in the bus access to insert stuff like this between other CPU accesses. I'm not sure if anything was built or if it was decided it was possible or not...

Maybe you could halt the CPU and transfer data faster somehow... I don't know if there's a way to do that, though an idea that just occurred to me: what if you built a mapper that could listen to an OAM DMA and send that data to CHR RAM as the PPU is busy loading it to OAM? You could do a few of those DMAs then finally finish with the real sprite load. (Probably this too has been discussed before, not sure.)

Edit: found two of the threads I was thinking of:

• Double Buffered CHR-RAM or DMA Steal?
• Cart ram used as CHR-RAM and WRAM simultaneously

That's how the SNES does it -- and it's still substantially faster than native 65816. Here's how the SNES does it (alternate reference) (and I'm speaking from a programmer standpoint, not a HW implementation standpoint): you tell the system via some dedicated DMA MMIO registers (one per DMA channel; there are 8 channels total) the length of the transfer, the transfer method (there are several methods, e.g. write-once, write-twice-same-value, write-low-byte-write-high-byte, etc.), incrementation method (e.g. by 1, by 32, etc.), the source address (in 24-bit addressing space -- which includes both ROM and dedicated RAM areas), the low byte of the destination address (high byte is always $21, e.g. to write to $2122 you use a value of $22), and what DMA channel number to enable (begin transfer). The native 65816 CPU is halted during such transfers; once done, it resumes where it left off. SNES DMA also lets you pick transfer direction, specifically ROM/RAM->PPU or PPU->ROM/RAM, although I've only seen the former used in practise.

The SNES general-purpose DMA method is pretty complicated and overkill for what I'm thinking of, and I imagine it's a lot of circuitry, plus at least one dedicated bus (edit: maybe that's not true, now that I think about it). I was thinking of something a lot simpler, and maybe the source data came from the linear/raw ROM itself rather than from the active 6502 memory space (if that's even possible; maybe people could transfer data to PPU RAM without having to swap in/out PRG pages, but maybe it can't work that way, re: how busses work. I'm sort of talking out my ass hardware-wise here, no idea what's feasible).

There is some stuff on the SNES that operates "in the background", mainly hardware multiplication/division capabilities via MMIO registers. The method there is basically set some values in registers. The mult/div begins happening once a write to a particular MMIO register happens. You can get your results from some other MMIO registers, but only after N CPU cycles have passed (N = 8 cycles for multiplication, or 16 for division). You can do whatever you want with the CPU/65816 during that time.

Edit: forgot to write up my response to the OAM DMA idea: that's actually pretty clever, and might be less work (to implement) if it could work (and would work reliably). Hmm!

I had considered re-using the sprite-DMA hardware, don't think it has been discussed. Has big disadvantages though, must be done during vblank, and can copy 256 bytes at a time only. It would be pretty good at copying 16 pattern tiles.

While it would be neat to reuse the hardware like that, I've also found that by the time you have A) a mapper capable of handling this and B) dual-port RAM, that we're probably better-off just creating custom DMA hardware inside the mapper that could copy data around without going through the NES bus at all.

I've been working a low-cost dual-port RAM cart this year, haven't done much on it lately though. I think INL may be working on something similar, also. One of the challenges with designing something like this, is that it can be uphill battle getting people to use any new hardware at all. Pretty much everyone tests on emulators, and there's the whole chicken before the egg problem when it comes to emulator support.

The OneBus Famiclones implement exactly such a feature --- in the console, reusing the Sprite DMA.

If it's just about testing (as opposed to wide support for the mapper on common emulators for a rom release), it seems that the community is pretty quick to add support for a new mapper if it's compelling enough. Mesen and FCEUX both support most of your GTROM functionality by now, and I imagine if you came out with a new mapper that was really compelling (both cheap and powerful), people would be interested enough in using it that SOMEBODY would make emulator support happen.