Common Mistakes and Good techniques

[Galandros]

[simplethinker]

Here's one that I use. It's basically the tab file with T-states and slightly clearer argument explanations. The right-most column is the number of T-states.
[attachment=2618:tab.txt]

[Galandros]

Before I forget, writing down notes here:

Initial errors and debug:
This things can freeze a calculator (it does "nothing")
- loop forever (most times caused by the counter that is destroyed in some routine)
- code execution gets out of your program area and enter into data or RAM page not to execution. (eg. in a apps I let the pc go behind the $8000 and so enters in a RAM page which has code execution protection, all because I forget a ret in a subroutine)

Also I saw a nifty debug macro for spasm (I don't know about tasm)
.echo > breakpoints.brk "\n"
#define break() .echo >> breakpoints.brk $
To use just write break() and you find the pc to toggle the breakpoints in emulator. Easier than searching yourself the code in the debugger.


Instead of seeing register in every breakpoint, a group of defines output some registers content to a log/buffer in safe ram. This won't work if the code crashes very hard. But when doing freaking math, investigating some routine output or other task that doesn't crash that hard, can be semi-useful. (breakpoints also do the job)
Would worth to anyone this asset of routines to easily output to a safe ram some registers? They will all preserve registers.
Its use would be like:
init_log() ;initialize saferam by putting a zero on the first byte. That byte says how many 8-bit registers are in the log
;code
log_de() ;de will be put into a safe ram and preserves all registers
;some more code
log_a() ;ouput a this time
;etc..
I can do this if there is interest.

[Mapar007]

Man, I feel I should really try Spasm 2...

Which emulator do you use?

[Galandros]

[magicdanw]

I love PindurTI's debugger. I hope Wabbitemu gets at least all of the features that PTI has, if it plans on becoming a good tool for development and hackery

[DigiTan]

I know it's been said before, but I've been doing a ton of accidental ld a,(6)'s instead of in a,(6)'s. Even when you know it's wrong, those are tough to avoid!

[Galandros]

[Mapar007]

Z80 is definitely my favorite language... I LOOVE the direct hardware control. It is so concrete, which, of course, has its advantages and disadvantages.

[simplethinker]

There's another error in ASM in 28 days that I don't think has been posted here. The getpixel routine in day 24:

[calc84maniac]

[hotdog1234]

I don't know if this one has been mentioned, but constants and labels cannot start with a number

[Mapar007]

Actually, that depends on your assembler, but yeah... At least, it's bad style.

[Galandros]

You should bug me to update this...

I have things to add and modify. :biggrin:

[jammasterz]

I have a few tips that ive come up with.

Good programming habbits:

1. Start by writing helping routines like displaying, keychecking and so on, and then use them in your code.

2. Do not optimize your code when its not done. Even though you know that XOR A is fatser than LD A, 0, use the other one, to avoid bugs and then when its fully tested- optimize it step by step.

3. If youre saving something to a specific memory location, try not using magical-variables. For example if you check some value at some address few hundread times in your code, and then you decided to change the adress, you have to change the code in few hundread places. Also it is very probable that you will make a typing mistake. Thats why i recommend using equates for adresses, for example variable .equ $9875

4. Even if you think its silly, do it. When you execute RET insturction, the calculator will jump to the adress that is on top of the stack. If you push something onto it, and forget to pop the calculator will most likely crash. I know its easy to count the amount of pushes and pops, but its not allways this easy. What i want you to be careful about is jumps within a routine. If you for example push something onto the stack in the beggining of the routine and the pop at the end there is no problem. But it may happen that you put a JP or JR instruction between PUSH and POP, which will cause the calculator to SKIP the POP instruction if a jump has occured. This is really important, and currently most difficult bug to find.

I think everything else has been mentioned.

Easy debugging method

There is a very easy method to debug with, it may had been mentioned but ill explain anyway.
If your program crashes do like this:
1. Remember exactly what youve done.
2. Then look at the code and simulate what happens in your head.

Its definitely much harder if you used someones routines because you dont know what is happening inside them. Try reading routine documentation.

When simulating its allways good to keep track of the stack on a piece of paper.