| BRK-flag [message #137501] |
Tue, 05 April 2005 06:07  |
Ruud.Baltissen
Messages: 64
Registered: July 2003
Karma: 0
|
Member |
|
|
Hallo allemaal,
Experimenting with VICE I noticed something strange. In the monitor
mode the BRK-flag was 0. But stepping through the instructions PHP and
PLA A was $32 at the end, meaning the BRK-flag was set at the moment
of PHP. But the monitor command 'r' showed the BRK-flag was 0.
I realise that stepping is done by using the BRK instruction and that
this is the possible cause of the set BRK-flag. But then why doesn't
it show with 'r'?
But the reasob I started experimenting: the BRK-flag is set by the BRK
instruction. But what does it reset again? I couldn't find anthing
about it and the only thing I can think of is an IRQ.
Any comment is welcome!
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org
|
|
|
|
| Re: BRK-flag [message #137502 is a reply to message #137501] |
Tue, 05 April 2005 06:57  |
Martijn van Buul
Messages: 326
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
It occurred to me that Ruud Baltissen wrote in comp.emulators.cbm:
>
> But the reasob I started experimenting: the BRK-flag is set by the BRK
> instruction. But what does it reset again?
RTI. It pops the processor status from the stack, which got put there by
the IRQ and/or BRK.
--
Martijn van Buul - pino@dohd.org - http://www.stack.nl/~martijnb/
Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...' Isaac Asimov
|
|
|
|
| Re: BRK-flag [message #137503 is a reply to message #137501] |
Tue, 05 April 2005 13:26 |
Andreas Boose
Messages: 46
Registered: September 2003
Karma: 0
|
Member |
|
|
On 5 Apr 2005 03:07:09 -0700, Ruud.Baltissen@abp.nl (Ruud Baltissen)
wrote:
> But the reasob I started experimenting: the BRK-flag is set by the BRK
> instruction. But what does it reset again? I couldn't find anthing
> about it and the only thing I can think of is an IRQ.
Real machine:
Bit #4 (BRK bit line) of the processor interal 8bit flag bus reflects
the status of the clear_ir signal. This signal is used by the
interrupt logic to pull down the inputs of the instruction decode
matrix as all interrupts are entered by executing the $00 opcode.
To distinguish between a software interrupt caused by the normal
execution of the $00 opcode (BRK) and forced execution of the $00
opcode (IRQ/NMI) due to the interrupt logic the signal clear_ir is
saved to stack.
So effectively the BRK bit (one can only observe if saved to stack)
is just the state of the clear_ir signal at the moment the interal
8bit flag bus has been pushed to stack.
The default state of this signal is 1. Only if an hardware interrupt
forces the execution of the $00 opcode the signal is 0 (= pull down
decode matrix inputs).
This explains why the BRK bit saved on stack is 1 for BRK and PHP and
0 for IRQ and NMI (ignoring the NMI during BRK corner case).
Writing to BRK bit makes no sense (PLP) as this is no read/write flip
flop compared to decimal flag for example but just the (buffered)
state of clear_ir signal.
Emulator:
VICE does not maintain any explicit default state of the BRK bit. The
actual state of the BRK bit is only generated at the moment the BRK
bit is actually saved to stack. In all other moments it may be
invalid.
This is sufficient for proper emulation of the processor core. But of
course it can be missleading if watched through the internal monitor.
Basically the monitor should always report 1 for BRK bit as the only
case when it can be actually 0 is IRQ/NMI which does not show up as
opcode anyway.
MfG Andreas
|
|
|
|
Members
Search
Help
Register
Login
Home
