Extra rows on graphics 8 display list

[wesmond]

Hi everyone,

 

For various fun reasons, I am trying on an 800xl (in Altirra first) to create a GRAPHICS 8+16 kind of display list with a few extra rows - 208 total would be perfect. I'm not worried about either screen position, or VBI running out of time. Ideally, I would like to be able to then PLOT 319,207, (but poking into screen memory would be ok too) - but I've got something wrong before I get to that stage... My dodgy BASIC effort is attached - I'm moving RAMTOP to 112 first, calling GRAPHICS, and putting this DL into the top of page 6:

112,112,79,0,112   [two 8*blank lines instead of 3, then LMS to 112*256, with a graphics 8 (+15) line]
15 [* 99] - [99 graphics 8 lines. Hence, my total, 100 * 40 bytes, is less than 4k.
79, 0, 128 [Another graphics 8 with LMS, for the next chunk]
15 [* 99] - [another 99 graphics 8 lines - again, less than 4k.]
79, 0, 144 [And another graphics 8 LMS...]
15 [* 7] - 7 more graphics 8 lines makes 208 in total,.

65, 0, 6 [JUMP back to the start]

 

I'm not quite sure what I'm getting in the end - probably about half a screen worth of GRAPHICS 8 that seems much higher than it should be, so I think I must be missing something fairly simple.

 

Can anyone point me in the right direction? Learning display lists properly is probably about 30 years overdue...

Thanks,

Wes

EDIT: Oh, there's a hideous and embarrassing  typo - I've poked 561 twice, instead of 560 and 561... (groan) Let me fix that and see where things are!

gr8big.lst

Edited November 25, 2019 by wesmond
typo

[wesmond]

Ok, having fixed that horrible typo, I think I now have a correct display list I can poke to, which is fine...! But continuing out of curiosity - at first, I couldn't PLOT or DRAWTO anything on the screen; they did nothing visible. After more Mapping the Atari reading, I added...

 

105 POKE 88,0:POKE 89,112:POKE 87,8

 

and now, when I do the corner-to-corner DRAWTO, I think it's looking good on the top part (first lms) correctly, but then something happens to it at the second LMS which must shift the display co-ordinates horizontally. I guess on a normal GRAPHICS 8 screen, BASIC gets round this somehow, as there's still a second lms in the middle...

 

Anyway, sorry for my first post being a red herring - if anyone knows about how to get PLOT and DRAWTO working on such a display list, I'd still be interested in that...

 

Thanks!

Wes

 

 

gr8big.lst

[globe]

3 hours ago, wesmond said:

but then something happens to it at the second LMS which must shift the display co-ordinates horizontally. I guess on a normal GRAPHICS 8 screen, BASIC gets round this somehow, as there's still a second lms in the middle...

 

 

gr8big.lst 749 B · 3 downloads

Hello Wes,

one problem is video memory allocation.

 

In your Display List you use 4000 bytes starting at the 4K boundary, then there's 96 bytes gap, then another 4000 bytes followed by another 96 bytes gap and remaining lines.

For such fragmented Vram you'd need a custom line routine.

 

Basic gets around this by not starting exactly at 4K boundary but 96 bytes later so when the 4K barrier is crossed the VRAM is still continuous without gaps.

You could apply this to your display list and start 16 bytes after the 4K boundary (112,112,79,16,112), followed by  15 [* 101].

Second LMS would stay unchanged but instead of 15 [* 99], use 15 [* 101] again.

This way you'll get 204 lines and continuous VRAM.

 

208 lines is kind of hard with this screen width since 4096 isn't divisible by 40 without reminder but it would be doable with narrow screen if you'd be ok with only 256 points of horizontal resolution instead of 320.

 

 

 

[Rybags]

The next problem you'll face - regardless of how tall the screen is, the OS routines will only support 320x192.

To draw in the extra area you'd need to set the screen base forward then allow for the new origin with your graphics operations.

 

And contiguous video memory - you'll hit trouble once you cross into a 3rd 4K region since 40 won't divide into 4096 evenly.

 

But, given the OS limitation as mentioned, you could leave padding between the normal 192 and extra scanlines since you need to change the OS screen pointer to do operations there.

[thorfdbg]

47 minutes ago, Rybags said:

The next problem you'll face - regardless of how tall the screen is, the OS routines will only support 320x192.

Yes, though it is possible to write another Os handler to manage such large screens. In fact, I should have such a thing somewhere and need to dig it out. It is a wide-display mode graphics 8 variant that is as tall as I could possibly make it. It does support PLOT and DRAWTO, though I need to check whether I still have the disk somewhere.

[wesmond]

Thanks everyone - that all makes total sense...

 

(In case anyone is curious, I've been solving adventofcode 2016 in Atari Basic with some ASM routines where needed - nearly all done, so I'm revisiting a few that offer some prettier representation. Nearly all the 2016 puzzles are doable on an Atari - my current exceptions are that a few days need MD5, which I might eventually try and implement in assembler... and one part needs load of memory - although I suspect there is an analytical solution that I can't find. The GR8 tall display is for day 1, where it's really easy to calculate and print the answer, but an animated version would be fun...

Going back to the figures - I only need PLOT actually, not DRAWTO, which helps a bit - and my answer fits in 205x205, so narrow playfield might do it. I hadn't thought of that.  Otherwise, I guess a custom PLOT function to POKE rather than PLOT would be fine...

Edited November 25, 2019 by wesmond
tpo

[wesmond]

I got there with 208 scanlines in a display list with the three LMSes; forget about being contiguous, as the OS can't draw beyond 192 anyway... so a custom PLOT routine to poke the point directly to the screen (and also return whether there was already a pixel there, which was useful for part two of the puzzle).

 

(github.com/weshinsley/advent-of-code-2016/tree/master/AtariBasic/d01).

 

Thanks for the pointers again! My first proper display list and VBI in a couple of decades.