8x16 and whatever else unreg wants to know
Moderator: Moderators
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 : ).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.
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.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
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.unregistered wrote:What is a 6502 simulator? I dont understand.
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.
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.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.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Wow THANK YOU so much tokumaru! I tried this codetokumaru wrote: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.unregistered wrote:What is a 6502 simulator? I dont understand.
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.
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
What is the problem with the rest of my code? Guess I have to read some instructions.
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.
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.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
tokumaru, THIS PROGRAM IS SO COOL! THANK YOU SO MUCH!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.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
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).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?
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.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.unregistered wrote: In nintendulator it pops up a small box that says "Bad opcode, CPU locked". So that is different...
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.