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

Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru » Sat Jun 09, 2012 12:07 pm

Honestly, I can't remember a single time when the ($XX,x) addressing was useful for me, so I would say it is not urgent to learn it, as it probably won't help you much either.

The ($XX),y addressing is a very important thing to learn, though.

tepples
Posts: 21809
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Sat Jun 09, 2012 2:24 pm

tokumaru wrote:The reason why ($XX, x) is rarely used is because it can't index the target data in any way. Once the address of the pointer is calculated ($XX + x) and the pointer is used, the target is a single byte. There's no way to access any bytes after that one. If you do wish to access the next bytes, you have to manipulate the pointer itself (INC the lower byte, if it overflows INC the higher byte), which is terribly slow.
But if you do have an array of pointers, such as one pointer for each sound channel, and you only consume a few bytes per frame, 10.02 cycles per increment (INC ptr,x BNE :+ INC ptr+1,x : ) isn't too much slower than 5.02 cycles per increment for (d),y (INY BNE :+ INC ptr+1 : ).

EDIT: cycle count corrected per tokumaru's clarification
Last edited by tepples on Sat Jun 09, 2012 4:02 pm, edited 1 time in total.

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

Post by tokumaru » Sat Jun 09, 2012 3:04 pm

Exactly. Reading data from music streams is the only legitimate use I can think of for this addressing mode. Also, incrementing the pointer is more like INC prt, x BNE :+ INC prt+1, x :, because if you knew what pointer to increment there would be no reason to use (ptr, x).

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

Post by unregistered » Sat Jun 09, 2012 4:56 pm

tokumaru wrote:It seems you are a bit confused about the addressing modes, so I suggest you play a bit with ($XX, x) and ($XX), y using the 6502 simulator until you understand how they work.
What is a 6502 simulator? :) I dont understand. :?

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

Post by tokumaru » Sun Jun 10, 2012 12:25 am

unregistered wrote:What is a 6502 simulator? :) I dont understand. :?
I'm talking about this. It's a 6502 simulator with integrated debug features. You write some code, assemble it (to memory, no files are generated), and then you run it and use a multitude of debugging features to analyze what the program is doing.

I used it a lot when I was first learning to program in 6502 assembly, to make sure I completely understood how the CPU worked. I wrote all kinds of test code to understand how the carry and the other flags were affected, how the addressing modes worked, subroutines, the stack, everything. Later I practiced by making some useful routines, such as multiplication and division, to make sure I got the hang of it.

User avatar
Jeroen
Posts: 982
Joined: Tue Jul 03, 2007 1:49 pm

Post by Jeroen » Sun Jun 10, 2012 3:50 am

I feel http://visual6502.org/welcome.html would be a more modern alternative. Reason being that it should be as accurate as a real 6502.

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

Post by tokumaru » Sun Jun 10, 2012 4:10 pm

Jeroen wrote:I feel http://visual6502.org/welcome.html would be a more modern alternative. Reason being that it should be as accurate as a real 6502.
That's like killing a fly with a bazooka. As I see it, This is geared towards people researching more obscure behaviors of the 6502, things that haven't been properly documented yet and that until recently required expensive equipment and a real 6502 to test. It is, however, very demanding on computer resources and doesn't offer particularly friendly debugging controls. For a newbie that's just trying to get the hang of how each instruction works, Michal Kowalski's tool is much more appropriate IMO.

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

Post by unregistered » Sun Jun 10, 2012 5:36 pm

tokumaru wrote:
unregistered wrote:What is a 6502 simulator? :) I dont understand. :?
I'm talking about this. It's a 6502 simulator with integrated debug features. You write some code, assemble it (to memory, no files are generated), and then you run it and use a multitude of debugging features to analyze what the program is doing.

I used it a lot when I was first learning to program in 6502 assembly, to make sure I completely understood how the CPU worked. I wrote all kinds of test code to understand how the carry and the other flags were affected, how the addressing modes worked, subroutines, the stack, everything. Later I practiced by making some useful routines, such as multiplication and division, to make sure I got the hang of it.
Wow THANK YOU so much tokumaru! :D I tried this code

Code: Select all

  .org $0000
temp .DB 0
grate .DB 7	

 .ORG $1000
   
  LDA #$03
  STA temp
  INC temp
  LDY #101
  STA ($34), y
  INY 
  INY
But the only thing that seems to work is it puts a 7 in address $0001.
What is the problem with the rest of my code? :) Guess I have to read some instructions. :?

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

Post by tokumaru » Sun Jun 10, 2012 6:33 pm

Since this simulator doesn't use a ROM, it doesn't have the IRQ, NMI and Reset vectors, so it uses the first .ORG in your code as the reset vector. Since you used .ORG $0000 to define your variables, that's where execution starts. Since you put a 0 there, and that's the opcode for the BRK instruction (instruction that the simulator uses to terminate the program), nothing happens.

Just put ".START $1000" at the very top, to tell the simulator where the program actually starts.

Also, by default, the simulator doesn't know what's RAM and what's ROM, so it will allow you to .DB a value somewhere (i.e. the 7 at $0001) and still use that location as RAM, but you should know that this is not possible on actual hardware. .DB can only be used to set bytes in ROM, to put a value in RAM you have to manually LOAD it and STORE it there.

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

Post by unregistered » Sun Jun 10, 2012 6:52 pm

tokumaru wrote:Since this simulator doesn't use a ROM, it doesn't have the IRQ, NMI and Reset vectors, so it uses the first .ORG in your code as the reset vector. Since you used .ORG $0000 to define your variables, that's where execution starts. Since you put a 0 there, and that's the opcode for the BRK instruction (instruction that the simulator uses to terminate the program), nothing happens.

Just put ".START $1000" at the very top, to tell the simulator where the program actually starts.

Also, by default, the simulator doesn't know what's RAM and what's ROM, so it will allow you to .DB a value somewhere (i.e. the 7 at $0001) and still use that location as RAM, but you should know that this is not possible on actual hardware. .DB can only be used to set bytes in ROM, to put a value in RAM you have to manually LOAD it and STORE it there.
tokumaru, THIS PROGRAM IS SO COOL! :D THANK YOU SO MUCH!

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

Post by unregistered » Wed Jun 13, 2012 1:19 pm

Now there is an 8pixel sometimes-tile-#0 thin line at the top of the screen... the nametable is pushed underneath. Has anyone had this happen to them in FCEUX and know what caused it?

In nintendulator it pops up a small box that says "Bad opcode, CPU locked". So that is different... :?

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

Post by tokumaru » Wed Jun 13, 2012 1:55 pm

unregistered wrote:Now there is an 8pixel sometimes-tile-#0 thin line at the top of the screen... the nametable is pushed underneath. Has anyone had this happen to them in FCEUX and know what caused it?
Not really sure what you're talking about here. Did you put unused sprites off-screen? You must put sprites you are not using below the end of the screen (use a Y coordinate of 240 or more) in order to hide them, otherwise most emulators will put the sprites at the top left of the screen (coordinates 0, 0).
In nintendulator it pops up a small box that says "Bad opcode, CPU locked". So that is different... :?
The program is crashing, just like it was before. You have to solve this the same way, tracing the code and finding out where it derails.

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

Post by Kasumi » Wed Jun 13, 2012 3:06 pm

unregistered wrote: In nintendulator it pops up a small box that says "Bad opcode, CPU locked". So that is different... :?
Just for the record, this specifically means your program has hit an invalid instruction. It usually happens when your program counter runs through data instead of code.

This should be a fairly easy one to debug by logging, because it's pretty likely the program halts very soon after the issue, instead of a wild goose chase when it could be anything like before.

User avatar
Dwedit
Posts: 4246
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Wed Jun 13, 2012 3:08 pm

It means you forgot to return or jump at the end of some function of code.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

smkd
Posts: 101
Joined: Sun Apr 22, 2007 6:07 am

Post by smkd » Wed Jun 13, 2012 10:04 pm

Another easy to overlook problem is pushing bytes onto the stack in some subroutine, but forgetting to pull them before the RTS is reached which will make the CPU jump off to some random location.

Post Reply