8x16 and whatever else unreg wants to know
Moderator: Moderators
Re: 8x16 sprite is really a 16x32 pixel image?
In my MMC1 projects I just had 32 different files. One for each half of the 16KB banks. I then just included them all in the main Program.asm file. But yeah, maybe use a Macro. Just so you don't have to change 16 boot programs if you want to change them.
Re: 8x16 sprite is really a 16x32 pixel image?
Back when I was looking for a good way to handle multiple banks in ASM6 I tried using macros, but something went wrong, I don't remember what... Maybe it wasn't possible to reference labels defined inside macros or something like that... Whatever it was, I ended up making one include file to include in all switchable banks, like I explained above... it works great and is easy to maintain (if I need to modify the stub I only have to change 1 file, not 16 or 32!).
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
My ROM is having problems. In my code... there's this
My init mapper routine is run at the top of init_graphics. When I open up my file in FCEUX 2.1.5 the screen is grey. My code appears at $8000 instead of $C000 like it should... at least it says that in FCEUX's debugger. Why? Shiru, I know that is a big section of code that I'm sharing... I feel that it has already been debugged; it's there again though because I'm at a gray screen again.
Code: Select all
; Actual program code. Our fixed bank is our last bank and the
; origin is $C000.
.org $C000
reset: sei
cld
; Wait two VBLANKs.
- lda $2002
bpl -
; Clear out RAM.
lda #$00
ldx #$00
- sta $000,x
sta $100,x
;sta $200,x ;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).
sta $300,x
sta $400,x
sta $500,x
sta $600,x
sta $700,x
inx
bne -
; Reset the stack pointer.
ldx #$FF
txs
; Disable all graphics.
inx ;lda #$00
stx $2000
stx $2001
- lda $2002
bpl - ;finish waiting for second vblank
jsr init_graphics
jsr init_input
jsr init_sound
; Set basic PPU registers. Load background from $0000,
; sprites from $1000, and the name table from $2000.
lda #%10001000
sta $2000
lda #%00011110
sta $2001
;matthew's init RAM
lda #$03
sta $0003 ;oX
sta $0006 ;oY
sta $0028 ;PointX
sta $002A ;PointY
lda #$00
sta $001d ;CameraX (object)
sta $001e ;CameraX+1
sta $002D ;ofracorhiX+0
sta $002E ;ofracorhiX+1
sta $002F ;ofracorhiY+0
sta $0030 ;ofracorhiY+1
sta tC
lda #$00
sta currNameTable
sta Next
sta Current
cli
;----------------------------END OF RESET----------------------------------
; Transfer control to the GAME LOGIC routines.
;initialize the flag to "false"
lda #$00
sta FrameReady
MainLoop:
;DO THE GAME LOGIC HERE (i.e. movement, collisions, etc.)
jsr react_to_input
jsr collisionU
ldx aFrame
jsr draw_sprite
sta $ff
;indicate that the frame calculations are done
dec FrameReady
WaitForUpdates:
;wait for the flag to change
bit FrameReady
bmi WaitForUpdates
jmp MainLoop
Re: 8x16 sprite is really a 16x32 pixel image?
Did you store $80+ to $8000+? You have to do that to make sure all MMC1's reset and put the code in $C000 page.
Also, why do you LDA #$00 in mathews init? As you cleared them before. Also, make them zeropage values to save a cycle each, as you write to a full address. Lastly, why not clear RAM, set the stack, etc. in one shot, then wait for vblanks? Last idea: use the first two bytes of RAM and clear RAM from $7FF down? You save a few bytes, and the speed doesn't matter since you're waiting for the PPU. But yeah, if you reset your mapper right, I dunno what else to say....
Also, why do you LDA #$00 in mathews init? As you cleared them before. Also, make them zeropage values to save a cycle each, as you write to a full address. Lastly, why not clear RAM, set the stack, etc. in one shot, then wait for vblanks? Last idea: use the first two bytes of RAM and clear RAM from $7FF down? You save a few bytes, and the speed doesn't matter since you're waiting for the PPU. But yeah, if you reset your mapper right, I dunno what else to say....
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
Yes I did.3gengames wrote:Did you store $80+ to $8000+? You have to do that to make sure all MMC1's reset and put the code in $C000 page.
I thought clearing RAM, and setting the stack... all of that should be done between waiting for vblanks. But thanks 3gengames thatt does make sense! I'll change that.3gengames wrote:Lastly, why not clear RAM, set the stack, etc. in one shot, then wait for vblanks
I think maybe it has something to do with the fact that I didn't include my 16 banks of memory... the code does follow tokumaru's idea. But I'm not sure where to place those .includes.3gengames wrote:Last idea: use the first two bytes of RAM and clear RAM from $7FF down? You save a few bytes, and the speed doesn't matter since you're waiting for the PPU. But yeah, if you reset your mapper right, I dunno what else to say....
Re: 8x16 sprite is really a 16x32 pixel image?
Well you can just include all the files in order in one main file. Have each file from there just assign all the right locations. Or you could do it in the main file. Sorry, never messed with ASM6 deep enough to know how it works well enough to help. I'm sure somebody will post an example program or something to show ya though.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
...it doesn't make sense to me... like there are 16 banks of memory but they arent all used at the same time. You have to write what bank you want to pick to the last 4 bits of the internal prg-bank. But, how am I susposed to .include those banks so they are like that?
Re: 8x16 sprite is really a 16x32 pixel image?
You include them in order. I dunno, usually there's a .bank directive or something too. You did look at MMC1 ASM6 template didn't you? Or UNROM? They're on the forums here.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
No, I didn't know there's a MMC1 ASM6 template... searched and found only your post here with "MMC1 ASM6 template" highlighted.3gengames wrote:You include them in order. I dunno, usually there's a .bank directive or something too. You did look at MMC1 ASM6 template didn't you? Or UNROM? They're on the forums here.
Re: 8x16 sprite is really a 16x32 pixel image?
In ASM6 you can simply put the switchable banks one after the other, you just have to use the .base directive to "reset" the program counter at the start of every bank (you can use .base instead of .org then). I know it isn't the exact same as MMC1, but my UNROM template should make it clear how to organize a ROM with multiple switchable banks. It's basically missing the reset stub, but we've already estabilished how that works.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
EXCELLENT!! THANK YOU SO MUCH TOKUMARU!!!tokumaru wrote:In ASM6 you can simply put the switchable banks one after the other, you just have to use the .base directive to "reset" the program counter at the start of every bank (you can use .base instead of .org then). I know it isn't the exact same as MMC1, but my UNROM template should make it clear how to organize a ROM with multiple switchable banks. It's basically missing the reset stub, but we've already estabilished how that works.
And thanks 3gengames for all of your friendly help too... I almost made it to the UNROM asm6 template you were guiding me to!
---
3gengames, I'm sorry for my last reply to you... it isn't kind... my mistake.
Re: 8x16 sprite is really a 16x32 pixel image?
Haha no mistake, I thought there were MMC1 and UNROM templates, guess there's only one.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
YEAY!!!! OUR MAPPER WORKS!!!
Now to continue with scrolling beyond two screens! Well... there's one problem... the screen changes to black at the start of scrolling. In FCEUX's "Name Table Viewer" it replaces the first nametable with the third screen at the exact same time the screen goes black. I guess that's my mistake; plan to fixtomorrow soon!
edit.
Now to continue with scrolling beyond two screens! Well... there's one problem... the screen changes to black at the start of scrolling. In FCEUX's "Name Table Viewer" it replaces the first nametable with the third screen at the exact same time the screen goes black. I guess that's my mistake; plan to fix
edit.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
With PPUCTRL register $2000... bits 0 and 1... The nesdev wiki tells us that the X value bit is bit 0... and I'm only scrolling horrizontally so I only need to worry about bit 0. When switching in a new screen after scrolling to the end, do I need to to invert that bit 0? When bit 0 is true the wiki says the x-corridnate is incremented by 256. Which makes sense because the screen is just 256 pixels wide. When you reach the end of nametable 1 and you set bit 0 to true... then it is time to replace nametable 0 with the next screen. Is that correct?
Definitions:
The x spot at the end of nametable 1
The next screen you would begin to see after scrolling to the right.
Code: Select all
[ 0 ][ 1 x]
Definitions:
The x spot at the end of nametable 1
The next screen you would begin to see after scrolling to the right.
Re: 8x16 sprite is really a 16x32 pixel image?
Yep, basically think of it as "Add 256 to the scroll"and that's how it works. So when you get to scroll=256, you have to put X to zero, then set the bit. That moves it to the next nametable as the default that you then scroll within.