Replacing ld cb,6143 with ld bc,6143 and reassembling now produces no errors whatsoever......despite the invalid ORG, misuse of A register and mistyped ldir.
Do you get any error messages for these three lines on your PASMO setup?
Interesting! I tried assembling your program (in both pasmo 0.5.4beta2 and 0.5.3) and got exactly the same results as you. Looks like you've found a bug or two there.
EDIT: Or pehaps not as that all seems to be intended behaviour. 16/8 bit references are assembled modulo 65536/256 - although I think it should at least emit a warning for this case. The "ldri" issue is not a bug, sincle pasmo allows you to have white space before labels. So what your program does is create an unreferenced label name "ldri". You can see this if you using the "-d" debug command line switch.
EDIT: Or pehaps not as that all seems to be intended behaviour.
With all due respect to the author of PASMO I would rather have ambiguous numerical errors flagged as such rather than the assembler make assumptions about modulo values. Can you just imagine the carnage in a program if you mistyped a RET as RED, assembled it and were told you had no errors. And the fun you'd then have debugging it!
I ran the same program through SjASMPlus (though I suspect other Z80 cross assemblers would do just as well). It stopped dead at the illegal Org refusing to go any further and when I fixed it flagged all the other errors:
A
Pass 1 complete (0 errors)
a.txt(2): error: Bytes lost
a.txt(5): error: Illegal instruction: ld cb,6143
a.txt(7): error: Unrecognized instruction: ldri
A
Pass 2 complete (3 errors)
Can you just imagine the carnage in a program if you mistyped a RET as RED, assembled it and were told you had no errors. And the fun you'd then have debugging it!
Yes I can. I don't know if there's a way to turn this behaviour off in pasmo (i.e. a switch to not permit linear whitespace before labels). I hope there is and I just haven't found it...
Well, all I can say is: either those typos are rather artificial, or I'm a much better typist than I realised, because I've been using Pasmo since 2004 and don't remember ever being stung by anything like that :-) (I wasn't even aware that it allowed whitespace before labels, and presumably I would have learned that the hard way if it had ever caused me problems...)
(Also, looking through those old emails from 2004, it looks like one of my bug reports may have indirectly prompted the 'mod 65536' behaviour... originally it didn't accept things like
free_space equ 65536 - $
so perhaps there's something odd going on in the expression evaluator which means that it can't validate numbers without validating intermediate values too...)
Well, all I can say is: either those typos are rather artificial, or I'm a much better typist than I realised, because I've been using Pasmo since 2004 and don't remember ever being stung by anything like that :-) (I wasn't even aware that it allowed whitespace before labels, and presumably I would have learned that the hard way if it had ever caused me problems...)
Same for me - it's never been an issue (not that I've written a huge amount of stuff with pasmo). But now I know that it'll happily assemble code like that without emitting any errors or warnings, I must admit it doesn't sit very easily at all.
Blimey, been away a few hours and quite a number of posts to read through and digest - lots of interesting stuff, thanks very much.
My none spectrum code is working well now and reaching the point where I need to start with the spectrum side soon, will let you all know how I get on.
BTW if anyone is particularly experienced with TZX 1.2 file format I'd like to speak with you as this is one part of my code that I'm having some trouble with a particular part of the TZX format but other than that all good.
Comments
EDIT: Or pehaps not as that all seems to be intended behaviour. 16/8 bit references are assembled modulo 65536/256 - although I think it should at least emit a warning for this case. The "ldri" issue is not a bug, sincle pasmo allows you to have white space before labels. So what your program does is create an unreferenced label name "ldri". You can see this if you using the "-d" debug command line switch.
With all due respect to the author of PASMO I would rather have ambiguous numerical errors flagged as such rather than the assembler make assumptions about modulo values. Can you just imagine the carnage in a program if you mistyped a RET as RED, assembled it and were told you had no errors. And the fun you'd then have debugging it!
I ran the same program through SjASMPlus (though I suspect other Z80 cross assemblers would do just as well). It stopped dead at the illegal Org refusing to go any further and when I fixed it flagged all the other errors: I thin I'll pass on PASMO.
(Also, looking through those old emails from 2004, it looks like one of my bug reports may have indirectly prompted the 'mod 65536' behaviour... originally it didn't accept things like so perhaps there's something odd going on in the expression evaluator which means that it can't validate numbers without validating intermediate values too...)
My none spectrum code is working well now and reaching the point where I need to start with the spectrum side soon, will let you all know how I get on.
BTW if anyone is particularly experienced with TZX 1.2 file format I'd like to speak with you as this is one part of my code that I'm having some trouble with a particular part of the TZX format but other than that all good.
Rich