> At 11:07 AM 11/3/97, nigel@ind.tansu.com.au wrote:
> >...
> >> Maybe by the time NetBSD hits 1.4 things will be in great shape and we'll
> >> have 100% hardware support (ok, maybe we won't have the DSP's going in
> >> the AV's but too bad :)
> >
> >        Too bad? I want DSP support damnit! I sure as hell can't program
> >for the DSP (easily) under MacOS.
> 
> I second, in theory anyway.  The AT&T DSP32 was a *really* hot chip in its day.

Well, the trouble with DSP support is that it is a raw co-processor. So you
can really just about send it anything.

This really goes beyond kernel support so a good idea for support would
be a kernel device that simply locates and maps in the DSP. Then in user
land an app could ask via an IOCTL what the base address and size of the
DSP region is, map it in, and do what it wants. This could be something
like loading in a real-time scheduler of it's own. I'd imagine somebody
could make a library that has calls like:

dsp_code *code ;
dsp_results *results ;
int priority = 1 ;

handle = acquire_dsp() ;
load_scheduler(handle) ;

code = load_dsp_code(fd) ;
run_dsp_code(handle, priority, code, results) ;

If anybody wants to take on this project please keep in mind that there
were NuBus cards by Radius that had AT&T DSP chips on them for Photoshop
acceleration. So a "driver" would have to deal with NuBus cards as well.