How does a H/V mirroring switch WORK?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
How does a H/V mirroring switch WORK?
by on (#20796)
I can understand how to install a H/V mirroring switch on a devcart, but since I don't like to let learning opportunities go by, I really want to understand why that kind of mirroring control is possible.

What I don't get is, what do the address lines that connect to the CHR-ROM chip have to do with the name tables? You get what I'm saying? I can't see what the pattern tables could possibly have to do with the name tables...

If anyone can clear that up for me, I'd be very grateful. Thanks for the help.

by on (#20800)
Connecting VRAM's A10 line to CHR A10 keeps the memory linear (data goes into NT0 & 1) for horizontal scrolling. Connecting it to CHR A11 will make A10 "don't care" and since the bit is shifted up, NT0 is selected through $2000-27FF while NT1 is $2800-2FFF instead of $2000-23FF and $2400-27FF.

Horizontal scrolling (vert mirror) v= address bits
NT 0 = $2000 = %xxxx00xxxxxxxxxx = $2000 NT0
NT 1 = $2400 = %xxxx01xxxxxxxxxx = $2400 NT1
NT 2 = $2800 = %xxxx10xxxxxxxxxx = $2000 NT0
NT 3 = $2C00 = %xxxx11xxxxxxxxxx = $2400 NT1

A11 only really matters if there is 4 screen; because the internal chip is only 2K it's only partially decoded.

Vertical scrolling
NT 0 = $2000 = %xxxx0xxxxxxxxxxx = $2000 NT0
NT 1 = $2400 = %xxxx1xxxxxxxxxxx = $2800 NT2
NT 2 = $2800 = %xxxx0xxxxxxxxxxx = $2000 NT0
NT 3 = $2C00 = %xxxx1xxxxxxxxxxx = $2800 NT2

by on (#20825)
What kyuusaku said. Basically the interesting and important thing to understand is that VRAM A10 is an address input to the CHR memory in the NES. With /IRQ, I think those 2 are the only input-only pins on the NES connector.

And yeah it is the same address lines as the pattern table, but there are separate chip enables for pattern and nametables. Like on Squeedo I keep the NES's VRAM disabled always, and if you wanted to for some reason, you could select the highest CHR-RAM bank to be pattern table and nametables at the same time.

by on (#20842)
It makes more sense now, since I know that these address lines are shared... but I'm still a bit confused. Not much about mirroring, I'm cool knowing that those address lines are also used for the name tables, but something else.

The CHR chip is disabled when memory over $1FFF is read, so that the data can come from the name tables (memory inside the NES) instead, right?

So, A12 would define if memory over $1FFF is being read (if A12 = 1 then address >= 8192) but /A13 is used for /CE? I don't get it... Why A13? And if the "/" means "inverted", if addresses over $3FFF were being accessed, the inverse of A13 would be 0... 0 into /CE would mean that the chip would be enabled when acessing memory over $3FFF? That's messed up... I must be sleepy or something, because that makes no sense!

Please guys, tell me how A13 relates to CE, or I'll go crazy trying to figure this out.

And Memblers, how do you manage to disable the NES's VRAM?

If I had a CHR-RAM chip on a cart, and it was larger than 8KB would it be simple to also use it for 4-screen mirroring then? just curious...

I guess the bottom line is: how does the NES know where to get the data from? Is it all done by just by enabling/disabling chips? How exactly is that set up? How do you specify if the name/attribute table data comes from the NES's VRAM or from the cart?

Thanks a lot for clearing this up!

EDIT: Sorry guys, my bad. I see now that A13 really is the bit that when set means that memory over $1FFF is being read. But I'm still confused about "/A13" being used as "/CE", mainly because of the "/".

by on (#20844)
I believe /A13 gets inverted before entering the CHR chip as /CE.

The cart can disable internal VRAM by forcing VRAM /CE high. Normally CHR /A13 is passed untouched through to the NES as VRAM /CE, but a cart can filter this behavior when the PPU address is within a certain range. I think some carts disable internal VRAM completely and maintain all 4 nametables in 4K of VRAM loaded on the cart.

I see no reason why you can't use a larger CHR-RAM chip to hold nametable data along with CHR data, as long as you use proper address decoding.

by on (#20846)
tokumaru wrote:
The CHR chip is disabled when memory over $1FFF is read, so that the data can come from the name tables (memory inside the NES) instead, right?


Right, these are the same addresses you set with the $2006 reg.


Quote:
And Memblers, how do you manage to disable the NES's VRAM?

By simply connecting the VRAM/CE (to NES internal RAM) to 5V, that'll put it to sleep. :)

Quote:
If I had a CHR-RAM chip on a cart, and it was larger than 8KB would it be simple to also use it for 4-screen mirroring then? just curious...

Yep, if you don't need any CHR bankswitching it'd be super simple. On Squeedo I have the name/ce gated with a NAND for each of my bank select bits.


Quote:
EDIT: Sorry guys, my bad. I see now that A13 really is the bit that when set means that memory over $1FFF is being read. But I'm still confused about "/A13" being used as "/CE", mainly because of the "/".


The / just means it's A13 inverted.

by on (#20848)
Memblers wrote:
The / just means it's A13 inverted.

Yeah, I get that. What confuses me is that the CE signal is also inverted.

so, when accessing address $2000, for example, A13 is 1. When inverted, it becomes 0. And then, 0 goes into /CE of the chip, and if 0 is "false", inverted it would become true, meanign that the chip would be enabled when accessing that memory. That's what doesn't make sense.

Unless 0 into /CE means that the chip is to be disabled, but that doesn't make sense, sice I'v seen people connect GND (0) to /CE before and the chips work.

Seriously, what am I missing here?

One more question about A13: In the case of mappers that do CHR bankswitching, /A13 is not directly connected to the chip, right? I mean, you have to be able to read memory over $1FFF, but the mapper takes care of mapping it to below that space. Is that correct? I'm asking because the pinouts of the CHR chips found on the nesdev page say that /A13 is conected to the chips, even the larger ones.

by on (#20849)
tokumaru wrote:
so, when accessing address $2000, for example, A13 is 1. When inverted, it becomes 0. And then, 0 goes into /CE of the chip, and if 0 is "false", inverted it would become true, meanign that the chip would be enabled when accessing that memory.


That is correct - by connecting PPU /A13 to VRAM /CE, you cause VRAM to be enabled for $2000-$3FFF. PPU A13 typically gets connected to CHR ROM|RAM /CE, which enables it for $0000-$1FFF.

by on (#20850)
But then why does this document say that /A13 goes into the CHR chip? I understand /A13 going into the VRAM chip, but not the CHR chip. I know that the document says "CE" and not "/CE", but that can't be right, since when placing EPROMs or Flash ROMs instead what goes in that hole is actually "/CE".

by on (#20904)
'VRAM' is a synonym of 'CHRRAM'.

On my understanding, the adresses on PPU bus are NOT the same as acedded from $2006, acutally A13 is toggled for some reason. So, $0000-$0fff become the name table space, and $2000-$3fff pattern table space. /CE is usually active low, but on some 8kb SRAMs there is a CE active high input, so I don't know.
To use 4-screen mirroring, you could just lazily put some 32kb RAM chip on the cart and leave CIRAM /CE high. That will get 8kb of CHRRAM and 4 name tables in the same chip. The PPU will never write or read anything in the range $1000-$1fff, so I think it's okay. If you wan't CHRROM, or if you just don't like being lazy and wasting the power of chips, you can use a '139 style decoder to get your own 2kb chip used for nametable 0 and 1, and the CIRAM chip for the nametables 2 and 3 (or any combination in that style). I think some '00 NAND gates can do the decoding also.
The typical way official carts does it is keep a whoel 8kb SRAM chip on the board (like for CHRRAM), but just have A13 disabling it instead of /A13. Also, it's a good idea to put A12 to ground instead to A12, because you never known when $1000-$1fff could be acessed (there is palette RAM mirored in $1f00-$1fff, remember, so it would be bad to have anyother device on the bus at that time).

Actually, there is thousands of other possibilities. You could get funky 3-screen mirroring, or do nametable bankswitching, or use CHRROM as nametable data, or whathver. Anything is allowed, since the cart has acess to the whole CHR bus.

You could even have a cart with no CHROM nor CHRAM at all, and have only ROM. If you tie for example CIRAM /CE to ground and CIRAM A10 to CHR A13, you'll definitely get one screen mirroring and no opportunity to have more than one nametable, and have 1kb of CHRRAM mirrored 8 times trough the pattern table. That would only allow 64 tiles to be used at one time. This could be done for very plain games on a cartridges, and prices could be lower by this technique to have no CHR chip at all !

by on (#20915)
tokumaru wrote:
But then why does this document say that /A13 goes into the CHR chip?


Because that document is wrong. If it had labeled the pin as +CE, then it would've been okay, but it just says "CE", and "CHR /RD" is labeled as "OE" even though it is clearly /OE.

Next question?

by on (#20923)
I see, but...

Quietust wrote:
Next question?

...why does a chip with a pin clearly named "/CE" (EPROM, Flash ROM) work when used in place of the Nintendo ROM (which supposedly has a +CE pin)?

Sorry if I'm being annoying over this, but this can't be right. You can't connect /A13 to /CE and expect the chip to be enabled when accessing memory below $2000.

by on (#20925)
tokumaru wrote:
I see, but...

Quietust wrote:
Next question?

...why does a chip with a pin clearly named "/CE" (EPROM, Flash ROM) work when used in place of the Nintendo ROM (which supposedly has a +CE pin)?

Sorry if I'm being annoying over this, but this can't be right. You can't connect /A13 to /CE and expect the chip to be enabled when accessing memory below $2000.


Because the Nintendo ROM doesn't have a +CE pin - it has a /CE pin which is connected to A13. /A13 is not used for CHR ROM (only nametable RAM), which is why I said that said document is wrong.

by on (#20927)
Quietust wrote:
Because the Nintendo ROM doesn't have a +CE pin - it has a /CE pin which is connected to A13. /A13 is not used for CHR ROM (only nametable RAM), which is why I said that said document is wrong.

Ahh... that makes a hell lot more sense! If A13 (no "/") is responsible for disabling the CHR chip and /A13 is responsible for disabling nametable RAM, everything is OK!

The problem is that I, as a humble hardware newbie, have to belive in the documents avaliable, and am not always able to spot these errors.

Thanks for clearing that up. It's such a simple answer ("actually, A13 is connected to /CE on the CHR chip, not /A13") that I wonder why no one said that before.

by on (#20928)
So the $2006 adresses matches the ones found on the CHR bus finally.

Actually the doccument *could* be right if it would also invert CHR A13 and CHR /A13 on the connector, so it all depends of the viewpoins.

by on (#20948)
Bregalad wrote:
You could even have a cart with no CHROM nor CHRAM at all, and have only ROM. If you tie for example CIRAM /CE to ground and CIRAM A10 to CHR A13, you'll definitely get one screen mirroring and no opportunity to have more than one nametable, and have 1kb of CHRRAM mirrored 8 times trough the pattern table. That would only allow 64 tiles to be used at one time.

Now this is a funky thing to try...! Although I doubt that only 64 tiles could be enough for a decent game. On the other hand, since it's RAM, the tiles could be updated to produce the animations, so that only 1 frame of animation is defined at a time, using as little tiles as possible. It's still too little for, say, a platformer or an RPG.

If you break the 64 tiles in half, 32 for sprites and 32 for the background, only 8 unique metatiles (2x2 tiles) could be defined. Too little for a meaningful background. Careful use of the palettes could make it look like there were more. As for the sprites, if your player is 16x32 pixels in size, it would use 8 tiles, leaving only 24 for enemies and other objects. Maybe enough to define 2 different kinds of enemies and still leave room for a couple of items and such. Sounds doable, but would look pretty plain.

It's at least curious that this is possible. Maybe it could work for a simple puzzle game. I really don't see the point today, but back in the days of the NES, it might have been cheaper to do simple puzzle games like this.

by on (#20954)
tokumaru wrote:
Although I doubt that only 64 tiles could be enough for a decent game. On the other hand, since it's RAM, the tiles could be updated to produce the animations, so that only 1 frame of animation is defined at a time, using as little tiles as possible. It's still too little for, say, a platformer or an RPG.

Centipede had 64 BG tiles (26 used for letters) and 64 sprite tiles.

Quote:
If you break the 64 tiles in half, 32 for sprites and 32 for the background, only 8 unique metatiles (2x2 tiles) could be defined.

Unless you use destructible environment (a la Crystal Mines/Exodus) and have the sprites and background share tiles.

Quote:
Too little for a meaningful background. Careful use of the palettes could make it look like there were more.

That and careful use of the solids.

Quote:
As for the sprites, if your player is 16x32 pixels in size, it would use 8 tiles, leaving only 24 for enemies and other objects.

8x16 (size of Smash TV character) would probably be a better choice here.

Quote:
Maybe enough to define 2 different kinds of enemies and still leave room for a couple of items and such. Sounds doable, but would look pretty plain.

It's at least curious that this is possible. Maybe it could work for a simple puzzle game.

It would work for at least Tetris, Dr. M, Yoshi, Yoshi's Cookie, Palamedes, and most other puzzle games I've played on NES (except Klax, part of whose playfield is a pseudo 3D projection).

by on (#20965)
I think a game with any complexity but almost no graphics (or very plain graphics) could use that 64-tiles trick.
Puzzle or chess game is what comes in mind. Also, I think Memblers' Munchie Attack could probably do this.
Actually there could be a huge PRGROM, with a simple bankswitching system, and no CHR at all (just the circuitery to use the internal CIRAM).
This could be done in emulation using mapper 7, and only write to the first 64 tiles available (and just use pattern table 0 always).

by on (#21199)
Bregalad wrote:
I think a game with any complexity but almost no graphics (or very plain graphics) could use that 64-tiles trick.
Puzzle or chess game is what comes in mind. Also, I think Memblers' Munchie Attack could probably do this.


To bring back this (slightly) old thread, just wanted to mention that I think that's really an excellent idea. It would work with Munchie Attack, with the minor (and kinda frivolous) exception of the way the title screen scrolls into view. 64 tiles is just enough for it. Cutting cost down by a couple bucks, one less chip, and less soldering, that's great. It's totally perfect for making NSF carts!

Wish I had known about it when I made my UNROM board, it could be rewired easily but the only bad thing is it'd be like the first Garage Cart where I'd have to cut a notch in the cart case so it won't smash the wire to the edge pin. I'll definitely keep that in mind if I ever revise the PCB.