Lets say that hypothetically, there could be a cartridge set up similar to the Famicom Disk System. Where you have RAM instead of ROM, and you load that RAM from a sort of mass storage. But unlike the FDS, loading would be much quicker.. say 2kB~3kB per frame. Absolute minimum access time would be 1 byte every 8 CPU cycles, surely fast enough for real-time streaming of data (with auto-incrementing address). Of course, if you need to index that data in non-sequential order, or execute it as code, then you would need to load it into CPU memory first.
The question I have, is what would be a good minimum of RAM to provide to the NES in this situation? For this question, here are some factors to consider:
This is totally different from a normal type of NES cart, so try to give some thought as to how data you would need to randomly index, and how much of that you would need immediate access to, in between loading times.
In my opinion, previously I had thought 128kB would be a good minimum, but really for quite a few NES games that is the entirety of CPU memory for the whole game. So I'm not so sure that an even smaller amount of RAM like 64kB is unrealistic. 32kB just seems kinda dinky though, but I put it in the poll anyways. Any thoughts?
Maybe I should have put this in NESdev instead of Hardware, I'm really trying to address the software aspects of this, not the hardware. I might move it later.
The question I have, is what would be a good minimum of RAM to provide to the NES in this situation? For this question, here are some factors to consider:
- assume smaller CPU RAM greatly allows other mapper features, finer sized CHR pages, lowers hardware cost, etc.
- 8 CPU cycles per byte access is fast enough to load CHR-RAM even with an unrolled loop (LDA absolute, STA $2007), some data like pattern tables and possibly raw nametables wouldn't even need to be in CPU memory ever.
- assume it could takes 3, 2 or just 1 write to set the address (if it could preserve your previously used address)
- assume the 'mass storage' source is huge.. megabytes at the minimum, and inexpensive
This is totally different from a normal type of NES cart, so try to give some thought as to how data you would need to randomly index, and how much of that you would need immediate access to, in between loading times.
In my opinion, previously I had thought 128kB would be a good minimum, but really for quite a few NES games that is the entirety of CPU memory for the whole game. So I'm not so sure that an even smaller amount of RAM like 64kB is unrealistic. 32kB just seems kinda dinky though, but I put it in the poll anyways. Any thoughts?
Maybe I should have put this in NESdev instead of Hardware, I'm really trying to address the software aspects of this, not the hardware. I might move it later.