[Coco] hardware scrolling

[Simon Jonassen]

Hey Steve...

I BEG TO DIFFER AGAIN !!!!

I actually have a routine that will obliterate the right hand border for any
given number of scanlines, and display graphics in the "overscan" portion
where the right border should be....

/Simon :-)
 

-----Oprindelig meddelelse-----
Fra: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] På
vegne af Steve
Sendt: 9. december 2013 19:08
Til: CoCoList for Color Computer Enthusiasts
Emne: Re: [Coco] hardware scrolling

On 12/8/2013 2:55 PM, Mathieu Bouchard wrote:
> Le 2013-12-01 à 00:18:00, Steve Bjork a écrit :
>
>> Now, on the subject of horizontal scrolling.  This system of changing 
>> the pointer to what byte will be read at the start of a scan line 
>> does change the source of the graphics data.  But that's not the 
>> change what bits of the byte to start with. The VDG must use the same 
>> one or two bits of a byte to create the first dot.  (It can not 
>> "scroll" them.) So, you must scroll on 4 or 8 dot boundary based on 
>> the color mode being 4 or 2 colors.  If in TEXT mode, the scroll 
>> would be by character (8-dots) and not by one dot at a time. Sorry, 
>> but scrolling on every fourth or eighth dot is not hardware scrolling.
>
> Is there any way to change the size of the left and right borders ? If 
> you do so for a whole picture by an amount of 0 to 3 pixels wide, you 
> can combine it with a every-fourth-dot scrolling to make smooth 
> scrolling in almost all of the picture.
>
> Playing with borders has been done extensively with VGA and Amiga, but 
> I don't know whether it's possible on CoCo, and to which extent (or 
> maybe I just don't recall).
>
No, you can not change the size of the marge on a CoCo 1/2.  Even it you
could, you would jump every 4 or 8 dots when you started the next byte over.
To do hardware scrolling the VDG would need to be able to change what bites
are used for what dot on the screen.  The VDG used the same
bit(s) in the byte for the first color dot and then shifts the data (from
the byte) for the next dot and so on.

The CoCo design to shared the memory between the CPU and VDG.  (Most games
systems at the time use two memory systems, one for CPU and one for Video.)
Since both memory bandwidth and size was very limited at the time, there was
no time left for fancy VDGs that read more the Bitmap display memory in any
but byte by byte in a row of graphics.

Systems like Atari 400/800 and Commodore Vic 20 and 64 used character
(block) graphics system.  This was simlinar to the text screens of the CoCo
that would display an 8 by 8 block of graphics select by the number stored
in the screen memory.  The advantage over the CoCo text mode is the the
"blocks" (Characters) data were stored in ram and easy change by the CPU.
It was common to have hardware scrolling and sprites because of the lower
memory bandwidth and size needed by this type of display system.

Like the CoCo, Apple and IBM all used standard Bitmap graphics for their
Hi-res Graphic displays because of there ease of design. (Very simple VDG
and memory circuit design.)

Even today's 3-D graphics systems have a Bitmap display at the heart.  
It's just the have lots of hardware that draws the image on to the Bitmap
memory known as the frame buffer.

Steve


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco
-----
Ingen virus fundet i denne meddelelse.
Kontrolleret af AVG - www.avg.com
Version: 2012.0.2247 / Virusdatabase: 3658/6404 - Udgivelsesdato: 09-12-2013