Custom Graphics Mode 160x96x?

[Tempus]

Hi,

 

I'd like to have custom graphics mode with the following features:

- HRes 160

- VRes 96

- Colors > 4

- Available for NTSC and PAL

- Minimum CPU/DMA load

- Easy color handling (no complicated color computations)

- Minimum screen flickering

 

Any suggestions how to achieve that?

 

Somewhere (I don't remember where) I've read about some clever Polish programmers who used the GTIA phase shift error to get a HRes of 160 in Antic mode F. How is this mode called? How does it work? Which software is using this feature?

 

Emkay gave me the idea of using GR#7 due to the low (CPU/)DMA load (automatic scan line doubling by Antic). Is it possible to use this feature also with Antic mode F? Or are doubling the scan lines with Vshift or doubled display list entries the only possibilities to achieve that?

[Synthpopalooza]

There is a way to do this using Graphics 15 but alternating the palette every other scanline. There's a whole thread about it here:

 

http://www.atariage....5-pal-blending/

 

How it works: You use 4 colors with a luma setting of about 2 or 4 on the first line, and on the second line you use monochrome settings. On PAL machines this will blend the colors together but leave blank scanlines. On NTSC, you can add a scanline shift by altering the first DLIST instruction between 96 and 112 every vblank.

 

It is also possible to use this idea in GTIA modes, by engaging mode 11 on the first scanline. You alter the display list to mode F every line that you engage mode 11.

 

Another idea is to do interpainter mode. In Graphics 7 you swap bitmaps every VBLANK, but do no color palette changes. By alternating color placement in a checkerboard pattern every frame, you get 9 to 10 colors onscreen at once with minimal flicker. This takes up 8K screen memory.

 

Re GTIA phase shift: This is called HIP mode ... it's an interlace of Graphics 9 and 10 with the mode 10 colors set to monochrome. There is a quirk in the hardware which shifts the pixels to the right by a color clock in mode 10, leading to the simulated 160x192 resolution. Problem is, the screen memory takes up 16K. One way to get around it is to do the GTIA mode changes and the DLIST instruction change I mentioned above to shift the screen.

 

I've also done some experiments in character mode ... using Antic 5 (Graphics 13), put ATASCII codes 0-119 to the screen repeatedly to fill your screen (add 128 to every char where you want to use the PF3 fifth color), and altering CHBAS every 3 char lines with a display list interrupt, then using a Super IRG type method to swap the char set memories every VBLANK to get 14 colors at once.

 

With this method, you alter your character set memory instead of the screen memory to place your pixels, and the bitmap setup is similar to the Commodore 64 lo-res bitmaps.

 

The flicker is reduced because you can do a checkerboard antiflicker dither when you blend colors. I've also used this with GTIA modes 9 and 10, but the flicker is a bit worse if you aren't careful with your color choices. This method will take up 8k for Antic 5, plus 480 bytes for the screen memory.

Edited February 14, 2013 by Synthpopalooza

[Rybags]

GTIA trick in hires to give the 160 mode works by starting each scanline in a GTIA mode then setting PRIOR back to normal mode.

 

GTIA gets confused and will use colour pairings for bits like:

 

00 = PF0

01 = PF1

10 = PF2

11 = PF3

 

The mode is very CPU expensive in that you're changing stuff every active scanline.

 

PAL colour mixing in 160x96 res is also CPU expensive but you can get at least 16 colour combos without flicker although there's the scanline artifacting and fact it doesn't work in NTSC.

[Synthpopalooza]

Well, for NTSC and the PAL mixing mode, you can always put in the scanline shift i mentioned (96 and 112 on first DLIST instruction) to mix the scanlines. Since NTSC has a faster refresh rate (60 hz), the colors blend together and it's not hard on the eyes at all.

[popmilo]

I'd like to have custom graphics mode with the following features:

- HRes 160

- VRes 96

- Colors > 4

- Easy color handling (no complicated color computations)

- Minimum screen flickering

Well, you just asked for A8's Holy Grail !

 

That was exactly what I was looking for and closest to it, is already mentioned Pal-blending mode...

 

Only other option to produce more colors in one row of 160 pixels is to mix Players and Missiles to add some color.

Plus 5th color (per character) in char mode of course.

 

And that is about it... Antic and Gtia were simply not designed for more than 4 colors in a scanline...

[emkay]

 

 

Emkay gave me the idea of using GR#7 due to the low (CPU/)DMA load (automatic scan line doubling by Antic). Is it possible to use this feature also with Antic mode F? Or are doubling the scan lines with Vshift or doubled display list entries the only possibilities to achieve that?

As soon as you want to change the gfx content, Antic has to read a scanline new.

So gr. 7 has depending 2 lines, no way to get rid of that.

But you can add PMg in single scanline resolution, overlaying the Gr. 7 pixels for some higher resolution for some more details... here and there.

[Tempus]

As soon as you want to change the gfx content, Antic has to read a scanline new.

So gr. 7 has depending 2 lines, no way to get rid of that.

But you can add PMg in single scanline resolution, overlaying the Gr. 7 pixels for some higher resolution for some more details... here and there.

Is it possible to get GR#9-11 doubling the scanlinies like GR#7 without additional CPU/DMA load (i.e. not by using VSHIFT or LMS doubling)? If not possible, what would be the way with minimum CPU/DMA load?

[emkay]

 

Is it possible to get GR#9-11 doubling the scanlinies like GR#7 without additional CPU/DMA load (i.e. not by using VSHIFT or LMS doubling)? If not possible, what would be the way with minimum CPU/DMA load?

If you try to exchange GTIA modes evey scanline anyways, you could also add the vscrol adjustments.

LMS doubling costs more cpu cycles every scanline. It won't get faster.

 

[emkay]

Gr. 7 can look nice with the gprior only colours.

Not sure, if you have seen this mockup.

 

 

The most interesting part with that GR. 7 mode is that you have the "most cpu cycles" per picture cell/detail level.

 

Remember Project-M ?

 

In GR. 7 such a game with PM overlay could stay at 20-25 fps , with more than one enemy on the screen.

Edited February 18, 2013 by emkay

[Xuel]

emkay, is there an executable for that image? I'd like to study the code.

[Tempus]

Gr. 7 can look nice with the gprior only colours.

Not sure, if you have seen this mockup.

 

 

The most interesting part with that GR. 7 mode is that you have the "most cpu cycles" per picture cell/detail level.

 

Remember Project-M ?

 

In GR. 7 such a game with PM overlay could stay at 20-25 fps , with more than one enemy on the screen.

I thought, Project-M is using APAC mode?

[emkay]

 

I thought, Project-M is using APAC mode?

 

That's why Project-M is rather limited in using moving objects. Possibly that's even the cause we don't see any further progress there. In GR. 7 you still have 50% CPU left, after doing the same movement as in Project-M.

[popmilo]

Is it possible to get GR#9-11 doubling the scanlinies like GR#7 without additional CPU/DMA load (i.e. not by using VSHIFT or LMS doubling)? If not possible, what would be the way with minimum CPU/DMA load?

Good question. One that probably every coder on A8 asked himself

GR#9-11 is just ordinary ANTIC mode $F (GR#8 ) with Different combination of bits set in PRIOR register.

So you can simply turn on bits 7 and 6 in PRIOR register ($D01B) and get GR#7 doubling with some of GTIA colors.

Problem is in how GTIA chip is constructed.

 

Read more about this here:

http://www.virtualdu...ntry.php?id=243

 

"...like ANTIC mode E, mode D also outputs BAK + PF0-PF2, and the result is that you can't get an encoding of 11 on AN0-AN1 and only 9 of the 16 colors are available..."

 

What it means is (if my calculation is right of course):

 

pixel value (0-15) -> color register (0-15)

 

0000 -> 0000 P0 1

0001 -> 0000 P0 -

0010 -> 0001 P1 2

0011 -> 0010 P2 3

0100 -> 0000 P0 -

0101 -> 0000 P0 -

0110 -> 0001 P1 -

0111 -> 0010 P2 -

1000 -> 0100 PF0 4

1001 -> 0100 PF0 -

1010 -> 0101 PF1 5

1011 -> 0110 PF2 6

1100 -> 1000 BK 7

1101 -> 1000 BK -

1110 -> 1001 BK -

1111 -> 1010 BK -

 

You get 7 colors and GR#7 doubling...

ps. Plus GTIA horizontal doubling

 

And here in the best manual ever:

http://www.virtualdu...ence Manual.pdf

[popmilo]

emkay, is there an executable for that image? I'd like to study the code.

Looks like simple 4 greys + PMs here and there...

[Tempus]

That's why Project-M is rather limited in using moving objects. Possibly that's even the cause we don't see any further progress there. In GR. 7 you still have 50% CPU left, after doing the same movement as in Project-M.

Understood. But what about the colors? 4 colors seem not to be enough for a Project-M in GR#7. Many DLIs will slow down the program. PM color enhancements are limited, too. What do you propose?

[Synthpopalooza]

What it means is (if my calculation is right of course):

 

pixel value (0-15) -> color register (0-15)

 

0000 -> 0000 P0 1

0001 -> 0000 P0 -

0010 -> 0001 P1 2

0011 -> 0010 P2 3

0100 -> 0000 P0 -

0101 -> 0000 P0 -

0110 -> 0001 P1 -

0111 -> 0010 P2 -

1000 -> 0100 PF0 4

1001 -> 0100 PF0 -

1010 -> 0101 PF1 5

1011 -> 0110 PF2 6

1100 -> 1000 BK 7

1101 -> 1000 BK -

1110 -> 1001 BK -

1111 -> 1010 BK -

 

 

Almost.

 

The colors change slightly for Graphics 10 in graphics 7/15. Color pattern #1000 becomes BAK in this mode and #1001 is still 4 (PF0). Only Altirra 2.0 and Atari++1.72 will display this correctly.

 

Now if a means could be done to use Antic 4/5 you'd get almost all the color combinations (14 colors in 9 and 11, all 9 colors in mode 10) through the use of inverse characters. In the case of mode 10, P3 replaces P2 and PF3 replaces PF2 in inverse,

 

So, potentially, you could do this: Set up ANTIC 5, do character set change every 3 char lines each DLI, double buffer your character fonts and your screen, and put atascii 0-199 onscreen sequentially to fill your screen, then swap the GTIA between normal (0) and mode 10 (128) every VBLANK. It's a full frame change but if you blend the colors right (and use checkerboard dithering where the PF colors mix) it won't flicker as bad, you should get about 35 colors.

Edited February 18, 2013 by Synthpopalooza

[emkay]

emkay, is there an executable for that image? I'd like to study the code.

Sorry, no.

 

The solution is to use all colours in grey tones.

In GPRIOR0 you get 2 players and two misslies usable in double or quad width, acting on 2 colours.

The other 2 players and missiles could be used in full width for the doors/square elements.

 

13 colour, no DLI used , just gprior 0 , ofcourse, you can have 14 colours this way

 

 

The clou is that you have enough cpu time available to handle the overlay.

Edited February 18, 2013 by emkay

[emkay]

 

Looks like simple 4 greys + PMs here and there...

 

That's the way , how it works the most impressive way. Black, grey, white , and colours where needed.

[emkay]

 

Understood. But what about the colors? 4 colors seem not to be enough for a Project-M in GR#7. Many DLIs will slow down the program. PM color enhancements are limited, too. What do you propose?

 

Look, how Project-M is done. There are mostly blocks, so for a Door, you'd need 2 DLI switches.

[Tempus]

 

You get 7 colors and GR#7 doubling...

ps. Plus GTIA horizontal doubling

 

Would it be possible using this and building something like TIP mode, i.e. getting a multi-color resoluton of 160x96?

[popmilo]

Would it be possible using this and building something like TIP mode, i.e. getting a multi-color resoluton of 160x96?

TIP is mixing three different color modes... I don't know how it looks on a real TV but it doesn't sound like a good idea for an arcade game to me...

[emkay]

 

Would it be possible using this and building something like TIP mode, i.e. getting a multi-color resoluton of 160x96?

 

The resulting colours would not help much, as the resolution would get lower.

[emkay]

btw: You know that the colours in Project-M were not real? They were build on PAL mixing.

 

A similar effect is possible, using the PMg every second scanline with gr. 7. The 14 colours were real, that what the A8 can produce. Using PAL Mixing would result in up to 22-28 colours per "visuable" scanline.

[Tempus]

btw: You know that the colours in Project-M were not real? They were build on PAL mixing.

 

A similar effect is possible, using the PMg every second scanline with gr. 7. The 14 colours were real, that what the A8 can produce. Using PAL Mixing would result in up to 22-28 colours per "visuable" scanline.

But the is also a NTSC version of Project-M. How is the coloring done?

[emkay]

 

But the is also a NTSC version of Project-M. How is the coloring done?

 

You see the separation of the colours and the brightness line more clear. The eye mixes the lines a bit, depending on the viewing distance. Emulation shows it wrong.