Video signal programmability

[EmilAmiga90]

I know that this will probably give rashes to almost everybody but i really would like to make a demo/game that uses 640x480 50Hz.

In other words I would like to use AGA to have high resolution WITHOUT the annoying flicker.

I am using AmiBlitz in BLITZ MODE as framework for ASM programming (I "almost" love ASM)

It seems really difficult to find information about the AGA video signal registers usage. I found one or two examples on Internet but it seems there is very few explanations about how those registers really work.

Does someone have some experience with AGA video signal programming? Or pheraps does someone know where to find some details?

(I bet I was not able to find it )

[Thomas Richter]

Originally Posted by EmilAmiga90

In other words I would like to use AGA to have high resolution WITHOUT the annoying flicker.

Use OpenScreenTagList() in the video mode you want to use.

Originally Posted by EmilAmiga90

It seems really difficult to find information about the AGA video signal registers usage.

Correct, because they're not supposed to be used. That's the domain of the Os.

[EmilAmiga90]

It seems that searching better I was able to find usefult hints

https://github.com/rkrajnc/minimig-m.../doc/amiga/aga

[paraj]

Preface: You probably don't want to use programmed modes. They only work in emulation or if the user has a multisync monitor. You'll be severely limiting your outreach this way.

But, yeah, best to go through the OS for this one. You can (apparently) damage the monitor if you do this wrong (I've luckily only seen really bad distortion on my multisync one).

If you need it to work w/o the OS for some reason, start a program that sets the correct mode and read out the values from e.g. WinUAE.

Designing your own mode from scratch? Hard to impossible. I've tried with elaborate spreadsheet calculations, but didn't work. You need to combine multiple sources to get the timing right. (Ross - the resident programmed mode wizard - helped me out, but this approach doesn't scale).

[meynaf]

Removing the flickering requires 31khz mode, i.e. VGA / Productivity.
So it should be easy enough to mount such a monitor, setup the workbench screen to use it, and then replicate the copperlist.
However this mode is gonna eat all available bandwidth if max colors is used.
Besides, not all monitors can support this ; typical 1084 f.e. does not. That would seriously limit the users of the program.

[ross]

Originally Posted by paraj

...(Ross - the resident programmed mode wizard ..

Yeah, truly a wizard who with just the setting of a few handful of registers managed to fry a (cheap) multisync in the 90s..
(but it must be said that I abused it like never before, so sooner or later I had to expect it to give in )

However, back to the OP's request, nothing to add to what was rightly said by everyone.
The difficulty lies not in setting the mode (or any other, some really weird ones..), but in ensuring that it is supported by as many devices as possible.
And which in fact allows usable performance from the Amiga.

[Photon]

Interlaced=15kHz, non-interlaced (progressive) is 31kHz. Progressive modes like 640x480 are available on RTG cards. On them, there's no need to limit Hz to 50 - higher is better.

So if Blitz Basic can open a screen on an RTG card, you're home. Whether you can make a fast/impressive game or demo on RTG is up to CPU horsepower - if the mode is a chunky mode.

IDK if there are progressive modes that use bitplanes on RTG, but if there is, this is one way to leverage the load that a higher resolution puts on the CPU. It will make the demo or game potentially less graphically impressive ofc, but less screen data will need to be updated. The other way is the familiar shrinking of the screen of e.g. Doom and Quake, which obviously reduces the resolution while still putting the burden of the full resolution on memory accesses.

The other way to get rid of the flicker is to just use hires, not interlace or progressive. It will take some doing to make the graphics look good in this mode where the pixels are skinny and tall. But you would get the other benefits, like smoother scrolling etc, without reduction of color or interlacing artifacts. E.g. Kang-Fu but better gfx.

[ Show youtube player ]