Alternating name tables ($2000.0) every 8 scanlines

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Alternating name tables ($2000.0) every 8 scanlines

Post by tokumaru »

So, I'm working on something that requires me to alternate between 2 side-by-side name tables every 8 scanlines (8 scanlines of name table A, 8 scanlines of name table B, then back to A, and so on). Can anyone think of a way to do this that doesn't involve using the MMC3 (or other complex mappers with IRQ functionality) or wasting nearly 100% of the CPU power on timed code?

In an ideal world, DMC IRQs would be enough to time this, but somehow I doubt I could get something stable enough out of that. On the other hand, there is the fact that the window for writing to $2000 is huge, since horizontal scroll changes are buffered until the end of the scanline, so the timing doesn't have to be particularly precise, just enough for the write to happen anywhere in the correct scanlines.

I might end up going with the MMC3, as that'd bring other advantages besides the scanline counter, but I though I'd ask here first to see if anyone could think of something I didn't consider. Thanks.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by lidnariq »

Is this to get 16x8 attribute zones? If so, you could interleave the data such that you only had to change after every 16 scanlines.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by tokumaru »

lidnariq wrote:Is this to get 16x8 attribute zones?
Nope, it's to draw software pixels that are 4 pixels tall, using tiles that are 8 pixels tall.
If so, you could interleave the data such that you only had to change after every 16 scanlines
I'm using the same principle, but on tiles rather than on attributes, so I can change nametables every 8 scanlines instead of 4. :wink:
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by Bregalad »

tokumaru wrote:Can anyone think of a way to do this that doesn't involve using the MMC3 (or other complex mappers with IRQ functionality) or wasting nearly 100% of the CPU power on timed code?
The obvious answer is using another mapper with scanline IRQs, such as any VRC mapper, MMC5, FME-7 or develop your game for the Famicom Disk System. I think that's not what you wanted to hear though.

DMC IRQs aren't precise enough for that, and you don't want to waste most of the CPU's time so the only way to go is developing a new hardware mapper capable of this automatically. By re-routing some adress line to CHR-A10 it should be doable easily, but will be havily non-standard and not emulatable.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by rainwarrior »

VRC IRQs are cycle based, rather than true scanline timings, so they might not be quite as good for chaining repeated splits like this.

A restricted subset of MMC3 probably isn't too bad to build these days.

A simple mapper that makes it easy could be great, too. Maybe something like the Punch Out mapper where reading byte 4 of a specific tile you place at the end of the line will trigger a split automatically. New mappers don't seem as big a problem to me as they used to, there's quite a few good actively developed emulators these days that might keep up.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by FrankenGraphics »

Yeah, for comparison, GTROM was let loose 2015(?), and by may 2017, mesen had full support. fceux r3293 has support for the most important features, and likewise, so does powerpak.
This is because GTROM has become a very popular homebrew mapper.

A mapper that is simple enough to be about as cheap as nrom, unrom, gtrom etc, yet passively interleaves rows from two nametables, would nicely fill a role for any homebrew that seeks a slanted topdown perspective (popular with adventure games, rpgs, action puzzles) or an isometric view.

The example below could be a probably have more liberally constructed maps, including the z axis, better shadow effects, and so on.
doodle i made some time ago for the "maybe sometime" pile of ideas.
doodle i made some time ago for the "maybe sometime" pile of ideas.
.

I'm not well-read on the cartridge port side, but am i right to believe all it'd take is cutting and jumpwiring some traces? alternatively from a design perspective, inculde a three-point jumper/solder bridge to be able to reroute the behaviour.
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by gauauu »

rainwarrior wrote:New mappers don't seem as big a problem to me as they used to, there's quite a few good actively developed emulators these days that might keep up.
FrankenGraphics wrote:Yeah, for comparison, GTROM was let loose 2015(?), and by may 2017, mesen had full support. fceux r3293 has support for the most important features, and likewise, so does powerpak.
This is because GTROM has become a very popular homebrew mapper.
It really all depends on whether you want emulator support primarily for development/test, vs if you plan to release a rom that you want the majority of people to be able to use. The average joe (who possibly plays emulated games on their phone or raspberry pi) won't have access to an emulator that supports GTROM or other new mappers for quite a while, I imagine.

That's not an issue if you primarily plan to release on cartridge-only, or if you don't care to target the larger rom-consuming community. But if you do, then using a new mapper will still limit your audience for quite a while. (and that's not even considering folks who have clones like the Retron 5, who may miss out when you use a custom mapper)


(I'm not trying to argue that a new mapper is a bad idea, heck, I'm using GTROM in the game I'm making. Just that there are potential downsides even IF you can find some emulator support)
User avatar
krzysiobal
Posts: 1036
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by krzysiobal »

For testing or playing under emulator - use MMC3
For doing physical cartridges - use 4020 counter and count 8 * 8 rising edges of PPU A12
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by FrankenGraphics »

good points gauauu, it then becomes a question of how you'd intend to spread the software. Unless it's a proof of concept for a small crowd.

-an mmc3 type of thing is available for everybody as a freely shared ROM.

-a cartridge release on a typical homebrew Kickstarter scale of 200-500 units (upper figure is rare) would benefit financially from having a cheaper mapper than an mmc3. Even if physical mmc3 games are doable like this, you need to reach a higher threshold to break even.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by lidnariq »

FrankenGraphics wrote:A mapper that is simple enough to be about as cheap as nrom, unrom, gtrom etc, yet passively interleaves rows from two nametables, would nicely fill a role for any homebrew that seeks a slanted topdown perspective (popular with adventure games, rpgs, action puzzles) or an isometric view.
[...]
I'm not well-read on the cartridge port side, but am i right to believe all it'd take is cutting and jumpwiring some traces? alternatively from a design perspective, inculde a three-point jumper/solder bridge to be able to reroute the behaviour.
Yes, one could easily add cartridge hardware—in fact, just a 74'161—to automatically interleave namatables every 4 rows.

Specifically: latch PPU A2..0 on reads from pattern tables (i.e. 74'161.CK ← PPU/RD and 74'161.LE ← PPUA13). Because of how the PPU's fetch cadence works, the first fetch will have bogus results—that nametable fetch follows a sprite pattern fetch instead of a background pattern fetch—but that can be concealed with the "mask left 8 pixels" control.

The complicated part is if you ever want to turn it off.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by tokumaru »

lidnariq, I'm in no way qualified to validate your idea, but it'd be great if it could really be this simple. Would CHR-RAM or 4-screen mirroring interfere with that in any way? I can live without being able to turn it off.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by tokumaru »

lidnariq wrote:Specifically: latch PPU A2..0 on reads from pattern tables (i.e. 74'161.CK ← PPU/RD and 74'161.LE ← PPUA13).
OK, I'm trying to make sense of if this: why do I need to latch PPU A2..0, and what do I do with them?

Now that I think of it, couldn't I latch just A2 (the bit that selects the top or bottom 4 rows of a tile) on pattern table reads, and use that as the lower name table selection bit? I'm not very good with hardware, so sorry if I'm way off, but my thinking is that whenever the top half of a tile is read, the left name table will be selected, and whenever the bottom half of a tile is read, the right name table will be selected. Does that make any sense?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by lidnariq »

Didn't you want automatic nametable switching? How are you thinking 4-screen would interact with that?

CHR-RAM wouldn't interfere.

This is approximately the same idea as mapper 96, or the initial drafts of what HardWareMan did for his InviteNES flashcart. (Unfortunately, his images expired from whatever host they're on)
tokumaru wrote:couldn't I latch just A2 (the bit that selects the top or bottom 4 rows of a tile) on pattern table reads, and use that as the lower name table selection bit?
No, that's exactly correct. I don't know if there's a cheaper way to get "latch one bit when signal is low and another signal rises" than just a single 74'161, though.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by tokumaru »

lidnariq wrote:Didn't you want automatic nametable switching? How are you thinking 4-screen would interact with that?
I don't know... I still want to have control over which pair of name tables to use with the automatic switching (i.e. the top 2 or the bottom 2), so I imagine I'd need another latch for that, right?

What I'm not sure is how I'd use the 2 name table selection bits to control the VRAM chip in the cartridge... They'd have to be used only on name table reads, so that'd be when A13 is high, right?
CHR-RAM wouldn't interfere.
OK.
This is approximately the same idea as mapper 96, or the initial drafts of what HardWareMan did for his InviteNES flashcart.
Oh, I didn't get much of that back then, but I see it now.
No, that's exactly correct. I don't know if there's a cheaper way to get "latch one bit when signal is low and another signal rises" than just a single 74'161, though.
Awesome. I guess this is still all a bit too experimental for my taste, though... It's mainly the lack of support for this in emulators and Flash carts that bothers me. I could build a socketed cartridge for development, but that'd be far from ideal.

EDIT: Wait, I don't need to latch the vertical name table selection bit, A11 can go through unmodified, but I do have to decide whether to drive the horizontal bit with the latched value (reads when A13 is high) or let A10 just go through (all other cases). Would that make 2 sets of 2 name tables possible?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Alternating name tables ($2000.0) every 8 scanlines

Post by lidnariq »

tokumaru wrote:
lidnariq wrote:Didn't you want automatic nametable switching? How are you thinking 4-screen would interact with that?
I don't know... I still want to have control over which pair of name tables to use with the automatic switching (i.e. the top 2 or the bottom 2), so I imagine I'd need another latch for that, right?

What I'm not sure is how I'd use the 2 name table selection bits to control the VRAM chip in the cartridge... They'd have to be used only on name table reads, so that'd be when A13 is high, right?
Think about it like this...

A nametable is 1K of memory. The PPU natively provides two controls (PPU A10 and A11) to address 4 nametables (but only pre-provides enough memory for 2). But you can keep on adding more address lines as long as you have enough memory for it.

For example:
"Horizontal mirroring" connects PPUA11 to CIRAMA10.
AOROM connects an output from the latch to CIRAMA10.
GTROM connects PPUA10, PPUA11, and an output from the latch (via extra hardware) to CHRRAMA10, CHRRAMA11, and CHRRAMA14.

All of these are ways to allocate some number of chunks of 1K of memory to the region seen by the PPU.

So there's a bunch of options, depending on just how much RAM you're talking about. If you wanted something like GTROM, but instead of having two planes of 4 nametables controlled by the CPU latch, you could instead just connect the output of the PPU address latch to the same extra hardware and end up with a single 64x120 "stout tile" display, corresponding to 512x480 pixels.

Alternatively, you could also get away with just using the 2K of RAM inside the NES; then you'd have a single 32x60 "stout tile" display, corresponding to 256x240 pixels.
It's mainly the lack of support for this in emulators
Looking quickly at Mesen's source (especially OekaKids and MMC2), I bet adding support would be really easy.
Post Reply