MEGA65: emulation of CPU 32bit virtual Q register and related opcodes

[JesperGravgaard]

Is your feature request related to a problem? Please describe.
The mega65 45GS02 CPU supports a virtual 32-bit register Q that uses the 4 8bit registers A, X, Y, Z as one big 32bit register. It has a special instruction prefix NEG NEG that converts instructions to 32bit instructions for loading/storing/modifying. For instance NEG NEG LDA $1234 becomes LDQ $1234 which will load the virtual 32bit register. See the mega65 reference manual appendix G (https://mega65.org/).

The Xemu mega65 emulator does not support this virtual register - so it is not possible to emulate programs that use it.

Describe the solution you'd like
I would like Xemu to support the NEG NEG opcode prefix and the virtual 32-bit instructions of the 45GS02 CPU.

MEGA65-specific opcodes table and comments: https://github.com/lgblgblgb/xemu/wiki/MEGA65-specific-opcodes

Issue about opcode timing, applies here as well: #303

[lgblgblgb]

OK, I'll do it, hopefully very soon. The CPU emulation has the notion already of deconding NEG-NEG prefix, even combined with NOP (NEG-NEG-NOP) however the code is missing to actually emulate opcodes with those prefixes (either NEG-NEG or NEG-NEG-NOP). Of course a straight NOP prefix before Z indexed ZP addressing opcodes already works, but that's nothing to do with "Q" of course.

[lgblgblgb]

For myself not to forget: some interesting problem, currently under on "internal forums". Summary: NEG and NOP was chosen as prefixes (among other reasons) because they are single cycle opcode at native C65 speed, and 65CE02 (thus 4510 too) won't allow interrupts after one-cycle length opcode. So in case of MEGA65, there is no danger of getting interrupt at the "middle" of a prefixed opcode, which would be disaster. However, there is a problem using GS prefixed opcodes on 1MHz mode. That is, in this case, opcode length is "extended" to more or less match to the 6510 (even on C65). That is, NOP is not a single cycle length opcode anymore, and interrupt is accepted after that. That is, in theory any GS specific opcodes are not save if CPU is in 1MHz mode (outside of the "6502 CPU persona" planned mode, that is).

About the danger of this scenario: MEGA65/mega65-user-guide#121

User guide documentation problems: MEGA65/mega65-user-guide#122

This problem has been eliminated since then by both of MEGA65-core and Xemu

[lgblgblgb]

New prefix handling: 3a3a455 but no actual opcode implementations! Though NOP prefixed ones should work already since a while (however since NEG-NEG-NOP is not handled beyond the prefix level, these currently interpreted as NOP only, which is of course not correct!).

[lgblgblgb]

@JesperGravgaard Do you have any test program to test these opcodes (NEG-NEG prefixed, NEG-NEG-NOP prefixed or NOP prefixed)? Currently we had some discussion and even for MEGA65 the problem, nobody tried to use these opcodes yet too much so not so much guaranteed they work, even not on MEGA65. Surely for emulation perspective it would be useful to have a test material as well. It already happened we found a bug at least one cases (ADCQ did not used the carry flag, if I remember correctly), for the real MEGA65.

[lgblgblgb]

https://github.com/lgblgblgb/xemu/wiki/MEGA65-specific-opcodes

[lgblgblgb]

2769f2a

[lgblgblgb]

Info: it seems even MEGA65 have "serious" questions how Q opcodes are implemented, works at all and exactly how ... In some cases the exact behaviour seems not to match with documentation or even considered "not right". So at this point, maybe it's not a good idea to try to emulate those opcodes before the questions solved at the MEGA65-level at least.

[lgblgblgb]

Started to implement Q opcodes in the "dev" tree. Though, it seems, some things may change soon even on the MEGA65 side, with Q-accumulator addressing mode opcodes at least (do not work on real hardware right now)! For now, let's implement what it "should do", and keep it in sync with MEGA65 later when it changes.

Anyway it's kinda funny that this issue is now more than 1 year old, the MEGA65 implementation thus must be older, and still today we face the problem that MEGA65 implementation is bad, and must change, what can be followed then with the emulation only to be really useful ... :-O

[lgblgblgb]

At this point, Q opcodes are emulated.