skoolkid / skoolkit

A suite of tools for creating disassemblies of ZX Spectrum games.

Home Page:https://skoolkit.ca

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

PEEK Macro is giving an unexpected value

Rui1973Martins opened this issue · comments

Given the following macro definition:

 #DEF(#COLORNAME(color)  #MAP($color)(UNKNOWN,0:BLACK,1:BLUE,2:RED,3:MAGENTA,4:GREEN,5:CYAN,6:YELLOW,7:WHITE))

The following code and comments

 $981A CP $04        ; {
 $981C JR NC,$9820   ; inkColor = ( borderColor is >= #COLORNAME($04) ) ? WHITE : BLACK
 $981E LD B,$07      ; }

Results in this description

inkColor = ( borderColor is >= GREEN ) ? WHITE : BLACK

Which is fine, correct and expected.

However, if we use PEEK with the location of the CP parameter ($981B):

 $981A CP $04        ; {
 $981C JR NC,$9820   ; inkColor = ( borderColor is >= #COLORNAME(#PEEK$981B) ) ? WHITE : BLACK
 $981E LD B,$07      ; }

The results is unexpectedly BLACK

inkColor = ( borderColor is >= BLACK ) ? WHITE : BLACK

Am I doing anything wrong ?

NOTE:
If I change the expression to inkColor = ( borderColor is >= #COLORNAME($04) ) ? WHITE : BLACK :> #PEEK$981B

I get:

inkColor = ( borderColor is >= GREEN ) ? WHITE : BLACK :> 0

Then I see that the problem is in the PEEK Macro itself.
Or some memory has been overwritten during processing.

I use this type of thing all the time, try just enclosing with brackets;

$981C JR NC,$9820 ; inkColor = ( borderColor is >= #COLORNAME(#PEEK($981B))) ? WHITE : BLACK

See; https://github.com/pobtastic/ultimate/blob/main/sources/aticatac/aticatac.ctl#L2627 / https://github.com/pobtastic/ultimate/blob/main/sources/aticatac/aticatac.ref#L167

https://pobtastic.github.io/ultimate/aticatac/asm/A311.html

You are probably missing an @assemble directive, to make sure that assembly language instructions are converted into byte values.

I tried the change to see if that was the cause inkColor = ( borderColor is >= #COLORNAME($04) ) ? WHITE : BLACK :> #PEEK($981B)

But it doesn't solve the issue, since I get the same wrong result (0), instead of 4:

inkColor = ( borderColor is >= GREEN ) ? WHITE : BLACK :> 0

Regarding the @assemble directive, it doesn't seem to apply, since this byte is part of an actual instruction and not a DEFB or DEFW.

EDIT: But reading a bit further, the example, appears to demonstrate this behaviour.

But this is a quirk of the processing, and should NOT be something for the user to be aware of.
Am I right ?

Hence is in fact a quirky behaviour or I would even call it a bug or missing feature.

The fact that a specific area of memory was Disassembled into ASM mnemonics MUST NOT affect the behaviour of PEEK Macro.

Did the @assemble directive fix the problem?

By the way, the fact that assembly language instructions are not converted into byte values by default is by design. @assemble was introduced in 5.0, and if @assemble=2 were the default, that would have negatively affected the performance of skool2html.py compared to 4.x.

I'll add a note to the documentation on the #PEEK macro about using @assemble to ensure that assembly language instructions are converted into byte values.

I think I understand the issue.
There is some other representation of the actual data, being used instead of the original snapshot memory dump.

But shouldn't PEEK just have access to the original snapshot memory dump and just fetch the byte directly ?
What prevents this ?

I have not tried the @assemble yet.
And I would prefer not to pollute the disassembly, with extra stuff to work around feature behaviours, if I can avoid it.

But shouldn't PEEK just have access to the original snapshot memory dump and just fetch the byte directly ? What prevents this ?

No, #PEEK does not have access to the original snapshot. The skool file has no knowledge of any snapshot.

I have not tried the @assemble yet. And I would prefer not to pollute the disassembly, with extra stuff to work around feature behaviours, if I can avoid it.

The best way to make #PEEK work in this case is to place an @assemble=2 directive in the skool file, at some point before the instruction whose byte values you want to inspect.

No, #PEEK does not have access to the original snapshot. The skool file has no knowledge of any snapshot.

Ah!

We are getting back to the ideia I mentioned the other day, that the Skool file should be like a project file and have references to CTL and snapshot file, defined somewhere.

Ok, Thank you for all the info and feedback.

I've updated the documentation on the #PEEK macro. It now mentions the @assemble directive.