This also forces the result of operations to be considered purely as
8-bit results in _some_ cases, but not in others. We were missing some
times when an overflow is the expected behavior; because SET_RESULT()
and mos6502_modify_status() use ints, this overflow was not properly
observed.
But weird forms. In most cases they basically are NOPs, except with
different opcodes. In other cases, we call them NP2 and NP3s, and do so
because they consume 2 or 3 bytes respectively (vs. just 1 with NOP).
We had to teach some arcane magic to the emulator for this to work. We
may want to refactor to decouple the number of bytes consumed from the
address mode.
This is not a real instruction in the 65c02 processor; I invented it for
the sole purpose of handling the specialized logic that is performed by
BIT in IMM mode. To be fair--I can imagine this really _was_ implemented
as a "separate" instruction on the chip! But I don't know that for sure.
1. The stack should descend, not ascend;
2. The stack should be pushed byte for byte; meaning, when pushing P or
A, those should consume one byte, not two;
3. The MSB should be pushed first when doing JSR and BRK, which makes
some sense if you were reading the stack from $0100 - $01FF.
Regarding soft switches, we had several we should have been listening
for on both reads and writes, but were only doing so on writes; this is
now fixed.
Regarding statuses, we were incorrectly calculating both carry and
overflow. This should now be fixed, although some quick examinations of
disassembly output suggest there is something else amiss. Debugging will
continue shortly.
To allow this to work, we had to allow the CPU struct to record what the
last opcode/operand/address were, although in truth we only needed the
last address.
The execute function should just work from the PC register. It might
seem to be easier to test by passing an arbitrary opcode into the
function, but because so much of the chip's execution is
context-sensitive (that is, it expects PC to be pointing at the opcode,
to have its operand in front of it, etc.), passing an arbitrary opcode
is not really reflective of what needs to be in place for the function
to work correctly.
Criterion's init and fini config options allow us to register setup and
teardown functions. We now use this to register the common cpu variable
for the mos6502 tests, albeit through the use of a global variable.
Doing so necessitated that each of the different test files have their
own suites, due to some implementation details in Criterion, but this is
No Big Deal.
