It is currently Tue Oct 17, 2017 2:45 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sat Apr 25, 2015 12:58 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7224
Location: Chexbres, VD, Switzerland
In this post, Myask wrote:
So what sort of CHR-banking (and PRG, I suppose) would be sensible, as it seems like "just" adding 8x8 attributes seems like a waste of CPLD?

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.

Quote:
It just sounds like a waste of space to dedicate the an entire 1KB to attributes, while all you really need is 240 bytes. Couldn't we use the rest of this memory as a name table for status bars or something?

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.


Last edited by Bregalad on Sat Apr 25, 2015 1:50 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 12:10 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
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.


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 12:51 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
(e: snipped other-topic-relevant portion)
Drag wrote:
Less-simple fixes would be tile counting like MMC5,
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.


Last edited by Myask on Mon Apr 27, 2015 4:06 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 1:14 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19084
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 4:44 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
...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.


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 5:55 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19084
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
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?

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.


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 6:32 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
tepples wrote:
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.


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 6:57 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19084
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sat Apr 25, 2015 9:27 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
tepples wrote:
The pattern address is sixteen times the tile index plus the Y line number.

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?


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 12:33 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7224
Location: Chexbres, VD, Switzerland
Quote:
...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.

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.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 8:07 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
Bregalad wrote:
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.

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.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 9:41 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19084
Location: NE Indiana, USA (NTSC)
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.

Image
Photo by Evan-Amos


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 9:50 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5709
Location: Canada
What are you calling "the NES's first direct successor"?


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 11:05 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19084
Location: NE Indiana, USA (NTSC)
TurboGrafx-16. I seem to remember Hudson proposing it to Nintendo; can someone dig up what I'm thinking of?


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 11:51 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group