It is currently Sat Nov 18, 2017 11:57 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Apr 22, 2015 6:52 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 946
In this post, tepples wrote:
Perhaps someone should mock up a specification for a CPLD that only provides 8x8 attributes and nothing else.

So something (static ver.) that did basically this:


Attachments:
MyaGrafx.png
MyaGrafx.png [ 2.33 KiB | Viewed 4037 times ]


Last edited by Myask on Thu Apr 23, 2015 8:35 am, edited 1 time in total.
Top
 Profile  
 
PostPosted: Wed Apr 22, 2015 8:55 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 946
New version with different attribute organisation, moment while I make a new graphic.


Attachments:
MyaGrafxDS.png
MyaGrafxDS.png [ 2.46 KiB | Viewed 4005 times ]
Top
 Profile  
 
PostPosted: Fri Apr 24, 2015 8:22 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Yeah, I was about to yell at you with the previous organization =P (although I think that it being big endian instead of little endian may be better, but this is still more manageable anyway)


Top
 Profile  
 
PostPosted: Fri Apr 24, 2015 8:50 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
The original organization is "free" because it retains the PPU's existing subdivision. The nicer organization requires something to shove bits around ... which is why UNL_DripGame presents its interface to 8x8 attributes as a 2048x2-bit array in CPU memory. (Does the convenience of "no bitpacking" outweigh the "takes four times as long"?)


Top
 Profile  
 
PostPosted: Fri Apr 24, 2015 9:10 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7266
Location: Chexbres, VD, Switzerland
I do not understand this picture. Attribute table RAM is normally $40 bytes long.

Personally if I'd have to do a circuit that does *only* 8x8 (or any finer than 16x16) attribute size, I believe it should be possible to do with discrete logic (and maybe PAL), by sacrifying one name table in CIRAM, and use the other half of CIRAM for colour data. Unfortunately it's *not* possible to highack the adress lines of CIRAM, making such a trick hard to realize. The answer is to steal a part of CHR-RAM, whose address lines *can* be highacked, by the second 1k of CIRAM.

So it'd work like that :
* Name-table : 1k of CIRAM (minus $3c0-$3ff, unused)
* Finer-grained attribute-table : 1k of CHR-RAM (reads like a name, table)
* Pattern tables : 7k stands in physical CHR-RAM, and 1k in the second half of CIRAM, but nobody notices, and this fakes 8k of CHR-RAM

A register traps NT fetched, and uses it's adress to replace adress lines of CHR-RAM on AT fetches... that's it. Not very simple, but not very complicated either. Oh, and all the content of the new attribute table should be repeated 4 times in a byte.


Top
 Profile  
 
PostPosted: Fri Apr 24, 2015 10:29 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
Nice idea, Bregalad! 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?


Top
 Profile  
 
PostPosted: Fri Apr 24, 2015 12:55 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
I touched on this briefly when I was working on my own hypothetical mapper.

You take advantage of the fact that the currently-needed attribute fetching address is derived from the nametable fetch that occurs immediately beforehand, so that's the first fetch with ppuA13 high. You just remember the address from that fetch (using a latch or something), and then you rearrange the bits to form a new attribute address to fetch. My design arranged the expanded attribute table to be like the regular attribute table, but with 8x8 regions instead of 16x16 (so each byte described a 16x16 region of four 8x8 regions).

And then after that, my design was to extract the two bits of interest from the extended attribute byte, repeating them 4 times to form a full byte, since the NES is still expecting its own attribute format and will select two bits out of the byte on its own, mirroring the bits just removes the need to figure out which two bits the NES is going to extract from the byte you give it.


Top
 Profile  
 
PostPosted: Fri Apr 24, 2015 1:01 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
It would probably be simple to just mirror the bits in the software that fills the attribute table, if you wanted to avoid spending hardware on extra data line mirroring logic.

Spending 1k on attributes instead of packing them sounds sensible enough to me, if it simplifies the hardware. You're probably not hurting for CHR-RAM size these days.


Top
 Profile  
 
PostPosted: Fri Apr 24, 2015 1:38 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 946
I thought I addressed most of this in the linked page in my userspace. Did people not click through?
Bregalad wrote:
I do not understand this picture. Attribute table RAM is normally $40 bytes long.
I seem to have neglected to precisely mention the actual "add a RAM chip to the cart to handle attributes" anywhere, aside from the //then cart-internals: first, the (probably 6264) But since the [added] RAM was only being used for Attribute Tables, not CHR, I called it ATRAM.
Bregalad wrote:
Unfortunately it's *not* possible to highack the adress lines of CIRAM,

I did note/mention that...
Bregalad wrote:
A register traps NT fetched, and uses it's adress to replace adress lines of CHR-RAM on AT fetches... that's it. Not very simple, but not very complicated either. Oh, and all the content of the new attribute table should be repeated 4 times in a byte.

That, however, is pretty close to exactly what the Verilog I wrote on the linked page in my userspace does. (It also remaps more of PPU-address-space as a write port.) It stores each attribute byte as packed, though, and just mirrors the relevant two-bits across the byte when read based on the preceding NT-fetch...like what Drag said.

[hr]

Mind, I didn't actually design/code the actual PRG- and CHR-mapping portions that need taking care of. I'm told that 1,2,4kiB SRAMs are no longer cheaply available, just 8kiB and 32kiB. The 4-screen AT is ~1kiB. 4-screen NT (that is, adding 2 screens' worth) is ~2kiB. CHR-RAM unbanked is 8kiB, so that's not nice to add without adding banking...

e: 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?


Top
 Profile  
 
PostPosted: Fri Apr 24, 2015 4:28 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
I've figured out a simple "CNRAM" style discrete logic 8x8 attributes in 5 ICs (nesdevwiki:User:Lidnariq/Mapper thoughts#8×8 attributes).

For the programmer, it'd be four 8 KiB pages of CHR-RAM, where tile #s $3C-$3F, $7C-$7F, $BC-$BF, and $FC-$FF in the left pattern table is replaced with the replacement attribute tables. Each of the four pages would correspond to the four corners of each 16x16 zone.

But this is the layout that Sik was complaining about, so maybe it's a bit too annoying.


Top
 Profile  
 
PostPosted: Fri Apr 24, 2015 11:44 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
Oops, I saw the image and skipped right over the link. Sorry. :P It looks like we had the same idea, so I don't have anything else to add, other than I tried a couple of layouts for the bitpacking and settled on the "like the PPU except 8x8" because it was already pretty versatile for both horizontal and vertical nametable updates.

I think Tepples might've mentioned the CPLD so there'd be an implementation of 8x8 attribute tables for others to use in their CPLD mappers, since 8x8 attributes doesn't really provide any advantages or disadvantages for any particular chr/prg banking style.


Top
 Profile  
 
PostPosted: Mon Apr 27, 2015 4:18 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 946
tokumaru wrote:
Nice idea, Bregalad! 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?

(moved from split topic)
"...per nametable upgraded. (And technically, 180 bytes, if you let CIRAM take some, but then you have less arrangement control.)"
Quote:
since 8x8 attributes doesn't really provide any advantages or disadvantages for any particular chr/prg banking style.

Quote:
like a waste of CPLD

okay, more like a waste of a 6264 (8kiB)...
There's already address lines attached to nice-arranged (present revision) to allow PPU-space mapped registers, at 14'b__11_xx01_RRRx_xxRR, instead of in CPU-space, but that would prevent raster effects from being as easy or as nice.


Top
 Profile  
 
PostPosted: Fri Oct 09, 2015 12:34 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 946
It occurs to me that one could implement 8x16 attributes with a little discrete logic: a flip-flop to toggle even/odd for each AT fetch, hooked up (with an AND to mask it to only AT area) to CIRAM /A10, so that the second nametable's attribute zone gets co-opted for the other half of the first. [Like my other "simple" suggestions, this is hellish to write to; restricting the oscillating behavior to reads with another input on the AND, and allowing PPUA10 to control CIRAMA10 for writes, would make it somewhat easier at the cost of somewhat more logic...but maybe you could fit it all in one NAND chip.]

16x8 attributes would be harder, since you need to implement a scanline counter and then switch every 8.

Of course, were the cartridge to have access to four more address lines, one would have just enough to maximize the first nametable's attribute density at 8x1, putting it in the other table. But that's just wishful thinking.


Top
 Profile  
 
PostPosted: Fri Oct 09, 2015 12:56 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
For either 8x16 or 16x8 attributes you may as well just latch A0 or A5 on the nametable fetch.


Top
 Profile  
 
PostPosted: Fri May 20, 2016 8:02 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 946
I was pondering how to make hexagon-arranged square attributes (think how Koei's strategy games often do it)--but then I realized that just doing a 16x8 and having some mild redundancy in attribute tables would be far, far, easier than actually implementing 16x16 offset attributes (check row, check column, selecting the proper attribute out of the byte, adding to the row...) along with being more flexible for the rest of the screen.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 0 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