sna2skool.py produces invalid Skool file for two-character operands

[morozov]

➜ sna2skool.py --version
SkoolKit 9.6

There is an issue with sna2skool.py with regard to processing character values.

I'm disassembling code from a *.sna file. The assembly equivalent of this code is:

LD HL,$3030

The meaning of this code is loading two zero characters into to H and L, so I'm annotating it as follows in the control file:

@ $5D78 isub=LD HL,"00"

sna2skool.py renders it as follows (incorrectly):

@isub=LD HL,"00"
 $5D78 LD HL,"0"

Then, in my build pipeline, skool2bin.py produces incorrect bytes instead of failing:

-21 30 30
+21 30 00

As a result, my seemingly valid @isub annotation makes Skoolkit quetly produce an invalid binary.

For reference Pasmo also allows one-character calue for a 2-byte operand, so this is probably correct:

➜ echo 'LD HL,"0"' | pasmo - - | xxd
00000000: 2130 00                                  !0.

I expect that the Skool file will look something like:

 $5D78 LD HL,"00"

[skoolkid]

SkoolKit doesn't support using 2-character strings as 16-bit operands, so it's no surprise you're having some trouble with this.

That said, I'm trying to figure out if there is a bug here. When I run LD HL,"00" through skool2bin.py I get something like this:

ERROR: Failed to assemble:
 23928 LD HL,"00"

But for you it gives no error, and produces the same output as it would for LD HL,"0"?

[Threetwosevensixseven]

I would question the entire concept of two character strings for 16 bit operands. Which assemblers support this?

There is an implicit convention that strings are processed or assembled into memory left-to-right, but Z80 is little-endian (right-to-left). Seems like this would cause much more confusion than it eliminates. If you must do it, LD HL, '0'|('0'<<8) or LD HL, '0'+'0'*256 seems less ambiguous.

[morozov]

That said, I'm trying to figure out if there is a bug here. When I run LD HL,"00" through skool2bin.py I get something like this:

ERROR: Failed to assemble:
 23928 LD HL,"00"

It may be a two-phase bug. On one of the steps of my build process, sna2skool.py produces the invalid LD HL,"0" (not LD HL,"00"):

sna2skool.py renders it as follows (incorrectly):

@isub=LD HL,"00"
 $5D78 LD HL,"0"

On a subsequent step, skool2bin.py doesn't error on LD HL,"00", it happily assembles LD HL,"0".

[morozov]

Which assemblers support this?

Pasmo does:

➜ echo 'LD HL,"00"' | pasmo - - | xxd
00000000: 2130 30                                  !00

[Threetwosevensixseven]

Pasmo does:

Which version? I get ERROR: Invalid literal, length 1 required in 0.5.4. Which is actually better validation that it usually does. I often get silent MOD 256 or MOD 65536 behaviour from it.

[morozov]

➜ pasmo --version
Pasmo 0.6.0.20070113.0
Copyright (C) 2004-2006 Julian Albo
...

➜ echo 'LD HL,"AB"' | pasmo - - | xxd
00000000: 2142 41                                  !BA

[skoolkid]

OK, I think sna2skool.py producing LD HL,"0" from 213030 is a bug. It should either produce an error, or just render the operand as a number instead of a character.

Can you show the skool2bin.py command line you're using that doesn't error out on LD HL,"00"?

[Threetwosevensixseven]

Pasmo 0.6.0.20070113.0

Thanks. I didn't bother too much with that version. It's 15 years older than the latest version, and the one time I tried it, it had regressions over the 0.5x code. Make sense he would have changed the validation if he rewrote the parser, though.

[morozov]

The exact command line I'm using is:

$(Z80_FIXED): $(SKOOL)
	skool2bin.py --ofix $< - | bin2sna.py --border 0 --org $(ORG) --start $(PC) --stack $(SP) - $@

The corresponding fragment of the Skool file is (note the discrepancy):

@isub=LD HL,"00"
 $5D78 LD HL,"0"     ; {Initialize all player scores to zero.

The corresponding control file that generated this Skool file is:

@ $5D78 isub=LD HL,"00"
M $5D78,18 Initialize all player scores to zero.

[skoolkid]

I think skool2bin.py is behaving as expected. Without the --isub option, it ignores @isub directives and so doesn't see the LD HL,"00" substitution.

Can you try adding the --isub option and see if it gives an error?

[morozov]

I didn't bother too much with that version. It's 15 years older than the latest version

Hm... I didn't realize that version 0.6.0-preview (2007) is older than 0.5.5 (2022).

[morozov]

I think skool2bin.py is behaving as expected. Without the --isub option, it ignores @isub directives and so doesn't see the LD HL,"00" substitution.

Can you try adding the --isub option and see if it gives an error?

It does:

ERROR: Failed to assemble:
 23762 LD HL,"00"