A.D.A. Amiga Demoscene Archive

  Welcome guest! Please register a new account or log in

  

  

  

log in with SceneID

  

Demos Amiga Demoscene Archive Forum / Coding / Blitting into hardware registers

 

Author Message
Toffeeman
Member
#1 - Posted: 15 Jul 2006 20:06
Reply Quote
I once read somewhere that with AGA you can blit into address space dff000 and above. I got a feeling though this might have been a joke as I couldn't get it to work. I think he said you could blit to the colour00 register using a modulo of -2 and you would get 2,3,2,3 pixel sizes. Is this true ? If not what did the term blitter screen mean ?
Kalms
Member
#2 - Posted: 16 Jul 2006 00:15 - Edited
Reply Quote
I doubt that the blitter can write to the $dff000 range, even under AGA; the BLTxPT registers probably ignore the top 11 bits of data that you write (so $dff000 will be interpreted as $1ff000, a place close to the end of chipmem).

In any case the blitter is too slow to write enough data to update color00 every 2-3 pixels:

* The original A500 CPU clock (7.14MHz) corresponds to one clock cycle = one lowres pixel
* In both OCS & AGA machines, the chipbus is clocked at half the original A500 CPU clock speed => one chipbus cycle = two lowres pixels
* In both OCS & AGA machines, the blitter can utilize only every other chipbus cycle => one blitter access = four lowres pixels
* To update one colour00 register, one read and one write must be performed => one colour update = eight lowres pixels

To sum it up, the blitter is not even able to *read* the original colour data from chip memory at the suggested 2,3,2,3 pixel speed.

"Blitterscreen" was a C2P method with 2x1 or 2x2 output pixelsize that relied purely on blitter, sprites and hardware scrolling.

It did 2 or 3 C2P passes using blitter, and then performed the final 1-bit merge using the hardware scrolling. Every other pixel would get a totally bogus colour, and therefore the hardware sprites were employed as a "mask" which would blank out the incorrect pixels. To get more aesthetically pleasing results, the incorrect pixels would be placed in a checkerboard pattern (on odd lines the odd pixels are wrong, on even lines the even pixels are wrong); the stipple pattern that the mask sprites produce looks better than the blank vertical lines one would otherwise get.
The resulting image will look a bit darker than an ordinary image, with more bland colours, due to the dark stipple pattern.

The main advantage for blitterscreen was that the blitter passes were reasonably fast compared to having a 020/14 doing merges using the CPU. On the 040+, however, the merges go roughly at writespeed and thus letting the blitter do any scrambling doesn't really help. Also, many 68040+ demos like to run with 1x1 pixelsize, and the blitter is not really fast enough to do many of the merges on such a large dataset.

The original demonstration of Blitterscreen is available at: http://main.aminet.net/dev/src/blitscreen.lha (includes both horribly ugly source, and a demonstration executable)
Toffeeman
Member
#3 - Posted: 18 Jul 2006 01:35
Reply Quote
Toffeeman
Toffeeman
Member
#4 - Posted: 18 Jul 2006 01:39
Reply Quote
Thank for the reply.

8 pixels would make sense as that is how long it takes the copper to change colour as well.

The blitter screen explanation explains all those masked displays I saw in demos ! I thought they did this for cosmetic/style reasons and not to cover up random pixel colours !

 

  Please register a new account or log in to comment

  

  

  

 

A.D.A. Amiga Demoscene Archive, Version 3.0