Well, this is embarrassing.
I have found a bug in Munch and Crunch.
It no doubt explains the occasional glitches I have seen. Its a fault in my simplistic return from interrupt:
loda,r0 STOREPSL
lpsl
loda,r0 STORER0
rete,un
The problem of course is that the condition code in the PSL gets changed by the final load instruction. Having looked at other disassemblies I must say that I’m impressed by how the AND $C0 to a copy of PSL correctly restores the condition code. The condition codes and their position in PSL were obviously carefully chosen when designing the processor. From Blackjack:
start_interrupt:
stra,r0 PRESERVER0 ;PRESERVER0 = r0
ppsl $12 ;bank 1, logical compare
spsl
stra,r0 PRESERVEPSL ;save PSL with bank 1 already selected!
..........
end_interrupt:
loda,r0 PRESERVEPSL ;
strz r4 ;put a copy of PSL in r4
lpsl ;restores psl (but with bank 1 still
; selected)
loda,r0 PRESERVER0 ;restore r0 (but probably changes the
; condition code)
andi,r4 $C0 ;this restores the condition code!
cpsl $10 ;switch to bank 0
rete,un ;
If it isn’t clear how that AND operation works, and it wasn’t to me, it’s because the condition code is in bits 7 and 6 of the PSL. Their binary values (00=zero, 01=positive, 10=negative) correspond to the result of the AND $C0 operation:
00000000 is zero,
01000000 is positive,
10000000 is negative.
I don’t know why they set logical compare, but perhaps that is all their program uses? For a more general purpose procedure, that should surely be
ppsl $10
The 2650B with its LDPL and STPL instructions that allowed the PSL to be saved directly to memory were a big improvement.