Two impossible effects in Mother?

In Mother there are 2 impressive graphical effects before the final boss fight that I thought were impossible on the NES!

1) Apparently 2 BG layers
2) SNES-like "mosaic" effect

Any info on this?

http://www.youtube.com/watch?v=wz6Ueh39A1g

Mother uses MMC3, so probably using the scanline counter to do a timed screen split at the 'ground' area. Mosaic effect is probably CHR bank switching.

Ah, of course. I also realized the rocks off to the sides are probably just sprites.

Actually looking closely, the holes in the ground show the other layer, so I'm not sure on the screen split idea.

Movax12: a scanline split doesn't account for the ragged edge/overlap along the entire line. (Edit: ah, you saw while I was posting.)

Why does it say (c) 2003 at the start of the video?

After looking around I found out why it says (c) 2003. This is a GBA game. Mystery solved.

Here's the Famicom version:
https://www.youtube.com/watch?v=y1gs2ndXZLQ

Would it be the GBA version instead of the original Famicom version?

Ah good, I couldn't figure out how that layering could be possible. No mosaic effect here though I am sure I've seen a game that does it with CHR banks. I think it was Kirby's Adventure?

famicom/NES: http://www.youtube.com/watch?v=R4V727GosfU

Edit: Kirby mosaic effect.. very fast, but it uses CHR banks: http://youtu.be/BVqSHZyu6n0?t=6m5s

Yeah. I looked around for the original Famicom version and it used a hard scanline split. Also the "flash" at the beginning is less smooth, and there was no mosaic effect, but it did pause awkwardly, as if there was supposed to be one. Go figure.

Seems to me that the holes on the ground do not show the other layer in the second clip, so it's definitely a split screen effect, and the 1st clip is from another version, probably the GBA one.

The first effect would indeed be hard to pull off on the NES, but could be done if you were willing to animate the CHR-RAM data of all the tiles where the layers overlap, and a single palette can represent both layers (at least near the split point). Hardly worth the trouble IMO.

The second effect could be pre-calculated, and the name tables updated really fast (or not that fast if you use the unseen part of the name tables for double-buffering).

I heard that Earthbound does a very nasty copy protection ckeck right before the last boss and deletes all save data if it founds out it's a pirated copy.
Could it be the cause of this awkward pause?

That's correct, Earthound do that.


If you reffer to what sonder wrote, then you confuse games. Eathbound (the SNES game) have the copy protection you mentioned. The game in discussion (officially named "Mother", never released in outside japan) ,as far as I know, does not - so it can not be the cause of the long pause.

Now I'm actually interested about the pause, was it intentional or not.

I guess the Kirby one uses at minimum 2k for 2 extra CHR pages, maybe? Maybe more depending on how many unique tiles are onscreen.

I had a funny thought though, with a custom mapper you could mask out the low 3 bits of CHR-ROM progressively for a vertical mosaic, and redirect the data lines for a horizontal one. (Probably this would be silly to do, especially if ROM is not scarce.)

If you want to be able to do mosaic everywhere (as on certain SNES games) without the bus masking, then it'd take a quadrupling of CHR ROM size or specialized hardware to queue up CHR RAM rewrites and execute them during dead times in the scanline.

the second idea sounds ... involved. at that stage you might as well move to the SNES

what's bus masking though?

"Bus masking" was my suggestion that you could get a vertical mosaic by applying a logical AND mask to the CHR-ROM address bus.

For instance, if you AND with %11111111111110 this means every second byte will be redirected to the previous byte. On CHR data this means every second line is a duplicate of the line above it. Mask another bit %11111111111100 and now you're duplicating 4 bytes at a time, etc.

For horizontal you would dupicate data lines instead. Duplicate every second bit in the fetched byte, every fourth bit, etc.. These aren't addressed, though, so instead of "bus masking" it'd be some kind of "multiplexing" operation, I suppose.

Edit: Actually, I guess if you didn't use the internal nametables and used your own on the cartridge, you could apply more masking for the nametable fetches to continue the mosaic beyond the 8x8 tile level?

What rainwarrior said. Specifically, one could pixelate the Y axis by having an AND or OR gate and three latched bits; something like CHRROM A[0..2] = AND(PPU A[0..2],LATCH0..2).
The X axis would be a much messier transformation; I don't see a way to do it short of a full multiplexer.

Yes, building a mapper that would allow mosaic of sizes 2, 4 and 8 both horizontally and vertically would actually be quite simple !
It's a shame this wasn't added to MMC5 for instance.

This can still easily be done in software (if CHR-RAM), though this will eat up CPU time and VRAM bandwith, or in hardware with CHR-ROM by wasting banks (Mega Man 5 does this). Not as cool as a mapper doing it !

Mosaic of other sizes would be hell of a nightmare to realize, even on a mapper.

Considering that modern SRAMs are normally 32K or larger, while a game with CHR RAM not often needs that much at once, extra CHR RAM banks could be used for the mozaic effect.

If you are animating any CHR RAM tiles, be they background or sprite, that quickly becomes impractical. Writing everything to CHR RAM four times just so that you can turn on mosaic when needed will cut CHR RAM update speed by a factor of four. That's what I meant by the update queue.

Not every game needs per-frame CHR RAM updates. One or four time CHR RAM update at start of a level won't make much difference for the player.