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 ?
Edit: code was improved, also a similar test with LAX ($AB) was added
Results of the experiments:
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
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
- NES rom
- (40.02 KiB) Downloaded 19 times
- Source code (Requires CC65)
- (13 KiB) Downloaded 16 times
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.
No, thanks a lot! It's very complete
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.
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.
- LAX test passed
- lax_test_passed.png (4.37 KiB) Viewed 1032 times
- Intro screen
- intro.png (5.6 KiB) Viewed 1032 times
Code: Select all
TAX LDA #imm 1. A→SB DB→SB 2. SB→X SB→A
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?
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.
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!
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?