David Gatwood wrote:

> I hope that's not the case.

Me either! :-)

I could be wrong but I think some of the "consumer" level 040 Macs might 
have the "no settable interrupts" issue. Machines like the Quadra 405 
and the like. Those machines were based on the MEMCjr. We should 
probably check the code.

> Ewww.  Ewww.  Ewww.  Ewww.  Ewww.  On UNDERflow?

Basically, if the CPU can't keep up with the hardware either during read 
or write, a bus error is issued. I suppose an interrupt wouldn't work 
because you are already doing the processing in an interrupt handler.

Basically the hardware is 50% of a DMA engine. The CPU substitutes for 
the part of the DMA engine that runs the script to move data between 
ports. I don't understand why they did this. I can't imagine it would 
have been much more expensive to create a small ASIC to do this or even 
get a small 8 bit CPU or something. After all, there are dual 6502's in 
the IIfx! But, no use crying over spilled milk, I suppose.

>
> The bus flow on overflow should be safe, since it can only occur when the
> driver is actually pushing data into that chunk of RAM, right?

Ok, looking at Allen's excellent comments, it seems the bus error only 
occurs when you explicitly read or write the PDMA space and the esp 
can't fill/drain the FIFO for that read/write. So perhaps this can be 
done safely. Though, I would imagine that Allen shut off interrupts for 
the duration of the routine for some reason. :) He goes to a great deal 
of trouble to briefly open up interrupts to allow serial interrupts to 
happen before proceeding through the rest of the loop.

I think this is done for time sensitive reasons. Basically, when you 
start blasting data into or out of the PDMA region you don't want to be 
interrupted by antyhing. This might only be for speed reasons, but it's 
not clear. Hopefully Allen can enlighten us further.

> Assuming you mean AMIC DMA off a MACE, I rather suspect you're going to
> run into an alignment nightmare if you try to DMA directly into the
> mbufs.  AMIC is a fun little spawn of satan....

Actually, in this case, it's the PSC DMA engine. As far as I can tell, 
the DMA engine can send data anywhere as long as the base address is 
2-byte aligned and the memory is physically contiguous.

The DMA engine itself doesn't have command packets but it seems each DMA 
channel has its own DMA engine interrupt. The idea is to setup an 
interrupt handler with the bus_dma map for a virtual region. When the 
DMA interrupt comes in, the interrupt handler gets the next physical 
region in the bus_dma map and slams the DMA engine with the phys address 
and length, then restarts the engine. They do some similar stuff in the 
x68k and NeXT/68k ports.

That's phase III. :-) Right now, I'm just trying to get the PSC to DMA 
into a random physical address rather than a pre-allocated bounce 
buffer. Once that happens, I'd like to implement the above idea in 
general, and then apply it to both the SCSI driver and maybe the 
ethernet driver if I have the time. SCSI DMA into a bounce buffer works 
great, though, so I know how the hardware works.

> Like PowerPC's TBR?

Something like that, yes. That gives you a "wall clock" to look at. With 
a wall clock you can correct for missing interrupts like this:

- At the end of the last timer interrupt you stash the expected wakeup 
time which is wall_clock_now + timer_interval.
- At the next timer interrupt you check the wall clock against your 
stashed expected wakeup time. If it's more than some slop value away 
from the expected wakeup time, you lost some clock ticks. You then go on 
and try to calculate how many you lost by comparing the current wall 
clock, your expected wakeup, and your timer interval. Otherwise, you 
didn't miss a clock tick and you can act like you normally would.
- Rinse lather repeat.

-- 
----------------------------------------------
  Michael Zucca - mrz5149@acm.org
----------------------------------------------
  "I'm too old to use Emacs." -- Rod MacDonald
----------------------------------------------