Kasumi taught me something like this...
Make each nametable with your tiles like this (we have lots of screens like this... and my sister put them all in one file):
Code:
screen_C_1:
; 0 1 2 3 4 5 6 7
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
.db $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
That is enough bytes for one entire screen... the commented numbers on top help us to quickly get to a specific 16x16 metatile.
We chose to do it this way because we can really easily change the screens if we want to... more easily than using a binary file as dougeff recommended, IMO.
I start my assigning nametable code out something like this:
Code:
ldx #$00 ;screen 0
lda lvl1_floorC_lo, x
sta $10
lda lvl1_floorC_hi, x
sta $11
ldy #$00
;from dougeff....
lda #$20
sta $2006
lda #$00
sta $2006
;^good code :)
- lda ($10), y
sta $2007
iny
bne -
Now that is better because the loop is smaller and quicker than dougeff's... his works... but he missed the importance of y in the
lda (pointer), y. Instead of incrementing the pointer... you can keep the pointer the same until you are ready to load another screen... you can increment y and stop the loop after it reaches 00 again. This loop will work if your PPU is set to increment by 1 after each write to $2007, I think...
lda (pointer), y adds y to the pointer... just like
lda address, x adds x to the address.
Code:
lvl1_floorC_lo:
.dl screen_C_1, screen_C_2, screen_C_3 ;.dl gets the low byte value
lvl1_floorC_hi:
.dh screen_C_1, screen_C_2, screen_C_3 ;.dh gets the high byte value
Since you are using asm6 you can use labels like
- and
+...
Restrictions:
- can only be used to branch to a lower address
+ can only be used to branch to a higher address
Benifits:
They are much better than the local @ labels, IMO, because you can use them over and over like:
Code:
iny
bpl +
;some code that only runs when y is negative
+ bmi +
;some code that only runs when the N flag is not set
+ ;more code
The
+ labels are exactly the same, but that is ok because when it branches to a
+ label it always branches to the first
+ label it finds... and asm6 does this perfectly every time. If you need another type of
+ label you can use ++ or +something. Same with the
- lables.
And you can do this to branch to the same line from either direction:
Code:
bne +
;some code
-
+ lda #$01
;some code
;edit: note: the code here better be able to change the flags or you'll have an infinite loop
bne -
both bnes will branch to the lda #$01 if the Z flag is not set... cause when looking at the .lst files every new line is the same address
until an instruction is found, then the next line will have a new address.edit.