It is currently Wed Nov 22, 2017 2:26 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1386 posts ]  Go to page Previous  1 ... 38, 39, 40, 41, 42, 43, 44 ... 93  Next
Author Message
 Post subject:
PostPosted: Sat Jun 09, 2012 12:07 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 09, 2012 2:24 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
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.

Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 09, 2012 3:04 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
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).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 09, 2012 4:56 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
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. :?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jun 10, 2012 12:25 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jun 10, 2012 3:50 am 
Offline
User avatar

Joined: Tue Jul 03, 2007 1:49 pm
Posts: 969
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jun 10, 2012 4:10 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jun 10, 2012 5:36 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
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. :?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jun 10, 2012 6:33 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jun 10, 2012 6:52 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
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!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 13, 2012 1:19 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 803
Location: cypress, texas
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... :?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 13, 2012 1:55 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 13, 2012 3:06 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1035
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 13, 2012 3:08 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3950
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!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 13, 2012 10:04 pm 
Offline

Joined: Sun Apr 22, 2007 6:07 am
Posts: 101
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1386 posts ]  Go to page Previous  1 ... 38, 39, 40, 41, 42, 43, 44 ... 93  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group