Moving screen memory to (intentionally) produce video feedback

[OxC0FFEE]

Been a while since I attempted this, and perhaps I'm getting Atari 8 and 16 bit machines a bit confused, but I remember writing a utility back in the day that moved the screen around memory. One interesting thing was that if the pointer to screen memory was placed just before or just after the start of actual screen memory, there would be a neat artifact like 1-dimensional video feeback, where one line would get duplicated, then that would get duplicated, etc. It looked like a faux 3d perspective effect where the "closer" objects would be taller.

 

I found From Compute's Second Book of Atari Graphics, Program two, here: http://www.atariarchives.org/c2bag/page185.php to move screen memory around, but it's not behaving how I'd like. I have a feeling it's limited to a specific region of memory. I started with it, modified to use graphics 9. It does move the screen through memory using the arrow keys, but does not exhibit the powers-of-two one-dimensional video feedback I remember. Perhaps it's not crossing the screen boundaries in the way I remember?

 

Modified listing using basic mode 9:

5 GRAPHICS 9
10 REM COARSE VERTICAL SCROLLING DEMO
15 REM PRESS UP/DOWN ARROWS TO MOVE DISPLAY THRU MEMORY
20 DLIST=PEEK(560)+PEEK(561)*256:REM GET START OF DISPLAY LIST
30 LMSL=DLIST+4:REM POINTER TO DISPLAY MEMORY
40 LMSH=DLIST+5
50 DISPLAYL=0:REM INITIALIZE ADDRESS OF DISPLAY MEMORY
55 REM READ KEYBOARD
60 IF PEEK(764)=255 THEN GOTO 60:REM WAIT FOR KEY
70 IF PEEK(764)=14 THEN POKE 764,255:GOTO 110:REM UP ARROW /
80 IF PEEK(764)=15 THEN POKE 764,255:GOTO 140:REM DOWN ARROW ?
90 GOTO 60
100 REM MOVE DISPLAY WINDOW INTO LOWER MEMORY
110 DISPLAYL=DISPLAYL-40
120 IF DISPLAYL>=0 THEN GOTO 170:REM CAN'T DISPLAY NEGATIVE MEMORY
122 DISPLAYH=DISPLAYH-1:DISPLAYL=0
124 IF DISPLAYH<0 THEN DISPLAYH=0
126 GOTO 170
130 REM MOVE DISPLAY WINDOW INTO HIGHER MEMORY
140 DISPLAYL=DISPLAYL+40
150 IF DISPLAYL>240 THEN DISPLAYH=DISPLAYH+1:DISPLAYL=0
160 REM CHANGE DISPLAY MEMORY POINTER
170 POKE LMSL,DISPLAYL:REM PUT NEW DIPLAY ADDR IN DISPLAY LIST
180 POKE LMSH,DISPLAYH
200 GOTO 60:REM GO WAIT FOR KEYBOARD ENTRY

The eventual goal is to have a split screen using display lists, having a static mode 11 top—rainbow sky—and a "scrolling" (by changing memory that then propagates down the feedback loop) bottom section in mode 9—ground. The features on the ground should ideally be bits from memory (to simplify my landscape drawing code

P189L2.bas.txt

[OxC0FFEE]

To clarify, this is what I mean by "video feedback". In the case of moving screen memory around though, it was limited to one dimension since the screen buffer is inherently 1D.

[OxC0FFEE]

And this is a (badly copy and pasted in Photoshop) example of what I mean by 1-d video feedback. Here the start of video memory has been shifted by 3 scan lines. I'm sorry I can't better explain the phenomenon but I hope this jogs someone's synapses.

Edited March 5, 2017 by OxC0FFEE

[emkay]

What stops you to do so?

 

The LMS line has to be set in the DL, for that range, you want to move.

 

It's just the GTIA Modes that need additional DLIs to get splitted on the screen.

[ZylonBane]

One interesting thing was that if the pointer to screen memory was placed just before or just after the start of actual screen memory...

 

This is a nonsense statement. The pointer to screen memory is by definition the start of actual screen memory. The hardware does not know or care where your fleshy human brain thinks screen memory begins.

[Rybags]

You can get duplicate lines by DList tricks. VScrol tricks can do it at times as well.

 

As for "feedback" - not really. You can get the video to come from the hardware register area which is feedback in a way in that you can see some stuff like keypresses.

Putting the display pointer to just before actual display Ram will normally mean that the display list gets shown onscreen.

Somewhat boring, e.g. the default text screen will just show a bunch of quote marks surrounded by other characters then the normal screen data.

e.g. on a 40K or more machine, stock Atari Basic:

POKE 39972,24

Will show the DList onscreen, likely preceeded by spaces (used that value to keep text X-alignment proper)

 

Bitmap modes you can get "interesting" effects from the 4K wraparound. Actually, any mode can do the 4K wraparound but hires ones can repeat data once or twice automatically.

 

But really, there's nothing much special to see here. Some of the most interesting graphics effects can be had when a game crashes spectacularly, especially if the DList hunts around and there's PM graphics onscreen. But still, all this stuff has an explanation, much of it in Avery's Altirra / Atari Hardware manual.

Edited March 6, 2017 by Rybags

[pirx]

there is such an easy DL trick possible as well:

https://youtu.be/NmDs50xtmTg?t=4m34s

it is done by DL jumping into itself.

[emkay]

A demo comes to my mind. Normally I stumble over it while searching for something "Atari" like, but today I cannot find it

 

It's that demo where the DL is used to have the graphics moving like a carpet in the wind... My guess was that the Thread Opener wants to resemble something like that...

Edited March 7, 2017 by emkay

[pirx]

carpet was in Five 2 Five demo

[IronWorks]

To me it looks like your after this type of effect...

Axelay2.atr

 

This is a bitmap display list with multiple copies of the same line repeated more and more as you go

down the screen.

I played with this last year with the idea of producing something like River Raid or Canyon (BBC micro)

But it uses a lot of vblank time updating all the load memory scans.

 

axelay5.atr

[+Stephen]

To me it looks like your after this type of effect...

Axelay2.atr

 

This is a bitmap display list with multiple copies of the same line repeated more and more as you go

down the screen.

I played with this last year with the idea of producing something like River Raid or Canyon (BBC micro)

But it uses a lot of vblank time updating all the load memory scans.

 

axelay5.atr

Cool! What do the various "timing bars" in version 5 represent?

[emkay]

carpet was in Five 2 Five demo

Thanks.

 

[OxC0FFEE]

To me it looks like your after this type of effect...

Axelay2.atr

 

This is a bitmap display list with multiple copies of the same line repeated more and more as you go

down the screen.

I played with this last year with the idea of producing something like River Raid or Canyon (BBC micro)

But it uses a lot of vblank time updating all the load memory scans.

 

axelay5.atr

 

Yes! Very nice work. That's the fine-tuned effect I'm after, sort of a mix of the split of axelay5 with the flying-over-land perspective effect of axelay2. Hoping to use the copying memory idea as a shortcut for terrain/feature generation. I'm unsure if it can be done in Turbo-Basic XL in a smallish program (competition constraint). TBXL does have a COPY command, so, perhaps. It might be hard in pure TBXL though. If the core copy is small and fast enough, maybe...

[emkay]

[OxC0FFEE]

Gorgeous. I envision the Star Wars title crawl

 

I don't imagine that's in basic/tbxl though? (i can hope)

[OxC0FFEE]

I want to let you know I appreciate your gentle nudges in the right direction. My sincere apologies for any newbie-level questions here. I'm doing my best to come back to A8 coding after 30 years and trying to do something interesting for a Basic competition. Trying to fit something profound in 10 lines of Basic is harder than it sounds

[IronWorks]

Heh, I obviously should have posted my first test.

axelay1.obx

 

This only needs 12 load memory scans to be updated. you lose the stretching but but you get

a nice looking radar effect.

 

Re. the colour bands on 5 that was a quick hack for graduated sky which later got used for

timing... when it went hideously wrong.

[OxC0FFEE]

I like that too. It's simple and minimal, and possibly something I could bite off in TBXL

Edited March 8, 2017 by OxC0FFEE