Disabling ANTIC and speed of Plot

[Darkhog]

I've read that when ANTIC (pretty accurate name now, huh?) is disabled (memory adress 559 dec or $22f hex = 0 ), atari operates about 30% percent faster. But I didn't notice any differences with PLOT operations, i.e. after setting this memory area to 0 and then restoring value after image has been drawn (to remove that nasty "rendering" behavior), time spent plotting was roughly same, the only change was that screen was blank until "rendering" been finished. What I'm doing wrong? More importantly, is there any faster version of PLOT for ACTION! ?

[Synthpopalooza]

Actually there is ... it's called POKEing directly to screen memory. As mentioned before, you figure out your screen memory from PEEK(88)+PEEK(89)*255, we usually assign this to a variable called SCR (at least I do)

 

The method of plot differs according to which graphics mode you are in, but for our purposes, we will deal with the three most common situations:

 

1. Graphics 8. The screen has 40 bytes across, and there are only two colors, so each byte can be reduced to a series of 8 bits ... the 1 bits indicating an active pixel. This means each byte is 8 pixels wide. So for instance, let's say you want to plot a pixel at screen coords 0,0. You would make a chart like this:

 

10000000 (8 bits, the first pixel is activated) ... convert it to decimal (128 in this case) then POKE SCR+0,128.

 

2. Graphics 15 (or Antic mode E). Again we are dealing with 40 bytes, but as this mode uses 4 colors, the 8 bytes are arranged into bit pairs, as follows:

 

00 - BAK 01 - PF0 (color 1) 10 - PF1 (Color 2) 11 - PF2 (Color 3)

 

So if you used this pattern: 11 01 10 00 ... you would have (using the Atari default colors) a 4 pixel pattern consisting of blue - orange - green - black (bg). To plot this, again convert it to decimal and POKE it to the correct SCR location.

 

3. GTIA MODES (Graphics 9, 10, or 11): 40 bytes again, but this time the 8 bits are divided into 2 nybbles, or groups of 4 bits. Each nybble can refer to any of the 16 color values in the GTIA modes. So for example, using this: 1100 0110 ... makes 2 gtia pixels of color 12 and color 6. To plot this pixel group, again you convert the 8 bits from binary into decimal and POKE it as before.

 

Doing plots like this are WAY faster than using the plot command and saves time, but requires a bit more calculation.

 

Now, if you are using character mode (like Graphics 0), you will be poking a single code to the screen which refers to your ATASCII character, however the screen codes are different from ATASCII. screen code 0 is a space char, for instance. You calculate your screen location as before, but you would need to refer to this table to figure out your character codes:

 

http://www.atariarchives.org/mapping/appendix10.php

 

You use screen codes 0-127 for characters, and 128-255 are inverses of 0-127.

 

These are for Graphics 0 (Antic 2) and Graphics 12/13 (Antic 4/5) ... for Graphics 1 and 2 (Antic 6/7), it's different yet again (sigh) ... 64 characters only, and screen codes 0-64 plot the character using PF0 color ... then each range of 64 is used with the next PF color.

 

The advantage here is, you can poke control characters like arrows or the clr character to the screen and it will display the char itself! You can even poke the return character (Inverse-escape, screen code 219) and have it show on the screen instead of it printing a carriage return.

[Darkhog]

Text mode isn't problem, as speed of Print and Printe is good enough. My game runs on Graphics 7 (ANTIC's 13 if I didn't mess up). Will this work like mode 15?

[Synthpopalooza]

it's identical, as each screen line is 40 bytes. Your screen ram is cut in half, is the only difference.

[Darkhog]

Is cut in half in 7 or 8?

 

Also, is there any faster method that one used by Plot function to change color of specific pixel on the screen? This is very important for precise positioning objects such as software sprites (you can't rely on 3 player sprites and 4 missiles when you are trying to make bullet hell) and drawing procedural stuff (like blood splats).

 

Another thing, are pixels in bytes organized in rows or columns? E.g. if I'd put byte 00011011bin onto screen, will it be arranged that:

[00]
[01]
[10]
[11]

or that?

[00][01][10][11]

[+JAC!]

Come on, grap on the spirit of the 80ies again and POKE ANY ADDRESS WITHOUT FEAR.. and see what happens!

 

It'll give you much more fun and understanding then this internet thing :-)

[+Larry]

... just avoid that 800 "paperweight -- self destruct" vector from Analog magazine!

 

-Larry

[Synthpopalooza]

The pixels are in rows from left to right in groups of 4. And to change just one pixel, you'd just need to do an add or subtract from the current byte on the screen.

 

Example: You have this pattern on screen (using the Atari default colors: black for background, orange for PF0, green for PF1, blue for PF2))

 

orange-green-black-blue

01 10 00 11

 

This pattern converts to 64+32+2+1, or 99

 

Now let's say you wanted to plot an orange pixel in the third column. You would just take the value of the pixel for that column only, like so:

 

black-black-orange-black

00 00 01 00

 

This is 4 in decimal. Then you add the 4 back to 99, and get the value of 103. This value will turn on the third pixel to orange but leave the others as is.

 

So in short, you are adding or subtracting values on the binary level.

 

Just do some experimenting, try poking the screen around in immediate mode, and see what happens. It's a good way of learning by doing, how the Atari creates it's bitmap graphics on the most basic level.

Edited April 21, 2013 by Synthpopalooza

[Darkhog]

I always thought that POKEing someone is impolite . But I'll try it, thanks. Also if I'd have byte 01 10 00 11 and I'd like to put 01 in fourth column? ORing it in wouldn't do a thing, what I should do?

Edited April 22, 2013 by Darkhog

[TMR]

Also if I'd have byte 01 10 00 11 and I'd like to put 01 in fourth column? ORing it in wouldn't do a thing, what I should do?

 

No, if you OR the %11 in that fourth column with %01 you'll get %11 back (if a bit in one byte OR the other is set, set a bit in the result).

 

AND can be used to clear bits first, so ANDing %01100011 with %11111100 it'll leave the other six bits you don't want to change intact whilst clearing the two you do. Once that's done you can OR it with %00000001 to set the bits you want.

[flashjazzcat]

PEEK the byte, AND it with %11111100, then OR it with %00000001. The general procedure for writing pixels to the display is:

 

1) Load byte

2) AND with background mask (to clear the bits you're going to change)

3) OR in new pixel bits

4) Store byte

[Darkhog]

Thanks. Once I'll know bit of assembly, I'd try to make my own Plot routine. Maybe it'll be faster.

[Synthpopalooza]

And this is for when you do learn assembly, remember this:

 

Try to use locations on page zero for temp storage when you do your routine, that will sharply cut down on your time spent executing code.

 

Reason why: Zero page (locations $00 through $FF, or 0 through 255 decimal) only require one byte to process. This can double your routine's execution speed. One caution, is that real estate at zero page is at a premium, much of it is taken up by system routines and such. Good news is, since you aren't using BASIC, you have more zero page locations at your disposal.

[Darkhog]

Bad news is that Action! occupies same locations as BASIC does and I hope to use Action! for game logic and other non-critical elements and assembly only when my game's performance is suffering by NOT using it.