4 replies to this topic

[Synthpopalooza]

I have been brainstorming, and something occured to me, after looking at the APAC article from the 1989 Analog issue ...

Is it possible to switch between 2 APAC mode screens every VBLANK? I think this could be achieved by reserving memory for 2 graphics 8 screens, setting up 2 display lists in memory which point to these 2 screens and have them call each other, then activating APAC mode.

Because the Gr. 11 and Gr. 9 lines overlap each other, you get 256 colors without flicker ... then by flipping the screens 60 times a second, the color resolution increases to about 32,767 colors or thereabouts, in theory. You'd still get the blank scan lines in the picture and the resolution would be 80x96. Of course this could also be done with Graphics 15 to increase resolution, with the color resolution decreased to something like 4.096 , with 4-level shading. You could have nice photo quality color resolution with this, almost into Amiga territory when it comes to color palette resolution.

I am going to attempt a test to see if this can be done, but I am wondering: What is the best way to set up screen flipping in Gr. 8? Reserve memory below ramtop for 2 Gr. 8 screens, and then 2 display lists which call each other?

[Rybags]

Done it before, as a way of increasing the pereived resolution by alternating the starting scanline of a picture.

I don't see how you think there can be 32,768 perceived colours. The best to hope for in reality is to give "0.5" luma steps which would give 31 perceived lumas instead of 16, which would = 480 colours.

The best way to swap betwen 2 screens is use an Immediate VBlank, it's then guaranteed to always be called. Just use low bit of low byte of RTCLOCK to choose which DList is in effect.

[simonl]

Rybags, on Thu Sep 8, 2011 8:16 PM, said:

Done it before, as a way of increasing the pereived resolution by alternating the starting scanline of a picture.

I don't see how you think there can be 32,768 perceived colours. The best to hope for in reality is to give "0.5" luma steps which would give 31 perceived lumas instead of 16, which would = 480 colours.

The best way to swap betwen 2 screens is use an Immediate VBlank, it's then guaranteed to always be called. Just use low bit of low byte of RTCLOCK to choose which DList is in effect.

The other thing is to try changing the chroma in each frame which allows you to do more washed out colors so you have to do less error correction, I did some examples with this but they didn't look that great on a CRT monitor. Looked excellent on an emulator or TFT but I suppose that's not really the point.

Cheers,

Simon

[JAC!]

Basically it's correct why Rybags says, but of course you can increase not only the number of luminances but also the number of chomas. But you have to be very careful when choosing the color cobination values, because 90% of them will flicker like hell. But mixing consequtive colors works very well.

I tested this last week on the real machine. Unfortuntely luma flickering is visible in PAL due to the low refresh rate even when using GTIA 9 (16 => 31 shades). In NTSC it's hard perceivable. Color flickering works fine for consequtive values. So combining both with give about (15+14)*(16+15)=29*31=651 colors.


Sources and executable are attached for playing around.

Attached Files

•  Flicker.zip   5.86K   41 downloads

Edited by JAC!, Fri Sep 9, 2011 4:28 AM.

[Rybags]

Yes, alternating certain chromas is entirely valid, but lack of chroma isn't really a big problem (other than the sad lack of reds esp in PAL).

The biggest problem with APAC and like modes is that the colours are washed out to begin with since you're losing 50% of the saturation due to PAL mixing an already not so saturated colour with a null colour (shade of white).

Additional to that is that PAL will flicker worse than NTSC, not that it matters because APAC and similar modes don't work in NTSC anyway.