home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!fhg!igd!kremser
- From: kremser@igd.fhg.de (Steffen Kremser)
- Newsgroups: comp.sys.atari.st
- Subject: Re: Use of the Falcon's DSP
- Message-ID: <1500@igd.fhg.de>
- Date: 11 Sep 92 10:00:38 GMT
- References: <1992Sep10.192157.1578@microware.com>
- Sender: news@igd.fhg.de
- Reply-To: user@machine.domain
- Organization: Haus der Graphischen Datenverarbeitung, 6100 Darmstadt
- Lines: 82
-
- In article <1992Sep10.192157.1578@microware.com>, erik@microware.com (Erik Johnson) writes:
- |> I have written an animation program that rotates images (ie. every pixel).
- |> If the DSP could be used as an image rotation engine, then I imagine that
- |> realtime animations could be created (now animations are compiled). By the
- |> way, the current code uses all integer math (of course), so writing DSP
- |> code should not be too tough.
- |>
- |> For this to work, the DSP would have to have full speed access to main
- |> memory; anyone know if this is so?
- |>
- |> Erik Johnson erik@microware.com
-
- No, it hasn't, for good (physical) reasons :
-
- - DSP adresses 64k Words (of 24 Bits), within
- 3 (possibly) distinct Adress spaces X,Y,PGM
-
- - "full speed access" means no_waitstates, no_shared_memory
- that's why the DSP has it's own FAST static RAM.
-
- You would need rather a lot of GLUE logic to make '030 and DSP share a common bus.
- i.e. Adress translation, Format conversion, bus arbitration,....
- And what for? the main bus is already crammed with the CPU, the Video System
- (incl. DRAM-refresh), optional '386 board, DMA access for HD,SCSI,Sound...
-
- But then, how IS the DSP linked to the rest of the system ?
-
- - the HOST interface : 8-Bit wide, with Handshake bits
- XBIOS calls provide interrupt driven block read (and/or) write
- operations, with or without blocking the calling process.
-
- - the SSI (synchronous serial interface) channeled through the sound system,
- whose DMA facilities should work for pixel data as well as for sounds.
-
- That way, DSP usage for Graphics should be similar to "normal" DSP usage :
-
- +-------------------------------+
- | DSP Program in harware loop |
- +-------------------------------+
- DATA IN ---->| arbitrary transformations |----> DATA OUT
- +-------------------------------+
- | DSP data (coefficients) |
- +-------------------------------+
-
- Data is fed through the DSP, which performs repeated online transformations.
-
- For example :
-
- - Viewing transformation :
- DSP setup : viewing matrix, viewing direction
- DATA in : 3D-Vectors (Object Coordinates)
- DATA out : 3D-Vectors (World Coo.)
- perhaps with flags for backfacing vectors.
-
- - Line by line Shading
- DSP setup : lighting model, lamps, material properties...
- DATA in : pre-sorted surfaces (triangles, meshes, perhaps NURBS)
- DATA out : pixel values
-
- - Ray tracing
- - Simulation (particle simulation ... flight simulation)
-
-
- And now for something completely different :
-
- The external SSI connection would allow a pipeline of !external! DSP boards.
- There are special chips for audio filtering used like this. (no complete DSP
- but just dedicated filtering stages).
-
- I'm not sure such an external pipeline would be worth its cost, but
-
- - the 56001 supports such small systems (internal RAM, bootstrap modes etc.)
-
- - While DSP's and fast SRAM aren't right now sold in sixpacks, with the growing
- DSP usage in telecommunications and consumer electronics, who knows ?
-
-
- ---------------------------------------------------------------------------------
- //// ----> Steffen Kremser <---------
- c-OO ----> kremser@igd.fhg.de <------
- | -~
-
-