bidirectional vertical coarse scrolling using LMS in TBXL

[OxC0FFEE]

Hi all,

I'm working on a proof of concept to scroll through memory with the joystick by incrementing and decrementing the pointer to screen memory. As a basis, I used listing two from chapter 6 (scrolling) in De Re Atari. I modified it to use the joystick as input and allow for two-way scrolling rather than just incrementing the pointer. DX is currently unused.

10 REM GR.0
20 DLIST=PEEK(560)+256*PEEK(561)
30 LMSLOW=DLIST+4
40 LMSHIGH=DLIST+5
50 SCREENLOW=PEEK(LMSLOW)
60 SCREENHIGH=PEEK(LMSHIGH)
65 S=STICK(0):IF S>0:DX=(S=7)-(S=11):DY=(S=13)-(S=14):ENDIF 
70 SCREENLOW=SCREENLOW+DY*40
80 IF SCREENLOW>255:SCREENHIGH=SCREENHIGH+1:SCREENLOW=SCREENLOW-256:ENDIF 
85 IF SCREENLOW<0:SCREENHIGH=SCREENHIGH-1:SCREENLOW=256+SCREENLOW:ENDIF 
120 POKE LMSLOW,SCREENLOW
130 POKE LMSHIGH,SCREENHIGH
140 GOTO 65

This works fine going one line up or down at a time. My goal is to go up and down arbitrary amounts, instead of just one line (40 characters) at a time. Instead of this concept of maniputlating the MSB and LSB independently when SCREENLOW overflows positively or negatively, I'd prefer to say "move up or down in memory this amount and calculate LMSLOW and LMSHIGH appropriately" because I'm trying to add the concept of acceleration (pushing for longer on the stick one way or the other) rather than just velocity (up or down a constant amount).

I'm using TBXL for this, and I know there are double-byte instructions, but I haven't used them, so let me know if this is pertinent and could make this easier. It seems that somehow modulo or integer division could make this simpler, but I can't quite wrap my head around it. It's been a while since I worked with the A8, so apologies if I'm a bit rusty!

CORERUN.BAS

Edited March 8, 2019 by OxC0FFEE

[Rybags]

The problem you'll run into is the 4K boundaries. Antic screen data reads wrap around to the start of the 4K block and that can occur partway through a scanline.

 

Problem #2 is that in standard or wide DMA the 40 or 48 bytes fetched isn't a factor of 4,096. In narrow DMA mode you have 32 bytes fetched which fits in nicely.

 

One way to at least partly overcome the problem is to do an LMS for every text line. That takes it beyond what Basic can efficiently do though the best method there would be to use 2 DLists and flip between them once the new one is built.

 

Yes, in TurboBasic you'd save coding and time by using the double byte POKEs.

Edited March 8, 2019 by Rybags

[OxC0FFEE]

What happens at 4K boundaries? Would that simply make a flicker or visual disturbance? When I page past 4K I don't notice anything different? should I?

 

I added a shotgun debugging statement to print the current value of SCREENHIGH*256+SCREENLOW and it works all the way up to ~65536 (and down to 0, when I get an error 3 poking into the LMS when it overflows below or above available memory. I get no problems at 4K boundaries?

[Rybags]

You get wraparound since Antic's screen fetch counter only has 12 bits of counter and the upper 4 bits are latch.

 

It can happen at the start of a new text/bitmap line but usually occurs partway through.

 

So the memory read sequence might be something like $7FFE, $7FFF, $4000, $4001 instead of $8000, $8001.

If you're moving through a constructed screen or document then it'll be pretty noticable.

[flashjazzcat]

I realise it probably partly defeats the object of the exercise with regard to display list manipulation, but it might be easier to simply use the TBXL MOVE statement to copy 960 bytes from the address pointed to be SCREENLOW/HIGH to the address pointed to by $58/59. If you just issue memory copies one after another even when the target address has not changed, you should get a reasonably dynamic depiction of any changes to memory as they happen.