It is currently Mon May 20, 2019 7:38 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 354 posts ]  Go to page Previous  1 ... 20, 21, 22, 23, 24
Author Message
PostPosted: Wed Dec 12, 2018 10:15 am 
Offline
Formerly 43110

Joined: Wed Feb 05, 2014 7:01 am
Posts: 384
Location: us-east
DocWaluigean wrote:
- LDAXY / STAXY = A crane machine where A is Red, X is Blue, and Y is Yellow, and the fluffy bunny doll represent numbers and what it does. [A fluffy bunny represent the sprite code for the main character which is the fluffy bunny.]

- Register = ???????????? [To be edited]

- TAX / TAY = A same crane that can be given number or decimals to each others. The prize is actually radioactive nitroglycerin, and cannot be in same room with X and Y togather, hence it only transfer between A and X or A and Y.

...

I feel I got certain jots down a little while. I hope I do not get penalize for long term issues. It will take me a while a LITTLE while to re-assume what to learn about the inside the NROM header thingy.[? or the templates?]


Welcome back.

Going with your crane machine analogy a Register would be the chute where the bunny is dropped at (but read on on why this description may be flawed), and JMP and Bxx would be oddly affecting the crane operator/player somehow?


I think most object analogies like this crane machine confuses one important fact about how the CPU works: Every tiny operation that's called a "move" or a "transfer" is actually copying.

In real life (as we all know) when a thing moves from one spot to another that thing no longer exists at the old location.
In the computer realm, the action that we call "moving" leaves the old pattern of bits exactly as it is, while causing the pattern of bits in the new location to be same as the old.

You could think of this a having many chalkboards (or just a single chalkboard divided up).
So to move a number from chalkboard X to chalkboard Y, chalkboard Y must first be erased then the number in chalkboard X is read and written to chalkboard Y.
You may think the CPU could just erase chalkboard X automatically after the copy, but that's a waste of real mechanical effort, so the old chalkboard X remains the same.

There was one part of an old book I used to read as a child that helped me really understand how the CPU of computers really function.
The book was Usborne Guide to Computers: A simple and colourful introduction for beginners
and in it there was 2 pages describing an activity where you cut out a long strip of paper with simple instructions and that long strip was feed through a small paper view, and you followed the instructions in that view which included steps like moving the viewer to a numbered part of the paper strip. http://www.asciimation.co.nz/bb/wpg2?g2_itemId=5489

I can't seem to find the book any more, but I found a through review of it at http://www.asciimation.co.nz/bb/2013/10/28/usborne-guide-to-computers


Top
 Profile  
 
PostPosted: Thu Dec 13, 2018 10:05 am 
Offline

Joined: Sun Jun 17, 2018 6:41 pm
Posts: 155
pwnskar wrote:
As a relatively new nesdever I'd recommend not worrying too much about tools in the beginning. You will gain a better understanding of how things are put together the longer you keep things basic. Following a simple tutorial with whatever tools used there will be enough to get you started. It's gonna take time but so does anything worth pursuing, right? :)


Thank you for tip, but that's what I'm trying to figure out or something, which is making the tutorial so easy to understand.

JRoatch wrote:
DocWaluigean wrote:
- LDAXY / STAXY = A crane machine where A is Red, X is Blue, and Y is Yellow, and the fluffy bunny doll represent numbers and what it does. [A fluffy bunny represent the sprite code for the main character which is the fluffy bunny.]

- Register = ???????????? [To be edited]

- TAX / TAY = A same crane that can be given number or decimals to each others. The prize is actually radioactive nitroglycerin, and cannot be in same room with X and Y togather, hence it only transfer between A and X or A and Y.

...

I feel I got certain jots down a little while. I hope I do not get penalize for long term issues. It will take me a while a LITTLE while to re-assume what to learn about the inside the NROM header thingy.[? or the templates?]


Welcome back.

Going with your crane machine analogy a Register would be the chute where the bunny is dropped at (but read on on why this description may be flawed), and JMP and Bxx would be oddly affecting the crane operator/player somehow?


I think most object analogies like this crane machine confuses one important fact about how the CPU works: Every tiny operation that's called a "move" or a "transfer" is actually copying.

In real life (as we all know) when a thing moves from one spot to another that thing no longer exists at the old location.
In the computer realm, the action that we call "moving" leaves the old pattern of bits exactly as it is, while causing the pattern of bits in the new location to be same as the old.

You could think of this a having many chalkboards (or just a single chalkboard divided up).
So to move a number from chalkboard X to chalkboard Y, chalkboard Y must first be erased then the number in chalkboard X is read and written to chalkboard Y.
You may think the CPU could just erase chalkboard X automatically after the copy, but that's a waste of real mechanical effort, so the old chalkboard X remains the same.

There was one part of an old book I used to read as a child that helped me really understand how the CPU of computers really function.
The book was Usborne Guide to Computers: A simple and colourful introduction for beginners
and in it there was 2 pages describing an activity where you cut out a long strip of paper with simple instructions and that long strip was feed through a small paper view, and you followed the instructions in that view which included steps like moving the viewer to a numbered part of the paper strip. http://www.asciimation.co.nz/bb/wpg2?g2_itemId=5489

I can't seem to find the book any more, but I found a through review of it at http://www.asciimation.co.nz/bb/2013/10/28/usborne-guide-to-computers


I think Unregistered has the website for it! Or is it some other one who goes by..? , because I keep getting off track a little. Anyway, I thank for constructive criticism, as sad as I can't explain well, so I'm going to be a little descrete:

-Let's say the claw is grabbing 8-ball [#$08] that's the letter A. It's in a different rooms
-The #$08 is being assigned to a specific bin which is like Address $0022
-The claw of A [Accelerator] is mobing the 8-ball to the cubical bin of Address $0022 and drops it, and it performs special actions.

---

Anyway, I'll try and see what each by each works as I'm re-reading my early post.

Code:
;----------------------------------------------------------------
; variables
;----------------------------------------------------------------

   .enum $0000

   ;NOTE: declare variables using the DSB and DSW directives, like this:

   ;MyVariable0 .dsb 1
   ;MyVariable1 .dsb 3

   .ende

   ;NOTE: you can also split the variable declarations into individual pages, like this:

   ;.enum $0100
   ;.ende

   ;.enum $0200
   ;.ende


Okay, there's PPU map, CPU map, and https://wiki.nesdev.com/w/index.php/PPU_memory_map other maps that I got lost so here's two things:

$0000 = Internal map of RAM, which is random access memory. I get fixated on words, so I may think this is "RAM is how much work CPU got to do before performing actions."

OR

$0000 = Pattern Table 0 . The place that is a home for the sprites and graphics.

Alongside, I do not know about, ".enum" and ".ende". Am I guessing it's the name of map? Ende is CPU Map, and Enum is PPU Map? I need a full explainations about the way "Variable" table goes, and why each code does like that.


Top
 Profile  
 
PostPosted: Thu Dec 13, 2018 11:00 pm 
Offline
Formerly 43110

Joined: Wed Feb 05, 2014 7:01 am
Posts: 384
Location: us-east
DocWaluigean wrote:
-Let's say the claw is grabbing 8-ball [#$08] that's the letter A. It's in a different rooms
-The #$08 is being assigned to a specific bin which is like Address $0022
-The claw of A [Accelerator] is mobing the 8-ball to the cubical bin of Address $0022 and drops it, and it performs special actions.

The cubical bin is RAM which keeps the thing that was last dropped into. in this case the 8-ball.

Some places that the 8-ball can be dropped into are not cubical bins, but instead chutes that leads to things like a large button that flashes lights (PPU Registers).

All the while, due to strange laws of computer physics the Accumulator Claw still has a 8-ball despite the claw dropping it so many times.

DocWaluigean wrote:
Anyway, I'll try and see what each by each works as I'm re-reading my early post.
I think you got the general idea that the CPU and PPU have different address spaces which is why address $0000 can refer to two different things.
So instead lets see if we can make sense of what this piece of code is doing (which has nothing to do with differing address buses).

tldr/summary: All labels between .enum $xxxx and .ende goes to RAM starting at $xxxx and not ROM.

------
First remember these are instructions to the assembler.
We are attempting to command the assembler to generate the contents of a ROM that will be later executed by a 6502 CPU in a NES machine.

By default most assembler instructions will generate 1 or more bytes in the resulting ROM. It'll also keep track of how many bytes it has written so that when a label like MyVariable0: comes along the assembler will know what byte the label means.

Code:
.enum $0000

This says a couple things on how the assembler should behave for the code that follows:
First .enum says that until the assembler sees a .ende it should not generate any bytes to the ROM, but to still track how many bytes instructions would of taken. That way labels still work.
The second part $0000 sets what address it's label tracking byte count starts at. asm6 still keeps it's old counter which it'll revert to once it gets to the .ende

If you remove the ; from the lines after the note, those lines will become active assembler instructions.
Code:
MyVariable0: .dsb 1

Normally .dsb generates a number of filler bytes, but since the assembler is in a enum block, it won't actually write that to ROM. It'll simply add 1 to the assembler's internal address counter (properly called the Program Counter).
The result of this instruction is that the label MyVariable0: is $0000, and the next label (if any) will be $0001.

Code:
MyVariable1: .dsb 3

The Program Counter is $0001, so the label MyVariable1: is $0001. Program Counter is increased by 3 so the next label will be $0004.

Code:
.ende

As explained above the assembler exits it's enum mode, restoring the Program Counter to whatever it was before, and generating more ROM bytes as it encounters more instructions.

So why does the assembler have this whole enum mechanism anyway? Labels that automatically add up their sizes are useful to work with, but the automatic generating of bytes into ROM becomes a hindrance when working in a area that doesn't exist in the ROM at all. Namely the RAM.

The term enum is shorten from the word enumeration which is the process of giving ordered numbers to a list of things, and that's basically the purpose this asm6 assembler mode.

The rest of that code then repeats these enum blocks for you to put more non-ROM things located at $0100 and $0200.


Top
 Profile  
 
PostPosted: Tue Dec 18, 2018 7:30 pm 
Offline

Joined: Sun Jun 17, 2018 6:41 pm
Posts: 155
JRoatch wrote:
DocWaluigean wrote:
-Let's say the claw is grabbing 8-ball [#$08] that's the letter A. It's in a different rooms
-The #$08 is being assigned to a specific bin which is like Address $0022
-The claw of A [Accelerator] is mobing the 8-ball to the cubical bin of Address $0022 and drops it, and it performs special actions.

The cubical bin is RAM which keeps the thing that was last dropped into. in this case the 8-ball.

Some places that the 8-ball can be dropped into are not cubical bins, but instead chutes that leads to things like a large button that flashes lights (PPU Registers).

All the while, due to strange laws of computer physics the Accumulator Claw still has a 8-ball despite the claw dropping it so many times.

DocWaluigean wrote:
Anyway, I'll try and see what each by each works as I'm re-reading my early post.
I think you got the general idea that the CPU and PPU have different address spaces which is why address $0000 can refer to two different things.
So instead lets see if we can make sense of what this piece of code is doing (which has nothing to do with differing address buses).

tldr/summary: All labels between .enum $xxxx and .ende goes to RAM starting at $xxxx and not ROM.

------
First remember these are instructions to the assembler.
We are attempting to command the assembler to generate the contents of a ROM that will be later executed by a 6502 CPU in a NES machine.

By default most assembler instructions will generate 1 or more bytes in the resulting ROM. It'll also keep track of how many bytes it has written so that when a label like MyVariable0: comes along the assembler will know what byte the label means.

Code:
.enum $0000

This says a couple things on how the assembler should behave for the code that follows:
First .enum says that until the assembler sees a .ende it should not generate any bytes to the ROM, but to still track how many bytes instructions would of taken. That way labels still work.
The second part $0000 sets what address it's label tracking byte count starts at. asm6 still keeps it's old counter which it'll revert to once it gets to the .ende

If you remove the ; from the lines after the note, those lines will become active assembler instructions.
Code:
MyVariable0: .dsb 1

Normally .dsb generates a number of filler bytes, but since the assembler is in a enum block, it won't actually write that to ROM. It'll simply add 1 to the assembler's internal address counter (properly called the Program Counter).
The result of this instruction is that the label MyVariable0: is $0000, and the next label (if any) will be $0001.

Code:
MyVariable1: .dsb 3

The Program Counter is $0001, so the label MyVariable1: is $0001. Program Counter is increased by 3 so the next label will be $0004.

Code:
.ende

As explained above the assembler exits it's enum mode, restoring the Program Counter to whatever it was before, and generating more ROM bytes as it encounters more instructions.

So why does the assembler have this whole enum mechanism anyway? Labels that automatically add up their sizes are useful to work with, but the automatic generating of bytes into ROM becomes a hindrance when working in a area that doesn't exist in the ROM at all. Namely the RAM.

The term enum is shorten from the word enumeration which is the process of giving ordered numbers to a list of things, and that's basically the purpose this asm6 assembler mode.

The rest of that code then repeats these enum blocks for you to put more non-ROM things located at $0100 and $0200.


So .enum and .ende [French?] is ASM-languages and not 6502-languages? Also, is it the reservation code?
I'm still a little confused on .dsb stuff. Is it the "COUNT 3" like it goes 3 steps up or down?

I feel like this isn't part of NES programming, and more of the custom-made ASM programming where it gives options, about if it can hold 64 or 16kb?


Top
 Profile  
 
PostPosted: Tue Dec 18, 2018 10:29 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11345
Location: Rio de Janeiro - Brazil
DocWaluigean wrote:
So .enum and .ende [French?] is ASM-languages and not 6502-languages?

.ENUM and .ENDE (not French, just short for "end enum") are assembler directives. Even though they aren't part of the 6502 specification, every assembler has a set of directives that are meant to make the programmer's job easier. They are used to organize the output, automate tedious tasks, and so on.

Quote:
Also, is it the reservation code?

The .ENUM directive provides a convenient way to declare variables. Instead of hardcoding addresses to each variable (e.g. MyVariable = $043B), which is tedious, error-prone and hard to manage should you need to move your variables around later on, you simply start from a base address and reserve as much space is needed for each variable.

Quote:
I'm still a little confused on .dsb stuff.

.DSB is what reserves the bytes. Here's a typical .ENUM block, commented:

Code:
.enum $0300 ;temporarily change the address to $0300, so that labels defined here start from that address, and inhibit output
  CurrentLevel .dsb 1 ;reserve 1 byte
  PlayerHealth .dsb 1 ;reserve 1 byte
  PlayerX .dsb 2 ;reserve 2 bytes, as this is a 16-bit variable
  PlayerY .dsb 2 ;reserve 2 bytes, as this is a 16-bit variable
.ende ;restores the address to what it was before, start outputting assembled code again

The code above creates 4 variables, starting from $0300, but you don't need to define the address of each one manually. Since you tell the assembler how big each one is, it knows that CurrentLavel = $0300, PlayerHealth = $0301, PlayerX = $0302 and PlayerY = $0304. If you need to put the variables elsewhere for whatever reason, you can just copy/paste their lines around, without needing to manually change any addresses.

Quote:
Is it the "COUNT 3" like it goes 3 steps up or down?

I don't understand the question. Where is this "COUNT" you're talking about.

Quote:
I feel like this isn't part of NES programming, and more of the custom-made ASM programming where it gives options, about if it can hold 64 or 16kb?

Yeah, it's not exactly 6502 code, but you need these directives if you want to be able to code efficiently. You need to format the output so that it has the structure of a valid cartridge image. You need to mange banks and variables. Assemblers exist to help you with that. You know, you could ignore everything about directives, labels, etc. and code NES programs by writing hex numbers in an hex editor (there's at least 1 crazy member here in the forum that does this!), but that's VERY error-prone and hard to maintain.


Top
 Profile  
 
PostPosted: Fri Mar 15, 2019 10:12 pm 
Offline

Joined: Sun Jun 17, 2018 6:41 pm
Posts: 155
I'm back again.

Thankfully, I still remember the Register and the some other part. I would be really depressed if I didn't understand this on today.

So, here's what I'm gonna do.

I'm going to write Psudocodes to get idea of what I want for NES ROM making and others, and try to understand the address map, going to try to leech out on many details of information of what each by each address code is for.

I'm going to draw images right now to give examples of what I want to accomplish.

Attachment:
NES exmp 1.png
NES exmp 1.png [ 75.18 KiB | Viewed 1402 times ]


For the first demo I want to make, it's a white background with my OC sprite walking from left to right, and repeat from left to right.

-

I just got back at night, so I really hope I can keep going with this tomorrow, so let me try to make mockup of Address of what I think of NES CPU addresses:

Attachment:
cpumemmap.png
cpumemmap.png [ 3.63 KiB | Viewed 1402 times ]


Obviously this, but if I want to start coding, I need to know what's inside of each by each...

Tomorrow, I think it will take me hours to remember what I need to learn about.. I think I'm thinking too ahead, so I haven't read the comment clearly now..

Just for self-confidence and motivation: You'd be surprised by how many people have said that, but either "forgot" or just gave up on NES development. ...I will not, or hopefully never, make that/the same mistake.


Top
 Profile  
 
PostPosted: Mon Mar 18, 2019 3:12 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 995
Location: cypress, texas
Welcome back DocW, maybe this has already been discussed in this thread, but regardless:

2KB INTERNAL RAM is memory that can be written to while the program (nes game) is running (i.e. variables).
PPU I/O PORTS are addresses that allow access to the PPU Picture Processing Unit
APU/CONTROLLER I/O PORTS are addresses that allow access to the APU Audio Processing Unit or allow access to the nes Controllers
8KB CARTIDGE RAM (WRAM) is the spot where it's possible to allow the saving of game-play progress
32KB CARTRIDGE ROM is the dwelling place of your game's code (ROM is Read Only Memory and can't be physically written to. Note: sta $E000 can allow mapper MMC1 to understand that it needs to do something, but don't consider enabling a different mapper right now. :) In other words, don't replace the simple NROM mapper that you, me, and most others have startted out using.)
NMI/RESET/IRQ VECTORS are three 16bit addresses that show the initial locations of your NMI, RESET, and IRQ functions (code) to the NES so it can use them when needed.

Much more info on the above definitions can be found at http://wiki.nesdev.com/. :)


Top
 Profile  
 
PostPosted: Mon Mar 18, 2019 11:38 pm 
Offline

Joined: Sun Jun 17, 2018 6:41 pm
Posts: 155
unregistered wrote:
Welcome back DocW, maybe this has already been discussed in this thread, but regardless:

2KB INTERNAL RAM is memory that can be written to while the program (nes game) is running (i.e. variables).
PPU I/O PORTS are addresses that allow access to the PPU Picture Processing Unit
APU/CONTROLLER I/O PORTS are addresses that allow access to the APU Audio Processing Unit or allow access to the nes Controllers
8KB CARTIDGE RAM (WRAM) is the spot where it's possible to allow the saving of game-play progress
32KB CARTRIDGE ROM is the dwelling place of your game's code (ROM is Read Only Memory and can't be physically written to. Note: sta $E000 can allow mapper MMC1 to understand that it needs to do something, but don't consider enabling a different mapper right now. :) In other words, don't replace the simple NROM mapper that you, me, and most others have startted out using.)
NMI/RESET/IRQ VECTORS are three 16bit addresses that show the initial locations of your NMI, RESET, and IRQ functions (code) to the NES so it can use them when needed.

Much more info on the above definitions can be found at http://wiki.nesdev.com/. :)


Thank you very much for warm welcoming!

I know this discussion in the previous thread, but not core details about what the Address does.

Attachment:
ppumemmap.png
ppumemmap.png [ 6.4 KiB | Viewed 1285 times ]


Obviously, Bunnyboy helps out some parts, but there is always missing parts of it:

$2001 - Masking screen with colors

[I'll write more because it's nighttime. I'm trying, while at same time, not to stress too much about learning.]


Top
 Profile  
 
PostPosted: Tue Mar 19, 2019 10:02 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 995
Location: cypress, texas
You're welcome. :)

Sprite Palette is a 16byte variable that explains to the NES what colors sprites can be drawn with. Those 16bytes are best interpreted as four palettes, each consisting of 4bytes, aka palettes 0, 1, 2 , and 3. The first byte of each palette is usually the "background" color. So each palette really only has 3 unique colors. (I said usually bc maybe there might be a way to specify 4 unique colors, but I can't remember what I've read and, nevertheless, my sister decided to create sprites using 3 unique colors as explained above. It must be impossible or extremely difficult to use 4 unique colors in each palette.)
---
Background Palette is set up the same as the Sprite Palette, but it explains to the NES what colors can be used for displaying the background-(the screen's image not considering sprites). (If you are using the Mesen emulator, Options>Video>Palette should show you the colors available on the NES. If Show color indexes is checked that will display each color's byte representation. i.e. If byte $3F00, $3F04, $3F08, and $3F0C are all #$01 then your background's "background" color would appear dark blue.)
---
Attribute Table is the 64byte specification to the NES PPU that explains how to apply the Background Palette so that the game's background may be displayed correctly. (i.e. Attribute Table 3 can only apply to Nametable 3, this application of Attribute Tables to Nametables must be specified in each NES game's header section. You've already set this specification up. :) An attribute byte can be #01010101b or #%01010101 to specify that the NES should color that 32bitx32bit screen location all with Background Palette's palette 1. NES games are restricted into forcing each 16bitx16bit section of the screen (background) to use the same palette (either palette 0, 1, 2 , or 3). This restriction does not encompass/affect sprite coloring.)
---
Name Table is the 960bytes that make allow the NES to display certain images from Pattern Table 0.
---
Pattern Table 1 is the image (actually a bunch, 256, of 8pixelx8pixel tiny images) that allows the ppu to draw a specific 8pixelx8pixel image when reading certain bytes from its sprite definitions.
---
Pattern Table 0 is the image (actually a bunch, 256, of 8pixelx8pixel tiny images) that allows the ppu to draw a specific 8pixelx8pixel image when reading each byte from the appropriate section of a Name Table that is attempting to be displayed.

Again: "core details" for each of the definitions above can be found at https://wiki.nesdev.com/w/index.php/Nesdev_Wiki. :)


edit: replaced "make" with "allow" bc making the PPU display nametable bytes requires setting PPU I/O PORTS (aka PPU REGISTERS)... the exact process can be found on the nesdev wiki.

edit Note: 960bytes per Name Table is quite a lot of space for each screen... this large amount of bytes per screen can be reduced for games using many screens by incorporating the use of metatiles and maybe further reduced by RLE use. Using metatiles and/or RLE takes even more learning; wanted to place this note here for some of the other people reading your thread. :)


final edit: posted secure wiki link; it seems like rainwarrior's findings he posted about on Nov. 23, 2017 are still around today... the wiki redirect doesn't keep the original http or https, rather it always redirects to http. :(


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 354 posts ]  Go to page Previous  1 ... 20, 21, 22, 23, 24

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