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: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol