Super72 mode problems
 

I noticed a couple of problems with Super72 modes. I'm testing with Kickstart 40.70, Workbench 40.42 (3.1), full ECS and using a border-blanking utility.

Set Workbench to Super72 super-high res laced (800x600). Run a program which opens a Super72 super-high res non-laced custom screen (800x300). The non-laced screen appears half-height. If you drag it down so the Workbench is exposed slightly (and therefore the Amiga output becomes interlaced) it changes to full-height. Drag the screen back up and it reverts to half height.

The next issue shows up with AGA chipset emulation. The Super72 display is offset to the right.

The next issue shows up with AGA chipset emulation and a couple of tooltypes set in the Super72 monitor driver:
TOTROWS=0x148
TOTCLKS=0x89
With those, the Amiga display (at 800x600) is offset to the right, so the rightmost part of Workbench is not visible. The part of the left border to the left of the mouse pointer appears non-blank (colour 0). But if I move the mouse right until the pointer is in the not-visible part, the extra colour 0 strip disappears.

Not a bug. Doublescanned modes disable line doubling because all other doublescan modes would be too high with line doubling. (Don't say just enable if it is "small enough". It isn't that simple)

Not a bug either. Mode has larger empty space in left side. I guess it is needed to allow AGA 64-bit fetch mode screen without losing overscan or something like that. (You can see it easily by making window very wide and disabling border blanking)

Later..

Left border mouse issue is of course a bug but I don't think this mode works properly on real Amigas either, it also should show big left side non-blanked area.

Horizontal end of display position is too large which makes it unreacahable = max non-blankable border region is fully visible on both sides.

Using those tooltypes with my ECS Amiga did work (and it works in WinUAE). I was probably trying to achieve less interlace flicker with those tooltypes; screenmode preferences says it's 79Hz. I don't have an AGA Amiga or compatible monitor to check what would happen there.

I figured out a workaround for that problem. You need to force the Amiga to always output an interlaced signal. Do that with the Lacer command like this: Lacer 1

With that Super72 800x300 screens appears as they should, albeit interlaced. But with WinUAE as opposed to a real Amiga that's generally not much of a problem. :)

The workaround isn't perfect; modes like Productivity 640x480 then appear as double-height, occupying 640x960 pixels in the emulation Window. On the other hand, that height-doubling could be useful if the user wants their Workbench to have a similar pixel aspect ratio to a 640x256 PAL high-res screen.

For years I thought Lacer did nothing. Until I disassembled it today and found out that when you run it without arguments, it only toggles the LACE bit in BPLCON0 if a genlock is connected. You have to specify 0 or 1 to disable/enable if you don't have a genlock. [Apparently Commodore included Lacer with the OS because A500s and (B)2000s don't always output interlaced video when a genlock is connected. That's probably a bug in Fat Agnus which was most likely fixed with ECS Agnus.]

[Did you mean programmed scanrate modes? Because Super72 800×300 isn't double-scanned.]

Resurrecting this old thread because I was curious... what's the reason for not being able to double all non-interlaced modes which have VTOTAL less than, say, $1B0 lines? (When line mode = Doubled of course.)

VTOTAL values for different modes:

SUPER72 VTOTAL $0156 = 342. WinUAE doesn't double.
HD720 VTOTAL $017C = 380. WinUAE does double HD720.
HighGfx 1024x384 VTOTAL $0194 = 404. WinUAE doesn't double this.
EURO72 640x400 VTOTAL = $01C1 = 449. WinUAE doesn't double this (which is correct).

So the threshold value to decide whether or not to double would be somewhere between 404 and 449.

Doublescan decision depends on length of scanline, it does not care about number of lines (and it shouldn't). Scandoubling technically means fitting two scanlines in period of single "normal" scanline length.

Current test is: it is scandoubled if HTOTAL is less than 165.

EDIT: I guess there could be separate test if HTOTAL is larger but ratio of V vs H is bad enough..

That would definitely help I think. Apart from making non-interlaced Super72/HighGfx screens look better, it would avoid the "screen bounce" which happens with interlaced Super72 modes. (On a screen mode change WinUAE doesn't know whether the new mode is interlaced or not, so for a moment the new mode appears half-height before expanding to fulll height.)

But the number of lines is related to the line length and frame rate. And frame rate is usually somewhere around 48-75 Hz (say). Which modes would a simple VTOTAL check fail on?

Actually 800x300 Super72 is not scandoubled. It really has only 300 lines. It is the monitor that adjusts to this mode and "scales" it to fill whole screen (using vsync and hsync lengths as usual)

Real scandoubled modes draw same scanline twice. (for example DBLPAL and DBLNTSC)

Problem is that emulation detects this mode as scandoubled = emulation doubling is disabled because doublescanning doubles it back to original size. (or real doublescanned modes would get doubled twice)

Detecting scandoubling using hardware parameters only is impossible for all conditions, unless there are some hardwired parameters for known common modes.

VTOTAL alone can't be used for detecting anything. (How are you going to know if for example vtotal=600 is 300 doublescanned lines or 600 "real" lines?).

EDIT: but I guess if mode is detected as doublescanned and VTOTAL is "too small", it probably isn't doublescanned after all.