I won't hijack this thread I'll just mention that there have been some discoveries [thanks lidnariq, torrasque] regarding the poor performance on Linux. Having said that, the minimum system requirements are still pretty high yet.tepples wrote:NESICIDE for Linux runs at less than full speed on my machine and therefore also lacks sound
cpow is the developer of NESICIDE, an emulator containing such a debugger.
8x16 and whatever else unreg wants to know
Moderator: Moderators
- cpow
- NESICIDE developer
- Posts: 1097
- Joined: Mon Oct 13, 2008 7:55 pm
- Location: Minneapolis, MN
- Contact:
Re: Sound, debugger, free: pick two
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
How could I do that too? ...with FCEUX.tokumaru[color=green], on [url=http://nesdev.com/bbs/viewtopic.php?p=94670#94670]page 37[/url], [/color] wrote:Personally, I always use writes to $FF as breakpoint triggers, so all I have to do is "sta $ff" at the point I want to debug.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Kasumi, thank you! I'm really happy for the help, but im a little confused to... what do yall do next that helps you? I only know about pressing "Run" and nothing happens.Kasumi wrote: Put 00FF in the address box of the add breakpoint dialog, then check the "write" box.
In your code, add an sta $FF before the routine you want to check.
Last edited by unregistered on Thu Jun 07, 2012 9:55 am, edited 1 time in total.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Ah, thank you 3gengames! This is becoming awesome! ...I didn't know what the step into button did. Thank you so much Kasumi and 3gengames!3gengames wrote:You have to use the step into button to step 1 line of a code at a time. Pressing RUN will run the program until that break point is hit again, not allowing you to see anything that is wrong.
edit: Step Into rocks! It's so helpful! hahaha I used to make breakpoints that ran to $FFFF so the Run button would keep working. (<-- me looking silly)
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
ok in my code there is
and so there is another part where I would like to try something like
but there are many questions I have
1.)Does the +1 only work on one group stas or on both stas and ldas?
2.)Is (this)+1,y possible?
3.)Is (this+1),y possible?
ok, it fit all into 3 questions...
Code: Select all
lda rc_upleft
sta screenArray,x
lda rc_upright
sta screenArray+1,x
Code: Select all
lda (rhombusCollision_low+1), y
1.)Does the +1 only work on one group stas or on both stas and ldas?
2.)Is (this)+1,y possible?
3.)Is (this+1),y possible?
ok, it fit all into 3 questions...
screenArray is a label that represents an address. Labels allow you to not care about actual physical addresses, assembler takes care on it. +1 etc is added to the address that is calculated by assembler for a label. So you can use it anywhere you could use an actual address, and it works exactly the same as for an address.
Like, sta $4000+1 is the same as sta $4001; if label=$4000, sta label+1 will be the same as sta $4001.
Like, sta $4000+1 is the same as sta $4001; if label=$4000, sta label+1 will be the same as sta $4001.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Wow, Shiru, great explanation! I really understand the +1 etc thing now; thank you so much!Shiru wrote:screenArray is a label that represents an address. Labels allow you to not care about actual physical addresses, assembler takes care on it. +1 etc is added to the address that is calculated by assembler for a label. So you can use it anywhere you could use an actual address, and it works exactly the same as for an address.
Like, sta $4000+1 is the same as sta $4001; if label=$4000, sta label+1 will be the same as sta $4001.
just added
These will probably assemble, but they will not work like you think. LDA (this)+1, y will most likely become LDA this+1, y, and LDA (this+1), y will use half of your pointer along with the next byte and form an invalid pointer, causing you to access garbage data.unregistered wrote:2.)Is (this)+1,y possible?
3.)Is (this+1),y possible?
To do what you want you'll either have to use 2 pointers (one of them pointing one byte ahead of the other), or increment Y or the low byte of the pointer between the two accesses. Indirect addressing on the 6502 is not as flexible as you'd like.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Thank you though for being brave and explaning to me the truth about my second and third question. I just coded a solution yesterday thinking the other two questions weren't important. Thank you tokumaru!tokumaru wrote:These will probably assemble, but they will not work like you think. LDA (this)+1, y will most likely become LDA this+1, y, and LDA (this+1), y will use half of your pointer along with the next byte and form an invalid pointer, causing you to access garbage data.unregistered wrote:2.)Is (this)+1,y possible?
3.)Is (this+1),y possible?
Sorry, I dont understand this right now... but, maybe that'll be ok if one of the 2 ideas below becomes possible. If not, I'll swing back to learn this.tokumaru wrote:To do what you want you'll either have to use 2 pointers (one of them pointing one byte ahead of the other), or increment Y or the low byte of the pointer between the two accesses. Indirect addressing on the 6502 is not as flexible as you'd like.
3gengames, thank you for explaining this. I don't think I could use a set value though because I'd have to recalculate it every time I added a line of code before it. Maybe I'm wrong about that? I dont know.3gengames wrote:As long as This is a set value and not a RAM location, 2 will not work and 3 will. If This is a RAM value, neither will work as you just can't do that.
Really?! 4.)Is LDA (this+3, x) possible?tepples wrote:If you have an array of pointers on zero page, LDA (d,x) might be your best bet.
Yes, as long as This is a ROM location that doesn't change (when compiled, not over the projects whole creation) then that would work. But, the thing you're missing is if you have a lot of pointers in zero page, then you need to just do the begging of the array+X to point to one, because that's what it does. If you have 3 pointers in an array, you can select any of the three by putting in the code LDA (ZeroPageArray,X) because it takes the array location, adds X to the pointer of it, then gets wherever THAT points to. If I could make something up in paint I would, but I'm too slow and my graduation party is begging in 2 hours. Think of it as a normal array (LDA Array,X) then then whatever that points to, it then looks at it. Remember, each pointer is 2 bytes so moving 1 byte ahead in the array will mean you have to either do a INX INX or a ASL A if you do a TAX to get X to something you need.unregistered wrote:Really?! 4.)Is LDA (this+3, x) possible?tepples wrote:If you have an array of pointers on zero page, LDA (d,x) might be your best bet.
It is, but again, I don't think it will do what you want. The ($XX), y addressing mode is meant for accessing an array through a pointer, while ($XX, x) is meant for using arrays of pointers. In the first case, the index register (Y) indexes the targeted data, in the second case, the index register (X) indexes a pointer in an array of pointers.unregistered wrote:Is LDA (this+3, x) possible?
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.
The +offset trick works with absolute addressing because the assembler calculates the absolute address for you based on the offsets you give it. With indirect addressing it's different, because it's not the assembler that will calculate the final address of the data, it's the CPU that will do it as the program runs. For this reason, if you try to use offsets they will not affect the final address, but rather the address of the pointer. I'm pretty sure that this is not what you want.
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.