Today's assembly mistakes

[Turtle_Quality]

1)

PUSH HL before a loop

POP HL within the loop

2)

Having too similar labels, Drop_Loop and Drop_Loops, one storage the other is a code label. Then I wonder who keeps updating my code while it's running

3) Use of LD(IY),0 , or LD (HL),0 ... not seeing that it's going to blank 2 bytes instead of one. The answer is obviously to load (HL) with some spare register set to zero, when obviously I don't have any spare registers

[Ast A. Moore]

Use of LD(IY),0 , or LD (HL),0 ... not seeing that it's going to blank 2 bytes instead of one.

Not sure what you mean here exactly. This will write 0 to the memory address pointed to by HL. Just one byte.

[Turtle_Quality]

You're right thanks, that was another wild goose chase. Found what was causing the nasty data and crashes now, HL expected to point to a label at the start of a long loop, and wasn't getting pointed there before I looped back.

Now I can write some more code and cause more crashes.

[Ast A. Moore]

Of all the bugs, I find those related to the stack to be the most pernicious and difficult to track down.

[cmal]

A common mistake I make is to forget to save and restore the IY register before returning to BASIC. Similar to forgetting to re-enabling interrupts.

Another one: getting the bit position wrong. E.g. Bit 7,A instead of Bit 0,A. I always have to remind myself about this.

[Turtle_Quality]

A common mistake I make is to forget to save and restore the IY register before returning to BASIC. Similar to forgetting to re-enabling interrupts.

Another one: getting the bit position wrong. E.g. Bit 7,A instead of Bit 0,A. I always have to remind myself about this.

With this program any return to Basic is a sign something went seriously wrong, but I did forget yesterday to LD IY,0x5c3a before calling the Rom print routine, and that produces interesting crashes. I think I managed a pretty comprehensive list of assembly errors yesterday

[Morkin]

Of all the bugs, I find those related to the stack to be the most pernicious and difficult to track down.

Definitely..! Possibly the hardest bug I've had is when I'd been playtesting a game and it'd would randomly crash after about 10-15 minutes. Not when I'd done anything particular, in any place, or at any time. Just playing the game.

Spent forever digging around in just about every game routine, looking for a possible un-PUSHed POP (or vice versa). Nothing in life nowadays beats the elation I felt when I found it

[Ast A. Moore]

Nothing in life nowadays beats the elation I felt when I found it

Amen to that!

[Mpk]

I lost an hour or so to this recently :

PUSH HL
PUSH DE
...stuff
POP HL
POP DE



Also, finding out that Zeus is fine with LD DE,HL when it really shouldn't be, and having to go back and replace each occurrence with 2 lines to get pasmo to compile.

[Ast A. Moore]

Also, finding out that Zeus is fine with LD DE,HL when it really shouldn't be, and having to go back and replace each occurrence with 2 lines to get pasmo to compile.

Yes, many assemblers are fine with this shorthand. I don’t particularly approve of it, because it leads to lazy coding, but many people like it because it saves them a few keystrokes.

[Turtle_Quality]

That one makes more sense to me with an index register... LD DE,(IX+2) ... because it can specify that E will be loaded from +2 and D from +3 and there's no further impact

When the assembler "takes care of" LD DE,HL for you, it's hiding an increment of HL, changes of flags, don't know if they DEC HL afterwards.

[Einar Saukas]

When the assembler "takes care of" LD DE,HL for you, it's hiding an increment of HL, changes of flags, don't know if they DEC HL afterwards.

"LD DE,HL" is just a common abbreviation for "LD D,H / LD E,L".

[Turtle_Quality]

I was seeing imaginary brackets, might explain my recent coding issues

Zeus does actually accept LD HL,(IX+d) (providing d<127) - Simon Brattel pointed that out to me about a month ago when I was trying to make an assembler function for index displacements.

I don't have a problem with LD HL,BC as it's the same as typing LD H,B ; LD L,C , it's tidier in the source but you should know that it's a pseudo-op

It would be nice if the highlighter could highlight that it's a pseudo-op but I think that would be quite tricky to implement.

[Mpk]

I only built mine in Pasmo because I couldn't figure out how to export a .tzx from Zeus.

It does seem to make sense to compile in different compilers though, and to test periodically in different emulators. I'd hate to get to the end of a project to find out that it misbehaves on real hardware or something. And so, I'll try and avoid deceptively handy shortcuts.

[Bubu]

Today I've been almost an hour tryng to figure out why my program doesn't work, I only have to do a comparison... and finally the mistake was de Carry flag:

Code: Select all

ld l, 250
cp l
jp nc, geater

I wanted the program to jump to "greater" label if a > 250. But obviously, it's "jp c", and not "jp nc" as I did.
This mistake, the carry flag's control when comparing, ussually gives me some headaches...

[Einar Saukas]

Code: Select all

ld l, 250
cp l
jp nc, geater

I wanted the program to jump to "greater" label if a > 250. But obviously, it's "jp c", and not "jp nc" as I did.

Obviously not

Using "jp c" will jump if a<250, and "jp nc" will jump if a>=250.

[Alcoholics Anonymous]

I only built mine in Pasmo because I couldn't figure out how to export a .tzx from Zeus.

Surely tap is sufficient? tzx is an audio format for storing tape noises (and suitable for tape preservation purposes) whereas tap stores the actual data you are saving which is what programmers want. Unless you're trying to put in speedloaders or some protection scheme that mangles the normal tape loading process.

By going tzx you are making it harder to load on real spectrums because an awful lot of real users are using devices like the divmmc which supports tap and not tzx. Users less commonly have things like the tzxduino which can turn the tzx into audio that you can load as if from a tape deck but you are going to suffer through loading times when the purpose of things like the divmmc is to allow instant loading.

It does seem to make sense to compile in different compilers though, and to test periodically in different emulators.

I hate the the shorthand macros with passion It completely disrupts how I read code; standard z80 I know how many bytes every instruction takes and how fast every instruction is at a glance. I can quickly imagine and evaluate alternative instructions. When people start using pseudo-instructions, it disrupts the thinking because you have to pause to figure out what the actual instructions really are and unwind them in your mind to know how long they take. Stuff like "LD HL,BC" is pretty clear about what is going on but sjasm, eg, is notorious for having allowed this sort of thing to the extreme. I have seen source code that I can't even read without expanding the pseudo-instructions in full and some of them I had to go into documentation to know what the proper equivalent was because there would be more than one way to do it. Some of these pseudo-instructions can also lead to bugs because they can end up accepting what looks like an illegal z80 opcode that gets turned into something a little bit different. So a person reading the code thinks they have a standard z80 opcode and wonder why the program doesn't work. Anyway, rant over.

[Mpk]

Surely tap is sufficient?

I couldn't figure that out either.

I hate the the shorthand macros with passion

Yeah, agreed. Makes learning anything much harder if code appears tied to a particular emulator.