Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Wrong PEEKed value from @label (*solved*)
#1
I have a label beetwen to pieces of machine code data:

Code:
asm
    defb 12,8 ; width and heigth (in characters)
end asm

galeon02Charset:

asm
    defb 0,0,0,0,0,0 ; many graphic data
end asm

I tried to access the first two bytes (before the label) from BASIC, PEEKing the label address plus an offset, but I got strange results. In order to find out the problem, I wrote the following:

Code:
    cls
    dim gal as uinteger
    let gal = @galeon02Charset
    print gal ' prints 36716, OK!
    print gal-2,peek(gal-2) ' prints 36714 and 12, OK!
    print gal-1,peek(gal-1) ' prints 36715 and 8, OK!

    print @galeon02Charset ' prints 36716, OK!
    print @galeon02Charset-2,peek(@galeon02Charset-2) ' prints 36714, 106 !!!
    print @galeon02Charset-1,peek(@galeon02Charset-1) ' prints 36715, 107 !!!

    print @galeon02Charset-2,peek(ubyte,@galeon02Charset-2) ' prints 36714, 106 !!!
    print @galeon02Charset-1,peek(ubyte,@galeon02Charset-1) ' prints 36715, 107 !!!

    print @galeon02Charset-2,peek((@galeon02Charset)-2) ' prints 36714, 106 !!!
    print @galeon02Charset-1,peek((@galeon02Charset)-1) ' prints 36715, 107 !!!

I don't understand why the address of the label is printed with PRINT but returns a wrong value with PEEK. Any issue about the type? But the address of a label is supposed to be uinteger, isn't it?

I don't understand why PEEK works with the uinteger variable, initialized to @label, but doesn't work directly with @label.

Is this a bug or am I missing something?
Reply
#2
It's a bug. I got the same thing. (though at different addresses)

I think the new label-offset code that Boriel put in isn't quite working correctly.

Looking at the asm:
Code:
print peek(gal-2)

Turns into:

ld hl, (_gal)
    dec hl
    dec hl
    ld b, h
    ld c, l
    ld a, (bc)
    call __PRINTU8
Which does indeed get the byte from gal-2 (albeit in a very strange fashion - what's wrong with ld a,(hl) instead of copying hl to bc ?)

Code:
print peek(@galeon02Charset-2)

Looks like it seems to turn into:

ld a, __LABEL__galeon02Charset - 2
call __PRINTU8

So you get the return value of 8 bits of the ADDRESS of galeon02Charset-2 not the value at this address. Your address was 36714 - which in HEX terms is 8F6A - and you are getting the 6A part (106 in decimal) returned to you.

Also, you may possibly get an extra opcode stuck in - because LD A,N only requires 2 bytes (62,N) and I'm thinking the assembler might be dropping LD A,NN in - which means the second "N" would be read as an instruction. This could quite easily crash if it was. I'm not sure looking at the disassembly though - it does look as though it isn't doing this - the LD,CALL,CALL structure seems intact.

I think it should be:
Code:
ld a, ( __LABEL__galeon02Charset - 2 )
Reply
#3
britlion Wrote:It's a bug. I got the same thing. (though at different addresses)

It was too strange to be a "feature", indeed. Next time I'll compare the resulting assembler codes as you did. It's the definitive way to see what's really happening. Thank you

Boriel, may you move this thread into the "non-features sub-forum"? Wink
Reply
#4
britlion Wrote:So you get the return value of 8 bits of the ADDRESS of galeon02Charset-2 not the value at this address. Your address was 36714 - which in HEX terms is 8F6A - and you are getting the 6A part (106 in decimal) returned to you.
If that is true, this is definitely a bug. So this topic is moved to Bug folder (I'm currently a bit busy 'till June 30, so fixing this might take time).
Reply
#5
Sorry to hear life got busy! But it's all good - there's a temporary workaround anyway (put it in a variable).

I hope, when you do find the time, that my investigation makes it easier to fix!
Reply
#6
Well, the bug has been fixed (it was quite easy to fix, in fact). The problem was I fixed it for Peek uinteger (which was the case LCD was using, If I recall correctly), but not for Ubyte (which is the default one).

The new version will be available this evening. :wink:
Reply
#7
britlion Wrote:It's a bug. I got the same thing. (though at different addresses)

I think the new label-offset code that Boriel put in isn't quite working correctly.

Looking at the asm:
Code:
print peek(gal-2)

Turns into:

ld hl, (_gal)
    dec hl
    dec hl
    ld b, h
    ld c, l
    ld a, (bc)
    call __PRINTU8
Which does indeed get the byte from gal-2 (albeit in a very strange fashion - what's wrong with ld a,(hl) instead of copying hl to bc ?)
I will investigate this, but it should be ld a,(hl) even if no optimization is being used. :?: hmmm.

britlion Wrote:I think it should be:
Code:
ld a, ( __LABEL__galeon02Charset - 2 )
That was the fix, indeed ;-)
Reply
#8
I cannot compile anything with the new version. If I use PRINT, CLS, PAUSE, etc., it says: xxx.asm not found (xxx=print, cls or pause).
Reinstalled old version and anything compiles again.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#9
Mine is working ok (windows / MSI). Anyway, I've just upload a new version (adds XOR, and ALIGN n in zxbasm). Please, download an reinstall. :roll:
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)