This feels like a little bit of a puzzle. Suppose your subroutine is going to run on a 65816 but you don't know whether it's in emulation or native mode, or 8 or 16 bit index or memory mode. How to determine the mode and return the information without messing up the machine?

My first thought of course is PHP then PLA. But I don't know the size of A! Perhaps I can save and restore S using TSX and a later TXS? But I don't know the size of X (or S) ... so it feels like some cleverness is going to be needed.

Only part of the solution, but this byte sequence ought to leave the Z flag cset when Memory/Accumulator is 8-bit, and clear when 16-bit.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Ah - how about PHP PHP PLA PHA PLP PLP - then we know the bottom byte of A will contain P. And we put the stack back where we found it.

I think its easier to work back from what state does the subroutine need the processor to be in to work correctly.

All the additional instructions and modes work emulation mode so you don't usually need to change the E bit unless the fixed stack location or interrupt behaviour is important. If you need to change state then start the function with CLC (or SEC)/XCE/PHP and finish with PLP/XCE before exiting.

8/16 index register size changes are tricky as X/Y get truncated if they get smaller so you need to PHX/PHY and save the current size with a PHP before X is changed.

If the accumulator is in the 8-bit state then it may be necessary to save B as well unless the routine can guarantee not to modify it.

Putting it all together you get


You don't always need to save everything of course some registers mat contain results on exit but a universal routine will be restricted to 8-bit values in A/B/X/Y.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Hmm, I think that's a good answer to a slightly different puzzle: how not to be affected by the initial state. I was thinking of trying to report the machine's state. For example, I give you an unknown 816 machine with an unknown OS and a Basic with an assembler. Somehow you want to figure out what mode Basic is using before (and after) it calls the code you've written.

Asking for a friend.

(Well, not really - some research would answer the case I'm thinking of. But out of this predicament came the puzzle.)

To report the machines state move to known state (like emulation or native with 8-bit MX) while pushing the old and look at stack.

How about this:

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Nicely done!

There was a somewhat-related discussion and/or challenge here.

_________________
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)

Ooh, good memory - and that challenge is as yet unresolved, I think.

(Andrew, just a thought about your solution: by switching to native mode might you get in trouble if there's an interrupt, if the system expected to be in emulation mode?)

Can't see why. There are separate vectors and all the bank registers are pushed. Its more of an issue the other way round. In emulation mode the interrupt always returns with PBR set to bank zero.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

They *are* separate vectors, and that could be a problem in itself if only one set of vectors is actually set up. It would be safer to disable interrupts while (possibly) in the "other" mode. And it would also be safest to switch to native mode rather than to emulation mode, because several registers are potentially corrupted by emulation mode.

We shouldn't necessarily be required to save P and switch modes just to detect our state, if we're clever enough to use a few bytes of scratch RAM to detect page wrapping behavior that's specific to the state we're in. Unfortunately, I'm not clever enough at the moment, so I'm just throwing the idea out there ...

_________________
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)

Better idea: emulation mode causes the M/X bits to be stuck on (part of forcing both to 8-bit mode). This can be detected without switching to native mode:

28 bytes of code? Very tidy. Nicely done!

_________________
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)

Nice! I do like the way Andrew used XCE to preserve the pre-existing machine state at the same time as putting it into a known state, but a solution which doesn't use XCE is even better.