This is an idea I had for a custom mapper that would raise the number of background tiles from 256 to 1024. The idea is that you divide each 16x16 block into 4 different graphics banks. Top-Left tile gets its own back, Top-Right tile gets its own bank, Bottom-Left tile gets its own bank, Bottom-Right tile gets its own bank. Wouldn't require very much hardware at all, just 32K of SRAM for the CHR-RAM, and a few discrete logic chips.
NES repeats this sequence of reads:
* Read Nametable byte
* Read Attribute Table byte
* Read background tile graphics low byte
* Read background tile graphics high byte
Then when it's time for sprites:
* Read garbage Nametable byte
* Read garbage Nametable byte
* Read sprite Tile graphics (sprite) low byte
* Read sprite Tile graphics (sprite) high byte
-
The critical part of this pattern is that it's always an Attribute table byte before background tile graphics, and always a Nametable byte before sprite tile graphics.
Nametables are at 2000-23BF and repeating every 400 bytes later (appears four times).
Attribute tables are at 23C0-23FF and repeating every 400 bytes later (appears four times)
Distinguishing the two requires not much more than ANDing a bunch of address lines together.
So now, when you see a Nametable read:
- Save the low bit of column and low bit of row, use those to make a value 0-3.
- Bankswitch CHR-RAM to bank 4 for sprites
Then when you see an Attribute table read:
- Bankswitch CHR-RAM to your value 0-3 for the background tile read
If I get this right, it's not extending the background tiles from 256 to 1024 but making them bigger. So you'd end up with 256 16x16 tiles rather than 8x8 one. It's super interesting but not as flexible as 1024 8x8 tiles. Hopefully you can make it someday!
Not quite, the 4 pieces can still select different tile numbers. It's more like 256 tiles that can only appear as top-left, 256 tiles that can only appear as top-right, etc...
So basically they give NES 1MB RAM, up to 3.5GB of NAND-based ROM, expand the PPU capabilities within the supposed circuit complexity of the MMC5, and then proceed to argue it's not anachronistic and was even economically viable at the time?
Roman Empire never came close to inventing communication networks despite having the economic incentives and long-range signaling tech, think about why.
They seem to be largely modeling after the launched idea of the Sega CD, even more restrictively in some aspects e.g. CPU expansion. The Sega CD released 3 years prior to the given timeframe and offered just shy of 1 MB RAM with the same proposed CD + multi-disc support. The main improvement being the speed of the drive (The '91 Sega CD was 1x instead of 4x) and yeah, they don't do that over a literal CD drive but that seems to have more to do with not wanting to make a literal CD drive the same as using an FPGA isn't about using FPGAs as much as not needing literal ASICs be made.
It's important to note they are talking about an imagined expansion to the system in 1994, not an alternative version of the console released in 1985. It's reasonably feasible to do something of this level at the time the question is more one of "would it really be sensible". With the SNES already being 4 years old at this point and the PlayStation releasing that same year anyways (with twice the RAM, 2x CD support, and a hell of a lot more compute) I can't think anyone would bother. At the same time, the project is explicitly not measuring by what people bothered with at the time and rather what the reasonable limits could have been.
It's a fantasy NES expansion like how the Pico 8 is a fantasy console. I think it's really cool, especially since the game will be coming out on a cartridge that's playable on a real NES
I saw a tweet about this new NES game in development that looks amazing. Seeing video of it, I thought it was a SNES game. This blog talks about how they are able to achieve these results on the NES.
Readit News
NES repeats this sequence of reads:
* Read Nametable byte
* Read Attribute Table byte
* Read background tile graphics low byte
* Read background tile graphics high byte
Then when it's time for sprites:
* Read garbage Nametable byte
* Read garbage Nametable byte
* Read sprite Tile graphics (sprite) low byte
* Read sprite Tile graphics (sprite) high byte
-
The critical part of this pattern is that it's always an Attribute table byte before background tile graphics, and always a Nametable byte before sprite tile graphics.
Nametables are at 2000-23BF and repeating every 400 bytes later (appears four times).
Attribute tables are at 23C0-23FF and repeating every 400 bytes later (appears four times)
Distinguishing the two requires not much more than ANDing a bunch of address lines together.
So now, when you see a Nametable read:
- Save the low bit of column and low bit of row, use those to make a value 0-3.
- Bankswitch CHR-RAM to bank 4 for sprites
Then when you see an Attribute table read:
- Bankswitch CHR-RAM to your value 0-3 for the background tile read
Roman Empire never came close to inventing communication networks despite having the economic incentives and long-range signaling tech, think about why.
It's important to note they are talking about an imagined expansion to the system in 1994, not an alternative version of the console released in 1985. It's reasonably feasible to do something of this level at the time the question is more one of "would it really be sensible". With the SNES already being 4 years old at this point and the PlayStation releasing that same year anyways (with twice the RAM, 2x CD support, and a hell of a lot more compute) I can't think anyone would bother. At the same time, the project is explicitly not measuring by what people bothered with at the time and rather what the reasonable limits could have been.
Would have been easier to make it a Turbografx CD game. It's got the 6502-like CPU and the CDROM interface just like they wanted.
Deleted Comment
I'd love to support this kind of thing, but just no given that option.
Dead Comment