Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!geech.gnu.ai.mit.edu!rjc From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell) Newsgroups: comp.sys.amiga.programmer Subject: Re: Information on Amiga Technical Reference Seri Message-ID: <1991Jun20.062054.6805@mintaka.lcs.mit.edu> Date: 20 Jun 91 06:20:54 GMT References: <1991Jun17.144051.3418@sugar.hackercorp.com> Sender: news@mintaka.lcs.mit.edu Organization: The Internet Lines: 37 In article caw@miroc.Chi.IL.US (Christopher A. Wichura) writes: >In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>>> The apps that use routines done this way won't at all break under future >>>> OS revs or anything. >>> >>>How do you know? >> >>Because you won't be relying on how the OS works. You will have code that is >>guaranteed to work (as long as you allocate your resources correctly) embedded >>in your application instead of external where CBM might muck it up. > >And what happens when we get DIG? If you've done an OwnBliter() and played >your own little games instead of using graphics.library functions (or a >combination thereof, as may be needed) then the chance for a DIG board to >translate that blitter job to something of its own goes down the tubes. Not really, there is a kludge (actually 2 kludges) that a board and DIG can add for "old" apps. 1) Have the board use Amiga chip ram for it's buffer 2) Copy the Amiga's screen(bitmap ram) occasionally to the board's onboard buffer (slow). Colorburst does this and so does the A2024. Colorburst is probably limited to 10hz refresh in it's highest res/color mode. >-=> CAW > >Christopher A. Wichura Multitasking. Just DO it. >caw@miroc.chi.il.us (my amiga) ...the Amiga way... >u12401@uicvm.uic.edu (school account) -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /