Display List question

[texacala]

I need help with modifying a display list in assembly. I want to change an LMS instruction address and some mode lines, about six bytes total. Should I just LDA, STA those six bytes in the display list or should I turn off ANTIC, modify the bytes, turn ANTIC back on? Or maybe change the JVB address to point to new list? I'm not sure what the best practice is here without garbling the screen. Thanks in advance for any reply.

[Creature XL]

I need help with modifying a display list in assembly. I want to change an LMS instruction address and some mode lines, about six bytes total. Should I just LDA, STA those six bytes in the display list or should I turn off ANTIC, modify the bytes, turn ANTIC back on? Or maybe change the JVB address to point to new list? I'm not sure what the best practice is here without garbling the screen. Thanks in advance for any reply.

Just change the bytes.

If it is during setup at the start of your program, you can wait for VCOUNT > 124

[texacala]

So if I follow, once a custom display list is running, I can change some of the bytes in the list without creating screen flicker or other problems? Or am I supposed to peek VCOUNT before I make any changes?

[Xuel]

You can definitely get screen flicker if your changes happen mid-screen. Possible solutions:

 

- Poll VCOUNT

- Interrupt handler that happens regularly outside the affected region of the screen, e.g.:

- VBI

- DLI on unaffected line (but not too soon before)

- Timer IRQ with 50Hz or 60Hz frequency depending on PAL or NTSC and appropriate phase

[Creature XL]

So if I follow, once a custom display list is running, I can change some of the bytes in the list without creating screen flicker or other problems? Or am I supposed to peek VCOUNT before I make any changes?

You should describe your problem a bit better if you want a better answer.

Do you want the change only once or do you want to make the every frame?

[Lazarus]

The best way would be to double buffer the display lists, where you modify one list while the other one is being displayed.

[Creature XL]

The best way would be to double buffer the display lists, where you modify one list while the other one is being displayed.

Generally this is correct. However, the OP wanted to change 6 bytes and I do no think that it is worth to double buffer it.

Double / Triple buffering is only useful when the "rendering task" needs longer then one frame. This is hardly the case when one wants to change 6 bytes. Further, you have to switch the buffers when the raster beam is not on the visible area, so that is the same time you have to change the DL

 

 

 

I asked the OP to be more specific. Because I can think of two needs for manipulating the DL.

First, one can copy the DL from the OS (or use Gr. XX) to generate it but change some bytes. This is a one-time action.

You can do it without any precautions as it would be almost non visible. If you want to make a perfect clean program, than wait for VCOUNT> 124 and do it. Or, you can peek at zeropage address 20 (the RTCLock) and wait for a change. That is the easiest way.

 

Secondly, you want to make these changes regularly. For example, when you scroll the screen. Then you might have a VBI installed already and the question when to change the DL is obvious

[texacala]

I'm working on a scrolling routine but the catch is that the screen memory is in 2 separate blocks of RAM. So I have 2 LMS instructions in my custom display list. What I want to do is scroll the first block (subtracting 40 bytes from screen address following LMS) but also subtract one mode line from the second block and add it to the first block. That makes 6 bytes to change at most in the DL. I wrote most of the code last night to do it, but I am unclear as to the best way to makes the changes without screen flicker/problems. Hope this helps explain a bit better. Also, I've never programmed using DLI or VBI before, still learning

[Creature XL]

I'm working on a scrolling routine but the catch is that the screen memory is in 2 separate blocks of RAM. So I have 2 LMS instructions in my custom display list. What I want to do is scroll the first block (subtracting 40 bytes from screen address following LMS) but also subtract one mode line from the second block and add it to the first block. That makes 6 bytes to change at most in the DL. I wrote most of the code last night to do it, but I am unclear as to the best way to makes the changes without screen flicker/problems. Hope this helps explain a bit better. Also, I've never programmed using DLI or VBI before, still learning

I am not sure why you do your scrolling like this. When you always move one mode line from the 2nd section to first you might run out mode lines

And the first section gets too large for the "4096 limit" as I assume you have a second LMS because of that.

Maybe you are trying to do something I do no understand, so its fine with me. As it is not important for your original question.

 

When you do scrolling (esp. vertical) you want to do the changes in the vertical blank. And therefore do it in the VBI/ DLI.

As you do not have such a thing, then your only possibility is to wait for VCOUNT > 124 (more specific: 8 < VCOUNT > 120) in your main loop.

When you have the system VBI running ( I assume you do) then you can wait fro a change of RAM location 20:

 

 lda 20
wait20:
 cmp 20
 beq wait20

 

 

If you do not want to wait in your main-loop then you have to face the flicker/glitches.

If needed, I can post a VBI-routine. It is tiny and you do not have to understand it

 

 

EDIT:

Explaination of the code: the RAM location 20 gets incremented by the system VBI.

So its value stays the same as long as no VBI has appeared.

Edited February 1, 2013 by Creature XL

[sack-c0s]

The best way would be to double buffer the display lists, where you modify one list while the other one is being displayed.

 

That's how I do copper programs on the Amiga, and how I'm doing it with some code I'm playing with at the moment on the A8

[Rybags]

Best practice is to modify the DList during VBlank. Note that if you double-buffer, the DList pointer is actually copied from shadow to hardware register before the Defferred VB routine via ($224) is called which could lead to confusion.

 

If you double-buffer then the timing becomes less critical but of course you don't want half-baked DLists being fired off.

[texacala]

Thank you all for the information! Looks like I'll explore VBlank options, and I expect I'll have more questions soon.