27 December 2012, 19:54 | #1 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,351
|
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. |
27 December 2012, 20:47 | #2 | |||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,603
|
Quote:
Quote:
Quote:
|
|||
28 December 2012, 12:56 | #3 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,603
|
Quote:
Horizontal end of display position is too large which makes it unreacahable = max non-blankable border region is fully visible on both sides. |
|
28 December 2012, 16:56 | #4 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,351
|
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.
|
28 December 2012, 17:10 | #5 | |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,351
|
Quote:
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.] Last edited by mark_k; 28 December 2012 at 17:17. |
|
27 February 2014, 18:32 | #6 | |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,351
|
Quote:
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. |
|
27 February 2014, 18:42 | #7 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,603
|
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.. Last edited by Toni Wilen; 27 February 2014 at 18:55. |
14 March 2014, 16:40 | #8 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,351
|
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? |
16 March 2014, 11:16 | #9 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,603
|
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. Last edited by Toni Wilen; 16 March 2014 at 11:26. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Mani Pulite sprite problems (A500 mode) | andreas | support.WinUAE | 17 | 22 January 2015 14:41 |
Personal project: EEEPC, Gamebase and WINAUE: problems problems | butter100fly | project.GameBase Amiga | 15 | 09 August 2009 10:51 |
'Warp Mode' broken in 'windowed mode' | NoX1911 | support.WinUAE | 3 | 26 May 2007 01:05 |
Problems with Detect Idle CPU mode | bdoe | support.WinUAE | 6 | 27 September 2002 13:44 |
GUI refresh problems + OpenGL Speed Problems in 0.821r4 | Danny Bacon | support.WinUAE | 1 | 07 June 2002 18:57 |
|
|