MyaxGrafx: Beyond 8x8: 8x1 pixel attributes...and more?

Yes and no. With my idea it could be realized with about ~4 discrete chip I guess. If you do only that then it's a waste of a CPLD, but if you combine that with a MMC3-class or even a simpler MMC1-class mapper then it's definitely no waste.


Well I'd take simple (identical to Name Table) addressing over a complicated bit scheme that is extremely annoying to go by, and very unsuited to the little 6502 CPU which can only shift one register one bit at a time... With ARM the attribute tables of the NES wouldn't be so much of a pain

But I think it might be possible to have 8x2 attributes by divinding the byte in the neo-attribute-table into four regions of 2 pixels height, each one having it's own 2 bits. This would definitely require a CPLD, as it'd need highacking the data line of the CHR-RAM in very specific fashion.

If you monitor the pattern fetches, you can determine which row of a tile is being rendered, and thus, which row of an 8x1 attribute table is needed. The row would be whatever the pattern address is, masked with 7.

The pattern fetch occurs after the attribute fetch though, so you'd be relying on the previous tile's patterns, which would work because the BG will always render the same row over and over for a single scanline, unless you split the screen (in which the tile immediately after the split may not have the correct attribute row). However, the leftmost tile of the screen will always have the wrong attribute row (it'll always be row 7, unless the scanline has 8 sprites on it, in which case it'll depend on the 8th sprite's Y position), and the only simple fix I can think of is to use the PPU's 8-pixel mask to hide the glitch.

Less-simple fixes would be tile counting like MMC5, or sprite pattern fetch vs bg pattern fetch like the MMC3, but it'd depend on whether being able to show the leftmost column of BG tiles is worth all the circuitry necessary to compensate for the glitch.

(e: snipped other-topic-relevant portion)
Hmm, watching for the triple-fetch and throwing in an increment would do for...actually, no, triple-fetch comes AFTER the first two tilefetches. Would have to tilecount to make the left TWO tiles get non-offset attributes...which would get complicated by the pre-render line, as it comes before the reset of vert(v) scroll.

Hmm.

You could have the triple nametable fetch clear a 6-bit counter that increments the line index after fetch 32 and ignores D2-D0 for fetches 33-40, so that it'll be correct for attribute fetch 41, which is the first fetch of the next background line.

...and there goes all the simplicity! =)

Honestly, better attribute resolution than 8x8 is cool and all, but where would you find the bandwidth to update the background when each tile has 8 sets of attributes? In the best case scenario (no redundant bits), we're looking at 30 NT bytes + 60 attribute bytes for a simple column. This might be cool for cutscenes, but wouldn't make much sense in a game that scrolls, unless the game was able to turn this on an off, making the mapper even more complex.

Where would you find the bandwidth to update the background when each tile has 16 bytes of CHR data? The most obvious translation of the TMS9918 display model, which uses a separate pair of colors per 8x1 sliver, would provide eight rows of attribute for each tile, not each nametable entry.

Are you really suggesting that attributes be selected in function of the pattern address rather than the NT address? That would actually make scrolling FASTER, since you wouldn't have to worry about attributes at all, at the expense of slower pattern updates (18 bytes per tile instead of 16... for background tiles anyway, since sprites wouldn't use these attribute bits) and duplicate tiles for the ones that would normally use palette swaps (which is more common on sprites than background, anyway).

Interesting idea, but is it possible, though? You don't have the pattern address yet when attributes are fetched, only the tile index.

The pattern address is sixteen times the tile index plus the Y line number.

But then anything dealing with 8x1 probably isn't so "minimal". First to PM me a split point gets a cookie.

What about bit 4 of PPU register $2000, which you can't monitor? Can you treat accesses to $0XXX and $1XXX all the same or would this be like the MMC3 requiring specific pattern tables to be used for sprites and background?

Honnestly a solution I find just as viable would be to have the attribute/colour data depend on the tile number itself, rather than it's position on the screen. That way attributes would be linked to pattern tables instead of name tables. I belive that'd fix this problem, but it would not be possible to re-use a tile for different palettes across the screen.

We could even use CHR-ROM for this, since you're likely to want to have some bunch of tiles always having the same palette everywhere in the game. By banking different CHR-ROM in a particular place that'd change which tiles uses which colour. Pretty cool, no? Of course that'd kill all the simplicity, as already said.

As for sacrifying half of CIRAM for fined attributes I think it makes sense because if you have finer attribute you can scroll with single-screen mirroring with no glitches, so a second nametable is only needed for a status bar or special effects. But many games do not necessary need status bars, a few sprites can be enough to display information.

Yeah, I got that from tepples' message, and found the idea really cool. I asked about telling $0XXX and $1XXX apart, but now I realize that's not necessary, just use the tile index and it will work for both pattern tables.

I don't think that giving up on palette swaps in the same screen is such a big problem, specially since you can still do it with sprites.

I also liked your CHR-ROM idea. Loading the extended attributes automatically along with the tiles is a nice advantage.

I think part of the reason people try to stretch the NES into something it was never intended to be is that the NES's first direct successor never sold in big enough volumes to make it affordable to casual collectors.

Cookie goes to Myask.


Photo by Evan-Amos

What are you calling "the NES's first direct successor"?

TurboGrafx-16. I seem to remember Hudson proposing it to Nintendo; can someone dig up what I'm thinking of?

It didn't sell in big enough quantities? I recall it completely trashing Sega's systems in Japan. But yeah, I guess the problem is having to scourge it away from Japan.

I'm not sure if Nintendo was ever proposed a console by Hudson, but if that's the case, then the Playstation would make a whole lot more sense now. The TG16 failed without Nintendo's involvement, why shouldn't the Playstation? And just like the PCE, it was backed by an electronics company larger than Nintendo.

Regardless, the PCE would fit Nintendo's logic of using frugal but capable tech proposed by Yokoi (ironically enough, the N64 and GameCube, and to some extent the SNES, used new, proprietary hardware that developers weren't quite familiar with), and was later taken to the extreme by Iwata. The PCE was essentially a supercharged NES, and in ways could actually outperform both the Genesis and SNES, at least on the CPU level, at the cost of having relatively old-fashioned graphical capabilities. It was a 6502 based machine that could display one layer of backgrounds and one layer of sprites, not unlike the NES, which means developer adoption for the system would be it's main advantage, at least in the short term due to the poor video hardware.