This change adds a new "Step Over" button, which is enabled
when a "JSR" (Jump to Subroutine) instruction is encountered
while stepping through execution one instruction at a time.
Pressing "Step Over" will continue running instructions until a
corresponding "RTS" (Return from Subroutine) is encountered.
While stepping over a subroutine, the call stack depth is tracked
in an attempt to halt only when the *correct* RTS is encountered.
In other words, it should skip over other subroutines nested
inside the call you want to step over:
```
JSR A # Step over here...
...
JSR B
...
RTS # Returns from 'B', doesn't halt
...
RTS # Returns from 'A', halts after return
```
Implements feature request #18.
- IR field in status panel now correctly displays the next instruction
to be executed, instead of the instruction that was just executed.
- Switched from built-in Java util logger to Logback
- Updated all copyright strings to 2016
The simulator now passes Klaus Dormann's 6502 Functional Test suite for
the first time.
Bug Fixes:
- PHP was not correctly setting the Break bit on the stack copy of the
processor status, so subsequent PLA's would not set the Break status
flag.
- The CPU had swapped NMI and IRQ reset vectors, so RTI was failing.
- BRK was pushing PC + 2 onto the stack, instead of PC + 1
- (Zero Page,X) addressing mode did not correctly wrap on zero page
boundaries.
- The instruction table used for disassembly had addressing modes
of LDA $B9 and $BD reversed. This did not affect behavior, only
disassembly of these instructions.
Other:
- Updated copyright date for 2013.
- Started migrating old JUnit 3 style tests to JUnit 4 annotations.
I was alarmed to discover just how slow `String.format()` is for doing
integer to hex conversions. Now that a trace window has been added to
Symon, it became especially clear that I needed a more efficient way to
handle it.
I looked into using `Integer.toHexString()`, but I would have had to
wrap it to do zero-padding, so I decided to just bite the bullet and do
my own with a lookup table. The implementation in `HexUtil` is just as
fast as `Integer.toHexString()`, but also zero-pads appropriately.
Combined with Java's `+` String concatenation, it seems perfectly
adequate.
For yet better performance with the trace window, it would make a lot of
sense to special-case stepping so that it just pops the top line off the
log, and appends to the bottom, rather than re-stringifying the entire
trace log each time. This will be a future enhancement.
Introduces an execution trace window that will keep track of the most
recent 10000 execution steps. I'm not entirely happy with the
implementation, yet.
This is something of a "Work in Progress" checkpoint of several features
that are all half baked:
1. Allow loading of 16KB ROM files at address $C000 at run-time, not
just at startup. See the "Load ROM..." File menu item.
2. Introduces the notion of "CPU Behaviors", so the core 6502 CPU
implementation can match the behavior of either an early NMOS 6502, late
NMOS 6502, or CMOS 65C02. Very little of this is actually implemented so
far.
3. Adds a completely bogus implementation of the 6522 VIA (it
does absolutely nothing right now).
4. Changes the address of the ACIA in the simulated system to match a
real hardware implementation I put together.
RuiFPB
Seth Morabito