I'm quite excited about this: I had the idea to probe a possible side-effect of perhaps the most interesting 6502 instruction, JSR.

And I got a result! My program runs one way on a real 6502, and another way on, I think, most emulators. And those emulators do the obvious thing, which is to say, they do what most people expect them to do. And so the result should be modestly surprising to most people here - which makes it interesting. (I expect most hardware re-implementations might also do the obvious thing, but haven't yet tested any. Not the MOnSter 6502 obviously.)

The program is in BBC Basic, but the motivated experimenter won't find that an obstacle.

On a BBC Master, which has a 65C102 in it:


Edit: see below for an improved version

At the time of writing, in owlet, which uses jsbeeb, an unusually high-fidelity emulation, the program prints F. Likewise in two of the three 6502 models in PiTubeDirect.

(To my slight surprise, the lib6502 model in PiTubeDirect prints a P, which doesn't match what I think lib6502 is doing, but this is probably my failure of understanding.)

What is that I'm testing, you ask? It's that JSR has two operand bytes, and it has to do two stack pushes, and in a real 6502 the sequence is that the first operand byte is read, then the two stack pushes happen, and then the second operand byte is read. So the test is to arrange that the second operand byte is overwritten by the stack. Truly self-modifying code.

There might be more to explore, both in the test program and in the emulators and re-implementations which we might be interested in.

Edit: oops, Mike (barrym95838) reminds us that he sketched exactly this kind of test only last year. I was there. And I'd forgotten.

(former placeholder - edited!)

Dave/hoglet has kindly run tests on various emulations and implementations, using the updated version of the test, which spots the kind of behaviour we see from lib6502 and in that case returns "X":



Also

(Which tells us that the '816 doesn't behave as a cycle-accurate 6502, as already noted in documentation and in this thread. By which I mean, the F does not mean that the '816 is failing as a CPU!)

That is very, very subtle. Well found!

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

That looks like a more mature version of my little brain-tickler from a while ago.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Interestingly the 65C816 doesn't seem to have this same behaviour (if I've read the datasheet correctly).
It reads both the new program counter low and high bytes before it pushes them onto the stack. Even in emulation mode.

At least I really hope that's what it does because that's how I've implemented it in my emulator. I damaged my '816 board so I can't quickly test this but I'd be interested to know if anyone else does.

Cheers!
Andrew

Oh goodness me, you're quite right Mike! Only last year, and I was engaged in the thread too, so I have no excuse for not remembering. I'll add a credit to the head post.

Meanwhile, I've got an improved version which distinguishes lib6502's different fail. I haven't yet tested on an NMOS 6502 or an '816 or any FPGA core yet. (Edit: but Dave now has, see the updated second post. Thanks Dave!)

Here's an improved version which sees lib6502's different kind of fail (it fails with "X"):

(well spotted Andrew, I'll see if we can test an '816)

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I believe on the 65816 there are a couple of forms of JSR that might exhibit this behaviour:

JSL (opcode 0x22)


JSR (IND16, X) (opcode 0xFC)


These both needed "special casing" in the 6502 Decoder.

Dave

Ah, that's a good point Dave, any core which works as a 6502 with the decoder must be doing the right thing.

Dave (hoglet) has kindly run tests - see the second post which has been updated.

Dave also has traced the execution of the "X" case which we see in lib6502 and in the '816:



And the answer is, yes indeed, the ORA comes for free from the stack pushes, and I couldn't think how to avoid it, but realised it's harmless and just needs an operand byte - which is a NOP. (I thought at first that 01 was an undefined opcode, but visual6502 reminded me that it's an ORA.)

FWIW, this was apparently fixed in VICE (the C64, C128, VIC20, PET and CBM-II emulator) some time in 2002. The memory access order for JSR is incorrect in VICE version 1.9, but correct in 1.10.

Very cool test case mind, I might have to do some code that relies on that at some point.

(Also, on my first reading I was distracted by the JSR instruction straddling the border between zero page and page 1 - took me a few minutes to realise that it was the pushes to stack that were vandalising the destination, not some kind of zero page memory access related thing!)

-ChristopherJam

Interesting info on VICE, thanks!

No worries.

If anyone's interested, here's the variant groepaz (once of the VICE maintainers) used to test with VICE's c64 emulator (I just went back and looked at old source tgzs after that to see when the pertinent emu code turned up). Formatted for ACME.

Thanks! There are many emulators out there and it might be interesting to see how many took care of this.