You can click the "Run" button to continue running the calculator while you're in the debugger. While it's running, you can't use the disassembler, but you can still view and edit the contents of the memory and registers.

You mean in the pindurti debugger? There is no run button I can see in the pundurti debugger. Am I blind? Help meh out.[/quote]

Ok, debugger questions aside (I'm starting to understand pindurti), on every debugger I see, I see a few odd registers I don't know.
what are bc', hl', etc...?

[/quote]
Oh, I thought you meant the WabbitEmu debugger. Regarding your second post (please don't double post), bc', hl', and the other registers like those are shadow registers, which are mainly used by interrupts.

Please indeed don't double-post. Actually, they're mostly used by the TI-OS interrupt; according to Benryves, that's very shortsighted of TI. They're alternative registers just like af, bc, de, hl, etc, and when you use the exx \ ex af',af command, the shadow registers and the normal registers have their contents swapped.

How exactly are they used by the interrupts? Can you explain it really quickly?

Basically, interrupts fire asynchronously, which means that the main code that's running on the calculator at any one time, such as your program, does not get any notification that the interrupt is about to run (unless you disable interrupts with di). Therefore, if the interrupt rampages over the registers, when your program continues running after the interrupt runs, it will probably promptly crash because the registers all got messed up. To solve this, the first thing many interrupts do is swap the registers with the shadow registers, which "saves" the value of the normal registers in the shadows. The last thing the interrupt does before ending and returning control to the normal code is swapping the registers back, restoring the values from the shadow registers.

Basically, TIOS swaps the registers during interrupt execution so that registers used by the currently running programs or the general operating system aren't changed during the interruption.

Thanks for the explainations, guys =)
I need to ask here about interrupts sooner or later, the tut I'm using doesn't cover them too well... but I'm not ready to ask yet. Still getting the hang of graphics.

Speaking of which....
let's say you just want to move 1 pixel. Do you need to b_call(_GrBufCpy) and copy the ENTIRE graph buffer JUST to change that ONE LITTLE PIXEL?! Is there any faster way to do it, or is that just how lcd interactions are handled?

You could possibly just rampage through the LCD's internal RAM manually to the byte that holds that pixel, but really, if you use something like the iFastcopy that comes with DCS, it's fast enough you don't really have to worry (plus, working directly with the LCD's internal ram can sometimes be rather slow and painful)

You can directly interact with the LCD to do what you want to do, but I think you'll find that it's a very rare instance where you don't want to change or move a whole bunch of different pieces of a buffer before re-copying it to the screen. The single-pixel or single-sprite case is so rare that there aren't generally-accepted routines to do such manipulation. I know you continue to want to re-invent the wheel, and I keep trying to force you into using a shell, but I should point out that _grbufcpy_V is roughly 4-9 times slower than Doors CS's iFastCopy routine, depending on what calculator and hardware you're using.

I never really thought about the fact that you'll rarely want to move only one pixel or one sprite. I do have a bit of experience with standard LCD's, but I'm not ready to dive into their memory in asm just yet, so for now I'll just use the b_call
How does one go about writing a routine like your iFastcopy? Is it as straightforward as it sounds? Just find the ports connected to the lcd's pins and set them as needed?
mind you, straightforward is not a synonym for easy

Actually, once you know how to work with ports $06 and $07 ($06 being the LCD command port that does all the magic, and $07 simply being the data input/output for the currently pointed to byte of LCD RAM), it isn't really that complex. Making it fast and reliable is a bit harder, but even still, it's not nearly as hard as interrupts, I assure you

I believe you mean Port 10h and Port 11h. Port 06h and 07h deal with mapping Flash pages into memory banks.

Ah yes silly me. I can't believe I just made that mistake :<

Thanks souvik and ashbad! are the ports 8 bits each? (I'm guessing yes)

basically, what you're telling me is I just have to

1)move first bit of graph buffer to the 10h port
2)toggle the lcd's clock with the 11h port (and whatever other lcd pins you might have to toggle)
3)if end of graph buffer not reached
4)goto 1
5)????
6)profit

Basically more like this:

1. Set the correct row for starting sending data into $10
2. loop for 12 bytes:
2a. Send the data at the current correlated graph buffer location into $11
3. Increment (or decrement, depending on the movement mode set into $10) the row by one
4. Repeat 2-4 64 times
5. gain interest on your profit

Depending on the device you're running on, you also need to check a certain port's status before sending the next chunk, otherwise you'll get tearing and corruption on the displays that have the glitchy driver.

The process seems pretty cut and dry, so how exactly do you make it FASTER? Just find instructions that are more compact and have shorter opcodes?

EDIT: I'm rephrasing about 90% of this post into one (kinda-simple) question.
how does the LCD command port work?
or, more simply, what does each bit in $10 do?

lol now I'm editing it a second time.
Kerm: what port do I have to check and why? what hardware do I have to check it on?

I suggest taking a look at the SDK documentation, specifically the "TI-83 Plus Developer Guide". Under "TI-83 Plus Specific Information" is a section Drivers > Display > Writing Directly to the Display Driver which has plenty of good information.