Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!motcsd!starnet!sschaem
From: sschaem@starnet.uucp (Stephan Schaem)
Newsgroups: comp.sys.amiga.graphics
Subject: Re: Colorburst and Animation
Message-ID: <1991Mar19.190444.4250@starnet.uucp>
Date: 19 Mar 91 19:04:44 GMT
References: <13948@life.ai.mit.edu> <1991Mar14.231042.26446@ncsu.edu> <14058@life.ai.mit.edu> <1991Mar17.131751.2152@ncsu.edu>
Organization: Starnet-Public Access UNIX-Los Altos,CA 415-949-3133, login:info
Lines: 33


 
  Talking about 68000 cycle for calculating Colorburst transfere is
   totaly wrong!.
    You dont need to cut the video DMA and use the processor to replce
     it by write data yourself.
      Since Colorburst is on the RGB port, th only way to send data is
       with the video processor or bypassing the dma (if you need to get
       data from the 32bit memory).
	
	 I already wrote a post with the actual figure.and you get a
	 320x200x24
	  at 30 frame second.and a 640x400x24 at 7 frame second (full
	  screen
	   animation).
	    Using hires 'overscan' data 'transfere'.
	     
Video DMA access the chip bus every cycle, not the 68000.And again the
CPU will be use the do transfer over the RGB port for non chip data (
and only 4 time slower from my tests).

Colorburst use the bus at the same rate has a 4bit DCTV overscan display
but update frame 6 time slower.(1 buffer example, if both are in chip).
DCTV simply change the dma adress, and first time it pass trought the
RGB port its displayed But you need 6 more pass for Colorburst.

You have 192 bus cycle per HLine, and let set YLine to 250.
thats 5760000 bytes transfer per second.a 320x200x24 is 192000bytes
and if you divide... you get 30, 30 frame seconds...
30 frame second is VERY nice! and you can get 15 frame second in
320x200x24 with 0 bus cycle stolen from the 68000!!!
So you can update/create/decompact/read you next frame while display the
previews one, transfering the curent...