Code for testing behaviour of XAA instruction
Moderator: Moderators
Code for testing behaviour of XAA instruction
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!
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
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!
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.
Re: Code for testing behaviour of XAA instruction
Here is an example of the first phase of the test, running on Nestopia.
- Attachments
-
- Example
- example.png (6.71 KiB) Viewed 12603 times
Re: Code for testing behaviour of XAA instruction
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).
I wonder whether there would be a performance penalty to an emulator to accurately tracking DPCM reads during XAA.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.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Code for testing behaviour of XAA instruction
do you know https://csdb.dk/release/?id=185341 if not you might want to give it a read.
Re: Code for testing behaviour of XAA instruction
No, thanks a lot! It's very completeOziphantom 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.
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.
Re: Code for testing behaviour of XAA instruction
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.
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.png (4.37 KiB) Viewed 11076 times
-
- Intro screen
- intro.png (5.6 KiB) Viewed 11076 times
Re: Code for testing behaviour of XAA instruction
LAX #imm is a combination of TAX and LDA #imm, which is on a cycle-by-cycle basis
... 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.
Code: Select all
TAX LDA #imm
1. A→SB DB→SB
2. SB→X SB→A
- Controllerhead
- Posts: 314
- Joined: Tue Nov 13, 2018 4:58 am
- Location: $4016
- Contact:
Re: Code for testing behaviour of XAA instruction
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?
Re: Code for testing behaviour of XAA instruction
No, the unintended instructions are all safe, just not necessarily useful (SYA, LAS) or predictable (XAA)
- Controllerhead
- Posts: 314
- Joined: Tue Nov 13, 2018 4:58 am
- Location: $4016
- Contact:
Re: Code for testing behaviour of XAA instruction
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?
Re: Code for testing behaviour of XAA instruction
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.
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.
Re: Code for testing behaviour of XAA instruction
There is no risk. Go ahead!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?
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!
Re: Code for testing behaviour of XAA instruction
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?
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?
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Code for testing behaviour of XAA instruction
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?
Re: Code for testing behaviour of XAA instruction
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