[Coco] hardware scrolling

Mon Oct 28 04:25:06 EDT 2013

Hey Torsten....

Firstly thank you for showing your appreciation ! - Some of the "been there
done that" comments had me slightly disheartened for a while until others
told me that they hadn't seen these techinques !

I would also like to say that my background is not 6809, but 6502 c64..... 

I hid away my coco back in 1987 and have first "rediscovered" it about 6
months ago......

What I will do now, is try to explain to you all how these "deceptively
simple" techniques do thier magic !

Firstly the overscan (sideborder routine) - took me ages to perfect ! 
-----------------------------------------------------------------------

Lets set up a graphichs mode - say G1R (which is a 16 byte mode).

Well, the vdg can shift mode or css anywhere on a scanline, so what happens
when we shift from G1R to G6R after a few cycles on a scanline ?

The vdg will continue the 16byte mode until it can shift to 32 byte, but now
that it's in 32 byte mode, it "has" to display all the bytes (internal
address counter)..... Where do these bytes go ? - the sideborder !!

Unfortunately this one is a "CPU HOG" because it has to be done on a per
scanline basis for as long as you want to display anything in the border !
But hey, who nees to display anything in the whole border ? 

Now onto the horizontal scrolling:
---------------------------------- 

This took about 2 or 3 weeks and some careful studying of the SAM/VDG
datasheets to perfect !!

Lets start by setting up a video mode - say G6R (colourset is what you want
it to be), see this mode is 256x192 and 1 bit of every byte represents a
pixel !

This would normaly be done by setting the mode on $ff22 (in this case #$f0),
and then setting the sam dislpay mode controls (V0/V1/V2) at $ffc0..$c5....
See a normal hires screen would have V1/V2 set.....

Now what happens if you also set V0 ? - apparently nothing.... (well, what
you can see is nothing), what actually happens, is that you are now in DMA
mode which has 42 bytes per line not 32 ! (you can't see these for now) !!
The other thing to note, is when you shift into DMA mode, the address
modifier logic of the SAM (V0/V1/V2) - specifically V0/V1 (V1 is Y modifier,
V0 is X modifier) becomes inactive...... So now we know that something is
happening to the address counter.....

So far, so good.... Now we will introduce our old friend the overscan
technique, or a variant of it....

Lets set up a "stable" raster routine (eg. Catch the Vsync and Hsync
pulses), so we wait for the Vsync, then count the Hsyncs until we hit the
first visible line (there are 312 lines for PAL and 262 for NTSC).

Why are we waiting for the first visible line i can hear you asking.....
Well, mode changes are only active on visible lines. And thats exactly what
we want to do, change the mode.... Back to our old friend the 16 byte mode
(wider pixels, same given area....) anyone starting to see a picture yet ?

See, what would normally happen would be a mode change to a lower resolution
- infact this still does happen, BUT remember that the address modifier
logic is now disabled... So if we hold the 16 byte mode for any given number
of cycles (lines), then shift back to the 32 byte mode (which is actually
42) the sam/vdg will pick up the next address in a different location.... 42
bytes wide now...

If you vary the delay between mode switch (in my case using the hsync as a
counter) then the screen will shift left or right.....

What we do have to remember though, is that the SAM also has provision for
page switching on 512 byte boundaries, and if you push the delay too far,
then you will hit one of the boundaries... Then you can switch page, reset
your delay and start again.....

GET THE PICTURE ?

Well, as for being cpu intensive, it can be if you make it so, but it
doesn't need to be....

It's really just one mode switch with a delay, so you can set the mode at
the start of one of the first visible scanlines, with varying delays to push
the bitmap back and forth, then you can reset the mode on a scanline before
it after the next Vsync......

I'm using the H/Vsync as i know it's stable and that it always starts in the
same place....

The first scroll routine uses 10 scanlines for 10 bytes of movement back and
forth, then it actually "wastes" the remaining scanlines in a loop waiting
for the right place to shift the mode..... 

No one is telling you to waste the cpu time - by all means, use it for what
you want !!!! - just shift the mode back at the appropriate time !

This routine relies on DMA and it being 42 bytes wide !!! 

As for showing you all a scroll routine without all the junk, here we go:

https://www.youtube.com/watch?v=wbJcu7srUF8

This image is a full 42 bytes wide (336 pixels)

This routine can also scroll a colour bitmap G6C , actually you can even
split the modes down the screen and vary the css as appropriate....

Hope this explanation will give you an insight into a "deceptively simple"
technique......

/Simon :-)

-----Oprindelig meddelelse-----
Fra: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] På
vegne af Torsten Dittel
Sendt: 27. oktober 2013 20:27
Til: coco at maltedmedia.com
Emne: Re: [Coco] hardware scrolling

Simon,

this looks really impressive. And I thought I had squeezed anything out of
the CoCo2 way back then... ;-)

Regarding the "yawn, had all allready been there..." which came up here
recently:

I claim I have seen a lot of VDG mode switching tricks on the CoCo and tried
out a lot myself (e.g. my Dragonfire "intro" with mixed modes, smooth hi-res
scrolling both horizontally and vertically and on-border segment coloring
and animation, http://www.6809.org.uk/tmp/da/pal_coco_probe/pal-
dragonfire-1.png ). Let's assume you're not copying bytes in memory to show
horizontal scrolling, and do not achieve this by keeping several "shifted" 
images in the memory, and do just "vertical page flipping" like in a flip-
book: I have never seen what you're showing in the last video as an effect
of SAM/VDG programming.

And what's even more impressive is that you can obviously truely "draw" on
the right border (not sure how difficult it is for a standard monitor to
catch such a video signal - some PAL color TV's did neither like the
Dragonfire intro thing because of a weird toggling of the color burst
signal).

If you ever manage to show a stable picture (without garbage), which is
wider than 256 pixel, I'm the first one to applaud.

I think the concerns which came up are related to the amount of CPU load it
takes to bring the SAM/VDG to what it's showing. If you have to write
several bytes per scanline to the involved registers to get a stable picture
(e.g. triggered by a Fast Sync interrupt), the CPU can hardly do anthing
else but showing that mode. This means you could not use it for an action
type game, however, there are programs where it could be useful, and if it
is "just" a demo / intro / slideshow etc., it would be still a great
achievement, assuming you could get rid of the garbage (e.g. fill the
involved memory areas with with monocolored pixels).

Currently, it looks like all you're showing is in "PMODE4,1:SCREEN1,0" 
(light green on dark green). I assume it would be even more fun to extend
this to other modes including color (or to the SCREEN1,1 variant).

Please don't stop having fun figuring this out - might be boring for some of
the guys who started with a CoCo3, but I'm a heavily interested follower...

Best regards,
Torsten

--
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.2242 / Virusdatabase: 3222/6285 - Udgivelsesdato: 27-10-2013