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.
The sector work being:
- We only wrap around if we go beyond the length of an encoded track, so
use ENC_ETRACK.
- If we DO wrap around, we don't use modulus; we simply reset to zero.
We use BUFSIZ everywhere, except in setvbuf(), which kinda needs to know
the proper buffer size. Because we were passing 256, which is (much!)
lower than BUFSIZ, we were wrapping output around in an odd, unexpected
way.
We were not encoding data properly, because in DOS 3.3 and ProDOS,
sectors must be interleaved on disk media (whereas in the original image
form, data is laid out in a linear fashion).
This solves a bug where we erroneously encountered a "bad" opcode (a7)
in the program code.
This is because the eff_addr variable is a 16bit one, and adding addr +
X or addr + Y can possibly result in a 9-bit value, which is not what we
want. (You'd be pulling data from the stack instead of the zero page.)
We need to accept values for result that are greater than a byte so that
we can determine if carry is set, but this causes an issue when an app
uses addition to force an overflow that would set the zero bit. Masking
result for only the LSB fixes that problem.
Excuse me, I just need to scream now.
AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
Thank you for your indulgence. Please carry on.
