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.
This change introduces a new command line flag, '-b', that cause the
simulator to halt on the `BRK` instruction. By default, however, the
simulator will no longer halt on `BRK`.
As before, this behavior can be toggled in the preferences at run-time.
So far as I can tell, ever since the first version of the ACIA emulation in
Symon, writing 0x00 to the control register has been interpreted as a request
to reset, rather than to actually set the control register to 0x00. This is
strange for a number of reasons:
- All-zeros is actually a very sensible value for the control register, and
is in fact the hardware-reset default.
- I can't find any description of such behaviour in the 6551, W65C51S, or
W65C51N data sheets.
- The 6551 already has a way to trigger "program reset" by writing to the
status register.
So I've removed that quirk, and writing to the control register now just
writes to the control register and nothing else.
The only description of the effects of "program reset" in the original MOS
datasheet is in the section for each register. The W65C51S and W65C51N
datasheets have a heading "PROGRAM RESET OPERATION", but it amounts to:
- internal registers are modified as described in the section for each register
- changes to the DTR, DCD, and DSR pins which Symon does not emulate
- the overrun flag is cleared
...which is what this new implementation does.
It would make *sense* for the reset to do things like "cancel transmission or
reception in progress" and stop asserting an interrupt, as the old code did,
but I can't find any evidence of such behaviour in the datasheets.
When describing the CPU's reset pin, the W65C02S data sheet says:
> All Registers are initialized by software except the Decimal and Interrupt
> disable mode select bits of the Processor Status Register (P) are initialized
> by hardware.
It then has a diagram of the power-on state of the processor status register:
> 7 6 5 4 3 2 1 0
> * * 1 1 0 1 * *
> N V - B D I Z C
>
> * = software initialized
Confusingly the text indicates that only the D and I flags are initialised by
hardware, while the diagram indicates that the B flag is initialised too.
Meanwhile, https://www.nesdev.org/wiki/CPU_power_up_state says that
the power-on state of the NES CPU is $34 (exactly matching the diagram above)
but https://www.nesdev.org/wiki/Status_flags#The_B_flag says that the B flag
does not physically exist within P register, it's only relevant in the copy
of P that gets pushed to the stack by BRK (set), PHP (set), or an interrupt
signal (cleared).
As a result, the most sensible power-on state for the processor status register
is with the "interrupt disable" flag set and everything else cleared.
A bug caused the video window to repaint only when the cursor was
blinking. This meant that if the cursor was disabled, the window would
never update!
This change removes the repaint logic from the cursor blinking timer,
and instead puts it into its own periodic timer callback that runs
independently of cursor blink.
* On Linux GTK+, the small text fields in the Status Panel displayed a
large inner margin, cutting off text. This change forces Java to use the
Metal look-and-feel for these fields, which forces no default inner
margin.
