Hey everybody,

On Kerm's advice, I decided to post a thread here where I can ask this very knowledgeable community a few random questions about z80. I hope I'm not being rude...

well, anyways, I'm trying to debug this particular snippet of code, and it seems that I can't jump exactly where I want to, when I want to:

Code:


I've stepped through this loop several times with wabbitemu and even if the hl register is 0 after the dec hl instruction, the
jr nz, while still jumps to the while label, even though the zero flag should clearly be set. Is the zero flag not triggered by 16 bit registers?

(this snippet should print 3 u's on the far right side of the screen)

Thanks for any help =)

If you take a gander at the most excellent Z80 Family CPU User Manual, a document that BenRyves frequently nags me to use as a reference and which I have finally ceded on, you'll see that 16-bit decrements don't affect the condition flags. You'll need to add:


Code:


To set/reset the zero flag based on whether hl is zero or not. Of course, make sure it's not clobbering a where you might need it.

I don't think the zero flag is affected by 16bit Inc/dec, you can verify this in WabbitEmu's debugger.
Meh, ninja'd.

Thank you for the information, kind sirs =) In the 28 days tut McLaughlin never really specified whether or not the 16-bit registers affect the flags.

Kerm: where can I find the z80 family cpu user manual online?

souvik1997: ninja'd you may have been, I still appreciate your help =)

The manual can be found here: http://www.zilog.com/docs/z80/um0080.pdf

awesome! thank you!!

While we're discussing that little snippet of code in your first post, I recommend that rather than magic numbers (such as AppBackUpScreen+5) you use named defines. For example, from my latest z80 project, Sandpaper:


Code:

Great advice Kerm. The only reason I'm not is because I usually only work with 4 or 5 variables in one program because my beginning programs are so tiny, but that's not a good excuse at all. Just because I'm making small programs doesn't mean that I can have poor programming practices.

You anticipated my objection perfectly and answered it yourself; I continue to be impressed. That's exactly right: the sooner you start setting good programming practices, no matter how trivial the program, the more likely you'll be to succeed in keeping your bigger projects sane and organized.

If your code does this to some effect:

Code:

Then the character you try to display will sometimes display one character space above where it is supposed to. Why? Is it because _PutC automatically increments (CurCol) and (CurRow) after it writes the character?? Is there any way to prevent this?

No, it's something more sinister. Because you're writing at the last row and column of the display, then the row and column are incremented, the calculator should decide that you've filled up the entire screen, and in many cases will decide to scroll up by one line so that you have the bottom row free to use again. Luckily, there's a flag you can twiddle to control that (but remember to change it back afterwards). The TI-83+ SDK PDF (page 24/188) says:


Code:
Therefore, you could do...


Code:

wabbitemu question about breakpoints. (Not sure if this is the right board. Feel free to move it if need be)

I'm trying to debug a program in wabbitemu, and I was under the impression that the

Code:

at the beginning of each program caused the program to be loaded into memory at the address $9d95 when it is executed.
Understandably, before the program is executed, the memory address $9d95 is filled with nops (I think I know why this is, but can someone explain?), so I just stick a breakpoint at the address $9d95 (and sometimes at the next 2 instructions just to be safe), thinking that the program will be loaded into memory at $9d95 and as soon as it starts executing, it will encounter the breakpoint, however, the breakpoints are totally ignored.
IS this an issue with wabbitemu, or am I wrong about where the program is loaded into memory at execution time?

I'm assuming that you're running your ASM programs from Doors CS in this case. If so, you should know that it (and similar shells) (and the TI-OS) all start executing programs at $9D95. However, I've found that Wabbitemu gets unhappy if you set a breakpoint at a particular address and the breakpoint gets passed with a different instruction at that address. You could try PindurTI, and I would also post a bug report in the WabbitEmu thread here on Cemetech to see if Buckeye has any ideas.

I am not using a shell. Like I said, I like reinventing the wheel. Before I use a shell in my asm adventures, I want to understand the inner workings of most of the shell's routines. Gives me more practice and makes me more knowledgeable.
That's beside the point however, because, of course, I'm using ti-os, so it all ends up at $9D95 anyways


sooo... could I just jenk it up and write the first instruction of my source code directly into the ram at $9D95 before setting a breakpoint?
e.g., the first instruction of my source code is:

Code:

so could I just use wabbit's memory editor to put
$211F00
at $9D95, thus making the instructions there the same as my code before I run the program, and set the breakpoint and then run the program? That way, the breakpoint gets passed with the same instruction at the same address.

EDIT: This method actually works (albeit with a success rate of about 50%). It's just a pain to look up the opcodes and wabbitemu randomly decides whether to crash or not. Sometimes it does, sometimes it doesn't. Looking for patterns as to when it crashes and when it doesn't.


I've tried almost every emulator out there, and wabbit was the only one that worked on my computer. Pindurti just showed up as a blue box. Am I doing something wrong?

You need to drag and drop the ROM image into the blue box before it will show up with anything.

Thanks a million, Iambian. It would be nice if the blue box had a "drag and drop ram here" watermark or something

[quote="Rascherite"]I've tried almost every emulator out there, and wabbit was the only one that worked on my computer. Pindurti just showed up as a blue box. Am I doing something wrong?] Well, it's actually four separate calculators. Just drag a ROM image from your calculator onto one of the four screens and it should start. Left-clicking on one of the four turns it on.

any type of skin for pindurti?

As far as I know, PindurTI relies exclusively on the keyboard to control the calculator. I could be wrong, though. This contains the PC key to calculator key mappings for your perusal.

can't say that I really fancy pindurti, I know this is a really noobish way of looking at it, but wabbit's fuller gui controls in the debugger make the learning curve shorter. How can I run the debugger while at the same time running the calculator? each time I open the debugger, the calc stops.

and thanks for the table, sovik.