Re: IRQ's in Amiga VSTa

[newsham@zang.kcc.hawaii.edu (Tim Newsham) writes:]

>It looks like the current IRQ handling scheme is not well suited
>to the amiga archetecture. I think I may have to use an aditional
>scheme (keeping the current scheme for where it is useful). To
>explain why let me first explain how amiga interupts are handled
>(to the best of my understanding).
>
>The 680x0 cpu family has 3 interupt lines used to signal an
>interupt on any of 7 levels. The interupts are prioritized,
>0 being non-interupt state, 7 being non-maskable interupts.
>When an interupt comes in the cpu sets a mask for all interupts
>at that level and lower. Higher priority interupts may occur
>but not lower. There are 7 interrupt vectors for these 7
>levels of interupts.
>
>The amiga has additional hardware which handle interupts before
>they ever reach the cpu. All external interupts are connected
>to this chip and translated to one of the cpu levels. The custom
>chips also have a number of internal interupts they can generate.
>There is a mask register for masking individual interupts and
>another register that is readable for determining what interupt
>lines are active. Here is a list of the interupts as seen
>by the custom chips:
>
>Level1 TBE - serial port transmit buffer empty
> DSKBLK - disk block transfer
> SOFTINT - software generated interupt
>Level2 CIAA - CIA A. This chip has its own interupt register
> and mask.
> PORTS - external interupts
>Level3 BLIT - blitter interupt
> COPER - coprocessor graphics interupt
> VERTB - vertical blanking interupt for video
>Level4 AUD1 - Audio channel interupts
> AUD2
> AUD3
> AUD4
>Level5 RBF - serial port receive buffer full
> DSKSYNC - disk sync pattern found
>Level6 CIAB - CIA B. This chip has its own interupt register/mask.
> EXTERN - external interupts
>Level7 NMI - non maskable interupts
>
>The internally generated interupts all fit in well with the
>message passing interupt scheme. The kernel can parse out the
>interupt type from the custom chips and the CIA chips to determine
>what exactly caused the interupt and send an ISR message with
>this information. The problem I am having is with the externally
>generated interupts.
>
> - Many devices may share the same interupt types "EXTERN" and
> "PORTS". (I suppose "NMI" also but I dont think they are
> used).
> - These interupt states are generated externally and may
> not be turned off by the kernel without the kernel knowing
> the hardware in question.
>
>What is happening to me currently is I get a PORTS interupt from
>my SCSI card (for dma). The kernel catches it as PORTS and
>queues up a message to the process. The kernel then returns from
>the interupt service routine but since the hardware line is
>still being driven high the interupt occurs immediately after
>returning. This causes the kernel to keep looping in the interupt
>service routine. No processes run, just about the only thing
>that still runs is the hard clock which is at a higher priority.
>The alternatives I have thought of at this point are:
>
> - Put Device drivers in the kernel. This is highly undesireable.
> - Put support for more devices in the kernel. Parse out
> the interupt types further. This means each time a new
> device driver is written the kernel has to be modified.
> - Add a mechanism for loading code into the running kernel.
> This is no simple feat and may make the kernel a bit larger.
> - Disable the specific interupt type before delivering the
> message. This requires that the process itself reenable
> the interupt when it is done or notifies the kernel that it
> may reenable the interupt. This scheme doesnt allow for
> different processes to receive interupts through the same
> vector.
> - Make a registry of interupt services for the PORTS and EXTERN
> interupts. When an interupt occurs, call each of the service
> routines in turn until one returns true indicating that the
> interupt was intended for it.
>
>I like the last alternative the best. This is how the amigados
>microkernel handles this. The problems I see are:
>
> - The kernel must find the process, switch to it and do some
> sort of jump into its address space.
> - The code will be running at a high priority level and maybe
> in priveledged mode.
> - There seems to be lots of room for something to go wrong
> if the handler is faulty.
>
>I'm not sure how all the details would work out.
>
>Comments? (many hopefully)....

(I usually don't quote whole messages, but I thought the list would be
interested in the progress of an Amiga port)

This is exactly the problem the HP 300 port was faced with. I was planning
on dumping P-code as a part of the interrupt registry. The P-code would be
just sufficient to query hardware, check/clear bits, and report a boolean
value back. The kernel interrupt handling would recognize a level which had
various P-code registries, and would call each registry. When one returned
"true", you'd queue up the ISR message for his associated server.

This was my theory. I'm still looking for time to try it in practice on a
300. The priority's somewhat lower since your 68k port already does most of
the "proof of portability" I was looking for. BTW, I'll want to take you
out to dinner when next you pass through the SF Bay Area!

                                        Regards,
                                        Andy
Received on Thu Nov 10 17:00:56 1994