APAC/Trucolour - a whole new approach

[analmux]

When you have a kernel of, say, 160 lines, then you need to do 160 times the gprior change. That is 1600 cycles. This eats 1600 of 35568 PAL cycles in a frame. (DMA stealing etc. not included). So, when the time inbetween the changes is used optimally, then there should be some possibilities. ...or what about a digi-sound?

[Rybags]

Agreed.

With unrolled code, and splitting loops into smaller sections, you could do "normal" processing as well as have a kernal.

 

114 cycles per line - 1 DList - 9 Refresh - 40 screen DMA - 10 for WSYNC/PRIOR change

leaves 54 cycles per scanline. Of course, you need to do WSYNC in time, else it'll skip ahead an extra line. So, maybe figure 48-50 or so cycles to be safe.

 

All it means is you have to change your program structure somewhat.

[Rybags]

Digi sound would be feasible too.

 

Thinking about it the other day (in the sense of what we've been talking about in other threads)...

 

To cut down the inline processing needed, possibly the easy way would be to just have the main loop do:

 

LDY DIGI_INDEX

... kernal stuff here

LDA (DIGI_POINTER),Y

ORA #$10

STA $D201 ; do sound

INY

... rest of kernal stuff

 

Since the playback rate might only be 8KHz or 4 KHz, that means that an 8-bit pointer will never overflow within one frame.

So, then, we can have the VBlank update the DIGI_POINTER in zero-page, then the main part of the program, and the DLI only need start with the initial Index value 0, and increment every 2, 4, however many scanlines.

 

In the case that 16 KHz playback is used, then we have an overflow condition. Of course, that happens right near the end of the display area, so in that case there would be sufficient time to do the extra processing needed.

[eru]

Hue (Gr. 11)

Luma (Gr.10 describing luma as done ad infinitum before)

... repeat for 192 lines ...

 

Hue (Gr. 10 describing colour, with re-assignments as below)

Luma (Gr.9)

... repeat for 192 lines ...

 

This is VERY close to TIP, which is:

Frame 1: Gr11, Gr10, Gr11, Gr9

Frame 2: Gr11, Gr9, Gr11, Gr10

 

The difference is you get effective 160 pixels in the hue part, while TIP had 80 pixels there only. I thought about doing that couple of years ago, but there is a drawback that makes it look significantly worse. In TIP, the luma lines alternate in a 'checkers' pattern, looking like it flickers less, and for you all the luma lines are either gr10 or gr9 in the entire frame.

 

In the end, it's a very valid approach, but it's a matter of taste if it looks better than TIP.

[Rybags]

It's a necessary tradeoff, I guess. You just can't reload 9 colour registers on 2 adjacent Gr. 10 lines, although you probably could if you sacrificed screen width, ie left some of the left hand side blank.

 

This method is possibly more effective if you want the extra colour definition, but at the expense of that flickering appearance.

[eru]

Yes, 1 scanline is not enough to change 8 registers... Unfortunately

 

In TIP, I thought about experimenting with a mode in which the hue pixels in gr11 are interlacing between the matching hue of the respective left/right pixels in gr15... That could reduce the contrast you sometimes observe in the hue map, and the flickering should be invisible or minimal. I was always too lazy to try - anyone willing to give it a shot?

[carmel_andrews]

Does, using a 'kernal' do away with using Antic...I thought that was Antic's job, to replace the need for doing 'Kernals' in software...excuse my ignorance as I haven't been swallowing biggo techie text books recently

[Rybags]

Not really.

 

"Graphics Kernal" is just a generic saying for something that does screen control work for a significant part of the display.

I think the expression was probably first used to desribe Basketball, as it plugged colour values into the PMs to give multicolour players.

 

You can't really "do away with Antic" ... unless all you want to display is PMGs or variations of the one background colour.

 

 

TIP horizontal interlace... interesting.

 

But the advantage of my way is that you only get a colour change half GR. 11 pixel boundaries, instead of a full boundary.

 

Another thing to try is having luma value 2 instead of 0 on the colour-only lines - sometimes it makes a picture look a little better.

 

 

Back to the cycle counting thing... you can save some cycles by disabling DList instruction fetch on Antic - it then just continues displaying the same graphics mode.

Problem is, of course, that you need to keep track, as you have to re-enable it for the instruction to LMS to get over the 4K boundary, and for the Jump-wait for VBlank.

Edited May 4, 2008 by Rybags

[peteym5]

I think APAC mode is still a better trade off comparing to some other modes. I have experimented with character mapped screens, mode 2 with switching the prior register every line, and using 2 fonts. Takes up far less ram. I thought about using it for simple puzzle games that are like blocky, like a Tetris, A Tron like game (2600 Surround), or a shifting puzzle type game. A turned based strategy game is possible also. Anywhere where a lot off speed is not critical. One issue is that you have to do all WSYNCs for every character line, which means your processing is frozen for almost 50% of the cpu. Been looking at ideals of making use of the unused cpu cycles.

[ZylonBane]

Apparently every new generation of Atari programmers is destined to rediscover ColorView mode.

[Allas]

Apparently every new generation of Atari programmers is destined to rediscover ColorView mode.

 

how many generations of Atari programmers exist?

[dwhyte]

Apparently every new generation of Atari programmers is destined to rediscover ColorView mode.

 

how many generations of Atari programmers exist?

 

Aren't we on the 2nd, if not 3rd in some cases, generation of A8 enthusiasts? I know I'm a 1st gen...

[Rybags]

Probably a mix of 1st and 3rd here.

 

Dropped interest from the early 90s, then picked it up again around 2001.

 

As for the "usefullness" of this method - I guess the best way to judge would be for me to generate each variety (APAC/TIP etc) from the same source material, then have them in the one file so they could be compared head to head.

[analmux]

I think APAC mode is still a better trade off comparing to some other modes. I have experimented with character mapped screens, mode 2 with switching the prior register every line, and using 2 fonts. Takes up far less ram. I thought about using it for simple puzzle games that are like blocky, like a Tetris, A Tron like game (2600 Surround), or a shifting puzzle type game. A turned based strategy game is possible also. Anywhere where a lot off speed is not critical. One issue is that you have to do all WSYNCs for every character line, which means your processing is frozen for almost 50% of the cpu. Been looking at ideals of making use of the unused cpu cycles.

 

Well, in a bitmap mode I would do the same. You need processing on every scanline anyway, and triggering the process everytime by a DLI eats away far more cycles than just doing a kernel routine like I described in post 25. So, the minimum in wasted CPU-time is with doing wsync anyway, I think.

[NRV]

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

[analmux]

If you know on a cycle-exact basis what you want to do then that may be the best solution.

 

But, if I'm correct there are instructions (indexed & indirect) that sometimes need 1 extra cycle. Then you have uncertainties.

 

So, the best use might be some unrolled code with simple LDA,STA absolute commands.

[Oswald]

If you know on a cycle-exact basis what you want to do then that may be the best solution.

 

But, if I'm correct there are instructions (indexed & indirect) that sometimes need 1 extra cycle. Then you have uncertainties.

 

So, the best use might be some unrolled code with simple LDA,STA absolute commands.

 

in such scenarios the best solution is always RTI. in most cases you never know on a cycle exact basis what you want to do.

[eru]

But, if I'm correct there are instructions (indexed & indirect) that sometimes need 1 extra cycle. Then you have uncertainties.

So, the best use might be some unrolled code with simple LDA,STA absolute commands.

You can remove the uncertainty if you make sure your memory accesses do not cross the page boundaries, and that's typically easy. Such unrolled code mixed with the code that changes the GFX mode is present in a lot of effects in Numen. But it's tricky to arrange, most people do not care that much about the speed

[eru]

in such scenarios the best solution is always RTI. in most cases you never know on a cycle exact basis what you want to do.

Interrupts kill the performance. Of course, for many types of routines it's impossible to have a predictable unrolled code. But for blitter-like routines (plasmas, bumps, tunnels etc) you can.

[Rybags]

In the context of displaying static pictures without any fancy extras like repositioning PMs or midline colour changes, WSYNC is fine.

Cycle counting and padding with NOPs and 3 cycle instructions when there's nothing to do anyway is kinda pointless.

 

Regarding "new" modes, I had another possible idea:

 

Mix GR. 11 (supplying the colour as usual) with Mode 4 lines. Use VSCROL tweaks to force all lines to 1 scanline high.

Intermixed with PMGs underlayed on the mode 4 lines, that would give a CIN type mode with 6 available luminences. Although of course, the PMG pixels would be "chunky" and need to be overlayed with foreground graphics. Probably best to use them for the lowest luma value where they'd be much less noticable.

[Rybags]

New mode "CIN+". OK, probably not new as I'm sure someone's tried this before.

 

 

Early proto stage here. But this is how it works: 16 colours at 6 luminences (with some restrictions) = 96 colours. Note: normal CIN allows 64 colours.

 

Gr. 11 supplying Hue info on even lines.

Single line of Gr. 12 (Antic 4, multicolour text) supplying luma.

 

It is possible to get this mix using VScroll tricks alone. Set VSCROL register to 0, then have Mode F VSCROL on, Mode 4 normal (and repeat).

The Mode 4 lines then become the last line of a scrolling region - as such, Antic displays from line 0, through to the VSCROL value (also 0 ).

Of course, we still need the DLI to change to GTIA hue mode ($C0) every second line.

 

Since Antic 4 allows us to select alternate colour by setting the high-bit of the character code, that gives us one extra luma to play with.

The second extra luma value will be supplied via PMG underlays.

 

To save RAM, PMGs are used in double-line resolution. The DLI stores zeros to their graphics registers directly before the Hue lines so they don't interfere there.

For the pixels in the luma lines, multiple charsets much like G2F will be used. To save more memory, character flipping (CHACT register) will be used, therefore giving 6 lines per character set.

 

Despite these optimisations, it will still be a somewhat memory-hungry way to do pictures. For a standard-sized display, about 25K although uncompressed on disk should still only be about 14K.

[ZylonBane]

Despite these optimisations, it will still be a somewhat memory-hungry way to do pictures. For a standard-sized display, about 25K although uncompressed on disk should still only be about 14K.

So it uses more RAM than ColorView mode, but provides fewer colors?

[Rybags]

There's true 160 horizontal resolution. The tradeoffs of course are blank scanlines like APAC, or flicker if it is done in an interlaced fashion.

 

But, there's tradeoffs with all these software driven modes.

[DamageX]

For static images or slideshow/video we can use a standard graphics 10 mode and change colors as necessary during the display (like Palette-CHanGe or Sliced modes on the Amiga, or like this thing for the MSX: http://www.msx.org/forumtopic7311p60.html ) pretending that we have 80x200 with 128 colors

 

Images can be processed beforehand to ensure that there are only 9 colors per line, and a list of color changes to apply will be built.

 

Additionally, maybe two gr. 10 screens can be interlaced with the half-pixel bug to show 160x200 with 128 colors?

[emkay]

For static images or slideshow/video we can use a standard graphics 10 mode and change colors as necessary during the display (like Palette-CHanGe or Sliced modes on the Amiga, or like this thing for the MSX: http://www.msx.org/forumtopic7311p60.html ) pretending that we have 80x200 with 128 colors

 

Images can be processed beforehand to ensure that there are only 9 colors per line, and a list of color changes to apply will be built.

 

Additionally, maybe two gr. 10 screens can be interlaced with the half-pixel bug to show 160x200 with 128 colors?

 

Impressive approach. Now someone could enhance the details by using some PM overlay.

Or changing the resolution at the "forest", continuing the picture with G2F techniques.

On the top of the picture one could put flying birds at 160 res.

So the landscape could be very colourfull and it could have all necessary details.

 

Btw: Nice colour usage.

 

...

 

Another approach was to use simple gr. 9 mode and using midline changes for the base colour and doing also colour and/or detail enhancements with the PM graphics.

Edited May 13, 2008 by emkay