Would it be at all possible to create a OneBus cartridge mapper for use with a regular NES/Famicom? This question came up in a chat recently. A "OneBus cartridge mapper" would be a mapper that accesses a single ROM chip, with its bank registers set up so that CPU reads are fetched from a different bank of the same ROM chip as PPU reads.
The OneBus famiclones can do it because the console itself carefully interleaves the timing of CPU and PPU read accesses. Such is not the case for a normal NES console: as I understand it, its CPU and PPU access its respective ROM chips simultaneously all the time, and the PRG/CHR data must be provided as long as the CPU/PPU requests it, and as soon as it requests it. The idea was to have mapper chip that is constantly latching a CPU byte and a PPU byte, and whenever either the CPU or PPU /RD signal goes low, it would quickly fetch the respective byte from the actual ROM chip and update its respective latch. This "quick fetch" would have to be short enough to maximally take the time interval between /RD going low and the CPU/PPU "really" needing the byte. I found this concept to be marginal, as such a time interval may not actually exist.
The only chance I see of making it work would be to use fully dual-ported ROM chips, which would be expensive to use in quantity, beating the original purpose of the OneBus system to save cost by using one instead of two ROM chips.
The OneBus famiclones can do it because the console itself carefully interleaves the timing of CPU and PPU read accesses. Such is not the case for a normal NES console: as I understand it, its CPU and PPU access its respective ROM chips simultaneously all the time, and the PRG/CHR data must be provided as long as the CPU/PPU requests it, and as soon as it requests it. The idea was to have mapper chip that is constantly latching a CPU byte and a PPU byte, and whenever either the CPU or PPU /RD signal goes low, it would quickly fetch the respective byte from the actual ROM chip and update its respective latch. This "quick fetch" would have to be short enough to maximally take the time interval between /RD going low and the CPU/PPU "really" needing the byte. I found this concept to be marginal, as such a time interval may not actually exist.
The only chance I see of making it work would be to use fully dual-ported ROM chips, which would be expensive to use in quantity, beating the original purpose of the OneBus system to save cost by using one instead of two ROM chips.