APAC/Trucolour - a whole new approach

[Rybags]

Problem 1: PMGs don't work properly in GTIA modes.

 

Gr. 9/11 - they always get priority. Gr. 10 - only missiles work and only when GPRIOR set for "PLR 4"

 

Problem 2: You can't do 9 register changes in HBlank. I guess you can work the colours to give some extra time, but still a pain.

No known method exists to shift Gr. 10 pixels to a "normal" position. You could probably save 1 cycle per line by turning off DList DMA which should cause Antic to just repeat whatever graphics mode it's already on.

 

Hoping here to have something in the next few days, ie 96 colours in true 160 horizontal resolution, although in "interlaced" fashion like APAC.

 

 

Yes, some nice colours there - maybe we can do 9 register changes? Each scanline would need special processing though to ensure the last colours used were towards the right hand side.

[+Philsan]

I vote for a colorful - not interlaced graphic mode like this one together with a PC program able to do the conversions automatically.

Edited May 13, 2008 by Philsan

[Rybags]

Like I said before, all these modes have pitfalls. Gr. 10 being that it's only 80 across, and all that time needed to change 9 registers.

 

9 register changes: You can preload AXY with 3 values before doing WSYNC. So that leaves:

9 store operations: 36 cycles

6 load operations: 12 cycles

 

Total 48 cycles. Problem is that we only have 34 cycles between RHS of one line and LHS of another. So, overlap of >14 cycles = 14 pixels.

 

Of course, we get a bit less time due to DList instruction fetch. But, whatever we do, there's always going to be some pixels with the "previous" colour register values in place.

 

Maybe a compromise could be to only change 6 or 7 colour registers per scanline. Either way, a clever program is needed to convert the graphics such that certain pixel values are avoided in certain places.

Edited May 13, 2008 by Rybags

[analmux]

Problem 1: PMGs don't work properly in GTIA modes. Gr. 9/11 - they always get priority. Gr. 10 - only missiles work and only when GPRIOR set for "PLR 4"

 

All PMs can be used in gr.10 mode. no problem. I did tests already. PMs can indeed be used to enhance resolution here and there. Using f.e. 5th player mode and colpf3 = black, you can have 160pix res. outlines with missiles easily. Remember that colpf3 has always the highest priority.

 

Problem 2: You can't do 9 register changes in HBlank.

 

But you can if you don't restrict to hblank. When only a palette-change is needed in the right part, then the needed reg-change can easily be done during drawing the left part of a scanline....etc.

 

Problem is if you can do this in the general case. An artist could of course make clever usage if needed.

Edited May 13, 2008 by Analogue Multiplexer

[Heaven/TQA]

are there really no schematics/internals of Antic available?

 

maybe there are some hidden features...

[Rybags]

I think Antic's bag of tricks is limited anyway.

All it does is feed data to GTIA, which does the grunt work so far as doing the display goes.

 

Of course, we have nice Antic tricks like VScroll foolery to get vertical resolutions that aren't in the book.

 

Looking back at the Gr. 9 thing - a big-arsed Kernal could do some nice things. Just a pain to implement on an individual picture basis.

One possibility might be to do dynamic changes from narrow-screen to standard screen mode on every scanline.

No idea if it would be workable, plus it would look kinda strange. Plus, it's sacrificing 6 machine cycles for the sake of saving 4.

 

Might have to play though with DList DMA tricks - only 1 cycle to be saved there, but it does mean a colour becomes ready at least 1 pixel earlier.

Edited May 13, 2008 by Rybags

[analmux]

OK I did a small colour/priority test.

 

Here you see a gfx 10 screen with vertical bars of graphics with increasing color-code.

The triangles are overlayed PMG.

 

Actually, the PM0 has the highest priority in this setting (145 --> gprior)

and PF3 (black here) doesn't have priority over all other gfx, but only over PF0,1,2 and BK.

 

It looks like there are possibilities to use PM overlays to enhance hor. res. a little here and there.

[Tezz]

It's interesting to read this thread, back in 1989 myself and my brother noticed that there didn't seem to be anyone exploiting those GTIA modes fully and in particular gfx10 so we decided to get to work creating a drawing program which we dubbed pandraw. For our own use in demos and game loading pics. We worked on that on and off until around 1992 adding new features and ideas. The early versions were simply gfx 10 screens with dli's added which to me at the time was great because even with the restricted res we had free colours at last! I can remember creating a lot of pics including the title screens for a platform game and missile command rip off cloan that we created for (compiled) Turbo Basic and some pics I did just for the sake of drawing such as an in-game pic of the game Virus. In the early versions we developed a simple file format to contain the dli data etc so they were a self contained file. Pretty simple beginnings but we were starting from the ground up with this so every small success along the way was a achivement. Anyway, as we didn't like the blank scanlines of known modes like APAC the idea of experimenting with Antic was interesting to us. Around 1990 we were attempting some of the ideas being discussed here trying to create a new mode, some tests had successes but the fact that the players were restricted in this mode and the fact that I wasn't confident thinking that someone else would have already done something like this if it was possible started to loose my interest in it. I remember reading an article in New Atari user (as I think it had become by then) creating new Antic modes which renewed my interest in it. It's great to see this develop here. I have some versions of the programs we created in my disks in storage which I've been planning forever to image I'm definately going to dig through them soon and check out the stuff we were working on back then.

[atariksi]

You should not use wsync if you are doing a kernel, maybe just for the starting synchronization.. if you know the number of cycles that you have per line you can pad with "nop's" in the worst case (or an instruction with an odd number of cycles)

 

in this test (from another post) the color lines are made without using wsync:

 

 

NRV

 

That would be the optimal approach since you save time on the PHA/PLA/RTI/WSYNC. Just do as many register changes as possible and pad with NOPs or idle task instructions that have fixed cycle count. Perhaps, in Graphics 10 you can pick the most common colors in the picture assigned to some indices and keep re-using the other indices even mid-screen (not HBI).

[emkay]

What to say.... all that was necessary was to use the Atari emulation and to put a front end to it, for making graphics.

Pictures like this "Gr.10" one... simply was possibe then... plus all possible enhancements

But the best available tool "Graph2font" doesn't support it... it doesn't even support PM over gr.9 screens. And I don't have any idea for changing the situation to have tools that simply apply to the given hardware restrictions.

Edited May 13, 2008 by emkay

[emkay]

Well... ofcourse a program simply could import PC graphics to gr. 10 ...

 

But, remebering that the screen isn't limited to a fixed mode.

Standard programming gives different modes every scanline. With changes midline , you can do much more.

 

 

The appended picture seems to be done rather easy... but to create it, it took a gazillion times of saving and loading it into the emulator, for having the result shown correctly.

 

To explain it directly: A proper working tool doesn't make an Artist feeleing depressed by all the missing features and he can do MUCH more... with much better results.

[rje]

I've been thinking about the changing 9 registers in one line thing as it relates to CpegView for a while now (as in on and off for the last couple of years), and while 9 truly independent colours per line would be nice I think it's not an absolute necesity *BUT* having said that, I've only been looking at it from the point of view of improving displayed JPEGs (i.e. photographs) rather than computer generated line drawings which may suffer a bit more.

 

A few thoughts on this:

 

If your resolution is high enough (or you stand far enough away from the screen ) you can approximate colours by dithering, basically draw the current pixel in the closest colour currently available and then adjust the colours of the pixels around it to compensate, e.g. if you haven't got the exact shade of blue you want, then the current pixel may end up being a darker shade of blue than it should be, but the surrounding pixels will be a lighter shade of blue to compensate.

 

My guess is that you could get some worthwhile improvements just by changing 4 colour registers during the HBlank, that would give 8 (maybe even 9 if you really wanted to) colour changes over two lines. There will be some "bleeding" of colour across the boundaries, pixels that should have been changed one line earlier but weren't. That would be more of a problem for line drawings than photographs, but it may not be so bad if you're a bit clever in chosing which registers to change, maybe changing the 4 least frequently used colours on a the previous line into the 4 most frequently used colours on the next line that aren't already loaded into a register, then repeat.

 

It's also unlikely that you'll need all 9 colours on both the right hand side of the previous line and the left hand side of the next line. So you can start changing registers before the HBlank and continue changing them after the scan line has started drawing. For any given line, figure out the first and last places each register is used and then prioritise the register changes to get as many changes in as possible. If you do happen to need a colour that's not available yet then either skip it and wait for it to (hopefully) appear on the next scan line, or apply some dithering.

 

CpegView already does dithering to a set of precalculated colours, it doesn't change colour registers but I think it can do that using one or more of those approaches without taking too much of a preformance hit, the biggest problem there is deciding what colours to use.

 

Another approach may be to look for ways of reducing the amount of flickering in interlaced modes, the biggest problem with interlacing is that large areas of a single colour, especially a bright colour, flicker more noticeably than smaller areas of dark colours. There may be a compromise to be had there, where some of the colours that are possible are sacrificed by using the same colour for both screens in exchange for less flickering. Maybe even using PMGs to fill in some of the gaps, and/or help cover any boundaries where there's a sharp change in colour. (JpegView/CpegView use PMGs to hide the jagged left and right edges in HIP/RIP/TIP mode)

 

None of these approaches are perfect, but they may be good enough to get some improvements.

[peteym5]

I look beyond doing still pictures on the Atari 8-bit system, look more into using these techniques with animation and games. I have got 2 fonts with alternating graphics 9 and 11 every pixel line. That is using Antic mode 2 with the GTIA mode controlled by a DLI. I have to work out how to do it without eating up a bunch of CPU time. Most of the time for a game you only need to do it on part of the screen and leave something to display the score. Like I said, it will work for something like those shifting puzzle games, turn based strategy, or a blocky games like Tetris, Columns, or 2600 Surround (Tron) like game.

[DamageX]

a PC program able to do the conversions automatically.

Yes, that is how I generated the pic that I posted. It was originally a 24-bit BMP, then converted to Atari's 128 colors and modified to fit the limitations of 9 colors/line and 2 color changes per Hblank. These are tunable parameters of the program... so more than 2 color changes per line could be allowed, or the limit could be set to 4 colors for ANTIC mode 14. I can upload the program later, but I haven't written the A8 routine to display the output yet.

No known method exists to shift Gr. 10 pixels to a "normal" position.

So Gr. 10 is always offset compared to the other GTIA modes then? I was misunderstanding the nature of the bug in that case.

[emkay]

a PC program able to do the conversions automatically.

Yes, that is how I generated the pic that I posted. It was originally a 24-bit BMP, then converted to Atari's 128 colors and modified to fit the limitations of 9 colors/line and 2 color changes per Hblank. These are tunable parameters of the program... so more than 2 color changes per line could be allowed, or the limit could be set to 4 colors for ANTIC mode 14. I can upload the program later, but I haven't written the A8 routine to display the output yet.

 

The easiest way of having a PC Gr. 10 tool was to implement it to G2F.... Someone has to pursuade Tebe to make the GTIA Modes fully available ....

 

No known method exists to shift Gr. 10 pixels to a "normal" position.

So Gr. 10 is always offset compared to the other GTIA modes then? I was misunderstanding the nature of the bug in that case.

 

In Gr. 9 and 11 the colours are straight results of the bit combination given by ANTIC.

Probably both are built the same, just inside the GTIA there seems to be a switch, acting on croma or luma.

 

In Gr. 10 GTIA has to add the colours out of the palette. This may cause this "one colour clock" offset, because of an extra needed "active cycle step".

Edited May 14, 2008 by emkay

[Rybags]

That's also my theory - delay due to palette-lookup vs just directly processing the pixel info.

 

You can see the same effect if you do a mid-scanline colour change - it always has that slight delay between the colour store and when it comes into effect.

[DamageX]

OK here it is (DOS/win executables, QBASIC source, BMP and XEX)

 

http://www.hyakushiki.net/cslice.zip

[atariksi]

I've been thinking about the changing 9 registers in one line thing as it relates to CpegView for a while now...

...

Another approach may be to look for ways of reducing the amount of flickering in interlaced modes, the biggest problem with interlacing is that large areas of a single colour, especially a bright colour, flicker more noticeably than smaller areas of dark colours....

 

None of these approaches are perfect, but they may be good enough to get some improvements.

 

I was thinking of just partitioning the 9 registers into 3 parts like 4:4:1 so for every scanline i, 4 registers stay the same for scanline i+1, 4 registers are modifed in HBLANK interval, and one register is repeatedly re-used during mid-screen. I have tried this and you can modify the same color register like 53274 SEVEN times during the scan-line after some phase shift(standard display poking $22->559). So you get 7 colors from that one index, 4 new colors for 4 other indices, and 4 colors from previous scan-line based on calculations of delta-modulation where colors that are more common don't need to be changed. That gives 15 indexed colors/scan line. I am sure you can also do the same for sprites and re-use a sprite 7 times and get up to 11 sprites/scan line.

 

Averaging at least the four pixels involved when every pixel is plotted in interlace is the best option since resampling data (without averaging) does not do that good of a job.

[atariksi]

That's also my theory - delay due to palette-lookup vs just directly processing the pixel info.

 

You can see the same effect if you do a mid-scanline colour change - it always has that slight delay between the colour store and when it comes into effect.

 

I guess the whole circuit of implementing Gr. 10 is more complex so the propagation delay can be expected to be more, but if you change the Graphics 9 -> Graphics 10 in mid-scanline you get only the one color clock cycle delay... it seems fast given an LMS eats up four color clock cycles.

[Heaven/TQA]

oh...interesting... just searched for qbasic stuff and then i discovered that my loved turbo basic/gfa basic does exist as windows port? cool... have to check that out tomorrow...

 

who needs c++

[+Philsan]

oh...interesting... just searched for qbasic stuff and then i discovered that my loved turbo basic/gfa basic does exist as windows port? cool... have to check that out tomorrow...

 

who needs c++

 

Where?

[Heaven/TQA]

http://gfabasic32.googlepages.com/

[analmux]

I am sure you can also do the same for sprites and re-use a sprite 7 times and get up to 11 sprites/scan line.

 

Depends on if you want to use other shapes as well. When not, it could be possible. But remember that for new sprites also a new shape and sometimes even a new colour could be wanted: this is already 3 regs. When PM DMA is activated, the PM data is only read once a scanline.

[Heaven/TQA]

just checked out the gfa32 basic...that looks like exactly what i was searching for years... I tried visual studio c(++,#), java, visual basic etc but only to write some small tools to generate lookuptables etc... and gfxbasic 32 seems to do the job... not my dark basic, not my purebasic etc... even no big junk to learn for Windows API stuff...

 

cool. Now I am back "home"... me as "procedual programmer"...

Edited May 17, 2008 by Heaven/TQA

[Rybags]

 

WIP screenshot of CIN++ mode (160x96 with 96 colours available)

 

Only 5 luma values per scanline here ATM - just have to put in the PMG underlays to give the extra one. Then, that will allow full 96 colour displays (with some restrictions).

 

Kinda crappy pic to demo it - hoping to have some much better stuff tomorrow sometime.

Edited May 19, 2008 by Rybags