.ASM into .NES assistance

[3gengames]

...... Uhhh....can you write the steps like you did on the ASM?

Not without doing all the work for you... you won't learn anything this way.

true...what is @vblankwait1 and 2? Do I put this in a notepad and convert it into ASM.? or bat.?

First, learn what the hell 6502 assembly is. Once yo understand 6502 programming ideas,read the wiki. It will have ALL questions answered there.

But it's to wait for the PPU to warm up. You can not write to it before the 2 vblanks, so we wait for those and do other initialization.

[caramelpuffpuff]

In asm6 and ca65, a label whose name starts with with @ is a "cheap local label" that can't be seen across regular labels. This allows reuse of label names such as "loop" in different parts of a single program.

Labels are case sensitive. The special '$' label holds the current program address. Labels beginning with '@' are local labels. They have limited scope, visible only between non-local labels. Names of local labels may be reused.

Likewise, the ca65 manual has a section on cheap local labels.

Code: Select all

label1:
  ; stuff
@loop:
  ; stuff
  dey
  bne loop  ; goes to the @loop below label1; can't see @loop below label2
label2:
  ; ...
@loop:
  ; stuff
  dey
  bne loop  ; goes to the @loop below label2; can't see @loop below label1

Yes, you do put the init code in Notepad.

Oooh.

Okay...I got the init code in ConTEXT (initializer.asm), I copy the game.nes to another folder in case if I "put the wrong ingrediants" in it...

[tokumaru]

At this point, you shouldn't have multiple .asm files, that would just complicate things. Once you know what you are doing, it is a good idea to separate code in different files, but not now.

Everything goes into game.asm. You have to put the init code right after the "Reset" label, like I told you before. Are you even paying attention or did you completely ignore that? If you want to be a programmer, you have to pay attention to detail, if you keep letting things slip like this you won't go very far.

[caramelpuffpuff]

At this point, you shouldn't have multiple .asm files, that would just complicate things. Once you know what you are doing, it is a good idea to separate code in different files, but not now.

Everything goes into game.asm. You have to put the init code right after the "Reset" label, like I told you before. Are you even paying attention or did you completely ignore that? If you want to be a programmer, you have to pay attention to detail, if you keep letting things slip like this you won't go very far.

I am trying hard to pay attention, but I think way too different, and every time I "understand", I perform things that isn't the correct way. I'm not like one of those "common sence" person; that's why I'm terrible at explaining things... You told me to initialize the system, and setting palettes and showing some tiles. I didn't understand if the code should be in the same asm. or in the completely new file, so I thought if I should've make a new ASM. files for the initializer, until now you told me that everything goes in the ASM. files that contains valid NES files...

[3gengames]

Sounds like you need to step back, and read on what you don't understand. Trying to perform actions with something you don't understand...how will you ever perform them correctly? You won't.

incbin just includes binary data into the location. Include includes a new source (.asm program) file to also add to it. And that's basically it. just gotta add the code to do everything. The initialization of the system is on the Wiki, or some of it should be.

You should probably ready the Nerdy Nights to learn the harware of the NES: http://www.nintendoage.com/pub/faq/NA/n ... s_out.html

[tokumaru]

I didn't understand if the code should be in the same asm.

In this post I said that the initialization code should be right after the "Reset" label, and this label is in the template you copied, so I assumed you'd realize it should be in the same file.

[caramelpuffpuff]

I didn't understand if the code should be in the same asm.

In this post I said that the initialization code should be right after the "Reset" label, and this label is in the template you copied, so I assumed you'd realize it should be in the same file.

I'm still reading it twice on http://www.nintendoage.com/forum/messag ... eadid=4440 , and I still forget it somewhat easily. I'm trying hard...I even have to look the dictionary to some words...

[3gengames]

Looks like progress to me. You understand why we're doing all that? Also, you may or may not want to clear all your RAM first, just to make sure.

[caramelpuffpuff]

Looks like progress to me. You understand why we're doing all that? Also, you may or may not want to clear all your RAM first, just to make sure.

Well...this is what the words it looks like:

(The bold is the one that is changed)

;----------------------------------------------------------------
; constants
;----------------------------------------------------------------

PRG_COUNT = 1 ;1 = 16KB, 2 = 32KB
MIRRORING = %0001 ;%0000 = horizontal, %0001 = vertical, %1000 = four-screen

;----------------------------------------------------------------
; 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

;----------------------------------------------------------------
; iNES header
;----------------------------------------------------------------

.db "NES", $1a ;identification of the iNES header
.db PRG_COUNT ;number of 16KB PRG-ROM pages
.db $01 ;number of 8KB CHR-ROM pages
.db $00|MIRRORING ;mapper 0 and mirroring
.dsb 9, $00 ;clear the remaining bytes

;----------------------------------------------------------------
; program bank(s)
;----------------------------------------------------------------

.base $10000-(PRG_COUNT*$4000)

Reset:
sei ; ignore IRQs
cld ; disable decimal mode
ldx #$40
stx $4017 ; disable APU frame IRQ
ldx #$ff
txs ; Set up stack
inx ; now X = 0
stx $2000 ; disable NMI
stx $2001 ; disable rendering
stx $4010 ; disable DMC IRQs

; Optional (omitted):
; Set up mapper and jmp to further init code here.

; Clear the vblank flag, so we know that we are waiting for the
; start of a vertical blank and not powering on with the
; vblank flag spuriously set
bit $2002

; First of two waits for vertical blank to make sure that the
; PPU has stabilized
@vblankwait1:
bit $2002
bpl @vblankwait1

; We now have about 30,000 cycles to burn before the PPU stabilizes.
; One thing we can do with this time is put RAM in a known state.
; Here we fill it with $00, which matches what (say) a C compiler
; expects for BSS. Conveniently, X is still 0.
txa
@clrmem:
sta $000,x
sta $100,x
sta $300,x
sta $400,x
sta $500,x
sta $600,x
sta $700,x ; Remove this if you're storing reset-persistent data

; We skipped $200,x on purpose. Usually, RAM page 2 is used for the
; display list to be copied to OAM. OAM needs to be initialized to
; $EF-$FF, not 0, or you'll get a bunch of garbage sprites at (0, 0).

inx
bne @clrmem

; Other things you can do between vblank waits are set up audio
; or set up other mapper registers.

@vblankwait2:
bit $2002
bpl @vblankwait2
;NOTE: initialization code goes here

NMI:

;NOTE: NMI code goes here

IRQ:

;NOTE: IRQ code goes here

;----------------------------------------------------------------
; interrupt vectors
;----------------------------------------------------------------

.org $fffa

.dw NMI
.dw Reset
.dw IRQ

;----------------------------------------------------------------
; CHR-ROM bank
;----------------------------------------------------------------

.incbin "NewFileaa.chr"

___

And to be honest...I somewhat don't understand what to do next...

aaaaand....maybe a little; to encourage me to do things independant?

[3gengames]

You can do a LDA #$FF STA $200,X to write FF to the $200 page, just putting that in there.

[caramelpuffpuff]

You can do a LDA #$FF STA $200,X to write FF to the $200 page, just putting that in there.

o-o........Uhhh...

LDA: the color palette.
STA: the location pixel....

"X to write FF to the $200 page"

is the "$200" the beginning of the location-screen? The "top-left" location of the screen?

[tokumaru]

is the "$200" the beginning of the location-screen? The "top-left" location of the screen?

No, $200 is the place where most people write their sprite attributes before uploading the to them PPU.

The CPU doesn't have direct access to the video memory, so you can't just STA to the location where you want a tile to be. The CPU communicates with the PPU through two memory mapped registers. One of them is used to tell the PPU which video memory address you'll be accessing, and the other is used to send/receive data. So, to put tile number 7 at the top left corner of the screen, you'd do this:

Code: Select all

;tell the CPU we'll write something to address $2000 in VRAM
lda #$20
sta $2006
lda #$00
sta $2006

;write the tile index there
lda #$07
sta $2007

This alone won't give you any picture yet, because you still have to do the following:

- set the palette (use $2006/$2007 to write color values to VRAM address $3F00 and up);
- reset the scroll (the scroll defines what part of the name table is visible, so you need to set it to (0,0) to actually see the top left corner);
- configure the PPU and enable rendering (read about registers $2000 and $2001);

Only after doing this you'll be able to see something on the screen.

[caramelpuffpuff]

is the "$200" the beginning of the location-screen? The "top-left" location of the screen?

No, $200 is the place where most people write their sprite attributes before uploading the to them PPU.

The CPU doesn't have direct access to the video memory, so you can't just STA to the location where you want a tile to be. The CPU communicates with the PPU through two memory mapped registers. One of them is used to tell the PPU which video memory address you'll be accessing, and the other is used to send/receive data. So, to put tile number 7 at the top left corner of the screen, you'd do this:

Code: Select all

;tell the CPU we'll write something to address $2000 in VRAM
lda #$20
sta $2006
lda #$00
sta $2006

;write the tile index there
lda #$07
sta $2007

This alone won't give you any picture yet, because you still have to do the following:

- set the palette (use $2006/$2007 to write color values to VRAM address $3F00 and up);
- reset the scroll (the scroll defines what part of the name table is visible, so you need to set it to (0,0) to actually see the top left corner);
- configure the PPU and enable rendering (read about registers $2000 and $2001);

Only after doing this you'll be able to see something on the screen.

I'm somewhat anxious to reply due to reaction thoughts... Where do I set the palette, reset the scroll, and configure the PPU and enable rendering? I'm lost here...

[3gengames]

You set the palette by setting the PPU data location to $3F00 and writing the 32 bytes of the palette. You set the scroll with registers $2005, and $2000. You enable rendering with $2001. It's all on the wiki:

http://wiki.nesdev.com/w/index.php/PPU_registers

[tepples]

The next question is "when". The correct time to set the scroll and enable rendering is after you've finished uploading all nametable and palette data to the PPU.