Two issues with macro CLEAN_START in macro.h

[Sigeberht]

1. The use of the Illegal Opcode LXA #0 appears not to work in Stella 7.0. I noticed the prior thread here discussing the stability of this op-code when CLEAN_START was modified to include it in 2020. While this issue is due to Stella not implementing this Illegal opcode correctly (and I'm reporting that separately), I think that including illegal opcodes in Macros by default is a poor choice. Better to opt in rather than opt out. Possibly difficult to change that without breaking other peoples code though, so I suggest removing the conditional compilation of LXA from CLEAN_START as the code isn't time critical. The workaround is to always define NO_ILLEGAL_OPCODES equ 1 (or wait and see if it gets fixed in Stella).

2. There is a spurious TAY instruction in CLEAN_START which is probably left over from an earlier implementation which didn't use the SP to implement the memory clear. I think this can be removed.
   Edit: On second thoughts, I think this is on purpose to set Y to zero on existing CLEAN_START.

Note that if CLEAN_START is executed immediately after Reset, then Register A is likely to be zero and the code clears the TIA and RAM correctly in Stella. Mine had extra banking switching code before CLEAN_START resulting in $FF in the register A, and the Stella bug resulted in all the TIA registers and RAM being set to $FF. Thus many people will not have seen this issue.

macro.h

        MAC CLEAN_START
            sei
            cld
        
            IFNCONST NO_ILLEGAL_OPCODES
                **lxa #0**
            ELSE
                ldx #0
                txa
            ENDIF
            **tay**

.CLEAR_STACK dex
txs
pha
bne .CLEAR_STACK ; SP=$FF, X = A = Y = 0

        ENDM

[thrust26]

@Sigeberht
I suppose you mean 0xAB, right? LXA #imm (actually LAX #imm) is considered highly unstable, therefore it should not be used.

[Sigeberht]

Yes. It doesn't disassemble it Stella but is shown as .byte. It's AB 00

[thrust26]

This is how we implemented it in Stella:

// LXA
case 0xab:
{
  operand = peek(PC++, DISASM_CODE);
}
{
  // NOTE: The implementation of this instruction is based on
  // information from the 64doc.txt file.  This instruction is
  // reported to be very unstable!
  A = X = (A | 0xee) & operand;
  notZ = A;
  N = A & 0x80;
}
break;

https://atarihq.com/danb/files/64doc.txt

[Sigeberht]

Odd. I would have thought that with an operand of #0 this would evaluate to zero. My code enters with A=0xFF and X = 0x00 and after LXA #0 I have no change to either register. I'm wondering if that code gets executed.

Setting NO_ILLEGAL_OPCODES equ 1 gives a working solution

[Sigeberht]

I see this immediately afterwards using LXA. The FF's in the RAM are from my previous run, but show the erroneous clear.

[Sigeberht]

For completeness, here is what happens with NO_ILLEGAL_OPCODES equ 1

[thrust26]

I'm wondering if that code gets executed.

Just use reset and single step.

[Sigeberht]

I was setting the PC back to the top and single stepping through. I just didn't step further than the offending instruction so hadn't completed the clear. The memory shows the result from running through the whole thing just before this and shows the end result of running the entire macro,

What I was wondering was if Stella is actually running that code fragment you posted. It looks more like I was getting a NOP.

[thrust26]

Why don't you make some tests and open a Stella ticket, if you find that it isn't executed as described in code?

[Sigeberht]

I'll do that. Thanks for your help.