Date   : Thu, 29 Jun 2006 21:09:20 +0200 (BST)
From   : Johan Heuseveldt <johan@...>
Subject: Re: Torch Graduate (Was: PEDL Z80 Board)

Hi Jonathan,

On Tue 27 Jun, Jonathan Graham Harston wrote:
> Johan Heuseveldt <johan@...> wrote:
> > On Thu 22 Jun, Jules Richardson wrote:

> > > were aware of the special feature in the code. If you assert the
> > > interrupt line on the 1MHz bus early on in the boot cycle the MOS
> > > will execute the code in the 256 byte memory mapped window in the
> > > 1Mhz bus space in the memory map
> > 
> > In the past (many years ago) I've studied the MOS 1.20 code
> > extensively. I can't remember anything 'odd' that could now
> > suggest something like above. OTOH, it's just like trying to find
>  
> It's quite clear:

Yes, in the end it is! :-)

> ************** clear interrupt and enable registers of Both VIAs ********
>  
> DA6B  LDA #&7F    ;
> DA6D  INX         ;
> DA6E  STA &FE4D,X ;
> DA71  STA &FE6D,X ;
> DA74  DEX         ;
> DA75  BPL &DA6E   ;
>  
> DA77  CLI         ; briefly allow interrupts to clear anything pending
> DA78  SEI         ; disallow again N.B. All VIA IRQs are disabled
> DA79  BIT &FC     ; if bit 6=1 IRQ occured, then JSR &F055
> DA7B  BVC &DA80   ;
> DA7D  JSR &F055   ; F055 -> JMP (&FDFE) execute code in hardware
>                   ; I/O area

I've worked it out myself, although I'll need to express my great thanks
to Peter Coghlan: During correspondence by private email, he put me back
with both feet on the floor - several times, when I got carried away with
my findings but didn't get it right.


The major pitfall I ran into was the code for reading the keyboard links,
using &FC as a scrap location. That made me believe - for quite a while -
that is was related to the code mentioned above. I had the impression that
&FC was /still/ related to the keyboard links, and IRQ would destroy that.

It's the other way around: Using &FC in the routine to read the keyboard
links, is purely accidental [1]. Using &FC in the code above is essential,
as it is changed by the interrupt routine: The first thing the interrupt
routine will do, is saving A to location &FC, which can only be &7F in
this particular case. It makes bit6=1, while location &FC is normally
zero, being initialised ot zero during a small loop, zeroing locations
&E2 to &FF (at addr. &DA54)



I had similar remarks at the CLI/SEI - as above - in my heavily
annotated listing, but that isn't clear enough. In fact it is very
unclear: It suggests (to me) that legimate interrupts could occur
from within the Beeb. But it can't! That is an important key to
crasp: Everything is in a clear RESET state, not being able to
assert the IRQ line.

Both VIAs are accessed (in the code above), and put in a known state:
first interrupts are disabled, and then cleared. This is already done by
RESET. But on a RESET not being a PowerUp startup, the system VIA is not
reset, because its RES input is wired differently. So putting the value
&7F in both registers &D/13 (IER) and &E/14 (IFR) is essential, but seems
unnecessary for the USER VIA. In the end, a real IRQ can only come from
an external source, being the 1MHz bus or the TUBE.

As we now know, the MOS only assumes code in JIM, so using the TUBE to
assert IRQ isn't a valid option. That is: using TUBE connector only.

So the combination CLI/SEI will /never/ fire up the interrupt routine
from an internal source. The source of an asserted IRQ can only be a
possible device on the 1MHz bus, explicitly doing so, and for this
explicit reason in the first place. And that makes the difference
of bit6 in location &FC, reacted on.



There is a still a minor thing to be understood by me: Because the
interrupt is obviously not recognised, the asserted IRQ line remains
low. Inspite of that, the 6502 is not entering an endless loop. Instead
of entering the interrupt routine again, the SEI is executed, and the
code continues. 

I assume this is of the pipeline, and the the Program Counter already
pointing to the following next opcode? That is, there is always a
concepts of a current instruction to finish?

Obviously, the interrupt can only be cleared when the code in JIM
is called.


[1] If Acorn did it intentionally to confuse people attempting reverse
     engineering the code, then Acorn was quite successfull with me!


Greetings,
Johan

-- 
Johan Heuseveldt <johan@...              >
  aka  waarland

  The best place is a Riscy place
 
Blessed are they that run around in circles,
for they shall be known as wheels.