WinUAE display bugs

[mr_a500]

I tried WinUAE again for the first time in years and saw that some old display bugs are still there. I was sure I reported them back in 2002, but maybe nobody got it so here they are again. Some of these are minor and have workarounds, but prevent me from properly emulating my real Amiga setups as they should be.
(testing done here with WinUAE 1.4.6)

1. Workbench border blanking does not work with Full ECS or ECS denise. It works with AGA, but it should also work with Full ECS and ECS denise too. (I bought the ECS denise for my A500 specifically for this purpose so that's how I know. The screenshots below are with AGA in config so that's why you can see the black border.)

2. NTSC Hires Interlace overscan screen height is being cut off at 468 (or 234 non-interlace). It should be 482 (241 non-interlace). My NTSC A500 setup is 692x482 and my A3000 is 720x480. (You can see that screenshots below have their top cut off.)

3. With scanlines enabled, a non-interlaced screen brought to the front then closed will cause scanlines to be drawn on an interlaced screen. Moving the cursor will then remove these scanlines one by one! Notice screenshot 1.png and 2.png (before and after). Also see it on Workbench - 3.png (the same problems occurs when no copper rainbows are used, so that's not it). Sometimes there are whole blocks of black as seen in 4.png - where I am just starting up WinUAE - and 5.png where I just opened a non-interlaced picture. It can also happen when opening scrolling screens.

4. So, to avoid the scanline problem, I started WinUAE without scanlines and you can see what happened in 6.png. I have no idea why this is happening because I'm sure I ran WinUAE without scanlines before.

Here's some of my WinUAE config

kickstart_rom_file=C:\WinUAE\ROM\kick310.rom
gfx_width_fullscreen=800
gfx_height_fullscreen=600
gfx_vsync=true
gfx_lores=false
gfx_linemode=scanlines
gfx_correct_aspect=false
gfx_fullscreen_amiga=true
gfx_center_horizontal=smart
gfx_center_vertical=smart
ntsc=true
cpu_speed=max
cpu_type=68020/68881
cpu_model=68020
fpu_model=68882



(I've also had lots of annoying problems with paths but I think I'll just stick to display problems here.)

[Toni Wilen]

Try latest beta first, it should fix everything except ntsc (but I checked number of lines using PAL A500 in NTSC mode, hmm..)

EDIT NTSC:

My tests show first visible line on PAL is 27 and first NTSC line is 28 which can't be right, perhaps it is the monitor, not the Amiga that causes this (only saw vblank area black before line 28). NTSC start line will be changed to 21.

[laser]

btw, which is the name of the program...I think it's a filemanager...is in screenshot 1.png?

[StrategyGamer]

If NTSC starts on line 21 then shouldn't PAL also start on 21 or before? Since PAL has more lines to display.

[Toni Wilen]

Originally Posted by StrategyGamer

If NTSC starts on line 21 then shouldn't PAL also start on 21 or before? Since PAL has more lines to display.

PAL is 28 to 312/313 (depending on long frame bit) and that has been confirmed 100%. (even tested with max overscan)

NTSC is not perfect because I don't have real NTSC hardware. (and I don't really care about NTSC either but I'll improve it if someone tests and confirms things using real NTSC hardware)

[mr_a500]

Thanks Toni for your fast response and for checking the NTSC problem so quickly. (...especially considering the fact that you seem to be personally offended by NTSC )

I downloaded the latest beta and tried to test it, but got an error saying Windows can't find d3d9.dll. I discovered that this is from Direct3D 9. The old crap computer I was testing on only has DirectX 8. I was going to install DirectX 9, but the download is 75Mb. I'm still on dialup (and the PC isn't mine anyway) so I wont be downloading that anytime soon. (...maybe in a few weeks when I get highspeed internet for my new SGI Indy.)

You should specify DirectX 9 as a new WinUAE requirement in your changelog.

[Toni Wilen]

Originally Posted by mr_a500

Thanks Toni for your fast response and for checking the NTSC problem so quickly. (...especially considering the fact that you seem to be personally offended by NTSC )

Because most "pal" games only use ntsc display area (lazy coders?) in pal machines and also work too fast in ntsc-mode. That was annoying.

I downloaded the latest beta and tried to test it, but got an error saying Windows can't find d3d9.dll.

"I don't support too old PCs or OS installations" (but it still shouldn't require d3d9.dll except if d3d filter is enabled)

[mr_a500]

Because most "pal" games only use ntsc display area (lazy coders?) in pal machines and also work too fast in ntsc-mode. That was annoying.

I can see how that can be annoying. I'm annoyed by games where I can't see the score at the top or buttons at the bottom because some lazy coder assumed Amigas are PAL-only. Still, I've got nothing against that horribly flickering PAL format.

"I don't support too old PCs or OS installations" (but it still shouldn't require d3d9.dll except if d3d filter is enabled)

I don't have the d3d filter enabled. The program fails with the error before it even opens the main window. I understand not supporting too old PCs or OSes, but this is Windows 2000 Professional SP4. Anyway, don't worry about it. I'll eventually get the newer DirectX and test it. I'll be happy if those display problems are fixed as you say.


@laser

The filemanager is ABCdir.

[ceztko]

Originally Posted by mr_a500

I can see how that can be annoying. I'm annoyed by games where I can't see the score at the top or buttons at the bottom because some lazy coder assumed Amigas are PAL-only.

You don't know how much europeans have suffered from bad games conversions (broken frame rates, enormous black borders, ...), especially in the console segment.

Originally Posted by mr_a500

Still, I've got nothing against that horribly flickering PAL format.

Flickering can't be related to PAL. Still, you (US/Jap consumers) still don't know how much S-Video sucks compared to RGB.

[rare_j]

Originally Posted by Toni Wilen

PAL is 28 to 312/313 (depending on long frame bit) and that has been confirmed 100%. (even tested with max overscan)

NTSC is not perfect because I don't have real NTSC hardware. (and I don't really care about NTSC either but I'll improve it if someone tests and confirms things using real NTSC hardware)

What NTSC hardware would you need? Do you need an NTSC TV or just an NTSC A500?

[Toni Wilen]

Originally Posted by Toni Wilen

PAL is 28 to 312/313 (depending on long frame bit))

28 may not 100% confirmed after all. Time to do some logic analyzer tests.. (instead of trusting my monitor..)

PAL minimum vblank end line is 25, max is apparently 37. Line 25 is also first line that enables sprite DMA so in theory 26 or 27 are also possible in PAL.

NTSC first sprite DMA line is 20 which matches perfectly with line 21 being first visible line. Line 21 is also first line that can show sprite image, previous line (20) is needed load sprite position registers. (in normal dma-mode without using copper to load position registers)

What NTSC hardware would you need? Do you need an NTSC TV or just an NTSC A500?

I think I can solve this problem without extra hardware (using my logic analyzer) but if not, NTSC A500 should help

[Toni Wilen]

A500 retest (8372A Agnus), using copper to change background colors, first visible line:

PAL: 26 (I think I had different monitor when I did this test last time, maybe some have some min vblank time requirement?)
NTSC: 23 (not 21.. interesting, perhaps monitor again..)

I guess 26 and 21 must be correct values because 25 and 20 are "sprite dma enable" lines.

EDIT: A1200 test: same results.

[ceztko]

Originally Posted by Toni Wilen

A500 retest (8372A Agnus), using copper to change background colors, first visible line:

PAL: 26 (I think I had different monitor when I did this test last time, maybe some have some min vblank time requirement?)
NTSC: 23 (not 21.. interesting, perhaps monitor again..)

I guess 26 and 21 must be correct values because 25 and 20 are "sprite dma enable" lines.

EDIT: A1200 test: same results.

Toni, if possibile, can you verify this for sure with your logic analyzer (or the oscilloscope, if you have one)? In fact, even if Non-Interlaced modes aren't exactly standards, I've found this documentation of a cirrus NTSC/PAL encoder that describe them very carefully:

5.2.9 PAL Progressive Scan
VSYNC will transition low at the beginning of the
odd field and will remain low for 2.5 lines or 2160
pixel cycles (864 × 2.5). PAL non-interlaced timing
is illustrated in Figure 10. In this mode, the
CS4954/5 expects digital video input on the V [7:0]
pins for 288 lines, beginning on active video line 23
and continuing through line 309.
The second field begins with VSYNC transitioning
low after 312 lines from the beginning of the first
field. VSYNC stays low for 2.5 line-times and transitions
high during the middle of line 315. Video
input on the V [7:0] pins is expected between line
335 through line 622. Field two is 313 lines; field
one is 312 lines.

And this for NTSC:

5.2.8 NTSC Progressive Scan
VSYNC will transition low at line four to begin
field one and will remain low for three lines or
2574 pixel cycles (858 × 3). NTSC interlaced timing
is illustrated in Figure 9. In this mode, the
CS4954/5 expects digital video input at the V [7:0]
pins for 240 lines beginning on active video line 22
and continuing through line 261.
Field two begins with VSYNC transitioning low at
line 266. VSYNC stays low for 3 line cycles and
transitions high during the end of line 268. Video
input on the V [7:0] pins is expected between line
284 and line 522. Field two is 263 lines; field one
is 262 lines.

(Figures are attached)

Sure, if they aren't standards, Amiga could use different values. But even this guy , testing the PlayStation2 with the oscilloscope studying progressive modes to use in his Z80 project, seems to have found the same values of the Cirrus documentation.

Let us know.

Thanks

[ceztko]

Originally Posted by Toni Wilen

PAL minimum vblank end line is 25.

Again, minimum vblank end line can't be 25, because the actual current vblanking signal start in the previous field. Minimun vblank end line for a correct pal signal should be 22. For the maximum value, have you read this PAL/NTSC specification document (I'd like to read the official one...it it was free!)? Yes, seems that the vblank signal can be "25 H + a", where "a" is the Line-blanking interval, that can be 12 +/- 0.3 (too bad, it should be in another measure unit...never mind). In this case, the maximun end line of the vblank signal is 34.

IMO, the right way to find where the "active signal" start (as definited from the pal specification) is not trying to measure what is the first visibile line of the amiga display, but measuring the vblank signal lenght, that HAVE TO be different from the other part of the signal (whenever it carries visibile output or not).

[Toni Wilen]

Line = number in VPOS register. Real vblank can be different but it is irrelevant, first line that is not blanked (due to "real" vblank OR denise blanking the signal) is the only thing that matters in this case.

We are not emulating monitor
(except if monitor is A2024..)

[ceztko]

Originally Posted by Toni Wilen

Line = number in VPOS register. Real vblank can be different but it is irrelevant, first line that is not blanked (due to "real" vblank OR denise blanking the signal) is the only thing that matters in this case.

Understood, I was just wondering if this would lead to precise centering anyway.

Originally Posted by Toni Wilen

We are not emulating monitor
(except if monitor is A2024..)

No, but real vblanking length will be useful trying to emulate precise amiga ouput signal But I think this will be impossible without additional hardware or writing custom drivers for a single video card model... Non only because few video cards can output a correct PAL RGB signal, with sane HSYNC-VSYNC signals, but because I doubt video-cards can easily implement 312-313 lines fields alternating. Uh, and maybe hires-lores pixel clock mixing is another weird thing that Amiga can do poking with the video signal...

[Yoto]

To: mr_A500

Why do you use those display modes anyway, why not just install Picasso96, with the rtg library and enable uaegfx? You could then set your Workbench 3.1 screen at 1280x1024 - 16 bit PC.

[mr_a500]

I use NTSC hires interlaced because that's what I'm using on my many real Amigas. None of them have graphics cards (damn overpriced eBay!).

If I take a drive out of a real Amiga and try to run it in WinUAE, I want it to look and act exactly the same. (that's the point of emulation, isn't it?)

[Yoto]

I guess emulation serves many purposes , to look exactly the same as a real A1200 with no graphics card is also one of them. Good luck!
BTW: To avoid the scan lines problem that goes away when you pass the mouse thru change the option (Refresh: Every Frame) to (Refresh:Every second Frame)

[mr_a500]

I guess emulation serves many purposes , to look exactly the same as a real A1200 with no graphics card is also one of them.

Actually the A1200 is one of the few Amigas I don't have. I've got an A500,A1000,A2000,A3000,A4000 and all (except the A1000) are using the same 16-colour NTSC highres interlaced setup - but different overscan depending on monitor. (A1000 uses 4-colour NTSC highres interaced 660x436)

BTW: To avoid the scan lines problem that goes away when you pass the mouse thru change the option (Refresh: Every Frame) to (Refresh:Every second Frame)

I just tried that, but it has no effect whatsoever on the scanline problem.

Toni said that it should be fixed in 1.5.0 so I'll download that DirectX 9 this weekend and test. I just downloaded a 47Mb BeOS install with my A500, so 75Mb shouldn't be too much more painful. (BeOS is awesome! Hey Toni, can you make me an updated BeUAE? )