Display List Help

[kamakazi]

OK...First of all it has been a long time since I last visited this board due to college work piling up but it's over with and I have graduated. I can now concentrate on starting the process of creating a couple of Atari games for the 8-bit computers and hopefully the Atari 5200 and 7800 since they are pretty much similar. I have been reading lots of books on Atari ML programming but the display list confuses me a bit.

 

I understand that if I want to add some points to a player's score all I have to do is LoaD Accumulator, X, or Y from a designated memory location, INCrease by the number of points, and then STore the results back into the same memory location. That's easy enough to understand. But I don't understand how to create a Display List that will end with the results I'm after. I understand how TV's work and that the beam's blank period between lines is referred to as a horizontal blank and when the beam is sent from the bottom-right of the screen to the top-left of the screen is called the vertical blank. I'm not too worried at the moment at learning how to access the various memory locations for function buttons and controller inputs...I can discover those later. Right now all I'm needing to understand is the display list creation process.

 

What I have in mind is say a Breakout field on the left and a HUD display on the right...similar to how Millipede looks on the NES. I'm not asking for others to create the work for me but to start me off on the right foot. Can the left half of the screen be, for lack of better ML terms, Graphics Mode 9 while the other half is Graphics Mode 0? Thanks in advance and some sample code would be appreciated.

[TMR]

What I have in mind is say a Breakout field on the left and a HUD display on the right...similar to how Millipede looks on the NES. I'm not asking for others to create the work for me but to start me off on the right foot. Can the left half of the screen be, for lack of better ML terms, Graphics Mode 9 while the other half is Graphics Mode 0? Thanks in advance and some sample code would be appreciated.

 

 

Not just from the display list no, that can specify what each line is doing but not what happens during the line. There are ways to change modes mid scanline but its fairly nasty to time consistently, a major hog of CPU cycles and pretty limited as to what can be done; mode 9 to mode 0 isn't possible as far as i'm aware...?

[kamakazi]

So, to make sure I understand correctly, I can't use a detailed graphics mode for game sprites on the left and use the right side for simple text like "SCORE" and other things? Thanks...that explains why Atari developers of the past always have a score on the top or bottom of their games.

[+JAC!]

>Graphics Mode 9 while the other half is Graphics Mode 0

This is possible, if the gr.0 is the left and the gr.9 is right.

What's also possible is gr.9 left and gr. 15 right.

In any case it takes the full CPU to perform cycle exact splits for ths.

It would work fine a Tetris like game for example.

[morelenmir]

You can INC a memory location directly.

 

Clearly a lot of split mode-line stuff was done - especially by the genius artisan programmers like the chap who wrote 'Alternate Reality'. However, at least going from "De Re Atari" it is something of a pain to implement. It gets more tedious still if you intend to allow the screen-protect feature to keep functioning as well. You are left with at best 10-20 cycles per vertical blank. Obviously it is possible and when you get right down to it not all that hard, but you have to be VERY clear in your mind what the various instruction timings add up to before you start.

[TMR]

So, to make sure I understand correctly, I can't use a detailed graphics mode for game sprites on the left and use the right side for simple text like "SCORE" and other things?

 

Not just from the display list no. It's using the ROM to generate on-screen "noise" for testing and has what would be the HUD on the left rather than the right (because it was a quick hack and that's easier to get going) but this...

 

 

...is possible if you throw all 192 scanlines of processor time at the job; its a fairly fiddly bugger to time though.

 

(Ignore the line of numbers, that was just me lining the routine up. =-)

[kamakazi]

OK...so...HUD on left and graphics on right would be possible. That would work as long as I don't use the Display List to perform it, right? I am assuming I would have to have ANTIC interrupt 6502 cycles to change the display mode from that on the left to what would be on the right. Maybe I can find some sample code somewhere I could play around with where a HUD is on the left and a graphics mode for game play is on the right.

 

While I'm here: I assume as well that I can set variables at the beginning of my code (of course, after an initial start-up for stating processor type and stuff like that)?

[Synthpopalooza]

Here's an idea, if you can spare some PMG's: Use the PMG's to make your score graphics. You can position them on your right, and they will show on top of your Graphics 9 screen, and give you the hi-res display you want. You would likely need your score to display vertically, like this:

 

S

C

O

R

E

 

because you'd be limited in the number of columns you can use ... you'd need a player for each column. Although if it's a vertical shooter like Galaga (where your ship only occupies the bottom and never moves vertically), the player for your ship can be reused as part of the scoring display by using a DLI to change the HPOS register wherever the scoring display is.

[Synthpopalooza]

 

What's also possible is gr.9 left and gr. 15 right.

In any case it takes the full CPU to perform cycle exact splits for ths.

It would work fine a Tetris like game for example.

 

Only drawback is, GTIA 9 under Antic mode E, gives you only 9 of the 16 possible shades, because of how mode 15 handles the graphics. If you use Antic 4, it's better ... you get 14 of the 16 shades, because 5 extra shades can be used when you inverse the characters. It cvan be very hard to get the gradients, since some shades can't be in the same character cell together. Of course you could always change between antic F and antic E horizontally, but that can be tricky to sync up with the mode 9 change.

[kamakazi]

I have been reading Atari Assembly Language Programmer's Guide and under the Atari Graphics section it talks about how to use and custom-create display lists. Surprisingly, the code example given is in BASIC.

 

5 REM ** CUSTOM DL/POSITIONING **
10 GRAPHICS 8
20 DL=PEEK(560)+PEEK(561)*256
30 POKE DL +3,70
40 POKE DL+6,6:POKE DL+7,6:POKE DL+8,6
50 POKE DL+139,7:POKE DL+140,7
60 POKE DL+141,65
70 POKE DL+142:PEEK(560):POKE DL+143:PEEK(561)
80 POKE 87,I:POSITION 0,0:? #6; "GRAPHICS PROGRAMMING"
85 POSITION 1,2:? #6; "SCREEN POSITIONING"
90 POKE 87, 8
100 TPSCRN=PEEK(88)+PEEK(89)*256
105 TPSCRN=PEEK(88)+PEEK(89)*256
110 TPSCRN=TPSCRN+81
120 POKE 88,TPSCRN-(INT(TPSCRN/256))256
130 POKE 89,INT(TPSCRN/256)
140 COLOR 1
150 FOR T=@ TO 720 STEP 3
160 W=T/57.26:R=5*W
170 X=INT(R*COS(W)):Y=INT(R*SIN(W))
180 IF T=0 THEN PLOT 160+X,64-Y
190 DRAWTO 160+X,64-Y
200 NEXT T
210 POKE 87,2
220 TPSCRN=TPSCRN+5200
230 POKE 88,TPSCRN-(INT(TPSCRN/256))*256
240 POKE 89,INT(TPSCRN/256)
250 POSITION 111,121: ? #6; "ATARI DISPLAY LIST"

 

It gives 4 scan lines of Graphics Mode 1, 128 scan lines of Mode 8, and 2 scan lines of Mode 2 for a total of 192 scan lines. Maybe I can use that instead and just have the information on the top or mix part of the HUD with some on the top of the screen and some on the bottom of the screen. However, I don't think that Mode 8 can give me the amount of colors I need which I'm currently using POKE locations 704 through 712.

 

What made want to learn Assembly Language in the first place was for the ability to have a display list not already created for BASIC by the OS...meaning I should be able to place what I want where. But from what has been posted so far it sounds more like a royal pain for a beginner with Assembly Language, and the idea that started the question of this thread is actually being created in BASIC. It is done with the game graphics (or maps) on the left and a HUD on the right although I am having to literally draw characters to the screen for labels and numbers. I am using POKEs to set colors and joystick routines at least and maybe with the sample code above found in the book I can get results that will work so I am not having to draw labels and numbers for the HUD. That was the main idea behind the original question. I figured once I perform the necessary work in BASIC I can use the Convert to Binary option in DOS to get a BIN file. From there I was going to try to disassemble the code to see what it looked like in Assembly Language and attempt to make modifications where needed or wanted.

 

 

 

WebRep

 

Overall rating

 

 

This site has no rating

(not enough votes)

Edited August 5, 2013 by kamakazi

[morelenmir]

One absolutely VITAL thing to bear in mind when using ASM is there is no such thing as the BASIC:

 

Graphics 8

 

or any other 'mode'. There are just 192 scanlines (if programming to the standard screen model) each gathered in to 1 or more 'mode lines' as defined by the various ANTIC modes. How you specify what 'Graphics mode' you want your screen to display is through defining at some position in memory a 'display list' and then telling ANTIC to use it.

 

This fact took me four solid months to finally appreciate!

 

As a related aside I would SERIOUSLY consider 'cross-assembling' through WUDSN and 'Eclipse'. Your workflow will go through the roof!

Edited August 5, 2013 by morelenmir

[flashjazzcat]

One absolutely VITAL thing to bear in mind when using ASM is there is no such thing as the BASIC:

 

Graphics 8

 

or any other 'mode'. There are just 192 scanlines (if programming to the standard screen model) each gathered in to 1 or more 'mode lines' as defined by the various ANTIC modes. How you specify what 'Graphics mode' you want your screen to display is through defining at some position in memory a 'display list' and then telling ANTIC to use it.

 

Well - that's not strictly true. The BASIC "GRAPHICS 8" statement is just a shorthand which calls the CIO to set up the "S:" handler in the appropriate screen mode. The "S:" device takes care of setting up all the (standard) display lists. So - if all you want is a standard graphics mode in your assembly language application, the easiest thing to do is call the CIO (which takes maybe 15-20 instructions). You can set this up as a macro or some such, so that you could say (in assembler):

 

GRAPHICS 8

 

As a related aside I would SERIOUSLY consider 'cross-assembling' through WUDSN and 'Eclipse'. Your workflow will go through the roof!

 

Agree with that 100 per cent.

[morelenmir]

You are of course spot on flashjazzcat! I do personally shy away from setting up the screen that way - but I have no doubts there are advantages to doing it that way. I'd argue its important to THINK of the screen in those terms though, even if you then go on to use an OS shortcut.

 

In the same fashion I think you can call the 'plot' and 'drawto' routines that also reside in CIO? However, it feels a lot 'purer' to me to do these things by hand - and probably objectively faster in terms of machine cycles? I would suggest any playfield graphics you are likely to employ in an ASM programme will almost always be pre-rendered and loaded in to memory with the programme rather than drawn at runtime.

 

As an aside I wonder if you could not have multiple pre-rendered images that reside in memory which are then swapped between at runtime by pointing ANTIC to the corresponding start address. I have not read about this in an atari context, but in Win32 programming that technique used to be called a 'virtual display'. The idea was to do all the updating and 'drawing' of your window surface on an 'off-screen' 'compatible device context' and then tell windows to copy the appropriate section from this to the ACTUAL display when the WM_PAINT message was received. Often only a small 'region' of a window's surface would be invalidated and therefore only a little section of the virtual display would need to be 'BitBlt()'ed during the paint event - which was a FAST function. The underlying idea was you did not need to completely redraw your whole window each time a WM_PAINT came along and I used to use that all the time when making custom 'gauges' or dynamic 'buttons'. This was in the mid nineties though and nomenclature has probably moved on, not to mention all the changes DirectX brought - which may have automated the process entirely.

[TMR]

OK...so...HUD on left and graphics on right would be possible. That would work as long as I don't use the Display List to perform it, right?

 

You have to use a display list because technically the two halves of the screen are the same mode the display list for each scanline is $0f with a couple of LMS commands).

 

I am assuming I would have to have ANTIC interrupt 6502 cycles to change the display mode from that on the left to what would be on the right. Maybe I can find some sample code somewhere I could play around with where a HUD is on the left and a graphics mode for game play is on the right.

 

It's a total mess because i hacked it together in about twenty minutes, but i'll post mine when i'm at my main PC if you want.

[+JAC!]

When using ANTIC mode 15 and GTIA mode splits, you can get mode horizontal sequence that looks like GR.8/9/15/9/15, plus the regular player/missles in addition.

You cannot get back to GR.9 in the same line. Here's an example that shows off a bit more of the variations and possible colors.

 

 

The DL lines with LMS instructions ($4f, lo, hi) are critical because their DMA takes some more cycles from the CPU, so you have to adjust the split timing in these lines.

In the normal DL layout this is line 0 and line 96.

 

>Only drawback is, GTIA 9 under Antic mode E,

Misunderstanding between "Interlace-Man" and "Split-Man" :-), it's only rendered like mode E (GR. 15), technicaly it's all mode F (GR. 8 ).

Hires-Split.zip

Edited August 5, 2013 by JAC!

[NRV]

When using ANTIC mode 15 and GTIA mode splits, you can get mode horizontal sequence that looks like GR.8/9/15/9/15, plus the regular player/missles in addition.

You cannot get back to GR.9 in the same line. Here's an example that shows off a bit more of the variations and possible colors.

 

 

Nice one "Split-Man", I suppose if you are going to take all the cycles of the line is better doing it with style

[kamakazi]

Well, I installed Eclipse and WUDSN earlier today. It's been my 4 year wedding anniversary so I haven't had much time to mess around with the environment. I also found differences between the images used to illustrate how to setup everything and the version of Eclipse I have. And I downloaded the version linked to on the WUDSN site. I am getting really excited about working in Assembly Language as it has been a long dream of mine and a personal goal for the past 3 to 4 years.

 

If memory serves me well Graphics 8 allows for only one color with two luminance levels. Is it possible to get more than one color out of this mode if it is used? OH...and I'm using an XEGS for my work combined with an 810 disk drive. Since the XEGS has 64k RAM are the memory locations going to be different?

[+JAC!]

>Graphics 8 allows for only one color with two luminance level

That's what ANTIC puts into GTIA which then turns the bit sequence into pixel sequences.

The modes GR.9/10/11 are the same as GR.8 (all ANTIC mode F) but GTIA uses 4 bit instead of 1 bit per pixel.

 

> Is it possible to get more than one color out of this mode if it is use

Download the above example and run it, you can see the chroma of the players is overlaying with the luma on the Hires part.

 

>Since the XEGS has 64k RAM are the memory locations going to be different?

No, just the OS ROM is a little different, but that's OK.

[danwinslow]

If I understand what you want correctly, another option to consider would be to just draw your own status area on the right or left....in other words, draw it the same way you draw the main playfield. You'd have to come up with a text rendering routine, but that's probably equivqlent or maybe less complicated than trying to count line cycles, plus leaves more cpu left over.

[Rybags]

There's a trick to get an extra CPU cycle per mode line if you're really tight.

 

Turn off Antic's DList DMA bit - the same mode will be repeated from before. But you have to then either turn it back on later or terminate the screen in some elegant way (unless you want display going down to 240th scanline).

The other thing is that you might still need to cater for LMS in the hires modes - not much can be done there, you're up for 3 cycles lost to cover that.

[kenjennings]

I have been reading Atari Assembly Language Programmer's Guide and under the Atari Graphics section it talks about how to use and custom-create display lists. Surprisingly, the code example given is in BASIC.

. ., .

Maybe I can use that instead and just have the information on the top or mix part of the HUD with some on the top of the screen and some on the bottom of the screen.

 

Yes, the display list is the usual way to get multiple graphics modes on screen at the same time. Think of the Atari display as just a vertical stack of graphics mode instructions, each one occupying the horizontal width of the screen. This way you can do as many different kinds of text and graphics modes as you need.

 

However, I don't think that Mode 8 can give me the amount of colors I need which I'm currently using POKE locations 704 through 712.

 

If you need to use all nine colors on the same horizontal line, that's a GTIA mode.

 

short story -- ANTIC handles generating all text and graphics modes. GTIA provides the color interpretation of the modes. GTIA has four ways of interpreting the color information (which is directed by a hardware register and is global for the entire display) . One color interpretation mode is "normal", the others are the special GTIA color options (16 shades, 16 colors, or 9 colors using the registers) that result in 80 pixels per scan line. These special color modes work best with ANTIC modes using high-res pixels (mode F and mode 2).

 

So, mixing ANTIC graphics modes (vertically) on the screen is just a matter of instructions in the ANTIC Display list. Mixing GTIA color interpretation modes vertically on screen requires some assembly language to do a Display List interrupt at the desired positions on the screen.

 

ANTIC:

http://en.wikipedia.org/wiki/ANTIC

 

GTIA:

http://en.wikipedia.org/wiki/CTIA_and_GTIA

 

 

What made want to learn Assembly Language in the first place was for the ability to have a display list not already created for BASIC by the OS...meaning I should be able to place what I want where. But from what has been posted so far it sounds more like a royal pain for a beginner with Assembly Language, and the idea that started the question of this thread is actually being created in BASIC.

 

Yes, if you start from the OS-created graphics mode there is less work in BASIC to modify it into a custom display. But, once you learn the ANTIC instruction set, it's not difficult to build a display in BASIC or Assembly from scratch.

 

 

I figured once I perform the necessary work in BASIC I can use the Convert to Binary option in DOS to get a BIN file. From there I was going to try to disassemble the code to see what it looked like in Assembly Language and attempt to make modifications where needed or wanted.

 

I'm not too sure what you want here, but I don;t think the DOS write binary file does what you think it will do. It's not going to convert BASIC to Assembly.

[Rybags]

5 ways for GTIA to interpret the graphics data, actually - 5th being the Mode E likeness you get by runnning a GTIA mode then switching back to normal - the bit pairs then select colours as PF0 for background, then PF1 thru PF3 for nonzero values.

[+playsoft]

Not nearly as impressive as the example above, but for starting out this might be useful.

 

Has anyone had any success using a Pokey timer, so that it doesn't hog so much cpu time?

 

I've had a play around with this tonight and this seems about as good as I can get it.

 

test.s

test.xex

 

I've sync'd the timer up to the display and used a display list interrupt at the top and bottom of the display to enable and disable the Pokey interrupt.

 

As you can see, there is some jitter. Originally I wasn't printing any characters, I just left the program in a tight loop doing nothing and there was no jitter... but obviously the point of this is to be able to do other things with the cpu!

 

Is there anything I can do to improve this?

 

I did try disguising the jitter by setting the colour registers to match and also using characters in the jitter area which look the same in both modes. This is the HIDE_JITTER option in the source code (which is ca65).

 

I did get some variation as to which characters I had to disguise. In Altirra (PAL & NTSC) it is character columns 23..27, my 400 (PAL) 24..29, my 130XE (PAL) 26..31 and my 800XL (NTSC) 25..30. Since I don't have two machines the same, I don't know if this is variation in components or machines. So I covered all bases and did characters 23..31.

 

hide.xex

 

In Altirra there is some jitter on the right edge of the screen which is not present on any of my machines, but I think this is down to change getting in earlier.

[Rybags]

Best case with Pokey Timers is to have the OS switched out and use the hardware vector direct.

Additional to that, make the Timer the only possible source of an IRQ which means there becomes no need to do bit testing, you only then need to disable/enable the Timer again to allow the next required IRQ.

 

Jitter is generally unavoidable with any interrupt due to the fact that 6502 will always finish an executing instruction before servicing an interrupt. On C64 on technique is to use 2 IRQs and have the first IRQ sit executing short instructions so the second one has a guaranteed "short" jitter.

 

We have the WSync register which allows a guaranteed known cycle position on the scanline but of course it can be defeating the purpose of using Timers rather than DLI in the first place if we want to conserve every possible machine cycle.

 

The other thing with Timers is that in emulation the accuracy is generally not very accurate. Altirra generally gets them cycle perfect but most others will only be scanline accurate which is next to useless for many purposes.

[toad]

I understand that if I want to add some points to a player's score all I have to do is LoaD Accumulator, X, or Y from a designated memory location, INCrease by the number of points, and then STore the results back into the same memory location.

 

Its interesting you should say this, because a while ago I purchased the atari assembler editor cart, and I wrote a small assembly routine....I was happy with it. Then I thought well, I will do another one where I update the score. Then I got busy and never came back to it, lol. But Ok, I am here now. so lets say I have a score, in decimal 12, and now I want to update the score area, with the character one, and the character two....12, in other words twelve.

 

So this must be such a common thing to do, no need to reinvent the wheel, but where do I grab the code? Does that make sense? Are there little open source games or something that should be my starting point?