[Coco] hardware scrolling

[Steve Bjork]

Simon,

Sorry for the delay on replying to your message, but life has kept me 
away from the list for over a month.

As I stated in my last post on this subject, I was changing the graphics 
mode.  At no time did I say anything about copying memory around for 
scrolling.

In the 1982 Canyon Climber game, the first round used changing of screen 
modes to shake the screen up/down to simulate an explosion. Please skip 
forward to about 55 second point on this video to view the screen shake...
http://www.youtube.com/watch?v=FXxwlXp5Lns

Bit of history: While James Garon was give game credit, the code was my 
creation.  Back in those days, Datasoft would only credit one person on 
a game. James did a bit of stuff here and there on CoCo titles but never 
got credit.  So, I let him take the Title Credit on Canyon Climber so he 
would get his name on a title screen.  Not till Sands of Egypt,  did 
everyone that worked on a game got title screen credit.

In 1984, I work on a little game called Desert Rider that scrolled the 
screen up/down with a bit more control.  This scrolling effect was to 
make the screen scroll down while your motor bike was jumping.  It also 
scrolled the screen down to change the screen to wipe away the game 
credit text.

Here is little video of Desert Rider...
http://www.youtube.com/watch?v=GlVFfWNgC_M

Both games only used some quick lines of code to change for the timing 
and changing the SAM registers.  The Desert Rider had better control of 
the screen scroll since it used the V-blank interrupt to trigger the 
start of the screen size change and counted H-blank interrupt for how 
long before switching back to the standard graphics mode.  This system 
took very little CPU cycles and allowed for a game to play while using 
this technique.  Your demo back in October only scrolled the screen 
without any CPU cycles left for real work like in a game or OS-9.  It 
been over a month since I look at the list and hopefully you worked on 
the code a bit since when.

The down side to this type of  scrolling that you are trying to reinvent 
is the changing size of the graphics display on the screen.  If you will 
note in the Desert Rider video, the title "Desert Rider" stretch in size 
as the screen scrolls down.  This is not a problem for Desert Rider 
since during game play the only part of the screen that stretch is the 
blue sky.  But any graphics at the top of the screen will grow in size 
as you scroll the screen.

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.

The other problem for horizontal scrolling is the CPU overhead.  Since 
every scan lines will need the CPU to change the SAM registers before 
the start of the scan line, this will take about 30% to 60% away from 
doing real work.  (That's the overhead of the h-blank interrupt on the 
CoCo 1/2.)

We old time CoCo programmers spend many a days, weeks and even months 
working on the CoCo back in the early 80's unlocking the secrets hidden 
within.  After all, it was our jobs! I'm not saying that we found 
everything the CoCo had hidden inside.  But, we did understand how the 
hardware works and how to trick it into things it was never designed to do.

I not saying that we found trick the CoCo could do.  But, a lot of what 
we found has been lost over the years.

The other problem, some of the tricks we found were not allowed to be 
used in software we sold to Tandy,  Why?  Tandy wanted make sure the old 
software worked on new versions of the CoCo.  As you know, some software 
that uses semi-graphics don't work on the CoCo 3 because that 
semi-graphics mode was not supported.  Think Plug & Power controller 
software for one.

By the way, using your "DMA" mode was a real No-No and Tandy would not 
buy software using it.

I say to you, keep playing with the CoCo and finding new ways to do 
stuff.  But, be careful saying "You are teaching the CoCo new tricks."  
It may be new to you, but others may of been teaching those tricks 30 
years ago.

Steve


On 10/26/2013 11:05 AM, Simon Jonassen wrote:
> Hey Steve...
>
> I beg to differ....
>
> The only thing i'm doing is shifting from 16 to 32 byte mode with 42 byte
> dma mode enabled on a per line basis....
> Then varying the raster split lines.... THERE IS NO SOFTWARE COPYING OF
> SCREEN RAM AT ALL !!!
>
> So if i'm not copying the bytes in software, then the hardware must be doing
> it for me !
>
> I would call that HARDWARE scrolling....
>
> The vdg/sam counters are being confused to give various effects....
>
> /Simon :-)
>   
>
> -----Oprindelig meddelelse-----
> Fra: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] På
> vegne af Steve Bjork
> Sendt: 26. oktober 2013 19:31
> Til: CoCoList for Color Computer Enthusiasts
> Emne: Re: [Coco] hardware scrolling
>
> I agree Nick, I've seen stuff like this while working on code that crashed.
>
> Not very useful with all that screen trash and the fact you spend all of the
> cpu time "scrolling" the screen.
>
> Now, I did make the screen shake in my Canyon Climber and scrolling in
> Desert Rider games for Tandy.  (Switching between 3K and 6K screen
> sizes.)  Even though the screen did scroll down, I would hardly call any of
> this stuff hardware scrolling by any means.
>
> In the years before the CoCo 3, we did a lot of "tricks" on the VDG/SAM to
> come up with new display modes.  Most of those tricks did not carry over to
> the CoCo3, so they been lost to the ages. It's a little like indoor pluming.
> The Roman Empire had it over 2,000 year ago and was lost of 100's of years
> because of the dark ages.
>
> As you know nick, the CoCo 3 can do true hardware scrolling. Marty's
> Nightmare and other CoCo 3 games are good examples.
>
> Steve
>
>
> On 10/25/2013 10:53 PM, Nick Marentes wrote:
>> This is not a new feature. It's been known. I just don't think that
>> anyone used it.
>>
>> Does anyone know of a CoCo 1/2 game that actually used the ability to
>> set start of video for vertical or horizontal scrolling? I think
>> everyone just used software which allowed for 1 byte movement. As it
>> stands, it jumps in increments of several bytes (6?).
>>
>> Also, same problem as the CoCo3 GIME... it moves the whole screen.
>>
>> Simon, your next challenge is split screen scrolling which I think the
>> VDG would be able to do by syncing on the horizontal scanlines and
>> changing the $FF22 at set points.
>
>
>