Player/Missile Manipulation via Strings

[atariksi]

Wasn't there some bug in Atari BASIC with 256*N byte string moves that you had to avoid, too?

Chapter 9

>>>

LINES 11045 AND 11047

 

Here I am initializing MISSILES$ and PLAYER0$ in a slightly different way. This is necessary because of an apparent bug in Atari BASIC. It seems that a statement such as MISSILES$=ERASE$ won't work if MISSILES$ is 256 bytes or more.

<<<

 

I haven't run their stuff, but isn't that a bug in the 3rd chapter where they use the D$ to compute the Filler2$ size to dimension.

 

DIM FILLER1$(1),FILLER2$((INT(ADR(FILLER1$)/1024)+1)*1024-ADR$(D$)-1)

 

Using D$ produces error 9 or something.

[+therealbountybob]

Wasn't there some bug in Atari BASIC with 256*N byte string moves that you had to avoid, too?

Chapter 9

>>>

LINES 11045 AND 11047

 

Here I am initializing MISSILES$ and PLAYER0$ in a slightly different way. This is necessary because of an apparent bug in Atari BASIC. It seems that a statement such as MISSILES$=ERASE$ won't work if MISSILES$ is 256 bytes or more.

<<<

 

I haven't run their stuff, but isn't that a bug in the 3rd chapter where they use the D$ to compute the Filler2$ size to dimension.

 

DIM FILLER1$(1),FILLER2$((INT(ADR(FILLER1$)/1024)+1)*1024-ADR$(D$)-1)

 

Using D$ produces error 9 or something.

YES - It should read filler1$ instead

[blitterbox]

Thanks Rybags. I finally found enough documentation that I know what it's doing.

 

I notice it's still possible for strings to get shifted; say when the program stops. Still much more reliable.

 

 

Perhaps you know the answer to a small side question I haven't tracked down. Where's the register which can suspend updates of the display so changes aren't visible until it's returned to normal?

[Rybags]

DMACTL, shadowed at dec. 559. Store 0 there and you blank the entire screen.

[+Stephen]

DMACTL, shadowed at dec. 559. Store 0 there and you blank the entire screen.

This won't let the screen remain visible and not show changes though. I wonder if this is what was needed?

[blitterbox]

Yes, I remember being able to poke a value in some address that kept the screen contents static until the original value was returned.

[atariksi]

Yes, I remember being able to poke a value in some address that kept the screen contents static until the original value was returned.

 

Probably: POKE 54286,0 and then 54286,192 to restore. That shuts down the VBI and DLIs so if your software is doing most of its action during those time periods, you have paused the screen.

[Rybags]

"Screen contents static" is a very broad statement and could mean any number of things.

 

You need to be more specific. You can't just keep a screen display static and be updating it at the same time. For that you'd probably be talking about page-flipping, especially in a BASIC environment.

[Divya16]

"Screen contents static" is a very broad statement and could mean any number of things.

 

You need to be more specific. You can't just keep a screen display static and be updating it at the same time. For that you'd probably be talking about page-flipping, especially in a BASIC environment.

 

There's CTRL+1 to pause the screen when you are listing things in BASIC. Maybe there's a POKE for doing that from within the program.

[Rybags]

POKE 767,255 = halt character output

POKE 767,0 = resume

[blitterbox]

Probably: POKE 54286,0 and then 54286,192 to restore. That shuts down the VBI and DLIs so if your software is doing most of its action during those time periods, you have paused the screen.

Using BASIC so no interrupts.

 

POKE 767,255 = halt character output

POKE 767,0 = resume

Character output is the activity I'm trying to obscure.

 

I used it elsewhere, but the only incidence which comes to mind was back in medieval times when I typed in a simple little maze navigation program from a magazine. It drew the maze view with a minimum of lines in GRAPHICS 7 after clearing the screen each time, all while you watched. Since the machine would have to get the display content from somewhere, I assume I must have used page flipping and used the address I can't recall to keep the machine displaying the old page until the new one was drawn. 8^/

[+Stephen]

Character output is the activity I'm trying to obscure.

 

I used it elsewhere, but the only incidence which comes to mind was back in medieval times when I typed in a simple little maze navigation program from a magazine. It drew the maze view with a minimum of lines in GRAPHICS 7 after clearing the screen each time, all while you watched. Since the machine would have to get the display content from somewhere, I assume I must have used page flipping and used the address I can't recall to keep the machine displaying the old page until the new one was drawn. 8^/

If you are going after a page-flipping approach, then you will want to change the location(s) of the screen RAM pointer in the display list.

PRINT PEEK(560) + PEEK(561) * 256

from BASIC will give the address of the DLIST. In the standard OS ones, bytes 5 and 6 will be the pointer to the start of screen ram. Change these 2 locations, and the screen will now draw from a new area.

[blitterbox]

If you are going after a page-flipping approach, then you will want to change the location(s) of the screen RAM pointer in the display list.

PRINT PEEK(560) + PEEK(561) * 256

from BASIC will give the address of the DLIST. In the standard OS ones, bytes 5 and 6 will be the pointer to the start of screen ram. Change these 2 locations, and the screen will now draw from a new area.

Doesn't the OS draw to the area currently pointed to? The location I'm trying to remember or find out about would keep it displaying the old data while drawing is going on in the new location so that even at the speed of BASIC, without DLI's or VBI's, the viewer doesn't see any drawing going on; just has to wait.

[+Stephen]

If you are going after a page-flipping approach, then you will want to change the location(s) of the screen RAM pointer in the display list.

PRINT PEEK(560) + PEEK(561) * 256

from BASIC will give the address of the DLIST. In the standard OS ones, bytes 5 and 6 will be the pointer to the start of screen ram. Change these 2 locations, and the screen will now draw from a new area.

Doesn't the OS draw to the area currently pointed to? The location I'm trying to remember or find out about would keep it displaying the old data while drawing is going on in the new location so that even at the speed of BASIC, without DLI's or VBI's, the viewer doesn't see any drawing going on; just has to wait.

That would depend on how you are drawing. If you used an OS routine like BASIC's "print" command, then yes, the output would go to the screen RAM being pointed to. However, you are free to draw to another area of RAM and once the drawing is finished, set the display list pointer to that area and you will instantly see the change.

 

On more modern consoles, this is usually referred to as drawing to a "back buffer". The penalty is needing double the RAM to hold two screens worth of data. There is no other way that I know of to do this without taking a double buffered approach.

[ANTIQ]

SAVMSC (88, 89) is the OS pointer to screen memory.

 

Maze Maniac?

[+therealbountybob]

Page 6 Issue 9 has an article on PMGs using Strings.

It uses a slightly different method to establish the page boundary than the book previously mentioned