8x16 and whatever else unreg wants to know

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

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames » Mon Dec 31, 2012 4:44 pm

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.

User avatar
tokumaru
Posts: 11466
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tokumaru » Mon Dec 31, 2012 5:06 pm

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!).

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Tue Jan 01, 2013 1:45 pm

My ROM is having problems. In my code... there's this

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

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames » Tue Jan 01, 2013 2:00 pm

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

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Tue Jan 01, 2013 2:22 pm

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.
Yes I did.
3gengames wrote:Lastly, why not clear RAM, set the stack, etc. in one shot, then wait for vblanks
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! :D I'll change that. :)
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....
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
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames » Tue Jan 01, 2013 2:25 pm

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. :)

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Tue Jan 01, 2013 2:44 pm

...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? :?

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames » Tue Jan 01, 2013 2:49 pm

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.

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Tue Jan 01, 2013 3:05 pm

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.
No, I didn't know there's a MMC1 ASM6 template... searched and found only your post here with "MMC1 ASM6 template" highlighted.

User avatar
tokumaru
Posts: 11466
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tokumaru » Tue Jan 01, 2013 3:31 pm

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.

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Tue Jan 01, 2013 4:43 pm

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.
EXCELLENT!! THANK YOU SO MUCH TOKUMARU!!! :mrgreen:
And thanks 3gengames for all of your friendly help too... I almost made it to the UNROM asm6 template you were guiding me to! :D

---
3gengames, I'm sorry for my last reply to you... it isn't kind... my mistake. :(

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames » Tue Jan 01, 2013 4:48 pm

Haha no mistake, I thought there were MMC1 and UNROM templates, guess there's only one. :P

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Wed Jan 02, 2013 5:31 pm

YEAY!!!! OUR MAPPER WORKS!!! :D
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 tomorrow soon! :)

edit.

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered » Fri Jan 04, 2013 5:52 pm

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? :) :?

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.

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames » Fri Jan 04, 2013 6:06 pm

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. :)

Post Reply