Idea of High-Capacity Mapper

Idea of High-Capacity Mapper
by qbradq on 2011-06-01 (#79015)

Hey all! It's time again for QBRADQ's mapper discussion of the week. Hurray!

I've had an idea for some cartridge hardware that would be:

Built from discrete logic
Include 32KB of PRG-RAM
Include 8KB of CHR-RAM
Support up to 16MB of data
Support up to 16MB of saved data without requiring a battery
Self-programmable

So the general idea is that I would have an 8KB ROM at $E000-$FFFF that would serve as a kind of boot ROM, containing common code (like CPU / RAM / Mapper init), mapper interface routines and initial program code loading. I could also put in some sort of "load from a controler-to-usb cable" mode in there too.

Then I would have 32KB of RAM mapped to $6000-$DFFF. This can be used for loading executable code and for general-purpose RAM.

Finally a serial FLASH ROM would be accessed through a register in the $5000-$5FFF range. Mapper interface routines provided in the ROM will copy arbitrary amounts of data from ROM to RAM, and will be able to copy 256-byte pages from RAM to ROM.

Other functions could be bolted on by adding some registers, such as name table mirroring select or bankable PRG / CHR RAM.

The Pros:

Lots of RAM available
Reliable (and huge) save storage
Huge data access
No need to split data into banks, it's one continuous address space
Ability to load program code through controller port, no programmer required

The Cons:

Very slow to load from ROM to RAM (compared to banking in a ROM page)
Must be able to fit all required data and code into 32KB.
This could be the birth of the NES loading screen

This hardware would seem to be a good fit for my current programing approach. I basically load all of the data I need for a given level (including sprite defs, tile set info, etc) into WRAM using routines in the fixed bank, then swap game mode specific code into the low bank.

What are ya'lls thoughts on this?

by Bregalad on 2011-06-01 (#79017)

Sounds extremely similar to the Famicom Disk System to me.

Re: Idea of High-Capacity Mapper
by lidnariq on 2011-06-01 (#79018)

qbradq wrote:
Support up to 16MB of data
Support up to 16MB of saved data without requiring a battery
And use compactflash for that, because it'll be cheaper than large 5V NAND EEPROMs. And that sounds awfully like a powerpak.

Don't get me wrong, it still sounds useful, but you should see these brainstormed mappers as the end themselves, rather than the means.

Re: Idea of High-Capacity Mapper
by Banshaku on 2011-06-01 (#79023)

qbradq wrote:
Hey all! It's time again for QBRADQ's mapper discussion of the week. Hurray!

Basically you're becoming a nesdev "regular". lol

by qbradq on 2011-06-01 (#79025)

Mappers are just so fun to talk about. I don't know what it is

I had never read much about the FDS. This is very similar. I suppose it's a solid-state FDS

Lidnariq,

I am not quite sure I understood your comments. I was thinking of using Flash ROMs, not EEPROMs. You can get a 1MB serial Flash ROM for $1.61 USD at Mouser. An 8MB chip is $3.71, and a 16MB chip is $7.18. I seriously doubt anyone will find a use for 16MB on an NES project, unless it's a UNROM pirate cart

by tepples on 2011-06-01 (#79028)

And I can find a 2000 MB serial flash for $1. Google keywords: 2gb microsd

by qbradq on 2011-06-01 (#79031)

That's an interesting thought. Data loading would be even slower when having to deal with the SD SPI interface and a FAT32 or FAT16 file system, but you could have a single cart that would be compatible with multiple games. The games could be distributed as a collection of files and placed on the SD card.

The only down side is that you'd basically have to use the "load entire file to this address" methodology used on the FDS. Using a serial Flash ROM you can do byte-by-byte access much easier.

All very interesting thoughts. I'll keep all this in mind if my project breaks that 512KB mark

by MottZilla on 2011-06-01 (#79043)

I really think you'd want more than 32KB of usable PRG. Banking is very helpful. Sure great games were made on the FDS. But why set such strange limits? Again with CHR, why limit yourself so much if you are designing something new?

Maybe if you had a way to design this and keeping it simple and cheap was an issue it would make sense then. If you need more than 512KB PRG-ROM, use MMC1. There are plenty of CHR bits to hijack to get more 256KB Pages.

by tepples on 2011-06-01 (#79044)

I agree with MottZilla that having more PRG RAM than FDS has benefits. But do we need 256 KiB like the TGCD's Super System Card, or can we get away with half that?

by MottZilla on 2011-06-01 (#79046)

I think 128KB of bankable memory would be enough for NES if you mean a system with mass storage to load the 128KB of PRG-RAM. If you are going to do that though I'd recommend having 32kb (or more) of CHR-RAM with bank switching so you can get the benefits of quick CHR banking.

by Memblers on 2011-06-01 (#79048)

I like the serial memory idea, it's what I've wanted to go with on Squeedo rev3 when I do it (both serial dataflash and micro SD). My plan, if/when the memory controller works, would copy the data off it nearly instantly (the dataflash would be faster and non-removable, which is why there would be both types).

With the NES using it directly, I wonder if there would be much of a speed penalty with using micro SD compared to other serial flash. Technically, you don't have to use FAT16/FAT32, if it helped any you could use your own custom formatting/filesystem (then have a PC program or something to make disk images and add/remove files).

I definitely agree that 32kB is too small, 128kB SRAM doesn't cost much more and would be a lot more useful. 32kB for CHR seems like enough.

BTW, the sound synth I'm working on (to use NES expansion port/controller port/FC exp port) is also supposed to include a large serial memory. Cool thing with that is that multiple games should be able to use it, for saving or for loading.

by lidnariq on 2011-06-01 (#79052)

qbradq wrote:
Lidnariq,

I am not quite sure I understood your comments. I was thinking of using Flash ROMs, not EEPROMs. You can get a 1MB serial Flash ROM for $1.61 USD at Mouser. An 8MB chip is $3.71, and a 16MB chip is $7.18. I seriously doubt anyone will find a use for 16MB on an NES project, unless it's a UNROM pirate cart :D
AFAIK, flash ROMs are NOR EEPROMs... The pricing I saw on digikey was pretty awful -- ~$10 for a 8MB one. That said, I don't see a 5V-compatible flash rom on mouser for a sane price...

Using something like compactflash (or any other parallel-bus flash) has the advantage that cpu-based reading isn't even slower. The big advantage to using something like CF (or SD or whatever) is that you can copy larger content using a card reader. (The downside is you now have to reimplement FAT)

Tangenting, I've recently had this silly idea of adding a CDROM drive to the expansion port of the NES, much like the PC-Engine's CDROM. Same problem, same approximately-FDS, but with streaming audio from disk.

by infiniteneslives on 2011-06-01 (#79054)

You could solve a lot of the SD card formatting issues if you just had a simple microcontroller interfacing between the NES and SD card.

You'd just need to setup a way to ask the uC for specific data and it could retrieve it at high speed and provide a full byte per clock cycle to the NES through a register. It could be similar for writing to the SD card kind of like what I'm trying to do with my project.

by qbradq on 2011-06-02 (#79066)

I had thought about using an MCU with a latch for data I/O, but it would still require all of the decoding logic and whatnot. It's not like I'm actually going to build this thing anyway

As for the 5V-compatible Flash ROM, I was not going to use 5V Flash. I was going to use 3.6V Flash and interface it with a 5V-compatible 3.3V latch. A latch is needed anyway, and this provides logic level translation. You can't beat that

by MottZilla on 2011-06-02 (#79075)

lidnariq wrote:
Tangenting, I've recently had this silly idea of adding a CDROM drive to the expansion port of the NES, much like the PC-Engine's CDROM. Same problem, same approximately-FDS, but with streaming audio from disk.

You know if you want a "NES" like platform with the benefits of CDROM the answer IS the PC-Engine. It was designed with getting Famicom developers on board afterall with its similar CPU and likely other aspects of design.

All these ideas are fun to come up with but the more practical thing to do if you need more space for your NES game is my earlier suggestion. Take the MMC1 SUROM to the next level. Reuse more CHR bits to control a bigger PRG-ROM. There are 5 CHR bits that aren't needed at all if you are using CHR-RAM. So that should give you 32 different 256KB Pages of ROM you could control giving you 8 Megabytes of ROM. I highly doubt you need this much space for any such NES game. Or you could make more of an extension of SXROM so that you could have 32kb of bankable PRG-RAM but also 2 megabytes of PRG-ROM.

All this can be done without creating any new mapper, just by rewiring an existing one of which is available new from RetroUSB. You could even try getting BunnyBoy to make a MMC1 PCB that is already capable of being wired this way for more PRG capacity.

And again, I highly doubt you need 8 Megabytes of PRG-ROM. So this solution should work for you.

by tepples on 2011-06-02 (#79077)

MottZilla wrote:
You know if you want a "NES" like platform with the benefits of CDROM the answer IS the PC-Engine.

Or it would be if the TG16 had become popular in the United States. I've seen one TG16 in my life, and it was someone's TurboExpress in college.

Quote:
the more practical thing to do if you need more space for your NES game is my earlier suggestion. Take the MMC1 SUROM to the next level. Reuse more CHR bits to control a bigger PRG-ROM. There are 5 CHR bits that aren't needed at all if you are using CHR-RAM.

CHR A12 passes through the MMC1 unchanged in 8K mode. To make use of it would involve rewiring A12 on the cart edge to A12 on the PRG RAM skipping the MMC1 entirely. Then ground the cart A12 input on the MMC1 and use 4K mode, freeing all of $A000 for extra bank bits.

Quote:
Or you could make more of an extension of SXROM so that you could have 32kb of bankable PRG-RAM

I think the idea was to allow far more than 32 KB of nonvolatile memory: "up to 16MB of saved data without requiring a battery" as qbradq put it.

by qbradq on 2011-06-02 (#79078)

I highly doubt I'll ever need more that 256KB for a game. This is just a fun idea

by Bregalad on 2011-06-02 (#79080)

Yes, but the lower line of the MMC1 CHR registers would just be a plain copy of PPU A12 if you set MMC1 in 8kb CHR-switching mode.

So to use it as a latch you'd *have* to set the MMC1 in 4kb CHR-switching mode, and always set both Reg1 and Reg2 the same value, so that this latched value is constant on MMC1's CHR-A12 line.

by MottZilla on 2011-06-02 (#79101)

I'm not sure what you mean about CHR A12. My idea is to connect CHR-RAM like you would on UNROM. Meaning the MMC1 wouldn't be controlling CHR at all. Modding an existing board might be hard. But part of the idea is if you needed more capacity a PCB with MMC1 clone could be designed with this high capacity method in mind.

by tokumaru on 2011-06-02 (#79102)

MottZilla wrote:
I'm not sure what you mean about CHR A12. My idea is to connect CHR-RAM like you would on UNROM. Meaning the MMC1 wouldn't be controlling CHR at all.

Even if the outputs of the MMC1 are not connected to the CHR chip, it will still make decisions based on the signals that are connected to it. Now that I think of it, it might be possible to trick the MMC1 by feeding it GND or Vcc instead of A12 from the NES, so that the it thinks that only one pattern table is ever accessed, which would allow you to use 4KB mode without having to write the bank number to both registers.

by MottZilla on 2011-06-02 (#79103)

I'm still missing the deal with 8k versus 4k mode. I understand that in 4K mode if you don't have the same value in both CHR registers it'll bankswitch undesirably for PRG purposes. But if you are in 8K mode, and the output now controls upper PRG-ROM lines and no CHR-RAM lines, what exactly is the problem? Why are you needing 4K mode?

I'm not sure if I'm missing something or not. I understand your point tokumaru about pattern table access and the two CHR registers and 4K mode. But if you are in 8K mode then you don't have to worry about that at all anyway. Is there some reason you couldn't be in 8K mode?

by tokumaru on 2011-06-02 (#79106)

MottZilla wrote:
But if you are in 8K mode, and the output now controls upper PRG-ROM lines and no CHR-RAM lines, what exactly is the problem? Why are you needing 4K mode?

You need 4KB mode to make use of A12. In 8KB mode, since the MMC1 doesn't do any sort of management on the 4KB level, A12 just passes through, and the NES directly picks which 4KB (i.e. which pattern table) it wants. If it passes through, it has no use for bankswitching, so we don't want it to pass through, which is why 4KB mode is needed.

Quote:
Is there some reason you couldn't be in 8K mode?

Only if you want to use A12 for bankswitching purposes. If you only want to use A13 and up 8KB mode is fine.

by MottZilla on 2011-06-02 (#79110)

Now I see what you mean. The lowest CHR bit you're talking about. Well in that case you could still have 4 megabytes of PRG or something like SXROM with 32KB PRGRAM and 1MB PRGROM. Still alot of memory.