Intro to C64 GFX Modes for A8 Users

[saehn]

An Introduction to C64 Graphics

For Atari 8-Bit Users

 

Overview

 

These notes are an attempt to provide a simple explanation of the C64's two standard graphics modes. Ideally it may entice some of the accomplished A8 graphicians I've seen to try their hand at C64 graphics. Additionally, I'm hoping that someone is inspired to create something like this for A8 graphics (particularly those that can be produced via Graph2Font with PMGs and DLI!).

 

Finally: this isn't meant as A8 vs. C64. I like the graphics produced by both machines, and always would like to see more from each.

 

Palette

 

Compared to the A8's wide palette of 256 colors, the C64 has only 16. The balance to the comparison is the C64's relative flexibility in displaying its available colors.

 

There are no real "fixed" or "official" RGB values for C64 colors. They occasionally varied slightly across individual machines. However, there are certain standards that have varying degrees of acceptance, such as the palettes from Pepto, DeeKay, Vanja, and Ptoing. See Links (below) for more information. One such palette is shown here.

 

 

Hi-Res Mode (320x200, AKA High Resolution, Single-Color)

 

Hi-Res Mode screens have a resolution of 320x200 pixels. The hi-res screen is divided into 1000 "cells", 40 across and 25 down. Each cell is 8x8 pixels in size, and any two C64 colors can be in each cell. Example cell layouts:

 

 

Here are some examples of hi-res mode:

 

 

 

 

MultiColor Mode (160x200, AKA Medium Resolution)

 

MultiColor screens have a resolution of 160x200 pixels. Each multicolor pixel is twice as wide as a hires pixel. The multicolor screen is divided into 1000 "cells", 40 across and 25 down. Each cell is 4x8 pixels in size. All cells share a common background color. In addition to the shared background color, any other three C64 colors can be in each cell. Example cell layouts (here, all sharing black background color):

 

 

Here are some examples of multicolor mode:

 

 

 

 

Links

 

Commodore VIC-II Color Analysis (Preview)

All you ever wanted to know about the colors of the Commodore 64

http://www.pepto.de/projects/colorvic/

 

Project One

Great introductory tool for most standard graphic modes

http://noname.c64.org/csdb/release/?id=39261

 

Timanthes

More complex tool for more involved graphic modes

http://noname.c64.org/csdb/release/?id=30789

 

References

 

Thanks to CreaMD/DMAgic (Hi Roman!) for already providing the basis for much of this information.

 

http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm

[flashjazzcat]

Absolutely fascinating stuff. I had no clue about how the C64 displayed colour till now.

[emkay]

Looks like a strategical step to subvert the last Atarian...

[saehn]

Looks like a strategical step to subvert the last Atarian...

 

Nah. Actually I'm interested in Atari graphics myself and was hoping that this could stimulate a dialogue between our two groups. I wish there was something closer to Project One for A8 graphics. Since there isn't maybe this inspire an A8er to create similar notes for G2F graphics.

Edited May 7, 2009 by saehn

[emkay]

Looks like a strategical step to subvert the last Atarian...

 

Nah. Actually I'm interested in Atari graphics myself and was hoping that this could stimulate a dialogue between our two groups. I wish there was something closer to Project One for A8 graphics. Since there isn't maybe this inspire an A8er to create similar notes for G2F graphics.

 

I think, we can forget any progress for any tool on the A8. There is no progress in RMT and there is no progress in G2F.

Sadly G2F has got more and more bugs, but the VBXE enhancement seems to work...

I'm not blaming anyone here, but the A8's community seems to be too small, for a further progress on any development.

[frogstar_robot]

I'd be interested in explanations of common software modes like MCI, FLI, SH and so-forth which are analogous to things like Super IRG, HIP, RIP, and so-forth on the A8. And what kind of tricks are available to make the hardware do some things it shouldn't be able to do "on paper".

 

It would also be interesting to know what tradeoffs those involve in terms of CPU usage, flicker, placement limitation and so-forth. And what are the best tools on PCs and the C-64 itself to create the screens.

 

Another good side topic is usage of sprites to enhance screens or using sprites as a graphics layer.

 

And I too would prefer to read about all this without asides on the subject of A8 superiority. It is interesting stuff in and of itself and any such should go to the monster thread reserved for it.

Edited May 7, 2009 by frogstar_robot

[frenchman]

That's just the basic stuff we've seen on Atari vs C64 from Wolfhound...gang...man....something.

[saehn]

Yeah but again, not meaning this as A8vsC64. I'd like to see something like this for the A8 graphics modes. The Wiki is pretty good but seems a little lacking, especially for the new modes.

[frogstar_robot]

Yeah but again, not meaning this as A8vsC64. I'd like to see something like this for the A8 graphics modes. The Wiki is pretty good but seems a little lacking, especially for the new modes.

 

The following on Wikipedia covers some of the software-driven modes:

 

http://en.wikipedia.org/wiki/Software-driv...8-bit_computers

 

I took the following straight from the A8 FAQ. Perhaps someone knowledgeable can talk about things like GPRIOR.

 

GRAPHICS MODES:

ANTIC GTIA CIO/BASIC Display Resolution Number of

Mode # Mode # Graphics # Type (full screen) Colors/Hues

----------------------------------------------------------------------

2 0 Char 40 x 24 1 *

3 - Char 40 x 19 1 *

4 12 ++ Char 40 x 24 5

5 13 ++ Char 40 x 12 5

6 1 Char 20 x 24 5

7 2 Char 20 x 12 5

8 3 Map 40 x 24 4

9 4 Map 80 x 48 2

A 5 Map 80 x 48 4

B 6 Map 160 x 96 2

C 14 ++ Map 160 x 192 2

D 7 Map 160 x 96 4

E 15 ++ Map 160 x 192 4

F 8 Map 320 x 192 1 *

+F 1 9 Map 80 x 192 1 **

+F 2 10 Map 80 x 192 9

+F 3 11 Map 80 x 192 16 ***

* 1 Hue, 2 Luminances

** 1 Hue, 16 Luminances (GTIA); or, 1 Hue, 8 Luminances (FGTIA)

*** 16 Hues, 1 Luminance

+ require the GTIA/FGTIA chip. (1979-1981 400/800's shipped with CTIA.)

++ Not available via the BASIC GRAPHICS command in 400/800 version of OS.

 

(See a separate section in this FAQ list for a discussion of the "missing"

ANTIC Modes 0 and 1.)

 

GRAPHICS INDIRECTION (COLOR REGISTERS AND CHARACTER SETS):

Nine color registers are available. Each color register holds any of 16

luminances x 16 hues = 256 colors. (Four registers are for player-missile

graphics.

 

Character sets of 128 8x8 characters, each with a normal and an inverse

video incarnation, are totally redefinable.

 

PLAYER-MISSILE GRAPHICS: (byte height and OR corrections from Piotr Fusik)

Four 8-bit wide, 120 or 240 byte high single color players, and four

2-bit wide, 120 or 240 byte high single color missiles are available.

A mode to combine the 4 missiles into a 5th 8-bit wide player is also

available, as is a mode to OR colors or blacken out colors when players

overlap (good for making three colors out of two players!) Players

and missiles have adjustable priority and collision detection.

 

DISPLAY LIST INTERRUPTS (DLI's):

Screen modes can be mixed (by lines) down the screen using the Display

List - a program which is executed by the ANTIC graphics chip every

screen refresh:

 

All other screen attributes (color, player/missile horizontal position,

screen width, player/missile/playfield priority, etc.) can be adjusted

at any point down the screen via DLI's.

 

And a bit more

 

http://lepix.sourceforge.net/#faq

http://rjespino.tripod.com/8bit/colrjpeg/colrjpeg.html

[+SpiceWare]

One thing people may not realize is that when using a character mode (tile based graphics), each of the 1000 cells can individually be set for multi-color or hi-res.

 

In this example from Humaniod you can see that the plants, water and pipes are in hi-res mode while the dirt is in multi-color mode.

Edited May 7, 2009 by SpiceWare

[+remowilliams]

Interesting, I didn't know the details of the C64 modes. And since this wasn't buried in a thread run amok, I got to read it.

[Heaven/TQA]

there are some additional built in modes... details here:

 

http://codebase64.org/doku.php?id=base:built_in_screen_modes

[DracIsBack]

Thanks for sharing! Always wondered how the C64 pulled off some of the graphics it did! Neat stuff

[+SpiceWare]

there are some additional built in modes... details here:

 

http://codebase64.org/doku.php?id=base:built_in_screen_modes

I'd forgotten about the Extended Background Color mode.

[Bryan]

Interesting. Thanks for the info.

 

I think the best approach to an A8 graphics program would be one that builds a kernel as you draw using a "rip-up and retry" approach to achieving the requested colors. It could also allow a line to be locked if the user wanted to enter custom code.

[emkay]

Well, the pic is created in Graph2fnt, by a horrible procedure of jumping around the tool's limitations.

The pic is originally 8x16 pixel (128 pixel) and it shows 128 colours. Every of those pixel can contain it's separate colour.

And, no, not 100% of the hardware is consumed here... Neither missiles nor GPRIOR features are used. Interlace ? No!

And, yes, you cannot use this high colour resolution for a full image, but you could do fullscreen images with real 8 shades and different colours for many objects on the screen at the resolution of 160x240 pixel.

Edited May 8, 2009 by emkay

[saehn]

I think the best approach to an A8 graphics program would be one that builds a kernel as you draw using a "rip-up and retry" approach to achieving the requested colors. It could also allow a line to be locked if the user wanted to enter custom code.

 

That would be awesome. Allow for the direct manipulation of DLIs and PMGs by more advanced users, but let non-techs have some fun too.

[frogstar_robot]

I think the best approach to an A8 graphics program would be one that builds a kernel as you draw using a "rip-up and retry" approach to achieving the requested colors. It could also allow a line to be locked if the user wanted to enter custom code.

 

That would be awesome. Allow for the direct manipulation of DLIs and PMGs by more advanced users, but let non-techs have some fun too.

 

 

It didn't do it automatically but the RAMbrandt drawing program did let you set DLIs with the cursor. You set where it started, ended, and the color. I always thought of them working like colored cellophane sheets that you place over the graphics background. RAMbrandt was pretty cool for an eighties graphics software but it didn't support the software modes in use now nor did it allow for using PMGs as enhancements.

[+CharlieChaplin]

Well,

here is some old info I have collected about HIP mode... maybe this is helpful for someone...

-Andreas Koch.

 

-------------------------------------------------------------

 

H I P:

 

hi everybody... this is v0.5 of the HIP-FAQ for all coders...

 

Date: 29th, August 1996...Writer: HeAvEn of Taquart

 

1. What is HIP?

 

HIP is a new method to displaing pictures on small atari...

 

HIP stands for HARD-Interlacing-Picture and was found by

Members of HARD Software, Hungary in June, July 1996...

 

It enables to display 160 x 240 Pixels with 30 shades without

nearly all flickering (depends on the source-picture you use)...

HARD stands not for HARD or HEAVY Interlacing, just for the

inventors... (HARD demo group, Hungary)

 

2. The History of HIP

 

Tamas Bene and I had a "EMail"-conversation the last few month and

we were talking about older demos and effects and suddenly we

have talked about the Visdowm II-Demo of JAC! where JAC had

managed to display 16 colors/shades in a resolution of Gr.15, which

means 160x200... We talked about the "unity"-demo where Our-5oft

switched 3 graficmodes in 1 scanline,

gr.8,gr.9 and something similar to gr.15 by altering the prior-

register per DLI... what do you think happens when

writing #0 in that register at the beginning of a scanline, waiting

some time... switching to gr.9 by writing #$40 there and after

a little while in the last 1/3 of the scanline back to gr.0 by

writing again #0 into it... what does the GTIA produce?

not gr.0 (or gr.8...)as normaly... he displays something similar to gr.15!!!

 

He then told me some stories of the coding-sessions of "Joyride" last summer

and in the DIL-Plasma-Screen they discovered another "BUG"...but

Tamas had written down the FX and had forgot it... till we were

taking about GTIA-BUGs...

 

so we talked now about known GTIA-Bugs and the next day Tamas was

upset and told me he had discovered a new bug and he had reproduced the

DIL-"BUG"... he discovered that some scanlines were shifted by

a half (!) gr.9-pixel when the scroller starts and they didnt fix

that BUG in the DIL-Screen...

But after reproducing this BUG he discovered that the reason wasnt the

scroller... it was the special display-list-routine...

 

3. Technical Infos conc. HIP

 

The basic idea is that all gr.10-lines were shifted by a half

color-clock (or pixel) by the GTIA and that always!!!! but noone

has ever tried to combine gr.9 and gr.10...

all have combined gr.9 (16 shades) and gr.11 (16 colors) to display

256 different colors (like in APACview)... but the resolution

was still 80x200... (80x192 interlaced, 80x96 non-interlaced)

 

So here is an ASCII-Description of the basic idea:

 

These are the combinations which are needed for the gr10-line and the

gr9-line to display the wanted HIP-color:

 

 

GR10 :000 000 000 222 222 222 222 444 444

GR09 :000 111 222 111 222 333 444 333 444

HIP :0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0

 

GR10 :444 444 666 666 666 666 888 888 888

GR09 :555 666 555 666 777 888 777 888 999

HIP :4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5

 

GR10 :888 aaa aaa aaa aaa ccc ccc ccc ccc

GR09 :aaa 999 aaa bbb ccc bbb ccc ddd eee

HIP :9.0 9.5 a.0 a.5 b.0 b.5 c.0 c.5 d.0

 

GR10 :eee eee eee

GR09 :ddd eee fff

HIP .5 e.0 e.5

 

and voila... here are 30 possibilites of shades...

Our eyes are averaging the two luminance-values by

interlacing the two lines each vbi.

--

 

but attention... in gr10 it is possible to select each

of the xl color registers (704-712), so in the display-

routine and the display-list-interrupt the color-registers

have to be set in a correct way!!!!

 

so if you look in the above table the values mean the xl-luminance!!!

example:

 

if we want to display HIP-color 6.5 then we have to set in the

gr.9-line the value 7 (in basic by color 7 plot x,y)

for the gr10-line there is the value 6 but... it would be

wrong to set the pixel by color 6... coz. we have just 8 color-registers

in gr10... so what about setting the color-registers

in the following way???

 

704 = 0

705 = 0

706 = 2

707 = 4

708 = 6

709 = 8

710 = 10

711 = 12

712 = 14

 

so... if we want luminance 6 then we have to set the pixel by

color 4:plot x,y !!!!!!! in gr.10 the pixel-value selects the

color-register!!! an empty/black pixel is not set by color 0 !!!

color 0 says to the gtia "put the pixel with the color which

is defined by color-register 704" !!! so if you have put 0 in 704

there will be a black-pixel visible...

 

But in gr.9 we can`t set 14 in 712 coz. in gr.9 register 712 defines

the basic-color... so if we want 30 grey-shades... we have to put

0 there... but in gr.10 there must be 14 there... hmmm... the solution

is a special DLI and Display-Lists...

 

1. vbi 2. vbi

 

DList1 DList2

 

gr9 (0) gr10(0) dli-bit set

gr10(1) gr9 (1)

gr9 (2) gr10(2) dli-bit set

gr10(3) gr9 (3)

gr9 (4) gr10(4) dli-bit set

... ...

 

(x) is the number of the scanline in each screen-ram...

 

so... if we loop this... we interlace between these two gr9 and gr10

screen-rams and we will have a hip-picture...but we have to set

the correct values in colbk $d01a (712, see above!!!)

 

1. vbi 2. vbi

 

DLI1 DLI2

 

pha pha

lda #$40 lda #$80 ; switching to correct gr-mode (gr9, gr10)

sta wsync sta wsync

sta gtiamode sta gtiamode

lda #0 lda #14 ;setting correct background-color

sta $d01a sta $d01a

lda #$80 lda #$40 ;switching to next gr.mode (see displaylist)

sta wsync sta wsync

sta gtiamode sta gtiamode

lda #14 lda #0 ;and dont forget the background color!

sta $d01a sta $d01a

pla pla

rti rti

 

so... this is the technique, but there is a "big" problem by

converting pictures...in gr9/10 each pixel is 4 "bits" large or

a nibble and in a hip-pixel 2 of them (the overlaping ones...)

 

here an example:

 

gr.10: ..00002222...

gr.9 : 000022224444...

HIP : ..00112233..

 

remember: GTIA shifts the gr10-lines by a half gr.10 pixel!!!

 

so... we will always track one half of the pixel-value to the next

hip-pixel... and this is the difficulty... the hip-colors are

NOT able to be set free!!! there are restrictions like the main one:

 

two following hip-pixels should not have a difference of their luminace

greater than 2 !!!! coz. then we could not set the right values and

the hip-pixel will begin to flicker!!!

 

Best way is to use digitised source-pictures with smooth luminance

for converting to hip-format... or raytraced stuff...

 

so try to code such a linear optimisation-algorithm...

 

4. Converters:

 

they are avaible for the following systems:

PC: Tipconv 1.0.0 by Epi (allows to convert GIF, JPG, PNG into TIP or HIP)

Amiga: converter by HEAVEN of Taquart (available where ?!?)

XL: (A8)JPEG-converter by Raphael Espino (look for Vers. 0.7 or newer)

 

For Converting you need:

 

-one of the above converters

-a paint-program which can produce pictures in REAL greyscale and max. 64

colors/greys in a size of 320x200 (not needed for the XL JPG-converter!)

I think the new version of the bmp2hip-pc-converter can handle

bigger sizes and more colors... however small pics can be converted much

better and faster on the little Atari (and you can view more details);

-the 320x200x64 picture must be saved in Windows-BMP format

(or JPG if using the JPG converter by Raphael Espino !!)

-a transfer program to XL (Ataridsk, SIO2PC, Ape, etc.)

-a HIP-display-routine on XL (Hipview by MacGyver or Visage by MadTeam)

 

I hope I could help someone to do HIPing... Heaven, 30.08.96

 

CrEdItS:

 

-Text by Heaven

-Algorithms by Sanyi and Tamas of HARD

-HIP-Display-Routine by Tamas of HARD

-JAC! for inspiration...

- Raphael Espino (Raf) for A8JPG-converter

 

ps. we have tried to do color-hipping but there is a difficulty

with the luminance of the xl-colors... the luminance is different

of some colors while setting the luminance to 0... so it

is HARD to calculate correct colors...but it is not impossible

(just read the Ripinfo.txt article by a member of Madteam...)

 

Future stuff:

 

-converters which can handle several formats and colored-picture formats

by generating the greyscale values by themselves...

-color-HIP... an algorithm to generate colored hips...

(look for the RIP sample disk, named RIPSRC.ATR to learn more)

-maybe it is possible to interlace HIP, so we could increase

the amount of colors once more ??? (seems to be possible with multi-color-RIP pics or simply

RIP mode 48, which has much more colors than mode 32!)

 

Many Thanx for all:

 

-Tamas Bene of HARD ...

_Slaves and rest of Taquart

-Gumi of Tight

-Marek Tomczyk for Websupporting

 

--HeAvEn

 

---------------------------------------------------------------------------------------------

 

Attached: some HIP pictures...

[+CharlieChaplin]

And err,

here is some old info about RIP as well... maybe usefull, maybe not... -Andreas Koch.

 

-----------------------------------------------------------------------------

 

subject: RIP format description

date: 15 Sep 2000 03:38:56

from: "Lizard :: aIDs" [e-mail adress removed!]

 

 

RIP picture format description

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

Original text by Rocky of Madteam taken from Syzygy Magazine

 

RIP picture was shown first time in Orneta of Poland in '97 in Igor

demo by Madteam. There we copied several disks of RIP images. RIP is

a new graphics storage format on Atari 8-bit. It is based on already

famous HIP picture format (Gr.9 + Gr.10). Theoretically it is possible

to get 144 colors (there are about 40 in practice) with resolution of

160x238 (RIP mode 32; 16 lum x 9 col). RIP is more complicated than HIP,

because of the header which contains a lot of information about colors,

resolution and a note from the author. RIP can have various vertical

sizes (max. 238 lines) which cause less space on disk and faster reading.

 

(E.g. we have a logo with 50 lines. Our logo will be saved with 200 lines

as HIP and takes about 16kB but saved as RIP - only 4kB plus several bytes

of header. That's a difference, isn't it?) In addition RIP can be colored

and HIP can only be grey scaled. (HIP can also be colored but there is no

room for color info in the header.) The first one can still be packed

(algorithm in end phase) for RIP dedicated Visage viewer which is able to

recognize its size, colors, compression method and displaying on screen.

Saving HIP as RIP is no problem 'couse of similar data format.

Adapting existing HIP viewers for RIP pictures shouldn't be problematic too;

Only what has to be done is format recognition, displaying of various image

height and setting colors (for Gr.10) from the header (see below).

 

 

How to make a RIP picture?

~~~~~~~~~~~~~~~~~~~~~~~~~~

 

It can be quite difficult. There is a converter for Amiga and PC.

This is not a real converter from any graphics format (GIF, IFF or

Jpeg) to RIP. To make a RIP picture, you will have to use programs not

only dedicated to RIP. The best for Amiga is Personal Paint and for

PC - Display. It's quite a large job. One picture has to be divided

into two others. Next: size modification, color palette reduction

(one of these two pictures has to be 16 grey scales what can be done

with almost all programs and the other picture has to be in 9 colors,

what most programs for the Amiga and PC simply cannot do).

The effect can be very satisfactory, but it might also be completely

bad, which happens quite often (none of the pics is perfect).

You can then always create a HIP picture, which is better in this case

(grey scale is easier to do) but you will be limited to 200 lines.

Well, life is brutal...

 

Header description:

~~~~~~~~~~~~~~~~~~~

 

In 'Description' filed text with quotes (") is pure ASCII string.

 

Offset | Len | Description

---

0 | 3 | "RIP" - RIP image identifier

3 | 4 | version:

| | "1.x " - standard RIP

| | "2.0 " - Multi RIP

7 | 1 | graphics mode:

| | $20 - RIP or HIP

| | $30 - Multi RIP, palette at the end of file

| | $0f - Graphics 8

| | $4f - Graphics 9

| | $8f - Graphics 10

| | $cf - Graphics 11

| | $0e - Graphics 15

8 | 2 | compression method:

| | 0, 0 - no compress

| | 0, 1 - RIPPCK

10 | 2 | header length in bytes, MSB/LSB !!!

12 | 1 | not used

13 | 1 | image width in pixels (max. 80) *see below

14 | 1 | not used

15 | 1 | image height in lines (max. 238)

16 | 1 | display option (?), standard set to $20

17 | 1 | author note length in bytes (max. 256)

18 | 2 | "T:" - text identifier

20 | n | author note

20+n | 1 | number of colors (fixed = 9 from Gr.10)

21+n | 3 | "CM:" - color map identifier

24+n | 9 | color values **see below

33+n | 3 | "PCK" - Multi RIP packed file only, means packed

| | images data

 

Directly after header images data are stored. First Gr.10, next Gr.9.

 

* HIP and RIP are 80 pixels wide pictures with shifted 9-color plan

(Gr.10) relativelly to 16-grey shaded plan (Gr.9) for half pixel

right. Thus, they appear as 160x200, but one pic has only 80x200;

 

** Number of colors is fixed to 9 now but it may change. So, take

number of colors from 20+n byte of header (n - length of author

note) for safety. (RIP mode 48 has more colors !!)

 

Displaying RIP "1.x" picture routine is similar to HIP routine. The

only difference is to set color registers with values put behind "CM:"

while Gr.10 line.

 

Information above is enough for writing own procedure showing RIP

1.x picture. For now I don't have any info about Multi RIP especially

for compression algorithm and color palette. The only thing I know

for sure is the palette should be changed every 2 scanlines. Maybe

someone else knows a little bit more about Multi RIP (or RIP mode

48 with many more colors than mode 32)...

 

Lizard/aids

 

----------------------------------------------------------------------------------

 

Attached: some RIP pics...

[+CharlieChaplin]

Well,

last not least here is some old info about TIP... Sorry for the bad text layout, but this is not my fault (its just how the text originally appeared and I did not change it)... -Andreas Koch.

 

----------------------------------------------------------------------------------------------

 

Taquart Interlace Picture (TIP)

===============================

 

This text is a translation of the

 

original article printed (yes!

 

printed!) in Polish magazine

 

"Atarynka", no. 2/2002.

 

This article describes a new graphics

 

mode, capable of showing 256 colors

 

in resolution 160 x 119.

 

 

HIP

---

 

Undoubtedly, invention of the HIP

 

(Hard Interlace Picture) mode was a

 

breakthrough in displaying graphics

 

on small Atari. This mode is capable

 

of showing many shades in high

 

(for an 8-bit computer) resolution

 

160 x 200, with little flickering.

 

It's hard to precisely tell

 

the number of shades this mode can

 

show. It's limited to 30 (shades

 

from 0 to 14.5, every 0.5), but

 

you can't freely use all the 30 shades,

 

because average amount of information

 

about single pixel is 3.5 bits

 

(GTIA mode 9 is 4-bit, mode 10 is

 

3-bit).

 

Excepting the confusion about HIP

 

files (there are two different

 

formats), enabling this mode is

 

easiest with setting GTIA color

 

registers to following values:

 

$X0 $X2 $X4 $X6 $X8 $XA $XC $XE $X0

 

(X is a hex digit, the color code).

 

This way all color registers are used

 

(you can't e.g. display a cursor

 

using a sprite in a distinct color),

 

but thanks to it you only need

 

to switch GTIA mode every line

 

(alternatively 9 and 10).

 

 

RIP

---

 

HIP has one big disadvantage:

 

it's monochrome. An idea of adding

 

colors is filling GTIA color registers

 

with different color codes.

 

Another problem, also solved

 

in RIP (Rocky Interlace Picture)

 

file format is picture dimension,

 

no longer fixed to 160 x 200.

 

Moreover, we can use more colors

 

by changing GTIA color registers

 

in consecutive screen lines.

 

Biggest disadvantage of RIP is

 

difficulty of manipulating it.

 

Creating a graphics editor, which

 

allows easy drawing in this mode,

 

is a difficult task. Also problematic

 

is the conversion - there's no easy

 

criterion of selecting color codes

 

for GTIA 10 mode. Fortunately,

 

all these obstacles are rewarded

 

by good looking of the graphics.

 

 

TIP

---

 

TIP is an enhacement of HIP,

 

adding the colors. The way colors

 

are added is so simple, that it's

 

odd why this mode wasn't invented

 

at the same time as HIP. This method

 

has been used so far for 256-color

 

modes (APC, ILC) and coloring MIC

 

pictures (CIN mode). Colors are

 

added by GTIA 11 lines. These lines

 

are displayed every frame, in same

 

place, with same contents. The line

 

of colors is always directly above

 

corresponding line of shades.

 

Of course nothing is for free, so we

 

pay for the colors with twice lower

 

vertical resolution and introduction

 

of dark lines. The good thing is

 

that pixels are now squares, which

 

is convenient for conversion.

 

We may consider "interlacing"

 

the colors, i.e. displaying distinct

 

colors in different frames. You have

 

to check in practice if it gives

 

a good effect.

 

 

Displaying

----------

 

The way of displaying TIP mode

 

is a simple enhancement of displaying

 

HIP. The GTIA color registers have

 

following values:

 

$00 $02 $04 $06 $08 $0A $0C $0E $00.

 

On the first screen we see:

 

- first line of colors (GTIA 11)

 

- first line of shades (GTIA 9)

 

- second line of colors (GTIA 11)

 

- second line of shades (GTIA 10)

 

...

 

and on the second one:

 

- first line of colors (GTIA 11)

 

- first line of shades (GTIA 10)

 

- second line of colors (GTIA 11)

 

- second line of shades (GTIA 9)

 

...

 

As you can see, TIP mode without

 

interlacing the colors takes less

 

memory/disk space than HIP (ca. 12 KB

 

vs 16 KB for a picture of typical

 

size).

 

 

Conversion

----------

 

Since there are no tools for

 

creating graphics directly in TIP

 

format (there's even no TIP file

 

format spec), the easiest method

 

of achieving graphics in this mode

 

is to convert it from a bigger

 

computer, and write a routine

 

to display it.

 

You can convert a 24-bit picture

 

in following way. You must ensure

 

proper resolution and palette.

 

As for the first, you scale/crop,

 

for the second - transform to Atari

 

palette. You can find 256-color

 

Atari palette, in Photoshop format,

 

e.g. in the Atari800 emulator.

 

Now you only need to take colors

 

and "HIP-data" for GTIA modes 9

 

and 10. The easiest way of getting

 

the colors is taking color of every

 

second pixel. Conversion of shades

 

to HIP can be problematic, but

 

a simple and giving good results

 

method is taking shade of every second

 

pixel (starting from the first) for

 

mode 9, and the other pixels' for

 

mode 10. We code GTIA 9 shades on

 

4 bits and in mode 10 we ignore

 

the lowest bit. As we have data

 

for modes 11, 9 and 10, there's

 

no problem to display them.

 

Piotr Fusik (Fox/Taquart)

 

P.S.: For easy conversions you may

also use the PC progam BMP2TIP.EXE

by EPI/Allegresse. Simply downsize

your BMP picture to a minimum of

160x1 and a maximum of 160x119 and

256 colors (uncompressed, please).

Then copy the new created TIP

picture to the little Atari and use

the A8 program TIPVIEW.COM by

EPI/Allegresse to view it...

 

------------------------------------------------------------------------------

 

Alternatively use Tipconv. 1.0.0 on the PC (on WINtel PC`s via the command line, not sure how it works on other PC`s or OS`s) to convert GIF or JPG or PNG pics into A8 TIP pictures. Then again use Tipview.COM by Epi to view them on the A8 (or convert many pics and then use Tip Animator by TeBe to animate them)...

 

Attached: some TIP pics...

[+CharlieChaplin]

Well,

in my collection there is also an old info about Gr. 9++ and G. 10++ modes... maybe this is helpful in any way...

-Andreas Koch.

 

----------------------------------------------------------------------------------------------

 

Graphics modes 9++ and 10++

===========================

 

This text is a translation of the

original article published

in Polish magazine "Atarynka",

no. 2/2002.

 

The most often used mode is "Konop's

mode", used for the first time

by Konop/Shadows in "Asskicker".

It has been used for years,

and probably there's no other mode,

as fast and with similar screen

parameters (square pixels, small

screen memory, 16 shades [or other

GTIA mode]).

lewiS/AiDS

"32 shades in mode 9"

(article published

in "Atarynka" no. 1/2002)

 

In this article I'll present the way

of obtaining a mode, which differs

from "Konop's mode" (also known as 9+)

by lack of blank lines, and which

is called, depending on used GTIA

mode, 9++ or 10++.

 

Advantages of the new mode

--------------------------

1. It's faster than the one with

blank lines (9+).

2. Display List is significantly

shorter (every mode line is created

by single DL instruction).

3. Since DL for this mode can load

ANTIC's screen memory pointer only

once, you don't need two DLs for

double-buffering, you may just

alter the screen address in DL.

4. It's easy to set another (up to 16)

height of a line of mode

(e.g. 3, 5 or 6 instead of 4).

5. It looks better - it's a matter

of taste, but in my opinion colors

in GTIA 10 mode look much better

- the blank lines lower

the brightness and saturation.

 

Disadvantages

-------------

1. This mode makes ANTIC eat less

cycles, for the cost of some

additional work of 6502. There's

not much of this work for CPU,

unfortunately it must be properly

synchronized with the display.

It means that in practice it's

not easy to get the first advantage,

i.e. it requires additional

programming effort.

2. It's known that there're problems

with displaying graphics in

the last, 240th line. This isn't

a problem for 9+ mode, because

you may put JVB at the end of DL

to get 60 lines. In modes 9++/10++

we may stay with 59 lines or...

use advantage 4 and lower

height of the top or the bottom

line to 3.

 

Idea

----

The idea is simple - let's make ANTIC

display the same line a few times,

using its internal memory. This is

what happens in mode 8 (system

GRAPHICS 3), where the data comes from

main memory only in the first line,

and then from ANTIC's own memory.

 

Theory

------

ANTIC contains internal 4-bit register

DCTR, which counts scanlines. Normally

for every line of mode it counts from

zero to a value specific to the mode

(in our case of ANTIC 15 mode it's

zero). It's different after enabling

vertical scrolling. In first scrolled

line DCTR counts from VSCROL to 0,

in the subsequent normally, and in

the last from 0 to VSCROL. "Counts

from a to b" means: first DCTR is

loaded with a, and near the end of

every line DCTR is compared with b,

if there's equality, next DL

instruction will be fetched; otherwise

DCTR is incremented by 1.

Consider following DL:

$2f

$0f

and VSCROL=13 (decimal). We will see:

- first line 4 times (DCTR values

13,14,15,0 - DCTR wraps from 15

to 0, because it's 4-bit)

- second line 14 times (DCTR values

from 0 to 13)

Similarly for VSCROL=3:

- first line 14 times

- second line 4 times

What is important, the screen data

repeated in several scanlines is

fetched from main memory only once.

 

Obtaining the mode

------------------

As should be now easy to figure out,

to have each line shown 4 times,

we create following Display List:

b($6f),a(screen)

b($0f)

b($2f)

b($0f)

...

and only have to update VSCROL

register in proper moments.

 

Following picture should help in

understanding what happens

(in this English translation

I'll just use ASCII art, I hope

it's readable :-) ).

 

DCTR

13 @-------------------------

14 --------------------------

15 --------------------------

0 --------------------------

0 ==========================

1 ==========================

2 ==========================

3 ====!==================*##

\--visible screen--/

 

'-' - first line of mode

(bit 5 in DL is set)

'=' - second line of mode

(bit 5 in DL is clear)

'@' - here VSCROL must contain 13

'!' - here starts DLI

'*' - here VSCROL must contain 3

'#' - here we put 13 into VSCROL

 

This picture shows two lines

of mode, i.e. 8 scanlines.

It also shows the timing (scale

is not preserved) - as time goes

by, each scanline is displayed

from the left to the right.

 

First VSCROL must contain 13 decimal

(it's a 4-bit register, so high

nibble of value written to $d405

may be anything). As soon as ANTIC

loads DCTR with this value, first

line of mode is guaranteed

to be displayed correctly. Then

the second line will be shown

and only near the end of last

scanline VSCROL is required to

contain 3. So we have much time

to write 3 to VSCROL. We may do it

e.g. on DLI in the first line.

It's much worse with preparing

to display third line of mode.

As you see on the picture ('#')

there's little time to put 13 into

VSCROL (just a few cycles).

 

Possible implementations

------------------------

We may update VSCROL:

a) using DLI interrupt,

b) inside unrolled code of our effect,

c) using one of POKEY timer IRQs.

 

Implementation a) is undoubtedly

easiest, unfortunately it's also

the slowest one. Optimal is

implementation b), unfortunately

it can be applied only to simple

effects, like bump mapping.

Implementation c) could be superior

to a), because POKEY timers may

be set with single cycle accuracy,

so we don't need to waste time

in the interrupt routine.

Unfortunately this implementation

is impractical (in a game or demo),

because POKEY timers are also used

for generating sound and we don't

want to sacrifice music quality

(less channels) only to enable

new graphics mode.

 

DLI interrupt routine

---------------------

We want it fast. Apparently using

DLI every second line of mode,

i.e. every 8 scanlines, is enough.

We enable it in DL opcodes with

5th bit clear. The interrupt

starts near the beginning of last

scanline (see '!' on above picture).

Normally the NMI service routine

checks the interrupt type (DLI

or VBLKI) and saves the registers

(at least the accumulator).

Nevertheless we still have much time

before writing 13 to VSCROL.

The easiest way to waste this time

(and ensure proper synchronization)

is to use WSYNC. Then we just write

13 to VSCROL and apparently it's

late enough to write 3 there.

Here comes an example:

 

lda #<dli

sta $200

lda #>dli

sta $201

lda #$22

sta $22f

lda #<dl

sta $230

lda #>dl

sta $231

lda #$40

sta $26f

lda #$c0

sta $d40e

jmp *

 

dli pha

sta $d40a

lda #13

sta $d405

lda #3

sta $d405

pla

rti

 

; 2 blank lines, 1 line of mode

dl db $90,$6f

dw $f000

; 29 times $8f,$2f => 58 lines

db $8f,$2f,$8f,$2f,$8f,$2f,$8f,$2f

db $8f,$2f,$8f,$2f,$8f,$2f,$8f,$2f

db $8f,$2f,$8f,$2f,$8f,$2f,$8f,$2f

db $8f,$2f,$8f,$2f,$8f,$2f,$8f,$2f

db $8f,$2f,$8f,$2f,$8f,$2f,$8f,$2f

db $8f,$2f,$8f,$2f,$8f,$2f,$8f,$2f

db $8f,$2f,$8f,$2f,$8f,$2f,$8f,$2f

db $8f,$2f

db $41

dw dl

 

What's not obvious at first sight,

is why we write 3 to VSCROL at the end

of DLI, not before writing to $d40a ?

As shown on the picture, VSCROL

in second line of mode is checked

near the end of scanline. Exactly,

there is done a check if current

DL opcode should end its execution.

But when we use DLI, which is called

in last scanline of DL opcode, there's

second (first in the order

of execution) comparison of DCTR

with VSCROL. Thus VSCROL must already

contain 3 when the interrupt starts.

 

How many cycles we gain?

------------------------

It's an important question, because

it was mentioned as the first

advantage of the new mode.

Single line of 9+ mode can look in DL

as follows:

db $0f,$00,$4f

dw screen

db $00

Total: 6 cycles for DL

+ (64 or 80) cycles for screen

(depending on width).

For 9++ mode it's only one DL opcode

(i.e. 1 cycle) + (32 or 40) cycles

for screen. Additionally 6502 has

to update VSCROL, which takes

6 cycles. Counting whole screen

(2 blank lines, 59 lines of mode,

screen address in first line, JVB)

we get:

Narrow screen:

9+: 1+59*(6+64)+2+3=4136

9++: 1+59*(1+32+6)+2+3=2307

Normal screen:

9+: 1+59*(6+80)+2+3=5080

9++: 1+59*(1+40+6)+2+3=2779

Roughly speaking the gain is about

6-7% of CPU time. Unfortunately it's

true only for the optimal

implementation, i.e. updating VSCROL

in unrolled code. If we use DLI,

as in the example, the new 9++ mode

turns out a bit slower than old 9+

(but still much faster than a mode

with no blank lines, done only

with DL). The reason is the time

we waste in STA $d40a. A good

(but hard) solution is to make use

of this time for some calculations.

 

Don't forget about other advantages

of 9++ mode, which can make it better

for your needs than a traditional

DL-only mode. When using DLI, there's

one more advantage: you can change

the background color in different

lines at almost no cost.

 

Piotr Fusik (Fox/Taquart)

<fox@scene.pl>

 

P.S. You may use the described VSCROL

method to get other interesting modes,

e.g. hardware-supported 40x40 text

mode.

 

 

-----------------------------------------------------------------------------------------------

 

no attachments here...

[+CharlieChaplin]

Well,

and here is some old blurb about the colorview and RGB mode(s)... -Andreas Koch.

 

----------------------------------------------------------------------------------------------------

 

"The general way of viewing ColorView files."

By Bill Kendrick, NBS 1993.

 

1) ColorView files:

ColorView mode is a 4096 color mode generated on the Atari Classic line of computers. It was created by Jeff Potter in a program called "ColrView" which is used in conjunction with a GIF viewer called "APACView" (which originally used a different, 256 color screen mode created by him as well). It is done by viewing three 16 color or lum. screens "simultaneously." These 16 color screens are in 80 x 192 resolution (not exactly high for today's standards), and are simply part of the Atari's built-in graphics modes (Graphics 9 to be exact). This 80 x 192 x 16 mode supports 16 shades of a specified color. This has come in handy with ColorView, because by using three screens, one being red, the second green, and the third blue, the Atari simulates 4096 true colors. (Another great advantage to ColorView modes was what it was originally made for: viewing GIF files. GIF files store their palettes' colors as red/green/blue values, so a program that converts GIFs into Color-View files only needs to know how to read the "RGB" palette and uncompress the image.) ColorView files are really made of three files. (Actually, this is really just the standard created by the inventor of ColorView, Jeff Potter.)

 

Last not least, while 4096 color mode is actually 3 files in Gr. 9 (80x192) resolution, one can also have three files in Gr. 8 (320x192) resolution which should give 2x2x2 colors (up to 8 colors, even more with dithering) and also three files in Gr. 15 (160x192) resolution with 4x4x4 colors (up to 64 colors, even more with dithering). Alas, it looks like some of the colorview modes are restricted to NTSC machines or at least do not work very well on PAL machines, this is especially true for the 4096 color (Gr. 9) mode and the 8 color ( Gr. 8 ) mode, while the 64 color (Gr. 15) mode seems to work well on both NTSC and PAL machines for whatever reason. On PAL machines you a) usually don`t see colors (just some greyscales), when using the Gr. 8 colorview mode and you b) don`t see anything near to 4096 colors in Gr. 9 colorview mode (just some 3-5 colors with 16 luminances each, thats 48-80 colors, quite far away from the 4096). But maybe this is just because of the chosen color palette (which transfers GIF colors into A8 colors - the palette provided by Jeff Potter) and could be solved by using a different color palette that works ok on both PAL and NTSC systems...

 

2) RGB-files:

Well, when talking of RGB-Files we simply mean 3 Colorview files (62 sectors each, with extender .R, .G, .B) that are RLE-compressed into one file with the help of Colorviewsquash by Clay Halliwell and viewed with Colorsquashview by Clay Halliwell (later Jview, another GIF converter for the A8 by Jeff Potter, also supported these RLE-compressed RGB-gfx files). Why would one use the RGB-file(s) instead of the separate R,G,B files with standard 62 sectors each - the answer is simple, we have only one file (.RGB) instead of three files and due to RLE-compressing the single RGB files is often much shorter than 186 sectors (which is the normal length of 3 pictures with 62 sectors each). When using RGB without dithering one can often achieve up to 50% or more compression (however with dithering the RLE compression ratio is really bad). But how can one load or display those RGB-files and what kind of RLE compression is used ? Well, simply take a look at the ATR-Image „RGB_SRC.ATR“ and the three sources DISPRGB.SRC, COMPRESS.SRC and EXPAND.SRC; they should explain all nescessary information to load, display or convert RGB graphics files...

 

 

3) Converters & Viewers

 

It seems until today there are only converters and viewers for this (these) gfx-mode(s) on the Atari 8Bit available. No converter or viewer seems to exist on other computers (like PC, MAC, Amiga, etc.). But maybe I am wrong here, anyways, here is whats available on the A8:

 

- converters: Apacview 2.4 by Jeff Potter (converts GIF87a into uncompressed .R, .G, .B files)

Colorviewsquash by Clay Halliwell (converts .R, .G, .B into one compressed .RGB file)

Jview 1.0 by Jeff Potter (converts GIF87a into uncompr. .R, .G, .B or into compr. .RGB)

 

- viewers: Colorview by Jeff Potter (lets you view uncompressed .R, .G, .B files)

Colorsquashview by Clay Halliwell (lets you view compressed .RGB files)

 

-------------------------------------------------------------------------------------------

 

Attached: some RGB gfx files...

Edited May 9, 2009 by CharlieChaplin

[+CharlieChaplin]

And err,

well, how about some CIN pictures, which means Gr. 15 (4 colours or 4 lum.) combined with Gr. 11 (16 colors), so we end up with a resolution of 160x192 (interlaced) and up to 64 colors...

 

Note: The older CIN picture format had 132 sectors in length and 160x192 resolution whereas the paint program Lepix-CIN uses a different format with only 129 sectors in length, but 160x200 resolution... Besides, CPEGVIEW by Raphael Espino can also convert JPG-pictures into the old CIN format...

 

Attached: some old CIN pics...

[+CharlieChaplin]

And finally,

here are the "sources" I have collected for some of the (then) new gfx-modes. Sometimes you will find assembler-sources on the A8 ATR images, sometimes you will only find plain text... look for newgfx_sources.zip

 

For all those that are interested in creating or converting their own HIP, RIP, TIP, RGB, CIN, ... gfx I have also added some A8 tools... look for GR_Conv.zip and I have added some PC tools and conversion utilities... look for all the other ZIP files...

 

greetings, Andreas Koch.

Edited May 9, 2009 by CharlieChaplin