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.
1. The phaser algorithm was reworked, and it should be more accurate in
choosing when to step forward or backward.
2. Writes should be committed when the latch has bit 7 high. This hasn't
actually been a problem yet, since other things are broken! But we might
as well fix it now that we've seen it.
