This PR fixes all discrepancies of sim65 instruction timings, for both the 6502 and the 65C02 processors.
The timings as implemented in this PR have been verified against actual hardware (Atari 800 XL for 6502; and WDC 65C02 for 65C02).
These timings can also be verified against the 65x02 test suite. However, in this case, a single discrepancy arises; the 65x02 testsuite suggests that the 65C02 opcode 0x5c should take 4 clocks. However, tests on a hardware 65C02 have conclusively shown that this instruction takes 8 clock cycles. The 8 clock cycles duration for the 65C02 0xfc opcode is also confirmed by other sources, e.g. Section 9 of http://www.6502.org/tutorials/65c02opcodes.html.
This test makes sim65 correct both in terms of functionality (all opcodes now do what they do on hardware) and in terms of timing (all instructions take as long as they would on real hardware).
The one discrepancy that remains, is that on a real 6502/65C02, some instructions issue R or W cycles on the bus while the instruction processing is being done. Those spurious bus cycles are not replicated in sim65. Sim65 is thus an instruction-level simulator, rather than a bus-cycle level simulator. In other words, while the clock cycle counts for each instruction are now correct, not all clock cycles are individually simulated.
This PR fixes the implementation of 5 illegal opcodes
in the 6502, which the 6502X supports:
* $93 SHA (zp),y
* $9B TAS abs,y
* $9C SHY abs,x
* $9E SHX abs,x
* $9F SHA abs,y
The common denominator of the previous implementation was that it didn't correctly handle the case when the Y or X indexing induced a page crossing. In those cases, the effective address calculation of the instructions becomes truly messed up (with the high byte of the address equal to the value being written).
The correctness of the implementations in this PR was verified using the 65x02 test suite, and corresponds to a (detailed) reading of the "No More Secrets" document.
Stylistically, there is room for improvement in these implementations, specifically in factoring out common behavior into macros. However, for now the "explicit" coding style will suffice. It is clear enough, and we want to reach a situation soon where the sim65
code is able to pass the full '65x02' testsuite. Once we get to that point, we can refactor this code with a lot more confidence, since we will have the benefit of a working exhaustive test to make sure we don't break stuff.
This PR implements support for 32 65C02-specific instructions
to sim65: BBRx, BBSx, RMBx, SMBx, with x = 0..7.
These instructions are implemented using two macros:
* The "ZP_BITOP" macro implements the RMBx and SMBx isntructions.
* The "ZP_BIT_BRANCH" macro implements the BBRx abd BBSx instructions.
The implementation of these instructions has been verified usingthe 65x02 test suite.
After a lot of preparatory work, we are now in position to finally tighten
the types of the 6502 registers defined in the CPURegs struct of sim65.
All registers were previously defined as bare 'unsigned', leading to subtle
bugs where the bits beyond the 8 or 16 "true" bits in the register could
become non-zero. Tightening the types of the registers to uint8_t and
uint16_t as appropriate gets rid of these subtle bugs once and for all,
assisted by the semantics of C when assigning an unsigned value to an
unsigned type with less bits: the high-order bits are simply discarded,
which is precisely what we'd want to happen.
This change cleans up a lot of spurious failures of sim65 against the
65x02 test-set. For the 6502 and 65C02, we're now *functionally*
compliant. For timing (i.e., clock cycle counts for each instruction),
some work remains.
ANE (0x8b) is an unstable illegal opcode that depends on a "constant" value that isn't
really constant. It varies between machines, with temperature, and so on. Original sim65
behavior was to use the constant value 0xEF. To get the behavior in line with the 65x02
testsuite, we now use the value 0xEE instead, which is also a reasonable choice that can
be observed in practice.
The obvious way to implement JSR for the 6502 is to (a) read the target address,
and then (b) push the return address minus one. Or do (b) first, then (a).
However, there is a non-obvious case where this conflicts with the actual order
of operations that the 6502 does, which is:
(a) Load the LSB of the target address.
(b) Push the MSB of the return address, minus one.
(c) Push the LSB of the return address, minus one.
(d) Load the MSB of the target address.
This can make a difference in a pretty esoteric case, if the JSR target is located,
wholly or in part, inside the stack page (!). This won't happen in normal code
but it can happen in specifically constructed examples.
To deal with this, we load the LSB and MSB of the target address separately, with
the pushing of the return address sandwiched in between, to mimic the order of the
bus operations on a real 6502.
It provides access to a handful of 64-bit counters that count different things:
- clock cycles
- instructions
- number of IRQ processed
- number of NMIs processed
- nanoseconds since 1-1-1970.
This in not ready yet to be pushed as a merge request into the upstream CC65
repository. What's lacking:
- documentation
- tests
And to be discussed:
- do we agree on this implementation direction and interface in principe?
- can I include inttypes.h for printing a 64-bit unsigned value?
- will clock_gettime() work on a Windows build?
The linkage of the 'Regs' variable in 6502.c was changed from static
to extern. This makes the Regs type visible (and even alterable) from
the outside.
This change helps tools to inspect the CPU state. In particular, it
was implemented to facilitate a tool that verifies opcode
functionality using the '65x02' testsuite. But the change is also
potentially useful for e.g. an online debugger that wants to inspect
the CPU state while the 6502 is neing simulated.
The current (before-this-patch) version of sim65.c does not correctly implement
the ADC and SBC instructions in 65C02 mode. This PR fixes that.
The 6502 and 65C02 behave identically in binary mode; in decimal behavior
however they diverge, both in the handling of inputs that are not BCD values,
and in the handling of processor flags.
This fix restructures the original "ADC" and "SBC" macros in versions that
are specific for the 6502 and the 65C02, and updates the opcode tables to
ensure that they point to the correct implementations.
Considering the ADC instruction for a moment, the original "ADC" macro was
changed to two macros ADC_6502 and ADC_65C02. These check the D (decimal
mode) bit, and defer their implementation to any of three macros ADC_BINARY_MODE,
ADC_DECIMAL_MODE_6502, and ADC_DECIMAL_MODE_65C02. This is a bit verbose but it
makes it very clear what's going on.
(For the SBC changes, the analogous changes were made.)
The correctness of the changes made is ensured as follows:
First, an in-depth study was made how ADC and SBC work, both in the original
6502 and the later 65C02 processor. The actual behavior of both processors
was captured on hardware (an Atari 800 XL with a 6502 and a Neo6502 equipped
with a WDC 65C02 processor), and was analyzed. The results were cross-referenced
with internet sources, leading to a C implementation that reproduces the exact
result of the hardware processors. See:
https://github.com/sidneycadot/6502-test/blob/main/functional_test/adc_sbc/c_and_python_implementations/6502_adc_sbc.c
Next, these C implementations of ADC and SBC were fitted into sim65's macro-
based implementation scheme, replacing the existing 6502-only implementation.
Finally, the new sim65 implementation was tested against the 65x02 testsuite,
showing that (1) the 6502 implementation was still correct; and (2) that
the 65C02 implementation is now also correct.
As an added bonus, this new implementation of ADC/SBC no longer relies on a
dirty implementation detail in sim65: the previous implementation relied on
the fact that currently, the A register in the simulator is implemented as
an "unsigned", with more bits than the actual A register (8 bits). In the
future we want to change the register width to 8 bits, and this updated
ADC/SBC is a necessary precursor to that change.
Issue #2539 brings to light a number of issues in the sim65 simulator.
Several issues can be traced back to undesirable side effects of the
use of bare 'unsigned' types for the CPU registers in the 'CPURegs'
type defined in src/sim65/6502.h.
The intention is to tighten the types of the registers defined there
to uint8_t and uint16_t, in accordance with the actual number of bits
that those registers have in the 6502. However, it turns out that a
handful of opcode implementations depend on the fact that the register
types currently have more bits than the actual 6502 registers themselves
for correct operation. This mostly involves operations that involve
the carry bit (ROL, ROR, ADC, SBC).
In preparation of fixing the CPURegs field types, we will first make
sure that those opcode implementations are changed in such a way that
they still work if the underlying register types are tightened to their
actual bit width.
This PR concerns this specific change for the ROL and ROR operations.
The correct functioning of ROL and ROR after this patch has been verified
by testing against the 65x02 test suite.
In sim65, simulator memory access to a 64 KB array is implemented via functions
defined in src/sim65/memory.h and src/sim65/memory.c.
In the old version, the types for both content bytes (8 bits), content words
(16 bits), regular addresses (16 bits), and zero-page addresses (8 bits) were
all given as bare 'unsigned'.
This lead to several cases of address overrun (e.g., when an instruction wraps
around from address 0xffff to 0x0000) when running the simulator against a
stress test (specifically, the 65x02 test suite). To protect from this, and to
more properly express the bit width of the types involved which is a good idea
anyway, we start using the fixed-width types provided by 'stdint.h'.
In the process, we also change the MemReadByte macro to a full function call.
This may impact performance (by a small amount), but it improves memory safety,
as cases where the address is accidentally expressed as a value exceeding 0xffff
are handled by wrap-around (as it is in the actual hardware), rather than causing
access outside of the Mem[] array where the 64 KB of simulated RAM resides.
The reason for this patch is twofold.
(1) It is a partial patch for issue #2539.
Several issues brought to the surface by running the 65x02 testsuite are
eliminated by these changes. In the discussion about this issue, it was
concluded that it is a Good Idea to use the stdint-types, both for the
simulated CPU registers and for the memory. This patch addresses the
memory-part of that change.
(2) It is a precursor patch for issue #2355.
For that issue, we will implement a memory-mapped timer register. This will
make handling of memory access in the simulator a bit more complex.
Having proper functions with the proper types in place will help to make the
timer register patch easier.
The BIT #imm instruction behaves differently from the BIT instruction with other
addressing modes, in that it does /not/ set the N and V flags according to the
value of its operand. It only sets the Z flag, in accordance to the value of
(A & operand).
This is corroborated in two ways:
- The 65x02 test suite;
- Documentation about BIT #imm such as http://www.6502.org/tutorials/65c02opcodes.html
This patch implements the correct behavior for BIT with immediate addressing.
The patched version passes the 65x02 test suite for 65C02 opcode 0x89.
Branch instructions, when taken, take three or four cycles,
depending on whether a page is crossed by the branch.
The proper check to determine whether the extra cycle must be added
is the target address of the branch vs the address immediately
following the branch.
In the former version of the BRANCH instruction handler, the target
address was incorrectly checked vs the address of the branch instruction
itself.
The corrected behavior was verified against a real 6502 (Atari) and
the 65x02 testsuite.
The JMP (ind) bug is present in the 6502 which is emulated by both the "6502" and "6502X"
emulation targets of sim65; specifically, the OPC_6502_6C handler. In the old code, the
bug-exhibiting code was not executed when the target was set to 6502X, which is incorrect.
the patch removes the (CPU == CPU_6502) check, which made no sense.
The JMP (ind) bug was actually fixed in the 65c02. Indeed, the OPC_65C02_6C opcode handler
has code that implements the 'right' behavior.
* Added a new pass that optimizes PHA/PLA sequences
* Added a new pass that optimizes AND/EOR/ORA when an operand is known
* Added a run of an existing pass at later stages to remove code that
otherwise goes unchanged.
* Handle binary operations in OptUnusedLoads in addition to real loads.
