04-01-2011, 05:12 AM
britlion Wrote:That should be defs 6912,0 I think. My error.I did defs 6912,65 and the Byte header was 28000, 12990 so it did fix the
You might want to do something like defs 6912, 128 just so you can see the code block for the buffer differently to empty ram.
I compiled this and I saw
initialize
gap of zeroes
buffer starting at 32768
E markers
A markers
B markers
C markers
Hmm. Not what I expected at all. I have to concur with your analysis. Darn. I had hopes for that method. I have no idea why the compiler would do that.
length problem. I saw the same thing through the debugger. I had a
larger program once with a lot of text in it and the compiled text was
all out of order even if it was within the same section of code, but it did not
use subs. I have no idea....
britlion Wrote:For:Then after that it does LD E, (HL) or was it LD (HL), E? I don't remember.
Asm
ld e, (16384)
End asm
Yes, that looks like a bug in the assembler in accepting that. Looks like it does a LD E,0 instruction there.
I think it was the latter. This passed through the assembler in the compiler
and through zbasm, double bug or the same bug that needs to be corrected
in two places.
Low strictly speaking would be below the ORG address or if I were to use
a new term, Start.Prog address. But that could be changed with a compiler
directive if a buffer has to go in between. The compiler would use Start.Prog
and the ASM part would use ORG.
The directive would let the beginning (or end for it goes bakwards towards
the 24 KiB limit) be a fixed number for a program.