Re: KA630: how does console I/O actually work?

On 2023-12-26 16:03, Mouse wrote:
>> I think NetBSD is depending on taking the interrupt being enough to
>> clear the interrupt.  [...]
> 
>> And, indeed, that's what I see in simh's code.  [...]
> 
> A relevant comment in myu emulator code says
> 
>     * The info above (apparently from EK-KA630-UG-001) is at least
>     *  partially false.  The IE bits in RXCS and TXCS are not enables
>     *  for level-triggered interrupts; rather, the interrupts are
>     *  edge-triggered, interrupting whenever the function "IE & DONE"
>     *  (RXCS) or "IE & RDY" (TXCS) changes from 0 to 1.  This comes from
>     *  the VARM and also seems to be how NetBSD's kernel treats it.
>     *  This is why cons_intr exists: to record these interrupt requests.
> 
> I went looking for the basis for the "comes from the VARM" part.
> 
> Using EL-00032-00-decStd32_Jan90.txt as my reference, this appears to
> refer to tables 10-4 and 10-6, on pages 10-35 and 10-36.  Table 10-4
> says, of RXCS's IE bit,
> 
>        interrupt enable  <6>     Read/write.     Cleared     by     processor
>                                  initialization  and  by  being written zero.
>                                  If interrupt enable is set by software while
>                                  RXDB  Ready  is  already set, or if ready is
>                                  set by the console while Interrupt enable is
>                                  already  set, then an interrupt is requested
>                                  at IPL 14 (hex).  That is, an  interrupt  is
>                                  requested  whenever  the function {interrupt
>                                  enable AND ready} changes from 0 to 1.
> 
> Note in particular the last sentence.
> 
> Table 10-6 uses similar language when describing TXCS's IE bit.

The problem is that this isn't actually telling anything about if it is 
edge triggered or level triggered. Because that description is equally 
true for both. The important question is when is the interrupt request 
dropped. Is it dropped at interrupt acknowledge, or at the clearing of 
IE or DONE?

> I suspect these are the VARM reference I had for the idea that these
> interrupts are, in at least this respect, edge-triggered.

Well, note the sentence in VARM that I previously quoted:

Underlying the VAX architectural concept of an interrupt is the notion 
that an interrupt request is a static condition, not a transient event, 
which can be sampled by a processor at appropriate times. Further, if 
the need for an interrupt disappears before a processor has honored an 
interrupt request, the interrupt request can be removed (subject 
implementation-dependent timing constraints) without consequence.


Note the last sentence which implies that there is no memory. The 
interrupt happens if it's at the interrupt level. If the level goes back 
up, the interrupt request is dropped, and the CPU will never know. Ie. 
level triggered.

Also, for RX, it's pretty clear in the simh code that the interrupt 
request is removed when DONE or IE is cleared.

But I'm still at loss for how TX works based on what I've seen so far.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol