Rather than me clogging this thread with questions and other marginally-related-to-the-topic nonsense, I'm starting a new thread instead.
So, I'm pretty much half-way through designing the rough draft of a pretty decent seeming mapper, needing only 74-series ICs so far. The absolute base design is as follows:
16k VRAM
12 1k PPU banks
3 8k PRG banks (E000-FFFF fixed to last bank)
The registers themselves (holding the current page number for each bank) are 4 74670s, which is a 4x4bit register file (basically 4 4-bit flipflops with built-in addressing and multiplexed output). The first three ICs handle the 12 PPU banks, and are 4-bit, which is perfect for the 16kb VRAM. The last IC handles the three PRG banks, and as-is, allow up to 128kb roms. However, the PRG banks can be extended to 8-bit by adding another 74670 in parallel to provide the upper 4 bits, allowing up to 2mb roms. This introduces slightly more complexity into the mapper, so I was thinking of having two seperate versions of the mapper, 128k and 2m.
The reasoning behind having 3 PRG banks is so you can have bankswitchable DPCM data, and the first two banks fit the harvard memory model nicely (where code and data are seperated). So for example, you can put your music engine's code in 8000-9FFF, and have the music data in A000-BFFF, which allows any number of pages of music data, and then C000-DFFF can contain the current DPCM sample.
I could easily cut this in half and have just one 16k PRG bank and one fixed 16k bank, and that'd allow 256k (with 4-bit registers) and 4m (with 8-bit registers), but you'd have a lot less flexibility with code and data space, plus no DPCM banking, so the 128k/2m cap seemed reasonable in light of this.
Here is the current list of extended features I've finished or am working on:
- Special exception for nametable banks where the first two pages refer to internal VRAM instead of cart VRAM.
You'll always have at least 2 nametables to work with, and at least 2k of pattern table data (128 tiles out of 512). The remaining 14k is shared between the two. If you just use 8k of ram for tiles (standard chr-ram), the other 8k (plus internal vram) can be used for 10 nametables. Incidently, you need 15k worth of pattern table data to fill the entire screen with unique tiles, which brings me to the next feature.
- Special bank 0 auto-increment-on-hot-tile mode (togglable).
A special mode where fetching the last byte of bank 0, which is pattern B of the last row of tile 3F, automatically advances bank 0 to the next page. This mode can be enabled or disabled as seen fit. This allows the extremely simple addition of digitized images to the screen, simply by displaying tiles 00-3F over and over on the nametable. This can fill the screen, or just be a smaller region (or 2) on the screen somewhere. Since this mode only affects bank 0, the other pattern table banks are free to hold whatever data you want, including UI elements, fonts, sprites, etc.
The way you'd use this mode is by writing to the 16th register (notice how only 15 are used for banks), which would actually load a counter with the starting page and enable the hot-tile mode, where the counter is incremented after the PPU finishes fetching from address $03FF. You'd need to reset the counter to the starting bank every vblank though. To go back to regular bank 0 mode, you'd just write to the bank 0 register like usual.
When I say "I'm working on this mapper", I'm actually writing out where the traces are connected, the logic, things like that. However, I still have some things I don't know. For instance, if I have a 4-way OR gate, can I feed it with a chip's /OE signal (or rather, the signal that drives the chip's /OE), and 3 of the chip's outputs? I've been working under the assumption that the three inputs being hi-z won't matter since the fourth input (the chip's /OE) will always be 1, and since the 1 means the OR will output 1 regardless of the other three inputs, it shouldn't matter of the three inputs are hi-z at that point. But I dunno if this is actually true.
So, I'm pretty much half-way through designing the rough draft of a pretty decent seeming mapper, needing only 74-series ICs so far. The absolute base design is as follows:
16k VRAM
12 1k PPU banks
3 8k PRG banks (E000-FFFF fixed to last bank)
The registers themselves (holding the current page number for each bank) are 4 74670s, which is a 4x4bit register file (basically 4 4-bit flipflops with built-in addressing and multiplexed output). The first three ICs handle the 12 PPU banks, and are 4-bit, which is perfect for the 16kb VRAM. The last IC handles the three PRG banks, and as-is, allow up to 128kb roms. However, the PRG banks can be extended to 8-bit by adding another 74670 in parallel to provide the upper 4 bits, allowing up to 2mb roms. This introduces slightly more complexity into the mapper, so I was thinking of having two seperate versions of the mapper, 128k and 2m.
The reasoning behind having 3 PRG banks is so you can have bankswitchable DPCM data, and the first two banks fit the harvard memory model nicely (where code and data are seperated). So for example, you can put your music engine's code in 8000-9FFF, and have the music data in A000-BFFF, which allows any number of pages of music data, and then C000-DFFF can contain the current DPCM sample.
I could easily cut this in half and have just one 16k PRG bank and one fixed 16k bank, and that'd allow 256k (with 4-bit registers) and 4m (with 8-bit registers), but you'd have a lot less flexibility with code and data space, plus no DPCM banking, so the 128k/2m cap seemed reasonable in light of this.
Here is the current list of extended features I've finished or am working on:
- Special exception for nametable banks where the first two pages refer to internal VRAM instead of cart VRAM.
You'll always have at least 2 nametables to work with, and at least 2k of pattern table data (128 tiles out of 512). The remaining 14k is shared between the two. If you just use 8k of ram for tiles (standard chr-ram), the other 8k (plus internal vram) can be used for 10 nametables. Incidently, you need 15k worth of pattern table data to fill the entire screen with unique tiles, which brings me to the next feature.
- Special bank 0 auto-increment-on-hot-tile mode (togglable).
A special mode where fetching the last byte of bank 0, which is pattern B of the last row of tile 3F, automatically advances bank 0 to the next page. This mode can be enabled or disabled as seen fit. This allows the extremely simple addition of digitized images to the screen, simply by displaying tiles 00-3F over and over on the nametable. This can fill the screen, or just be a smaller region (or 2) on the screen somewhere. Since this mode only affects bank 0, the other pattern table banks are free to hold whatever data you want, including UI elements, fonts, sprites, etc.
The way you'd use this mode is by writing to the 16th register (notice how only 15 are used for banks), which would actually load a counter with the starting page and enable the hot-tile mode, where the counter is incremented after the PPU finishes fetching from address $03FF. You'd need to reset the counter to the starting bank every vblank though. To go back to regular bank 0 mode, you'd just write to the bank 0 register like usual.
When I say "I'm working on this mapper", I'm actually writing out where the traces are connected, the logic, things like that. However, I still have some things I don't know. For instance, if I have a 4-way OR gate, can I feed it with a chip's /OE signal (or rather, the signal that drives the chip's /OE), and 3 of the chip's outputs? I've been working under the assumption that the three inputs being hi-z won't matter since the fourth input (the chip's /OE) will always be 1, and since the 1 means the OR will output 1 regardless of the other three inputs, it shouldn't matter of the three inputs are hi-z at that point. But I dunno if this is actually true.