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

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>>                                  at IPL 14 (hex).  That is, an  interrupt  is
>>>                                  requested  whenever  the function {interrupt
>>>                                  enable AND ready} changes from 0 to 1.
>> I don't, however, see any language implying that the interrupt
>> request is - or isn't - rescinded if DONE or IE is cleared before
>> the interrupt is taken.  I don't rescind them.  simh does.  NetBSD
>> seems to tolerate either (not surprising).
> Well, this whole thread started because you noted that NetBSD does in
> fact not tolerate your implementation under some circumstances...

There are at least three versions of "[my] implementation" under
discussion here: (1) a pure level-triggered version; (2) an
edge-triggered version which (2a) doesn't or (2b) does clear the
request state bit on I/O reset.  We can, for sake of discussion, add
(3) which is just like (2b) except that it clears any untaken interrupt
request if the RDY&IE function drops to 0.

(1) goes into a TX interrupt livelock once NetBSD finishes autoconf and
goes to userland.

(2a) works in most circumstances, but fails when rebooting after halt.

(2b) works in every test case I've tried so far.

(3) is what simh does, I think; the code I have makes it look that way
to me, at least.  None of my versions do this.

I first implemented version 1, ran into the livelock, and turned it
into version 2a.  Back at the beginning of this thread, I dug into the
issue, determined what was behind the crash, and created version 2b.
That's what prompted my post.

At this point, I'm moderately sure the TX hardware acts edge-triggered
in that taking the interrupt clears the interrupt request even if RDY
and IE are both still set.  simh acts level-triggered in that clearing
RDY or IE will withdraw any pending (ie, not yet taken) interrupt
request; my code is pure edge-triggered, in that a pending interrupt
request cannot be withdrawn except by taking the interrupt or doing an
I/O reset.  NetBSD and the ROMs appear to be tolerant of both 2b and 3.

The VARM contains language implying each way, thus arguing that simh's
model is more accurate.  Real hardware clearly has at least one bit of
state (for TX; we don't have any particular evidence either way for RX,
at least not based on what I've seen here), so the simplest hardware
implementation would be pure edge-triggered - to clear the state bit
when RDY&IE drops would probably mean additional circuitry.

But those arguments are relatively weak.  That's why I'm trying to find
out whether simh's code or mine is a more accurate model of the
hardware: is it pure edge-triggered, or is it a mashup, edge-triggered
in some respects and level-triggered in others?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B