[Coco] hardware scrolling

[Simon Jonassen]

Hey Steve !

I hear what your saying... 

If i see a "glitch" on the screen when i play with the vdg/sam, i'm at it
like a dog with a bone until i get it to work ! - in the 80's i programmed
demos etc for the c64....

But at the same time, alot of people might not have seen all these tricks
that you are saying have been lost to the eons of time.... 

So my re-inventing the wheel and making the sourcecode for it freely
available might help these tricks survive !

Another thing, why was the "DMA" mode such a big no no ???????? - it's in
there and it can be exploited.....

Just my 2 cents

/Simon :-)


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

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.
>
>
>


--
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: 3629/6381 - Udgivelsesdato: 30-11-2013