[Coco] hardware scrolling

[Steve]

It may do what you say and I can only take you word since I don't have a 
CoCo system setup for assembling code.  (My CoCo development gear was 
stolen from my storage unit.)

But looking over your code I see that it use 100% of the CPU cycles to 
kill the boarder.  In other words, not too useful since you can't do 
anything else while the CPU is spending it time tricking the screen.  
There are times when the CPU is waiting in a SYNC command and could a 
little work then.  As for using Interrupt to do the video code, it may 
or may not work since the timing is so critical.  Even so, the CPU will 
spend 50% to 70% doing the video trick.  Not much CPU power leftover for 
a game or OS-9.

But the question that Mathieu had was changing the size of the Left 
marge to slide of the screen by 1,2,or 3 dots to the right. Since your 
code only turns on/off the right marge is completely useless for this 
discussion.

The VDG/SAM are simple circuits and playing around with their control 
ports will make them act in ways they were never design to.  But the 
real TRICK is not causing them to look like a crash screen but something 
that is useful.  Try spend a little time on cleaning up what is 
displayed on the screen so it nice and clean. I know you can do it.

A quick programming note:  The cmpx #0 is not needed in your code since 
the leax -1,x will effect the Zero flag.  This also true for the leay, 
but not leau or leas since the zero flag is not effected during stack 
register operations.

Steve

On 12/9/2013 11:12 AM, Simon Jonassen wrote:
> Hey again...
>
> This routine will remove the right hand side border for all 192 lines:
>
> http://roust-it.dk/coco/john/border.asm
>
> You may need to adjust the timing for NTSC/PAL
>
> Currently the routine is NTSC...
>
> It's in hires mode....
>
> It breaks the right hand border by fooling the VDG by shifting from 16 to 32
> byte mode....
>
> YES IT HAS BEEN TESTED ON REAL HARDWARE !!! (PAL COCO IIB 64K ECB)
>
> /Simon :-)
>   
>
> -----Oprindelig meddelelse-----
> Fra: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] På
> vegne af Simon Jonassen
> Sendt: 9. december 2013 20:00
> Til: 'CoCoList for Color Computer Enthusiasts'
> Emne: Re: [Coco] hardware scrolling
>
> 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
>
> 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
>
>
>