OneBus mapper for standard NES?

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

Post Reply
NewRisingSun
Posts: 1068
Joined: Thu May 19, 2005 11:30 am

OneBus mapper for standard NES?

Post by NewRisingSun » Tue Jul 30, 2019 12:50 pm

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.

lidnariq
Posts: 8792
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: OneBus mapper for standard NES?

Post by lidnariq » Tue Jul 30, 2019 1:03 pm

Yes, it's possible. Both the CPU and PPU are slow enough that one could multiplex everything.

The problem is that it's I/O intensive, basically requiring a high pin count FPGA, and a large chunk of NOR flash, resulting in a price tag that'll make it hard to justify.

And, of course, it can't be compatible with any of the higher-color video modes.

supercat
Posts: 161
Joined: Thu Apr 18, 2019 9:13 am

Re: OneBus mapper for standard NES?

Post by supercat » Thu Aug 01, 2019 9:09 am

lidnariq wrote:Yes, it's possible. Both the CPU and PPU are slow enough that one could multiplex everything.

The problem is that it's I/O intensive, basically requiring a high pin count FPGA, and a large chunk of NOR flash, resulting in a price tag that'll make it hard to justify.

And, of course, it can't be compatible with any of the higher-color video modes.
Would one need to feed all the pins through an FPGA to multiplex them? Some level-conversion chips have three-state outputs, and many cheap FPGA and memory chips aren't 5-volt tolerant, so why not solve all problems at once by using level shifters with 3-state outputs to multiplex address/data from the NES, and 74HCT-family registers or latches to feed data back to the NES?

lidnariq
Posts: 8792
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: OneBus mapper for standard NES?

Post by lidnariq » Thu Aug 01, 2019 11:36 am

Ultimately ... because you're still limited to the library of the VT02. All the later VRTech consoles added more advanced video modes, so I assume they would be glitchy at best on an original Famicom.

There are other less important reasons, such as the relative cost of parallel or serial NOR flash, the complexity of doing the clock recovery to handle the multiplexing, and needing some programmable logic to implement all the other various features that even just the VT02 has over a plain Famicom (MMC3, sound, IRQ source, others)

User avatar
Ben Boldt
Posts: 424
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: OneBus mapper for standard NES?

Post by Ben Boldt » Thu Aug 01, 2019 11:41 am

supercat wrote:
lidnariq wrote:Yes, it's possible. Both the CPU and PPU are slow enough that one could multiplex everything.

The problem is that it's I/O intensive, basically requiring a high pin count FPGA, and a large chunk of NOR flash, resulting in a price tag that'll make it hard to justify.

And, of course, it can't be compatible with any of the higher-color video modes.
Would one need to feed all the pins through an FPGA to multiplex them? Some level-conversion chips have three-state outputs, and many cheap FPGA and memory chips aren't 5-volt tolerant, so why not solve all problems at once by using level shifters with 3-state outputs to multiplex address/data from the NES, and 74HCT-family registers or latches to feed data back to the NES?
I was pretty intrigued by the EPM3128 CPLD that byemu used on the famulatogo (viewtopic.php?f=9&t=19101). I had not heard of it before. It is cheap, truly 5V tolerant, and maybe (?) complex enough to do this? It seems like the only necessary external components are a 3.3V regulator and some filter caps. What do you think? I want to know reasons against this thing because I am dreaming kind of wild about what to do with it...

Post Reply