In this case, I may already have the MoveUp code done as my original
assumptions were valid except for limits on 'Y' and 'LINES' which go from 23
to 192, *but* remain as a single byte and do not affect the logic.
Just to make certain we are on the same page:
'X' is byte position in GR 8 scan line, 0-38
'Y' is line position on GR 8 screen, 0-192
'LINES' is count of GR 8 lines to scroll, 0-192
'BYTES' is count of bytes per GR 8 line to move, 0-39
IE, routine moves a rectangular block that is 'BYTES' wide and 'LINES' scan
lines tall begining at GR 8 position 8*'X', 'Y' up or down by 8 scan lines.
Some other algorythm will check screen edge limits and clean up the 8 scan
lines which are not overwritten.
--
Ron
http://www.atariland.com/members/oldatarian
and mirror
http://www.powow.com/oldatarian
> when I want to scroll 8 lines of text in graphics 8, I had to let
lines=8*8.
> X is a value (0-39), it's already givven in bytes.
> > I have the logic completed for all but:
> > converting X (0-319) to a byte value (0-39)
> > manipulating bits for partial byte moves
> > screen edge and bottom limit checks
> > those last 8 scanlines on the move up process
> > X will be a 2-byte vale, *but* the high byte is always '0' or '1' to
> > represent bit values from 0-319. We just divide X by 8 to locate the
byte
> > offset and somehow extract bit offset from the remainder...
> > --
> > Ron
> > http://www.atariland.com/members/oldatarian
> > and mirror
> > http://www.powow.com/oldatarian
> > > It was the P*40 byte offset that led me astray; GR 8 squeezes 320 X
> > > positions into the same 40 bytes as each mode line of GR 0.
> > > Sounds like X can range 0-319 and Y as well as LINES could be up to
192.
> > > Since BYTES is limited to 40, only X will require 2 bytes and the
> > complexity
> > > should not increase too much, hopefully.
> > > BTW, moving mapped GR 8 text will involve some possible bit mangling
on
> > each
> > > end of each scan line of bytes.
> > > Also, what happens in the area below the last 8 scan lines which are
> moved
> > > up? Surely we do not want to leave those 8 lines duplicated on
screen...
> > > --
> > > Ron
> > > http://www.atariland.com/members/oldatarian
> > > and mirror
> > > http://www.powow.com/oldatarian
> > > > This routine should scroll some TEXT-lines in GR.8 up and down, so I
> > need
> > > > two routines, one to scroll up and one to scroll down. It's nearly
> like
> > > the
> > > > MOVE and the -MOVE commands.
> > > > Mirko
> > > > www.atarixle.de
> > > > > It looks more to a GR.8 (24) routine to me. By adding 320 you get
> the
> > > > bytes
> > > > > from 8 scan lines below, so the routine 'moves' a window 8 lines
up
> on
> > > the
> > > > > screen. There will be a problem when the window is on the bottom
of
> > the
> > > > > screen, since then it gets out of screen ram by the +320.
> > > > > Mirko, please explain what the routine should do, so we can make
> > correct
> > > > > code.
> > > > > Freddy.
> > > > > > Hi Mirko;
> > > > > > This looks like we are working with a GR.0 screen and copying
> > > rectangles
> > > > > of
> > > > > > text from a 'work' area into the display RAM.
> > > > > > --
> > > > > > Ron
> > > > > > http://www.atariland.com/members/oldatarian
> > > > > > and mirror
> > > > > > http://www.powow.com/oldatarian
> > > > > > > Can anybody translate this into fast assembler?
> > > > > > > 100 FOR P=0 to LINES-1
> > > > > > > 110 MOVE
DPEEK(88)+P*40+320+X+Y*40,DPEEK(88)+P*40+X+Y*40,BYTES
Quote:> > > > > > > 120 NEXT P
> > > ---------------------------------------------------
> > > > > > > so I could call it
> > > > > > > A=USR(move$,X,Y,LINES,BYTES)
> > > > > > > Thanks
> > > > > > > Mirko
> > > > > > > www.atarixle.de