Closed infromthecold closed 1 year ago
Yes, it should. The watch expressions basically work like an 'eval' in javascript. Beforehand the registers and labels are exchanged with their real values. Also shifting is supported.
I would need to see the program snippet to judge if something is wrong here. But maybe it is because of the parenthesis: The JS 'eval' treats the parenthesis mathematically only. Maybe you have expected that they should return the contents of the address, like in LD A,(HL).
DeZog calculates the value in the watch expression and afterwards reads the contents from the memory address.
Hey Maziac I don't think you need the snippet as this is a breakpoint before the functionality, and you can see the raw values for ix+object.fixedYPos, iy+object.fixedYPos, ix+object.fixedXPos and iy+object.fixedXPos in the images which are correct,
in the image below
ix+object.fixedYPos is $0AF0 iy+object.fixedYPos is $0AA0
$0AF0-$0AA0 should be $0050 for the ix+object.fixedYPos-iy+object.fixedYPos calculation
ix+object.fixedXPos is $17D0 iy+object.fixedXPos is $0C00
and $17D0-$0C00 should be $0BD0 for the ix+object.fixedXPos-iy+object.fixedXPos calculation
as you can see its still producing a wrong value without the inner parentheses.
And with no parentheses
Ignore the highlights on the row that's just where the cursor was! Patricia
E.g. ix+object.fixedYPos is $0AF0 i.e. it is the contents of the address pointed to by ix+object.fixedYPos
When you do ix+object.fixedYPos - iy+object.fixedYPos you do pointer arithmetics.
Lets assume ix+object.fixedYPos is pointing to 0xB000 and iy+object.fixedYPos is pointing to 0xA000 then the result is 0x1000. The watch expression will then return the value pointed to by 0x1000.
I guess you are trying to achieve to get the distance, i.e. the difference of the contents of ix+object.fixedYPos subtracted by the contents of iy+object.fixedYPos.
I guess that cannot be achieved in the watches.
BTW, if you like you can try a preview of DeZog 3.0: https://github.com/maziac/DeZog/releases/tag/v3.0.0-rc1
Maziac Will do, changing web servers at the moment, so I'm pretty busy :)
Many thanks
On Tue, 4 Oct 2022 at 18:48, maziac @.***> wrote:
BTW, if you like you can try a preview of DeZog 3.0: https://github.com/maziac/DeZog/releases/tag/v3.0.0-rc1
— Reply to this email directly, view it on GitHub https://github.com/maziac/DeZog/issues/98#issuecomment-1267349486, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7EKGFPZJQOEAAFK466IFTWBRUVPANCNFSM6AAAAAAQ3U2K3Q . You are receiving this because you authored the thread.Message ID: @.***>
Is it OK to close this?
Hi Maziac Sorry yes , close it.
Many thanks Trish
On Sat, 19 Nov 2022 at 10:30, maziac @.***> wrote:
Is it OK to close this?
— Reply to this email directly, view it on GitHub https://github.com/maziac/DeZog/issues/98#issuecomment-1320854738, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7EKGHKJGJOO3ICXGTTLITWJCT5PANCNFSM6AAAAAAQ3U2K3Q . You are receiving this because you authored the thread.Message ID: @.***>
Hi Maziac, I hope you are well, I have a question, is the functionality for the watches able to do complex reads and calculations?
The image above demonstrates that the complex calculation evaluates to a wrong value which I am assuming is the error value as its being substituted for both the x and y calculations
((ix+object.fixedYPos)-(iy+object.fixedYPos))>>4 should be $0002 and not $D342 ((ix+object.fixedXPos)-(iy+object.fixedXPos))>>4 should be $00bb and not $D342
As you can see in this image the values are incorrect even without the bit shifts
Patricia