It is currently Sun Jun 24, 2018 8:18 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Fri Jun 01, 2018 4:08 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2094
Location: DIGDUG
Does anyone understand what he's doing in these videos?

https://youtu.be/ar9WRwCiSr0

https://youtu.be/hTlNVUmBA28

I see that he wired a Pi to a cartridge, and I'm assuming that he's changing CHR-RAM on the fly. But I don't get how the attribute tables can be changed every scanline without turning rendering off.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 4:15 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4051
Quote:
Cycles 1-256
The data for each tile is fetched during this phase. Each memory access takes 2 PPU cycles to complete, and 4 must be performed per tile:

Nametable byte
Attribute table byte
Tile bitmap low
Tile bitmap high (+8 bytes from tile bitmap low)


So each 8x1 sliver gets its own attribute table byte, they are just mapped to the same address for the whole 16x16 area. But if you are manipulating what bytes get read back, you can mess with the attribute byte for each 8x1 sliver.

Also there is no CHR-RAM, just a program that makes the PPU read back the bytes it wants it to read.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 4:43 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7229
Location: Seattle
dougeff wrote:
But I don't get how the attribute tables can be changed every scanline without turning rendering off.
You don't even need to use an external processor for it; I did so using just a raster effect on a mapper that supported 16 nametables (in this case, in ROM)—caveat: my attribute zones are 16x1 instead of 8x1, but I believe more careful timing could have switched nametable registers every 16 pixels (offset by 8 pixels relative to the native 16x16 pixel attribute grid) to achieve 8x1 attribute zones also.


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 5:17 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2094
Location: DIGDUG
So...he's changing PPU addresses during the attribute read?

I'm assuming that this sort of manipulation isn't feasible for a game? (without a Pi)

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 5:34 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7229
Location: Seattle
No, not at all. He's just directly taking advantage of the PPU's predictable fetch cadence. It always fetches the same four type of bytes over and over: the first byte is from the nametable, and that determines what address will be used later on. The second byte is from the attribute table, and two bits of it determine the palette used for that 8x1 sliver. The next two bytes are the two bitplanes for that 8x1 sliver.

(During sprites the nametable and attribute table fetches still happen, but their contents are ignored)

He can provide any raw numbers he wants, and the PPU just obligingly turns that into a picture.

That I can do something similar using 100% of the CPU time isn't really the same.

The MMC5's 8x8 attribute mode is the closest "real" thing to what he's done.

Tom7's method is really a hack: the Pi is really not designed for emitting bytes at 5.42.7MHz (and especially not in response to external stimuli); a cleaner prior design was linked in one of our discussion threads about tom7's instantiation.

For a game, without adding schmancy external hardware (i.e. MMC5, N163, VRC6, Sunsoft 4), the closest you'll get is GTROM with its 8 nametables. Those could be used with timed code to make 8x4 attribute zones to make a really pretty title screen, I guess.


Last edited by lidnariq on Fri Jun 01, 2018 5:52 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 5:40 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6351
Location: Canada
By the way there is already a thread about these videos: https://forums.nesdev.com/viewtopic.php?f=9&t=17398

However it was maybe not so focused on specific questions about how. Mostly people started coming up with arbitrary definitions for "NES game" in response instead.


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 6:45 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10527
Location: Rio de Janeiro - Brazil
Apparently there's no CHR-RAM or NT/AT RAM that the NES can write to, the cart is actually wired to disable the internal VRAM (cartridges using 4-screen layout may do this too, if the memory for the 4 name tables is inside the cartridge), and the Raspberry Pi watches the PPU bus to supply the appropriate data every time the PPU tries to fetch data from VRAM.

Even though attributes are limited to 16x16-pixel areas on the NES, the PPU actually fetches an attribute byte for every 8x1-pixel area, so if a mapper (like the MMC5) or a coprocessor (like the Raspberry Pi) keeps track of the memory fetches, it can supply different attribute data for each fetch, allowing for finer attribute distribution than the typical 16x16 chunks.


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 7:05 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2094
Location: DIGDUG
Quote:
wired to disable the internal VRAM (cartridges using 4-screen layout may do this too,


This was the answer I was looking for. I understand now.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 7:14 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10527
Location: Rio de Janeiro - Brazil
Yeah, you can use the CIRAM /CE line on the cartridge connector for this... Just tie it to +5V and the internal VRAM will be permanently disabled. The cartridge/mapper is then free to respond to VRAM fetches however it wants.

You can also do the opposite and keep the internal VRAM always enabled, even for CHR accesses, so that the NES would use its internal 2KB for both patterns and NTs/ATs, while the cartridge wouldn't have a CHR chip at all. This would result in a pretty challenging configuration to make a decent game with, since you'd only have 64 tiles and 1 name table (maybe more tiles if you blanked part of the screen) to work with. This had been discussed before ("1-chip NES games" or something).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

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