Hello, new here, and need best recommandations.

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

DocWaluigean
Posts: 205
Joined: Sun Jun 17, 2018 6:41 pm

Re: Hello, new here, and need best recommandations.

Post by DocWaluigean »

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: Select all

.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: Select all

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: Select all

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: Select all

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

Re: Hello, new here, and need best recommandations.

Post by tokumaru »

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.
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.
I'm still a little confused on .dsb stuff.
.DSB is what reserves the bytes. Here's a typical .ENUM block, commented:

Code: Select all

.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.
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.
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.
DocWaluigean
Posts: 205
Joined: Sun Jun 17, 2018 6:41 pm

Re: Hello, new here, and need best recommandations.

Post by DocWaluigean »

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.
NES exmp 1.png
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:
cpumemmap.png
cpumemmap.png (3.63 KiB) Viewed 7060 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.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Hello, new here, and need best recommandations.

Post by unregistered »

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/. :)
DocWaluigean
Posts: 205
Joined: Sun Jun 17, 2018 6:41 pm

Re: Hello, new here, and need best recommandations.

Post by DocWaluigean »

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.
ppumemmap.png
ppumemmap.png (6.4 KiB) Viewed 6943 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.]
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: Hello, new here, and need best recommandations.

Post by unregistered »

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. :(
Post Reply