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

User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 and whatever else unreg wants to know

Post by Kasumi »

well, there is still the problem because I am certain the address in sprite_layouts_lo and sprite_layouts_hi is correct... and the data it points to are our sprite definitions
That doesn't prevent your sprite definitions from being wrong. Did you check the actual data? Can you just post that table?

And you are certain the addresses in sprite_layouts_lo/hi are correct, but did you actually check the addresses?

If something is wrong, you really can't be sure without checking. So actually check if you haven't. If you have, tell me what you actually did check or I can't help.

If this adds 8 to your sprites

Code: Select all

lda (t0+0), y  ;<-- INDIRECT INDEXED ADDRESSING
                             iny
                                ;ect. start
                             clc
                          adc #$A8;The value that we expect should work
                       sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
                             inx
And this doesn't

Code: Select all

lda #$00  ;<-- INDIRECT INDEXED ADDRESSING
                             iny
                                ;ect. start
                             clc
                          adc oY;The value that we expect should work
                       sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
                             inx
(Note that above will obviously draw all sprites at the same y location, but if it's the right starting location the problem is probably your definitions)

If the top of the sprite is offset by 8 in both of these, then something is probably changing sprite,x later.

What this all boils down to is this: You are checking if the constant you put in works, while reading the data doesn't. If the correct constant works, and the data doesn't, that means you're obviously not getting that value from the data. Which means the data is wrong, or the pointer is set up incorrectly.

If the correct constant and data both give the same result, that rules out that variable/data as the problem. (Or the correct constant you are supplying is actually not correct. :wink:

So be specific about what happens when you do both of the above, share the data tables and their addresses, post what's in t0 and t0+1 when you do this.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Kasumi wrote:Can you just post that table?
I would have posted the table, but my sister is the boss and she didn't want me to post the table.
The table is correct. :)
Kasumi wrote:And you are certain the addresses in sprite_layouts_lo/hi are correct, but did you actually check the addresses?
Yes I remember checking the addresses in my listing file and they pointed to oY. I just checked the t0 offset after she has fallen to the ground... it is either $06, $0E, $16, or $1E. oY is always $A8. I'm sorry, I hope to regain and retain my thoroughness.
Kasumi wrote:If something is wrong, you really can't be sure without checking. So actually check if you haven't. If you have, tell me what you actually did check or I can't help.
That makes sense, ok.
Kasumi wrote:If this adds 8 to your sprites

Code: Select all

lda (t0+0), y  ;<-- INDIRECT INDEXED ADDRESSING
                             iny
                                ;ect. start
                             clc
                          adc #$A8;The value that we expect should work
                       sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
                             inx
Yes it does... my sprite is standing on #$D0.
Kasumi wrote:And this doesn't

Code: Select all

lda #$00  ;<-- INDIRECT INDEXED ADDRESSING
                             iny
                                ;ect. start
                             clc
                          adc oY;The value that we expect should work
                       sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
                             inx
No. Actually, it does add eight... she (32 bits tall) is still standing on #$D0.
Kasumi wrote:(Note that above will obviously draw all sprites at the same y location, but if it's the right starting location the problem is probably your definitions)

If the top of the sprite is offset by 8 in both of these, then something is probably changing sprite,x later.

What this all boils down to is this: You are checking if the constant you put in works, while reading the data doesn't. If the correct constant works, and the data doesn't, that means you're obviously not getting that value from the data. Which means the data is wrong, or the pointer is set up incorrectly.

If the correct constant and data both give the same result, that rules out that variable/data as the problem. (Or the correct constant you are supplying is actually not correct. :wink:

So be specific about what happens when you do both of the above, share the data tables and their addresses, post what's in t0 and t0+1 when you do this.
Thank you for all of your help so far. You have really helped me Kasumi! :D I need to do the rest of this by myself. Please forgive me for asking you, "Do you have any other methods or ideas?" I don't mean to milk or squeeze every bit of help out of you. Thank you for all of your help so far; I can do this. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Thank you so much Kasumi!!!!!!!!! :D
unregistered wrote:
Kasumi wrote:As well, related to collision: Consider that I know the tile a position is in is collision enabled. I need to eject upwards. My tile size is a power of two.

Code: Select all

lda position
and #%00001111;For 16
sta temp

lda position
clc
sbc temp
sta position
Done. How does it work? A tile for this example is 16 pixels. So the lowest 4 bits of the position will tell us how far we are into the tile. Say we're at 0000, the very top of the tile. We want to eject one pixel. So we clear the carry to subtract 1 extra. And subtract 0.

Say we're at 1111 ($F). That's the bottom of the tile. To get outside, we want to subtract sixteen. Which... is $F+1, so the same thing works. It works in all the cases. (with square tiles.)
I'm going to answer this part later... thank you for giving me some more time to think about it. :)
edit: Rolly noly goaly toly... well, I just used this SWEET code that works for everything... and it ejected my character to $B0... which is looks like she is standing 8 pixels below $D0... it says 176... which = $B0. How does that happen? I remember doing something a long time ago... but I can't remember right now... well... back to this fun problem I go.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Right now I'm getting the address $06 as data. How do I get my accumulator value "$06" to become an address? Please help me. :)
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 and whatever else unreg wants to know

Post by Kasumi »

unregistered wrote: edit: Rolly noly goaly toly... well, I just used this SWEET code that works for everything... and it ejected my character to $B0... which is looks like she is standing 8 pixels below $D0... it says 176... which = $B0. How does that happen?
This isn't a forum that makes a topic unread upon edits, so I never saw this until today. And I have no idea. I can't know from the information I have.
Right now I'm getting the address $06 as data. How do I get my accumulator value "$06" to become an address? Please help me.
I don't understand the question. Are you asking how to indirectly access data starting from $0006? $0600 maybe? Something else?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 and whatever else unreg wants to know

Post by tokumaru »

I'm assuming $06 is some sort of offset? If that's the case, here's my answer:

If the data you want to access is 256 bytes or less, the easiest thing to do is transfer the number (offset) from A to X or Y and use absolute indexed addressing. It's as simple as TAX; LDA BaseAddress, X;

If the total of data is more than 256 bytes, you'll need to create a pointer in Zero Page and use Indirect Indexed addressing. You'll have to do a 16-bit addition of the offset with the base address and store the result in Zero Page. Then you can LDA (Pointer), Y to read the data. Y should be 0 in this case, because the full address is in the pointer already, but the 6502 doesn't have an indirect addressing mode that isn't indexed.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

tokumaru wrote:I'm assuming $06 is some sort of offset? If that's the case, here's my answer:

If the data you want to access is 256 bytes or less, the easiest thing to do is transfer the number (offset) from A to X or Y and use absolute indexed addressing. It's as simple as TAX; LDA BaseAddress, X;
SWEET SASSY MOLASSY!!!! TOKUMARU WE SHOULD REQUEST ALL NES 6502 PROGRAMMERS TO ENGRAVE THIS ON ONE OF THEIR ARMS :P :lol: :shock: :)
tokumaru wrote:If the total of data is more than 256 bytes, you'll need to create a pointer in Zero Page and use Indirect Indexed addressing. You'll have to do a 16-bit addition of the offset with the base address and store the result in Zero Page. Then you can LDA (Pointer), Y to read the data. Y should be 0 in this case, because the full address is in the pointer already, but the 6502 doesn't have an indirect addressing mode that isn't indexed.
THANKS TOKUMARU FOR THIS ENTIRE RESPONSE!! :D :D

Here is my code now... all of the new code instructions are CAPITALIZED

Code: Select all

  draw_sprite: ;must set x prior to calling draw_sprite
	 
	   ;jsr onscreen
	   
	  
	  ; t0-t2 are temporary zero page locations holding
	  ; the address of a particular sprite layout and the
	  ; number of sprites left to draw
	  lda sprite_layouts_lo, x  ;<-- ABSOLUTE INDEXED ADDRESSING
	  ;1l1 nothing here.
	  sta t0
	  lda sprite_layouts_hi, x  ;<-- ABSOLUTE INDEXED ADDRESSING
	  sta t0+1
	  lda sprite_layouts_count, x  ;<-- ABSOLUTE INDEXED ADDRESSING
	  sta t2
	  ldy #0
	  ; oamIndex is a variable tracking how far you've written
	  ; into shadow OAM (customarily at $0200-$02FF)
	  ldx oamIndex
	@loop:
	  ; If you have the address of an array in a zero page pointer,
	  ; you use the (d),y addressing mode and increase Y to go
	  ; to the next byte.
	    TYA
	    PHA ;------------->
	  lda (t0+0), y  ;<-- INDIRECT INDEXED ADDRESSING
	    TAY
	    LDA $0000, y ;<-- engrave this on your arm! :P :)
	    STA t2+1
	    PLA ;<-------------
	    TAY
	  iny
	  ;ect. start
	    LDA t2+1
	  clc
	  adc oY
	  sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
	  inx
	lda oY   
	sta $E1
	lda t0  
	sta $E2  
	lda t0+1  
	sta $E3  
	  
	  
	  lda (t0+0), y
	sta $E6
	  iny
	  sta sprite, x
	  inx
	  
	  lda (t0+0), y
	sta $E7  
	  iny
	  sta sprite, x
	  inx
	  
	        TYA
		PHA ;--------------->
	  lda (t0+0), y
	    TAY
		LDA $0000, y
		STA t2+1
		PLA ;<---------------
		TAY
	  
	  iny
	    LDA t2+1
	  clc
	  adc oX
	  sta sprite, x
	  inx
	  
	  ;end ect.		  
	  dec t2
	  bne @loop
	  stx oamIndex
+end  rts ;end of draw_sprite
...Now Kasumi and tokumaru, I don't mean for yall to trudge through all of that code... I just want yall to see the CAPITALIZED instructions that I added. Now my code doesn't add #$03 to every x value. Our sprite is drawn at the oX value #$00 now (right up next to the left side of the screen). My sister helped me to learn that it was starting with #$03 because oX is at address $0003. oY is at address $0006 so the same should happen to that value... but it doesn't yet for some reason... it's kind of weird.

edit.

edit2: I want to point out that there are two groups of CAPITALIZED code... one before the adc oY part... and then one before the adc oX part. Both groups should be the exact same code... I will double check that tomorrow... goodnight yalll everyone. :)

edit3.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 and whatever else unreg wants to know

Post by Kasumi »

I'm not sure I understand the purpose of the new code. t0 and t1 have the address we want to load the data from. Y keeps track of how far into the data we are.

Code: Select all

 TYA;We're pushing the value in Y
       PHA;To the stack
     lda (t0+0), y  ;We're loading from the data. So shouldn't this mean the value we've meant to load is now in A?
       TAY;But then we move it into Y
       LDA $0000, y;And load a zero page variable?
       STA t2+1
       PLA ;<-------------
       TAY
This code suggests your table whose address is stored at t0 contains a zero page index that contains the actual value you want. This is not necessarily bad, but why the extra step? Why not just store the actual value you want rather than a reference to a variable that contains that value?
My sister helped me to learn that it was starting with #$03 because oX is at address $0003
I'm not sure I understand. Where the variable is on the zero page should have no bearing on what its initial/current value would ever be.

If your table was set up like this:

Code: Select all

sprite_layout_one:
.db $00;Y offset for sprite 0
.db $00;Tile for sprite 0
.db %00000000;Attributes for sprite 0
.db $00;X offset for sprite 0

.db $00;Y offset for sprite 1
.db $01;Tile for sprite 1
.db %00000000;Attributes for sprite 1
.db $08;X offset for sprite 1

.db $08;Y offset for sprite 2
.db $02;Tile for sprite 2
.db %00000000;Attributes for sprite 2
.db $00;X offset for sprite 2

.db $08;Y offset for sprite 3
.db $03;Tile for sprite 3
.db %00000000;Attributes for sprite 3
.db $08;X offset for sprite 3

;Sprite 0 is drawn using tile index #$00 directly at the X and Y position.
;Sprite 1 is drawn using tile index #$01 eight pixels to the right of the X position, and directly at the Y position
;Sprite 2 is drawn using tile index #$02 directly at the X position, and eight pixels below the Y position
;Sprite 3 is drawn using tile index #$03 eight pixels to the right of the X position, and eight pixels below the Y position
You'd already have all the info you need by accessing sprite_layout_one. Like so:

Code: Select all

@loop:
lda sprite_layout_one,y;This is how far the sprite is OFFSET from our Y position
clc;So we add it to the Y position
adc oY
sta sprite,x
iny
inx

lda sprite_layout_one,y;Tile index
sta sprite,x

iny
inx

lda sprite_layout_one,y;Sprite attributes
sta sprite,x

iny
inx

lda sprite_layout_one,y;This is how far the sprite is OFFSET from our X position
clc;So we add it to the x position
adc oX
sta sprite,x

iny
inx

dec t2
bne @loop
stx oamIndex
rts
The only thing missing in the above is the indirect part.

Code: Select all

;If the low and high bytes of sprite_layout_one were in t0 and t1, the following two lines of code would access the same value. (And put it into A)

lda sprite_layout_one,y
lda (t0),y
So a full version might look like...

Code: Select all

; t0-t2 are temporary zero page locations holding
; the address of a particular sprite layout and the
; number of sprites left to draw
draw_sprite:

lda sprite_layouts_lo, x
sta t0
lda sprite_layouts_hi, x  ;<-- ABSOLUTE INDEXED ADDRESSING
sta t0+1

lda sprite_layouts_count, x  ;<-- ABSOLUTE INDEXED ADDRESSING
sta t2

ldy #0
ldx oamIndex; oamIndex is a variable tracking how far you've written
; into shadow OAM (customarily at $0200-$02FF)

@loop:
lda (t0),y;This is how far the sprite is OFFSET from our Y position
clc;So we add it to the Y position
adc oY
sta sprite,x
iny
inx

lda (t0),y;Tile index
sta sprite,x

iny
inx

lda (t0),y;Sprite attributes
sta sprite,x

iny
inx

lda (t0),y;This is how far the sprite is OFFSET from our X position
clc;So we add it to the x position
adc oX
sta sprite,x

iny
inx

dec t2
bne @loop:
stx oamIndex
rts

sprite_layout_one:
.db $00;Y offset for sprite 0
.db $00;Tile for sprite 0
.db %00000000;Attributes for sprite 0
.db $00;X offset for sprite 0

.db $00;Y offset for sprite 1
.db $01;Tile for sprite 1
.db %00000000;Attributes for sprite 1
.db $08;X offset for sprite 1

.db $08;Y offset for sprite 2
.db $02;Tile for sprite 2
.db %00000000;Attributes for sprite 2
.db $00;X offset for sprite 2

.db $08;Y offset for sprite 3
.db $03;Tile for sprite 3
.db %00000000;Attributes for sprite 3
.db $08;X offset for sprite 3

;Sprite 0 is drawn using tile index #$00 directly at the X and Y position.
;Sprite 1 is drawn using tile index #$01 eight pixels to the right of the X position, and directly at the Y position
;Sprite 2 is drawn using tile index #$02 directly at the X position, and eight pixels below the Y position
;Sprite 3 is drawn using tile index #$03 eight pixels to the right of the X position, and eight pixels below the Y position


sprite_layouts_lo:
.db <sprite_layout_one

sprite_layouts_hi:
.db >sprite_layout_one

sprite_layouts_count:
.db 4;There are four sprites in sprite_layout_one
So if you did

Code: Select all

ldx #$00
jsr draw_sprite
You'd get a 16x16 metasprite composed of tile $00 for top left corner, tile $01 for the top right corner, tile $02 for the bottom left corner, tile $03 for the bottom right corner. All with no flipping, and palette 0.

I have zero idea what your tables look like or how your data is stored. So here's a way store the data and access it that might be different from what you're doing.

I did test the above, but full disclosure: I tested it very briefly and I had to convert its syntax to NESASM, so something small done in that process may have fixed a potential issue. But I can fix this if it's broken. I cannot help fix what you have without... the rest of what you have.

edit: I made a test rom, because lately I've been making a lot of mistakes by trying to help without testing my code. And since the test rom exists, may as well attach it. It is the definition of quick and dirty, you've got to edit RAM manually to see the sprite move. ($03 and $04 are its X and Y positions respectively.) After initialization it literally does nothing but run this routine in the main loop every frame. The NMI updates palettes so the sprite is visible, and of course does the sprite DMA. Nothing else. (Also, adc oY and adc oX end up assembled as absolute not zero page, because I didn't bother doing zero page the nesasm way when converting.)
Attachments
main.nes
(24.02 KiB) Downloaded 145 times
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

:oops: :oops: :oops:
qbradq[color=#FFBF80], on page 3,[/color] wrote:So your example above becomes:

Code: Select all

aY EQU 10
aX EQU 20
.db aY, $80, $00, aX, aY, $81, $00, aX +1

Remember, the .byte and .db directives emit a byte of data into the output ROM file. The EQU directive (and it's cousin, the = operator) create symbols within the assembler that you can use latter on.
tokumaru[color=#FFBF80], also, a post or two later, on page 3,[/color] wrote:Symbols are just "nicknames" for numbers. These numbers can represent memory locations (which is the case of labels and variables) or numeric constants (values you commonly use throughout the program).

They exist only in the source code to make programming easier (just imagine if you had to remember the addresses of everything!), they do not exist in the assembled program.
So you would think I would have learned that symbols do not exist in the assembled program... but no after being given this on page 4
tepples[color=#00BFFF], on page 4,[/color] wrote:

Code: Select all

hero_frame1:
  .db aY,    $80, $00, ax, aY,    $81, $00, aX+8
  .db aY+8,  $90, $00, aX, aY+8,  $91, $00, aX+8
  .db aY+16, $a0, $00, aX, aY+16, $a1, $00, aX+8
  .db aY+24, $b0, $00, aX, aY+24, $b1, $00, aX+8
I changed the aYs to oYs and the aXes to oXen... and so that is how our sprite definitions have been till now... but tomorrow I am going to change everything all of them back to aY and aX. That will be a start in the right direction, I think. :)

edit.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Kasumi wrote:edit: I made a test rom, because lately I've been making a lot of mistakes by trying to help without testing my code. And since the test rom exists, may as well attach it. It is the definition of quick and dirty, you've got to edit RAM manually to see the sprite move. ($03 and $04 are its X and Y positions respectively.) After initialization it literally does nothing but run this routine in the main loop every frame. The NMI updates palettes so the sprite is visible, and of course does the sprite DMA. Nothing else. (Also, adc oY and adc oX end up assembled as absolute not zero page, because I didn't bother doing zero page the nesasm way when converting.)
Kasumi, thank you so much for this test rom!! :D I just figured out how to edit RAM manually in FCEUX 2.1.5! I clicked Tools>Cheats... and this window came up where I then entered 0003 in the "Address:" box and 80 in the "Value:" box... and then I clicked the Add button and WALAAH!!! :D It moved the sprite down :shock: to the middle of the screen! (So I think your definitions are backwards...)
($03 and $04 are its X and Y positions respectively.)
should be "($03 and $04 are its Y and X positions respectively)", I think. : )

edit: And guess what you were right to say you didn't understand why I added my capitalized code to draw_sprite. I just commented all of those capitalized code lines away and our 32 pixel tall girl is standing on $D0! JUST LIKE MARIO!!! AND ALL OF THE OYS AND OXEN ARE AYS AND AXES NOW!!!!! IT'S SWEEEEEEEEEEET!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WOO HOOO THANK YOU KASUMI!!!!! :D :D :)
Last edited by unregistered on Wed Nov 05, 2014 12:06 pm, edited 1 time in total.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 and whatever else unreg wants to know

Post by tokumaru »

unregistered wrote:I just figured out how to edit RAM manually in FCEUX 2.1.5! I clicked Tools>Cheats... and this window came up where I then entered 0003 in the "Address:" box and 80 in the "Value:" box... and then I clicked the Add button
That's actually patching, not RAM editing. The difference is that patched bytes can't be changed by the game program (i.e. $03 will always read back as $80 even if the game program tries to store something there). Sometimes that may even be the desired behavior, but other times you may actually want to change values and let the game code manipulate them after that. When that's the case, you can use FCEUX's hex editor. There you can select what kind of memory you want to see (e.g. ROM, RAM, VRAM), and then you can just click on the bytes to input new values. There are also options to freeze and unfreeze values.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

tokumaru wrote:
unregistered wrote:I just figured out how to edit RAM manually in FCEUX 2.1.5! I clicked Tools>Cheats... and this window came up where I then entered 0003 in the "Address:" box and 80 in the "Value:" box... and then I clicked the Add button
That's actually patching, not RAM editing. The difference is that patched bytes can't be changed by the game program (i.e. $03 will always read back as $80 even if the game program tries to store something there). Sometimes that may even be the desired behavior, but other times you may actually want to change values and let the game code manipulate them after that. When that's the case, you can use FCEUX's hex editor. There you can select what kind of memory you want to see (e.g. ROM, RAM, VRAM), and then you can just click on the bytes to input new values. There are also options to freeze and unfreeze values.
Thank you so much tokumaru!! :D Well... um... how can I just click on the bytes to input new values? I've never tried that... will try that! Thanks! :D
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 and whatever else unreg wants to know

Post by Kasumi »

Hah, yep $03 and $04 backwards. Sorry about that. Even when I made sure the code worked, I messed up the description. :lol:
I just figured out how to edit RAM manually in FCEUX 2.1.5!
Tokumaru ninja'd, but I'm adding that cheats also might affect later boots. (Even if you close FCEUX and open it again, the value may remain frozen or "cheat'd" depending on your settings.) I definitely prefer the hex editor.

Edit: Yes, just scroll to the byte you want, click it and start typing.
I am going to change everything all of them back to aY and aX.
It's not even required to do that. You can have just the offset value. (If aY and aX are both zero, anyway. Otherwise it may still be convenient to have them as global offsets to add to the other offsets.) Glad it's working either way!
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Kasumi wrote:Hah, yep $03 and $04 backwards. Sorry about that. Even when I made sure the code worked, I messed up the description. :lol:
Glad you are laughing. :)
Kasumi wrote:
I just figured out how to edit RAM manually in FCEUX 2.1.5!
Tokumaru ninja'd, but I'm adding that cheats also might affect later boots. (Even if you close FCEUX and open it again, the value may remain frozen or "cheat'd" depending on your settings.) I definitely prefer the hex editor.
Thanks, me too. :)
Kasumi wrote:Edit: Yes, just scroll to the byte you want, click it and start typing.
This would have been very helpful... thank you Kasumi! :D I reached a point of confusion where I didn't know what to do to make the hex editor work like tokumaru described... so I just tried typing. :)
Kasumi wrote:
I am going to change everything all of them back to aY and aX.
It's not even required to do that. You can have just the offset value. (If aY and aX are both zero, anyway. Otherwise it may still be convenient to have them as global offsets to add to the other offsets.) Glad it's working either way!
Thanks! :D

edit.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Shiru[color=#FFFF00], on page 46,[/color] wrote:There is no official NES programming manual available, but you can easily find the SNES one, if you are just interested what an official doc looks like.
Shiru, I want to buy the SNES one... how do I find it?
Post Reply