I need another assembler routine

I need another assembler routine

Post by Mirko Sob » Sat, 12 Oct 2002 23:00:08



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
120 NEXT P
-------------------------------------------------------------------

so I could call it
A=USR(move$,X,Y,LINES,BYTES)

Thanks
Mirko

www.atarixle.de

 
 
 

I need another assembler routine

Post by Freddy Offeng » Sun, 13 Oct 2002 01:21:36


Yes. ;-)

Freddy.


Quote:> 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
> 120 NEXT P
> -------------------------------------------------------------------

> so I could call it
> A=USR(move$,X,Y,LINES,BYTES)

> Thanks
> Mirko

> www.atarixle.de


 
 
 

I need another assembler routine

Post by Ron Hamilto » Wed, 16 Oct 2002 05:51:12


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. Can we assume that X and BYTES
are 0-39 and that Y and LINES are 0-23 or at least require a single byte in
the range less than 255?

This routine would be simpler in fixed address code using some JSRs, but can
be accomplished in a relocatable string with a bit of creativity. I would
put the indirect indexed stuff in the floating point registers FR0-FR1 since
the routine is stand alone and reset with each USR call.

--
Ron

http://www.atariland.com/members/oldatarian
and mirror
http://www.powow.com/oldatarian

Quote:> 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
> 120 NEXT P
> -------------------------------------------------------------------

> so I could call it
> A=USR(move$,X,Y,LINES,BYTES)

> Thanks
> Mirko

> www.atarixle.de

 
 
 

I need another assembler routine

Post by Freddy Offeng » Wed, 16 Oct 2002 06:49:41


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. Can we assume that X and
BYTES
> are 0-39 and that Y and LINES are 0-23 or at least require a single byte
in
> the range less than 255?

> This routine would be simpler in fixed address code using some JSRs, but
can
> be accomplished in a relocatable string with a bit of creativity. I would
> put the indirect indexed stuff in the floating point registers FR0-FR1
since
> the routine is stand alone and reset with each USR call.

> --
> 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
> > 120 NEXT P
> > -------------------------------------------------------------------

> > so I could call it
> > A=USR(move$,X,Y,LINES,BYTES)

> > Thanks
> > Mirko

> > www.atarixle.de

 
 
 

I need another assembler routine

Post by Ron Hamilto » Thu, 17 Oct 2002 01:51:41


Well, Freddy; that does sound more like what Mirko would be doing.

I had relocatable code down to 112 bytes using single byte arguments and no
limit checks on edge of screen stuff. Need to establish our environment
before before we debug and verify functionality and optimize size and
flow...

--
Ron

http://www.atariland.com/members/oldatarian
and mirror
http://www.powow.com/oldatarian

> 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. Can we assume that X and
> BYTES
> > are 0-39 and that Y and LINES are 0-23 or at least require a single byte
> in
> > the range less than 255?

> > This routine would be simpler in fixed address code using some JSRs, but
> can
> > be accomplished in a relocatable string with a bit of creativity. I
would
> > put the indirect indexed stuff in the floating point registers FR0-FR1
> since
> > the routine is stand alone and reset with each USR call.
> > --
> > 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
> > > 120 NEXT P
> > > -------------------------------------------------------------------

> > > so I could call it
> > > A=USR(move$,X,Y,LINES,BYTES)

> > > Thanks
> > > Mirko

> > > www.atarixle.de

 
 
 

I need another assembler routine

Post by Mirko Sob » Thu, 17 Oct 2002 03:44:40


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. Can we assume that X and
> BYTES
> > are 0-39 and that Y and LINES are 0-23 or at least require a single byte
> in
> > the range less than 255?

> > This routine would be simpler in fixed address code using some JSRs, but
> can
> > be accomplished in a relocatable string with a bit of creativity. I
would
> > put the indirect indexed stuff in the floating point registers FR0-FR1
> since
> > the routine is stand alone and reset with each USR call.

> > --
> > 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
> > > 120 NEXT P
> > > -------------------------------------------------------------------

> > > so I could call it
> > > A=USR(move$,X,Y,LINES,BYTES)

> > > Thanks
> > > Mirko

> > > www.atarixle.de

 
 
 

I need another assembler routine

Post by Ron Hamilto » Sat, 19 Oct 2002 04:48:20


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
> > > > 120 NEXT P
> > > > -------------------------------------------------------------------

> > > > so I could call it
> > > > A=USR(move$,X,Y,LINES,BYTES)

> > > > Thanks
> > > > Mirko

> > > > www.atarixle.de

 
 
 

I need another assembler routine

Post by Ron Hamilto » Sat, 19 Oct 2002 06:23:52


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
> > > > > 120 NEXT P

> -------------------------------------------------------------------

> > > > > so I could call it
> > > > > A=USR(move$,X,Y,LINES,BYTES)

> > > > > Thanks
> > > > > Mirko

> > > > > www.atarixle.de

 
 
 

I need another assembler routine

Post by Mirko Sob » Sat, 19 Oct 2002 07:13:53


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
> > > > > > 120 NEXT P

> > -------------------------------------------------------------------

> > > > > > so I could call it
> > > > > > A=USR(move$,X,Y,LINES,BYTES)

> > > > > > Thanks
> > > > > > Mirko

> > > > > > www.atarixle.de

 
 
 

I need another assembler routine

Post by Freddy Offeng » Sat, 19 Oct 2002 07:15:45


Ron,

I don't think Mirko needs pixel aligned X values. So, IMO X could just be
0-39.
If it's really text scrolling he wants, then he will probably clear the top
part and place new text at the bottom area (in the case of up-scroll).

Ehm, it seems he needs crude window routines. I still need more info (partly
because I don't like to program without thinking about the design).

Freddy.


> 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
> > > > > > 120 NEXT P

> > -------------------------------------------------------------------

> > > > > > so I could call it
> > > > > > A=USR(move$,X,Y,LINES,BYTES)

> > > > > > Thanks
> > > > > > Mirko

> > > > > > www.atarixle.de

 
 
 

I need another assembler routine

Post by Ron Hamilto » Sun, 20 Oct 2002 06:01:32


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

- Show quoted text -

Quote:> > > > > > > 120 NEXT P

> > > ---------------------------------------------------

> > > > > > > so I could call it
> > > > > > > A=USR(move$,X,Y,LINES,BYTES)

> > > > > > > Thanks
> > > > > > > Mirko

> > > > > > > www.atarixle.de

 
 
 

I need another assembler routine

Post by Ron Hamilto » Sun, 20 Oct 2002 06:06:13


Hi, Freddy;
That occurred to me overnight as the original TB statement is byte oriented
and would do any bit operations on that GR 8 screen.

--
Ron

http://www.atariland.com/members/oldatarian
and mirror
http://www.powow.com/oldatarian


> Ron,

> I don't think Mirko needs pixel aligned X values. So, IMO X could just be
> 0-39.
> If it's really text scrolling he wants, then he will probably clear the
top
> part and place new text at the bottom area (in the case of up-scroll).

> Ehm, it seems he needs crude window routines. I still need more info
(partly
> because I don't like to program without thinking about the design).

> Freddy.


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

- Show quoted text -

Quote:> > > > > > > 120 NEXT P

> > > ---------------------------------------------------

> > > > > > > so I could call it
> > > > > > > A=USR(move$,X,Y,LINES,BYTES)

> > > > > > > Thanks
> > > > > > > Mirko

> > > > > > > www.atarixle.de

 
 
 

I need another assembler routine

Post by Ron Hamilto » Mon, 21 Oct 2002 04:26:50


that should have been *not* do any bit ...

--
Ron

http://www.atariland.com/members/oldatarian
and mirror
http://www.powow.com/oldatarian


> Hi, Freddy;
> That occurred to me overnight as the original TB statement is byte
oriented
> and would do any bit operations on that GR 8 screen.

> --
> Ron
<snip>

> > > > > > > > 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
> > > > > > > > 120 NEXT P

> > > > ---------------------------------------------------

> > > > > > > > so I could call it
> > > > > > > > A=USR(move$,X,Y,LINES,BYTES)

> > > > > > > > Thanks
> > > > > > > > Mirko

> > > > > > > > www.atarixle.de

 
 
 

I need another assembler routine

Post by Ron Hamilto » Wed, 23 Oct 2002 05:32:16


Hi Mirko;
More on the 'same page' theme:
Your MOVEUP$ routine specifies X and Y coordinates of the upper left corner
of the destination, which is fine, but not best for the MOVEDOWN$ version to
avoid extra math and we must begin moving down with the bottom line or risk
overwriting the source like the A$(2)=A$ trick.

Do you prefer any standard syntax for the USR( calls? Or will X, Y be source
in move down and destination in move up?

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


> > > > 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
> > > > 120 NEXT P
> > > > -------------------------------------------------------------------

> > > > so I could call it
> > > > A=USR(move$,X,Y,LINES,BYTES)

> > > > Thanks
> > > > Mirko

> > > > www.atarixle.de

 
 
 

I need another assembler routine

Post by Mirko Sob » Wed, 23 Oct 2002 19:10:22


If I have to call two different MOVE$-routines, it's no problem to use
different X and Y values.



> Hi Mirko;
> More on the 'same page' theme:
> Your MOVEUP$ routine specifies X and Y coordinates of the upper left
corner
> of the destination, which is fine, but not best for the MOVEDOWN$ version
to
> avoid extra math and we must begin moving down with the bottom line or
risk
> overwriting the source like the A$(2)=A$ trick.

> Do you prefer any standard syntax for the USR( calls? Or will X, Y be
source
> in move down and destination in move up?

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


> > > > > 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
> > > > > 120 NEXT P

> -------------------------------------------------------------------

> > > > > so I could call it
> > > > > A=USR(move$,X,Y,LINES,BYTES)

> > > > > Thanks
> > > > > Mirko

> > > > > www.atarixle.de

 
 
 

1. I need an assembler routine!

Can anybody translate this Turbo-BASIC-Code into assembler:

10 dim pic$(7680),txt$(7680)
20 rem pic$ is a background picture
30 rem txt$ is a picture witch contains text in graphic 15
99 -----------------------------------------------------
100 pic=adr(pic$):txt=adr(txt$):scr=dpeek(88)
110 for p=0 to 7679
120     poke scr+p,peek(pic+p)!peek(txt+p)
130 next p

this routine should be called using the command

A=USR(routine$,pic,txt)

can anybody do this? I would like to have the source code (ATARI-ASM or
ATMASII).

2. Call for papers DOOD'91

3. Wanted, Mac/65 assembler or Elcomp Assembler or Synapse assembler cart

4. CD Player bugs

5. W: music player routine in assembler

6. UseNet Resources at eBayTech

7. Assembler routine that generates random numbers?

8. See all files?

9. looking for an assembler routine

10. Assembler routine that generates random numbers?

11. How do I protect an ML routine in BASIC if the routine isn't mine?

12. Macro's in X-assembler (quick Assembler)

13. Help needed with interupt routines