4 replies to this topic

[Rybags]

 parrot.zip   5.86K   77 downloads

Zip contains Parrot.XEX binary load program (parrot picture). Colours are a bit out, but it shows what can be done.



 apachip.zip   3.45K   67 downloads

Zip contains .ATR with a BASIC LOAD file, as well as .BAS file (run under BASIC from H: drive).

This demo uses a DLI to create a graphics window with 160x160 resolution mixed APAC and HIP modes, with 256 colours.

It uses 2 Display Lists and alternates graphics modes as follows:

Frame 0:
GR. 11 (16 colours, 1 lum) - 1st line from frame buffer 1
GR. 9 (16 lum) - 1st line from frame buffer 2
GR. 11 - 2nd line from frame buffer 1
GR. 10 (9 colours) - 2nd line from frame buffer 3
... repeated 40 times

Frame 1:
GR. 11 - 1st line from frame buffer 1
GR. 10 - 1st line from frame buffer 3
GR. 11 - 2nd line from frame buffer 1
GR. 9 - 2nd line from frame buffer 2
... repeated 40 times

As such, the colour component is displayed every second line for every frame. Every other second line alternates between GR. 9 and 10, which due to the GTIA bug/feature gives 160 perceived pixels instead of 80, albeit with some flickering.

A more complex setup might have the colour and luminence lines interlaced. You can get some idea of how that would look by changing one of the display lists. Try entering POKE 20480,96 to force interlace (poke 112 back to restore).

The program uses short VBI and DLI routines (DLI @ $6000, VBI @ $6080).
The actual display uses around 12K RAM. 3 graphics 7 displays are allocated, then 2 display lists are setup.
Colour 8 (mapped to COLBK in GR. 10) is not used - for purpose of simplifying the code.

You can play around with the program. Before drawing, use POKE 89, SC1H or SC2H or SC3H to select which frame buffer to draw to (colour, lum. mode 10 or lum. mode 9).
For the GR. 10 buffer - the colours used should be 0 thru 7, corresponding to lum values 0, 2, ... 14.
For the GR. 9 buffer - the colours used correspond to the luminence value (0-15).

[CharlieChaplin]

Hmm,
this sounds similar to the polish gr.-format "TIP". It is the last (?!?) step in the HIP, RIP,TIP gr. modes which use the GTIA gr. 10 graphic bug for a higher resolution. There is already a .BMP to .TIP converter available as well as .TIP viewers for the XL/XE (Tipview by Epi and Visage 2.7 by MadTeam). Alas, TIP has one drawback: when one converts BMP into TIP it creates some false colours - not sure why... and TIP has a max. resolution of 160x119 pixels... better than 80x96 non-interlaced APAC, but still not enough...

Afaik there is a webpage (alas in polish language) where one can get all details about HIP, RIP and TIP as well as other information. It is something like... atari8info.pl or so (not sure about the correct URL)... -Andreas Magenheimer.

P.S.: At atariarea.krap.pl or atariarea.histeria.pl you can download many HIP, RIP and TIP pictures and utilities (viewers, converters, etc.)...

[CharlieChaplin]

Well,
you can also find some info about *.TIP here (again, polish language):
http://atariki.krap.pl/index.php/TIP
simply change TIP to HIP or RIP to get info about the other formats as well.

Afaik, Heaven once posted the info about HIP (maybe RIP and TIP also) in english language here or he posted it at comp.sys.atari.8bit ...

But... TIP uses a max. of 160x119 pixels, whereas your routine uses / claims to use 160x160 pixels (maybe even up to 160x192 or 160x200 pixels ?), so there seems to be some difference...

Now, is it possible to use your trick or the TIP trick with gr.8 ?!? Meaning gr.8 (320x200) combined with gr. 10 and gr. 11, thus having 2 lum. (gr. x8 lum (gr.10) x 16 colors (gr. 11) or simply 16 lum. x 16 colors (256 colors) in a 320x200 resolution ?!? This would be absolutely cool !! -greetings, Andreas Magenheimer.

[Heaven/TQA]

www.s-direktnet.de/homepages/k_nadj/tip.html

[Rybags]

There are programs around like CJPEGVIEW which mix GR.11 with GR.15 (using 4 shades of grey). It calls the mode "C-15".

Other combinations are out there too.

The thing in common with many of these "modes" is that you get flickering (except APAC with interleaved GR.11 and 9).

The emulator has a slight bug where colours "bleed" from GR.11 to the next scanline. On a real machine, this is only really valid in the modes which switch between GR.11 and 9 (and/or 10).

Another thing in common with all these modes is that they are very processor intensive. You need either a DLI every line or one DLI which creates a screen Kernal for the duration of the picture.

The best use of these modes is in static displays, title screens or background graphics which occupy a smallish area of the screen.