Code for testing behaviour of XAA instruction

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
aureus123
Posts: 11
Joined: Mon Mar 30, 2020 10:35 am

Code for testing behaviour of XAA instruction

Post by aureus123 »

Hi,

I have always been interested in the behavior of this illegal instruction but I never did anything, until now :) that I've a bit more time for being confined in my house because of the coronavirus.

So, I made a simple test program that makes an "histogram" of the magic numbers that the XAA instruction hits, and then test the 256^3 combinations of values for registers A, X and the imm. value of XAA. Then, I've tested it on some emulators and real machines (a Famicom and a RetroN 3). Hope you enjoy it, and I'd be pleased if you test it on your NES! :D

Is there any possibility to add it to https://wiki.nesdev.com/w/index.php/Emulator_tests ?

Best,
Aureus.


Edit: code was improved, also a similar test with LAX ($AB) was added


Results of the experiments:

Real hardware:

1) On a japanese famicom with an Everdrive N8, magic number seems to be #$FF for XAA and LAX. However, LAX
doesn't behave as expected in http://csdb.dk/release/?id=152327. At the beginning of the 2nd. phase the test fails with:
A = 0, I = 1, R = 0, E = 1, X = 0
(see the meaning of these values in the README)

2) On a Hypekin RetroN 3 (non-HDMI version) with and Everdrive N8 + 60-to-72 pin converter, magic seems to
be #$FF for XAA and #$00 for LAX. Here, XAA doesn't behave as expected. At the beginning of the 2nd. phase
the test fails with:
A = 1, X = 1, I = 0, R = 1, E = 0

Emulators:

1) Mesen 0.9.8: XAA: magic = 0, fails on 2nd. phase with A = 1, X = 0, I = 0, R = 1, E = 0
LAX: magic = FF, ok

2) Nintendulator 0.975: same results as Mesen.

3) Nestopia 1.39: XAA: magic = EE, ok
LAX: magic = EE, ok

4) EmuVT 1.13: same as Nestopia

5) FCEUX 2.2.3: XAA: magic = EE, ok
LAX: magic = FF, ok
Attachments
test_xaa.nes
NES rom
(40.02 KiB) Downloaded 129 times
test_xaa.zip
Source code (Requires CC65)
(13 KiB) Downloaded 120 times
Last edited by aureus123 on Tue Jul 21, 2020 8:56 am, edited 1 time in total.
aureus123
Posts: 11
Joined: Mon Mar 30, 2020 10:35 am

Re: Code for testing behaviour of XAA instruction

Post by aureus123 »

Here is an example of the first phase of the test, running on Nestopia.
Attachments
Example
Example
example.png (6.71 KiB) Viewed 12603 times
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Code for testing behaviour of XAA instruction

Post by lidnariq »

On actual hardware, the behavior of XAA will depend on if it collides with a DPCM read... (or, in the case of the C64, any time something de-asserts +RDY).
Visual6502wiki wrote: In some computers, RDY is used to stall the CPU while the bus is used for DMA, which means the bus contains data such as video data for several cycles, except the last. In the case of XAA, every cycle's data is ANDed into A, and this is why the final value of A changes even for the same values of operand, X and A.
I wonder whether there would be a performance penalty to an emulator to accurately tracking DPCM reads during XAA.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Code for testing behaviour of XAA instruction

Post by Oziphantom »

do you know https://csdb.dk/release/?id=185341 if not you might want to give it a read.
aureus123
Posts: 11
Joined: Mon Mar 30, 2020 10:35 am

Re: Code for testing behaviour of XAA instruction

Post by aureus123 »

Oziphantom wrote: Wed Apr 01, 2020 8:42 pm do you know https://csdb.dk/release/?id=185341 if not you might want to give it a read.
No, thanks a lot! It's very complete :D

My interest is to see the behavior on different famiclones for the sake of enjoyment, although I'm pretty sure that those who use NoaCs don't implement these opcodes or do something else.
aureus123
Posts: 11
Joined: Mon Mar 30, 2020 10:35 am

Re: Code for testing behaviour of XAA instruction

Post by aureus123 »

Hi,

I updated the code (2nd. phase is "prettier") and added another test for LAX ($AB), see the pics below. I was surprised to see that LAX doesn't behave as the book "No more Secrets" says. I also didn't find anything about this behavior ($AB opcode on NES) on visual6502.org.
Attachments
LAX test passed
LAX test passed
lax_test_passed.png (4.37 KiB) Viewed 11076 times
Intro screen
Intro screen
intro.png (5.6 KiB) Viewed 11076 times
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Code for testing behaviour of XAA instruction

Post by lidnariq »

LAX #imm is a combination of TAX and LDA #imm, which is on a cycle-by-cycle basis

Code: Select all

   TAX    LDA #imm
1. A→SB    DB→SB
2. SB→X    SB→A
... honestly, I'm not clear why this one is unstable. There's no feedback stage, just a bus conflict...? Some sources I found imply that getting A out of the ALU via the BCD adjustment logic might be slow enough to cause a race in this bus conflict case.
User avatar
Controllerhead
Posts: 314
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Code for testing behaviour of XAA instruction

Post by Controllerhead »

Nice job. I am very curious about this! Say i were to load this on my everdrive and play it on my toploader or toaster. Is it potentially dangerous? Can it create some voltage situations that will fry them?
Image
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Code for testing behaviour of XAA instruction

Post by lidnariq »

No, the unintended instructions are all safe, just not necessarily useful (SYA, LAS) or predictable (XAA)
User avatar
Controllerhead
Posts: 314
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Code for testing behaviour of XAA instruction

Post by Controllerhead »

lidnariq wrote: Tue Jul 21, 2020 11:14 pm No, the unintended instructions are all safe, just not necessarily useful (SYA, LAS) or predictable (XAA)
If you say it's safe, i trust you man. Thanks!

LAX is the only one i find useful, so far, but i avoid it because of emulator compatibility.

EDIT: All the undocumented instructions do is confuse the decode ROM inside the 6502, or Ricoh derivatives perhaps, right?
Image
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Code for testing behaviour of XAA instruction

Post by lidnariq »

I wouldn't even go as far as "confuse". Just "try to follow two different sets of instructions at the same time", which is surprisingly mostly not contradictory.

Tepples wrote an article on the wiki about using these instructions. The most conspicuously useful instruction to me is AXS($CB), because it lets you add constants to the X register beyond the 1 and -1 as provided by INX and DEX.
aureus123
Posts: 11
Joined: Mon Mar 30, 2020 10:35 am

Re: Code for testing behaviour of XAA instruction

Post by aureus123 »

Controllerhead wrote: Tue Jul 21, 2020 9:25 pm Nice job. I am very curious about this! Say i were to load this on my everdrive and play it on my toploader or toaster. Is it potentially dangerous? Can it create some voltage situations that will fry them?
There is no risk. Go ahead! :)

If you don't want to read the README just:

Execute the .nes file, press A, wait 2-3 of minutes (the more time passes, the more chance there is for a 2nd. magic number to emerge), take a pic of the screen, press B, wait until the counters stop and the screen turns green/red, take another pic, and them share the images with us so I make the analysis.

Then do the same for LAX instruction.

For XAA, the whole process may take half an a hour, for LAX is much less.

Thanks in advance! :wink:
gpz
Posts: 2
Joined: Wed Jul 22, 2020 2:52 am

Re: Code for testing behaviour of XAA instruction

Post by gpz »

Hey ppl!

I am the weirdo who wrote the above mentioned PDF, someone pointed to me this thread.

Regarding ANE#imm and LAX#imm, those are some strange buddies. It took us (various people that wrote test programs and let them run on their C64s) years to come up with the current version of the truth described in the PDF - and so far almost every year (with every update to the PDF) i learned something new about the "unstable" opcodes :)

Since last release, i discovered something really surprising - a very popular C64 game (Wizball) uses LAX#imm, and even in a very "unstable" way (LAX#$ff) and then relies on the result (it must be $ee). Or in other words: using any other value for the "magic constant" than $ee makes it crash (this is in the "get ready" screen, if you want to check yourself). That was very surprising to me, as this means the LAX#imm opcode isnt quite as unstable as we thought at all.

Now that you observed something completely different on NES is really interesting, can you describe what exactly the observed behaviour is on the NES? Are there any other undocs that work differently than described in the PDF?
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Code for testing behaviour of XAA instruction

Post by Oziphantom »

Do you think it might be down to the Mhz. The NES runs faster so some lines might not have time to reach "hi" or be drained to "lo"? Do the opcodes behave identically at 2mhz on a 128 for example?
gpz
Posts: 2
Joined: Wed Jul 22, 2020 2:52 am

Re: Code for testing behaviour of XAA instruction

Post by gpz »

That could be one factor... noone really knows what actually makes the "magic constant" (like some weird analog side effects). Feel free to test on C128 in 2Mhz too :)
Post Reply