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?
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.
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.
This PR is mostly a complete rewrite of the emulator for 6502/65c02 opcodes.
It provides an easier to maintain implementation of the instructions, by using few macros rather than having hand-written code for each function.
All undocumented, previously missing opcodes for 6502 are also implemented.
The patch also includes a detailed documentation of those opcodes, for reference to developers.
This PR should fix one of the milestones listed here for the next version of CC65:
https://github.com/cc65/wiki/wiki/Before-the-next-release
MaxCycleCount is accounted by countdown, eliminating the 1-instruction-overhead issue, and removing the need to compare against a growing TotalCycles.
Makes main.c responsible for counting total cycles, instead of 6502.c, so the size of MaxCycleCount etc. is fully determined in one location.
Makes error.c responsible for PrintCycles instead of paravirt.c, so that it can be treated globally instead of
Return value of main() should be SIM65_ERROR because it is unreachable by design.
* The pointer wraps around the stack page.
* The break flag exists on only the stack, and only after an interrupt.
* 65C02 interrupts clear the decimal-mode flag.
The sim65 source code has been a construction site for over a decade.
I was looking for a simple cc65 program execution environment for
regression tests. So I decided to re-purpose sim65 for that task by
removing about everything but the 6502 emulation.
There's no memory mapped i/o emulation whatsoever. Rather exit(),
open(), close(), read() and write() calls are supported by mapping
them through a thin paravirtualization layer to the corresponding
host os functions.
Note: The sim65 6502 emulation provides means to switch between
6502 and 65C02 emulation but currently there are no actual 65C02
opcodes implemented.
