I am doing half decent going through the nerdy nights tutorials. While looking at the 'Backgrounds' section, I'm not exactly sure how different palettes are assigned. Maybe it's a bit much to ask, but anyone willing to show me how that works with the example code from the background tutorial script. I know the color limits and such I think, just don't see how the colors are assigned from the .asm file.
Maybe post the .asm file as an attachment so people can see it and tell you?
General palette details, including PPU memory offsets for what's relevant: https://wiki.nesdev.com/w/index.php/PPU_palettes
General palette details, including PPU memory offsets for what's relevant: https://wiki.nesdev.com/w/index.php/PPU_palettes
This is the file included with the tutorial. when ran through emultaor the background tiles have different palette colors, I really think I'm over reading something, I see where u can enter the palette color numbers, add sprites etc, just not sure which bit says, ok these tiles are that color, and these over there are this color lol I dunno how else to explain it, I can't really read the language yet, but I can spot where somethings are happening, just not clear.
Are we talking about sprites or backgrounds? Your Subject says sprites, but your description now says backgrounds.
The part you're probably confused about is the attribute table: https://wiki.nesdev.com/w/index.php/PPU ... ute_tables
Note that I do not find this page particularly helpful, especially for beginners, but everyone reads/interprets documentation differently. From my own docs in days of yore:
Hope this helps.
The part you're probably confused about is the attribute table: https://wiki.nesdev.com/w/index.php/PPU ... ute_tables
Note that I do not find this page particularly helpful, especially for beginners, but everyone reads/interprets documentation differently. From my own docs in days of yore:
Code:
C. Name Tables
--------------
The NES displays graphics using a matrix of "tiles"; this grid is called
a Name Table. Tiles themselves are 8x8 pixels. The entire Name Table
itself is 32x30 tiles (256x240 pixels). Keep in mind that the displayed
resolution differs between NTSC and PAL units.
The Name Tables holds the tile number of the data kept in the Pattern
Table (continue on).
D. Pattern Tables
-----------------
The Pattern Table contains the actual 8x8 tiles which the Name Table
refers to. It also holds the lower two (2) bits of the 4-bit colour
matrix needed to access all 16 colours of the NES palette. Example:
VRAM Contents of Colour
Addr Pattern Table Result
------ --------------- --------
$0000: %00010000 = $10 --+ ...1.... Periods are used to
.. %00000000 = $00 | ..2.2... represent colour 0.
.. %01000100 = $44 | .3...3.. Numbers represent
.. %00000000 = $00 +-- Bit 0 2.....2. the actual palette
.. %11111110 = $FE | 1111111. colour #.
.. %00000000 = $00 | 2.....2.
.. %10000010 = $82 | 3.....3.
$0007: %00000000 = $00 --+ ........
$0008: %00000000 = $00 --+
.. %00101000 = $28 |
.. %01000100 = $44 |
.. %10000010 = $82 +-- Bit 1
.. %00000000 = $00 |
.. %10000010 = $82 |
.. %10000010 = $82 |
$000F: %00000000 = $00 --+
The result of the above Pattern Table is the character 'A', as shown
in the "Colour Result" section in the upper right.
E. Attribute Tables
-------------------
Each byte in an Attribute Table represents a 4x4 group of tiles on the
screen. There's multiple ways to describe what the function of one (1)
byte in the Attribute Table is:
* Holds the upper two (2) bits of a 32x32 pixel grid, per 16x16 pixels.
* Holds the upper two (2) bits of sixteen (16) 8x8 tiles.
* Holds the upper two (2) bits of four (4) 4x4 tile grids.
It's quite confusing; two graphical diagrams may help:
+------------+------------+
| Square 0 | Square 1 | #0-F represents an 8x8 tile
| #0 #1 | #4 #5 |
| #2 #3 | #6 #7 | Square [x] represents four (4) 8x8 tiles
+------------+------------+ (i.e. a 16x16 pixel grid)
| Square 2 | Square 3 |
| #8 #9 | #C #D |
| #A #B | #E #F |
+------------+------------+
The actual format of the attribute byte is the following (and corris-
ponds to the above example):
Attribute Byte
(Square #)
----------------
33221100
||||||+--- Upper two (2) colour bits for Square 0 (Tiles #0,1,2,3)
||||+----- Upper two (2) colour bits for Square 1 (Tiles #4,5,6,7)
||+------- Upper two (2) colour bits for Square 2 (Tiles #8,9,A,B)
+--------- Upper two (2) colour bits for Square 3 (Tiles #C,D,E,F)
--------------
The NES displays graphics using a matrix of "tiles"; this grid is called
a Name Table. Tiles themselves are 8x8 pixels. The entire Name Table
itself is 32x30 tiles (256x240 pixels). Keep in mind that the displayed
resolution differs between NTSC and PAL units.
The Name Tables holds the tile number of the data kept in the Pattern
Table (continue on).
D. Pattern Tables
-----------------
The Pattern Table contains the actual 8x8 tiles which the Name Table
refers to. It also holds the lower two (2) bits of the 4-bit colour
matrix needed to access all 16 colours of the NES palette. Example:
VRAM Contents of Colour
Addr Pattern Table Result
------ --------------- --------
$0000: %00010000 = $10 --+ ...1.... Periods are used to
.. %00000000 = $00 | ..2.2... represent colour 0.
.. %01000100 = $44 | .3...3.. Numbers represent
.. %00000000 = $00 +-- Bit 0 2.....2. the actual palette
.. %11111110 = $FE | 1111111. colour #.
.. %00000000 = $00 | 2.....2.
.. %10000010 = $82 | 3.....3.
$0007: %00000000 = $00 --+ ........
$0008: %00000000 = $00 --+
.. %00101000 = $28 |
.. %01000100 = $44 |
.. %10000010 = $82 +-- Bit 1
.. %00000000 = $00 |
.. %10000010 = $82 |
.. %10000010 = $82 |
$000F: %00000000 = $00 --+
The result of the above Pattern Table is the character 'A', as shown
in the "Colour Result" section in the upper right.
E. Attribute Tables
-------------------
Each byte in an Attribute Table represents a 4x4 group of tiles on the
screen. There's multiple ways to describe what the function of one (1)
byte in the Attribute Table is:
* Holds the upper two (2) bits of a 32x32 pixel grid, per 16x16 pixels.
* Holds the upper two (2) bits of sixteen (16) 8x8 tiles.
* Holds the upper two (2) bits of four (4) 4x4 tile grids.
It's quite confusing; two graphical diagrams may help:
+------------+------------+
| Square 0 | Square 1 | #0-F represents an 8x8 tile
| #0 #1 | #4 #5 |
| #2 #3 | #6 #7 | Square [x] represents four (4) 8x8 tiles
+------------+------------+ (i.e. a 16x16 pixel grid)
| Square 2 | Square 3 |
| #8 #9 | #C #D |
| #A #B | #E #F |
+------------+------------+
The actual format of the attribute byte is the following (and corris-
ponds to the above example):
Attribute Byte
(Square #)
----------------
33221100
||||||+--- Upper two (2) colour bits for Square 0 (Tiles #0,1,2,3)
||||+----- Upper two (2) colour bits for Square 1 (Tiles #4,5,6,7)
||+------- Upper two (2) colour bits for Square 2 (Tiles #8,9,A,B)
+--------- Upper two (2) colour bits for Square 3 (Tiles #C,D,E,F)
Hope this helps.
Yeah sorry, i'm speaking with mixed words because I don't see where either color was chosen, figured it might be the same way, my bad.
Perhaps it is the attribute table thats confusing me. I just read what you sent there, it's not clicking yet. But i'll read it a couple times over. I asked for someone to point it out with the code because I'm a visual learner, once I see where its happening in the code I understand it more, just reading about how the code is constructed without seeig it takes a few tries for me to get what the person is saying. BUTTTT yes I will reread a couple times and let you know whats up : ) Thanks for the info dude!
Perhaps it is the attribute table thats confusing me. I just read what you sent there, it's not clicking yet. But i'll read it a couple times over. I asked for someone to point it out with the code because I'm a visual learner, once I see where its happening in the code I understand it more, just reading about how the code is constructed without seeig it takes a few tries for me to get what the person is saying. BUTTTT yes I will reread a couple times and let you know whats up : ) Thanks for the info dude!
lol its such a weird thing, I read what you sent 3 times as I was eating. And I was like... yeah so, i get that?
It makes sense to me while reading,but for the life of me, i dont see where in the file that its written its making me a lil loopy. I'm totally not getting it, or understanding the logic for whatever reason. I will keep at it though, im not sure what to say i dont understand because when I read both tutorial and what you wrote, its clear to me how things are made up. But when I read the lines of code, im just like, yup i really dont see how its working. lol brain fart, once its explained to me a certain way ill bang my head on a wall for being numb : )
It makes sense to me while reading,but for the life of me, i dont see where in the file that its written its making me a lil loopy. I'm totally not getting it, or understanding the logic for whatever reason. I will keep at it though, im not sure what to say i dont understand because when I read both tutorial and what you wrote, its clear to me how things are made up. But when I read the lines of code, im just like, yup i really dont see how its working. lol brain fart, once its explained to me a certain way ill bang my head on a wall for being numb : )
Okay, in the .asm file:
* The pattern table data is CHR-ROM, so PPU RAM $0000 to $1FFF is mapped to the single 8KB CHR bank (this is stored in file mario.chr; see the end of the .asm file)
* The name table data (screen layout data) is handled in routine LoadBackground -- it populates PPU RAM $2000 to $207F with data that's defined at location background
* The attribute table data (just described this) is handled in routine LoadAttribute -- it populates PPU RAM $23C0 to $23C7 with data that's defined at location attribute
* The palette data is handled in routine LoadPalettes -- it populates PPU RAM $3F00 to $3F1F with data that's defined at location palette
For a NES PPU RAM memory map, see: https://wiki.nesdev.com/w/index.php/PPU_memory_map
The format of all this data, and how the pattern table + attribute table work together to make a specific pixel's colour, have been described already. There is a Youtube video on the NES attribute table but I find the presenter to be a bit confusing (and some of the assembler syntaxes he uses are questionable, i.e. using spaces in operand values), but it might help you: https://www.youtube.com/watch?v=RH2TFflORLs
The code in the routines references are all commented. If the 6502 is confusing, why don't you take the time to actually post the code snippets which confuse you and do your best to explain what's confusing you or where you get lost? We need to see what it is that's confusing you.
Possibly what would benefit you more would be not learning the NES, but rather learning 6502 in general? Kasumi posted something a few days ago that covered this already: viewtopic.php?p=179883#p179883
The NES, in my opinion, does not make a good "starter system" for learning 6502; the PPU greatly complicates the learning for new folks, because it's almost like you're learning "two systems" at once (6502 assembly + nuances of the PPU, memory layout, etc.). IMO, the Apple II (which is what I started out on) is a lot more user-friendly when it comes to learning 6502; it has a ROM (think BIOS) with a large number of built-in routines that are documented, and a general interface that lets you do things like print text on screen. I have no experience with the Commodore 64 but possibly it's another option (unsure).
But respectfully, not meant to dishearten: when you started posting here, you admitted you had no assembly experience, and only with C# and Unity. C# does a lot of the "heavy lifting" for you as far as PLs go, and Unity as a framework does **insane** amounts of hand-holding. What you are used to are tools that are doing lots of things for you; the NES is not like this. You are in full 100% control of the console itself, and are expected to do everything yourself. There really isn't a lot of hand-holding involved with NES development (or any other kind of classic console); the learning curve is extremely steep. You've also stated, quote, "Well I choose the Nes because I WANT the restrictions", so you're going to have to be very precise when it comes to asking for help. :-)
* The pattern table data is CHR-ROM, so PPU RAM $0000 to $1FFF is mapped to the single 8KB CHR bank (this is stored in file mario.chr; see the end of the .asm file)
* The name table data (screen layout data) is handled in routine LoadBackground -- it populates PPU RAM $2000 to $207F with data that's defined at location background
* The attribute table data (just described this) is handled in routine LoadAttribute -- it populates PPU RAM $23C0 to $23C7 with data that's defined at location attribute
* The palette data is handled in routine LoadPalettes -- it populates PPU RAM $3F00 to $3F1F with data that's defined at location palette
For a NES PPU RAM memory map, see: https://wiki.nesdev.com/w/index.php/PPU_memory_map
The format of all this data, and how the pattern table + attribute table work together to make a specific pixel's colour, have been described already. There is a Youtube video on the NES attribute table but I find the presenter to be a bit confusing (and some of the assembler syntaxes he uses are questionable, i.e. using spaces in operand values), but it might help you: https://www.youtube.com/watch?v=RH2TFflORLs
The code in the routines references are all commented. If the 6502 is confusing, why don't you take the time to actually post the code snippets which confuse you and do your best to explain what's confusing you or where you get lost? We need to see what it is that's confusing you.
Possibly what would benefit you more would be not learning the NES, but rather learning 6502 in general? Kasumi posted something a few days ago that covered this already: viewtopic.php?p=179883#p179883
The NES, in my opinion, does not make a good "starter system" for learning 6502; the PPU greatly complicates the learning for new folks, because it's almost like you're learning "two systems" at once (6502 assembly + nuances of the PPU, memory layout, etc.). IMO, the Apple II (which is what I started out on) is a lot more user-friendly when it comes to learning 6502; it has a ROM (think BIOS) with a large number of built-in routines that are documented, and a general interface that lets you do things like print text on screen. I have no experience with the Commodore 64 but possibly it's another option (unsure).
But respectfully, not meant to dishearten: when you started posting here, you admitted you had no assembly experience, and only with C# and Unity. C# does a lot of the "heavy lifting" for you as far as PLs go, and Unity as a framework does **insane** amounts of hand-holding. What you are used to are tools that are doing lots of things for you; the NES is not like this. You are in full 100% control of the console itself, and are expected to do everything yourself. There really isn't a lot of hand-holding involved with NES development (or any other kind of classic console); the learning curve is extremely steep. You've also stated, quote, "Well I choose the Nes because I WANT the restrictions", so you're going to have to be very precise when it comes to asking for help. :-)
koitsu wrote:
Okay, in the .asm file:
But respectfully, not meant to dishearten: when you started posting here, you admitted you had no assembly experience, and only with C# and Unity. C# does a lot of the "heavy lifting" for you as far as PLs go, and Unity as a framework does **insane** amounts of hand-holding. What you are used to are tools that are doing lots of things for you; the NES is not like this. You are in full 100% control of the console itself, and are expected to do everything yourself. There really isn't a lot of hand-holding involved with NES development (or any other kind of classic console); the learning curve is extremely steep. You've also stated, quote, "Well I choose the Nes because I WANT the restrictions", so you're going to have to be very precise when it comes to asking for help.
But respectfully, not meant to dishearten: when you started posting here, you admitted you had no assembly experience, and only with C# and Unity. C# does a lot of the "heavy lifting" for you as far as PLs go, and Unity as a framework does **insane** amounts of hand-holding. What you are used to are tools that are doing lots of things for you; the NES is not like this. You are in full 100% control of the console itself, and are expected to do everything yourself. There really isn't a lot of hand-holding involved with NES development (or any other kind of classic console); the learning curve is extremely steep. You've also stated, quote, "Well I choose the Nes because I WANT the restrictions", so you're going to have to be very precise when it comes to asking for help.
lol yeah, well aware its annoying when someone has no knowledge and asking questions that seem odd and random. But its how I do things, I will figure it out. I've met many people who love to teach no matter how dumb the questions, its how i learned c#/everything else in life, you cannot dishearten a curious person. I'll stick with the NES project. to one day decide i wanted to learn how to 3d model, learn c#, animation,and the unity engine was no small task either. But yet it got done, a playable demo, that sucks, but got done lol.
Beyond that, the more i read the more its making sense, your info has been useful as well. if i'm annoying everyone, i'll just make friends at another forum. There's always someone somewhere. Plus i'm sure everything im asking and posting is already here, I just like the convo.
As a reminder, I also stated i'm not trying to make a game. I'm only going as far as getting the sprites on screen, and some animation when moved. That's about the extent of it. What I am asking is one of few things I don't understand for what I am doing, turning away now and starting a new project is silly lol.
Nope, not annoying at all. Just that you need to be more clear in what's confusing you, including giving code snippets etc.. A few of your posts are sort of "arm-flailing", as in "I don't understand this! What is going on! HELP!" without too much definition ("I don't see where the colour was chosen") ("Not sure what bit says X/Y/Z"). The vagueness is what makes helping someone difficult.
Don't feel bad if the pattern + attribute table combination doesn't fully click with you yet. This took me almost a year to grasp; it never made sense to me until my roommate, who I was working on a NES emulator with back in 1997, explained it in such a way that suddenly it all made sense. That's why in my nestech documentation I described the attribute table 3 different ways and used visual diagrams.
If it helps -- and this is a bold statement -- then don't use the attribute table at all (zero it out), essentially limiting yourself to 2 palettes only. Remember: you're learning/starting out; baby steps!
Don't feel bad if the pattern + attribute table combination doesn't fully click with you yet. This took me almost a year to grasp; it never made sense to me until my roommate, who I was working on a NES emulator with back in 1997, explained it in such a way that suddenly it all made sense. That's why in my nestech documentation I described the attribute table 3 different ways and used visual diagrams.
If it helps -- and this is a bold statement -- then don't use the attribute table at all (zero it out), essentially limiting yourself to 2 palettes only. Remember: you're learning/starting out; baby steps!
koitsu wrote:
If it helps -- and this is a bold statement -- then don't use the attribute table at all (zero it out), essentially limiting yourself to 4 colours. Remember: you're learning/starting out; baby steps!
That is kinda smart. And interesting because as I was drawing I kinda liked how everything was using the same palette aat one point. But yet boring as well lol. Gotta remember I am 80-90% artist, which is why im dying for color.
koitsu wrote:
https://www.youtube.com/watch?v=RH2TFflORLs
DUDE sorry it took so long for me to watch the video, but THANKS YOU lol watching that while looking at your second post finally made it click. Its just seeing someone demonstrate it does the job : )
The problem was
.db $80, $2, $01, $58
I didnt realize that $00 was the attribute, I kept over looking it in the comment. So I changed to $01, and the palette changed. Which is what I wanted to happen. Sorry for making that so confusing, told ya it was a brain fart lolll
Not exactly sure thats the proper way to do it, but if it is, someone could have easily pointed out thats where the palette change happens haha