Jump to content
IGNORED

X_SET_BIT and X_CLR_BIT EXEC addresses


Recommended Posts

I've been putzing around with disassembly, and found what I think
to be an error in the presumed addresses for the EXEC's X_SET_BIT
and X_CLR_BIT routines (SETBIT and CLRBIT in YFTE parlance).

In some other threads discussing disassembly, and from looking
at jzintv's dis1600, it seems the current assumption is effectively
this mapping:

 

X_SET_BIT   EQU     $16DB
X_CLR_BIT   EQU     $16E6

 

But looking at the disassembly of the EXEC, it appears that
the code at $16DB does the CLRBIT operation, and the code at
$16E6 does the SETBIT operation.

 

A typical invocation looks like this:

 

        MVII    #$0003, R0   ;  We want to clear bit 3 (which has mask $0008)
        JSR     R5,     X_CLR_BIT
        DECLE   $0183        ; Address of DECLE whose 3rd bit we want to clear

 

The code at $16E6 is as follows:

 

L16E6:  PSHR    R0             ; Preserve R0
        PSHR    R1             ; Preserve R1
        MVI@    R5,     R1     ; Load address into R1 (e.g., R1 = $0183)
        PSHR    R5             ; Save return address on stack
        JSR     R5,     X_POW2 ; Convert bit number to mask (e.g., R0 = 1 << 3)
        MOVR    R0,     R5     ; Make a copy of the mask, R5 = $0008
        COMR    R0             ; Invert the mask:  R0 = $FFF7
        AND@    R1,     R0     ; Temporarily clear bit 3 of the value at $0183
        XORR    R5,     R0     ; Set bit 3, and also set status word as if "OR"
        MVO@    R0,     R1     ; Store modified value back to $0183
        PULR    R5
        PULR    R1
        PULR    R0

        ; To return, avoid MOVR R5, R7 as that would change the status word.
        ; Setting the status word is part of the semantics of this function.
        PSHR    R5
        PULR    R7

 

So it looks like X_CLR_BIT actually does the SETBIT operation.

The X_SET_BIT code is similar, but it only does the AND@ operation,
and not the XORR, so in effect it is clearing the bit.

 

If @intvnut is listening, perhaps he can verify my analysis,
and update dis1600 as appropriate.

 

I googled around to see if this was a known issue, and didn't find anything.
So I suspect there aren't any homebrews using these EXEC functions.
 

  • Like 2
Link to comment
Share on other sites

I never found documentation on EXEC entry points, so I never used the EXEC.

 

At the end wasn't so bad, because the EXEC has some known limitations. And from reading the code shown, it appears like it is very inefficient!!!

Link to comment
Share on other sites

12 hours ago, nanochess said:

I never found documentation on EXEC entry points, so I never used the EXEC.

 

At the end wasn't so bad, because the EXEC has some known limitations. And from reading the code shown, it appears like it is very inefficient!!!

There is a very small list of known entry points here.

 

There really is no point to knowing Exec entry points outside of ROM hacking, because it's just there so early games could fit inside of 4K ROM.

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...