DLI and VCOUNT

[flure]

Hello,

 

This is my very first post on this forum. I started programming the Atari 800 XL about 10 days ago, using WUDSN by Jac! (and it's great!).

For a beginning, I would like to make raster bars in mode $C.

So I built a display list with only $C mode lines, with a DLI on each one.

My DLI currently just changes the colour so that it should draw 16 pixels wide bars. I use VCOUNT for that.

I also set up a VBI to move the bar vertically.

 

But I have a few problems : I read here that VCOUNT holds the line number divided by two, and that it can go only from 0 to 155 on PAL, including the 24 blank lines at the start of the display list. This is exactly the point I don't understand correctly. Does that mean that I can use it only from 24 to 155, and thus that I am limited to 131 mode lines in my display list ? De Re Atari states that I could use 192 lines total, I guess it is for NTSC ?

 

Well, I'm a bit lost, and currently my program doesn't do what I expect it to...

 

Included below is my source code, so you can see exactly what my problem is. Any help or pointers would be greatly appreciated, thanks !

 

PS : sorry for not introducing myself better, I promise I will do it later in a dedicated post.

 

Thanks again for any help.

 

 

 

rasters.asm

[Rybags]

Active display is limited to 240 scanlines total for both Pal/NTSC. Actual generated display is 312 or 262 scanlines, the inaccessable ones are black.

 

VCount doesn't correlate directly to the visible display and yes, the lowest bit isn't available. But it's not usually a problem.

Since you're using DLIs, you generally know where you are in the display anyway... of course if doing multiple DLIs you don't but can easily enough use an index counter variable or other means.

 

To do simple "raster bars" the best method is usually a single DLI - use stores to WSYNC which halts the CPU until the beam is just offscreen to the right, then do the colour changes.

To have the colour scrolling up/down, have the VBlank routine increment or decrement the initial colour value that the DLI starts with.

[Creature XL]

Additionally, the first visible scan-line is 8 and the last visible is 248. Corresponding to VCOUNT=4 and 124.

 

The 24 blank scan-lines aren't really needed (nowadays). AFAIK they were introduced back in the day as some TV sets couldn't display those.

Similar to letting the BASIC-editor only use 38 columns when you do not change it with a poke.

In the present days it shouldn't be a problem. There is even a picture which uses 256 scanlines (the last 16 only with PMG due to to HW bug)

 

 

@your code:

No idea why it doesn't work as you expected. As I can not figure out what you are doing there at first glance. Maybe I look again tomorrow but i had a beer already

However, I want to point out some things which seem important to me:

 

- you do not need to save/restore the registers in the VBI. the OS does that before it calls your routine.

- raster_dir seems to be either 0 or 1. so you can remove the "cmp #1" as the Zero flag is set when you do "lda raster_dir"

- there is a "cpx" instruction. So the "txa" before the "cmp #130" isn't needed AFAICS.

- NMIEN can not be read. it is write only. Just set it to 192 when you use DLIs.

 

Of course it can be optimized even further, but my remarks are of a more general nature which help you understand the 6502 (and the Atari) better. So you can do the other optimizations later yourself.

And one important note to everyone rather new to the Atari. Search for the "Altirra HW manual". If you find an up-to-date version you know everything you need to know!

 

 

Have fun coding!

Edited May 30, 2014 by Creature XL

[Xuel]

Your program didn't assemble for me. You must put an "org" statement after "run" or put run at the end of the file. Think of "run address" as "org $2E0" followed by "dta a(address)". So without another "org", the origin counter will continue counting from $2E2 after the run.

 

Here's what I get when I assemble your program with the run at the end:

 

 

It's an animated GIF so click on it to see the animation.

 

So the bar is moving up and down. Looks like you need to fix up the behavior at the bottom, but otherwise looks OK.

[Xuel]

Correction: Your program did assemble for me, it just didn't run because the run caused INITAD ($2E2 and $2E2) to be filled with $8A48 which means that after loading, DOS tries to JSR to $8A48 which is blank so a BRK is executed. Anyhow, the moral of the story is be careful where you put "run".

[Creature XL]

I am not sure if the "bmi direction_bas" is correct.

At least I use BCS to check for ">=" or BCC for "<".

 

BMI/BPL can only be used in the same way when you are dealing with 7 bit values. Which you aren't as 130 uses 8 bits.

[Xuel]

CreatureXL, that's a good point about signed/unsigned comparisons (see also here) but it actually doesn't matter in this case since the usable VCOUNTs only go up to 124 as you said earlier. The problem here is that flure is trying to make the bar go past the end of the DLIST where there are no DLIs. To fix it he can increase the number of lines in the DLIST and decrease the max VCOUNT that the bar can go down to. Here's my fix:

 

rasters.zip

 

Though since the DLIs are firing every scanline they're basically consuming 100% of the CPU anyway, so you might as well just use a display kernel. Or modify the DLIST every frame to enable DLIs on just the lines that need them. But with a display kernel you could have the bars extend outside of the playfield area. Or I guess you could use timer IRQs to do that as well.

[flure]

Wow, I'm glad I posted here

Xuel, when you talk about a display kernel, you think about some code that executes outside DLI and VBI ? With that, I don't see how I could synchronize my code so that the colour changes happen at the end of each line, so that the raster bar displays correctly ?

[Xuel]

I think of a display kernel as a program than runs in lock step with the electron beam for a large portion of the screen. As opposed to a DLI which typically just runs for one scan line like in your code. But there's no reason you can't have a multi-scanline DLI. That would be useful if you wanted shaded raster bars for example. You could set the DLI to fire just on the first scanline of the raster bar and then use repeated WSYNC writes to change COLBAK for several lines.