nesdev.com
https://forums.nesdev.com/

8x16 and whatever else unreg wants to know
https://forums.nesdev.com/viewtopic.php?f=10&t=7451
Page 41 of 97

Author:  Shiru [ Sat Jun 09, 2012 12:07 pm ]
Post subject: 

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.

Author:  tepples [ Sat Jun 09, 2012 2:24 pm ]
Post subject: 

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

Author:  tokumaru [ Sat Jun 09, 2012 3:04 pm ]
Post subject: 

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

Author:  unregistered [ Sat Jun 09, 2012 4:56 pm ]
Post subject: 

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

Author:  tokumaru [ Sun Jun 10, 2012 12:25 am ]
Post subject: 

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.

Author:  Jeroen [ Sun Jun 10, 2012 3:50 am ]
Post subject: 

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.

Author:  tokumaru [ Sun Jun 10, 2012 4:10 pm ]
Post subject: 

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.

Author:  unregistered [ Sun Jun 10, 2012 5:36 pm ]
Post subject: 

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

Author:  tokumaru [ Sun Jun 10, 2012 6:33 pm ]
Post subject: 

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.

Author:  unregistered [ Sun Jun 10, 2012 6:52 pm ]
Post subject: 

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!

Author:  unregistered [ Wed Jun 13, 2012 1:19 pm ]
Post subject: 

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

Author:  tokumaru [ Wed Jun 13, 2012 1:55 pm ]
Post subject: 

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

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

Author:  Kasumi [ Wed Jun 13, 2012 3:06 pm ]
Post subject: 

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.

Author:  Dwedit [ Wed Jun 13, 2012 3:08 pm ]
Post subject: 

It means you forgot to return or jump at the end of some function of code.

Author:  smkd [ Wed Jun 13, 2012 10:04 pm ]
Post subject: 

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.

Page 41 of 97 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/