WinUAE 4.0.0 beta series

[Retro-Nerd]

50Hz capable monitors aren't expensive these days. There is no need for CRT anymore.

[Toni Wilen]

It is probably impossible to find modern non-50Hz capable monitor today, at least if it is 1080p and/or 4K HDMI capable. Some even support backlight strobing at low refresh rates but result probably is extremely flickery..

But lets not make this monitor thread. Also buying/replacing monitor won't help with laptops..

[Steve]

Originally Posted by Leandro Jardim

Here too. But seems that a good game to check this is James Pond II AGA. A couple of times it gave problems here... Of which game in particular you are speaking?

Sensible World of Soccer. It seems more pronounced in the 'crowd' sections when playing up the pitch, the horizontal scrolling makes for a fair amount of tearing in the crowd.

I have tried 2 and 4 for the 'layers' option but nothing has seemed to fix the problem. I might try more a few more of the layer settings to see if that will improve the issue.

[Toni Wilen]

Originally Posted by Steve

Sensible World of Soccer. It seems more pronounced in the 'crowd' sections when playing up the pitch, the horizontal scrolling makes for a fair amount of tearing in the crowd.

I have tried 2 and 4 for the 'layers' option but nothing has seemed to fix the problem. I might try more a few more of the layer settings to see if that will improve the issue.

Finding some demo with huge full height horizontal scroller would be the easiest way to see tearing

[lordofchaos]

Originally Posted by Toni Wilen

Finding some demo with huge full height horizontal scroller would be the easiest way to see tearing

http://www.pouet.net/prod.php?which=3841

Megademo by Dragons might prove useful? Text scrollers section perhaps.

[Retro-Nerd]

8bit Jungle should be nice test too. Runs rock solid on my display.

[ Show youtube player ]

[Toni Wilen]

Originally Posted by MagikGimp

Hi Toni,

Some "mini-dump" crash files or whatever they are I've had generated over the last few days of recently revisiting this hobby, if you're interested. I get the feeling my whole setup is borked. Please do let me know if this is actually the case!

Oh, they're for beta 2. And now you've released 3. Damn it!

JIT on? Crash dumps are mostly useless if JIT is active.

[mcbpete]

Originally Posted by Toni Wilen

It is probably impossible to find modern non-50Hz capable monitor today .... Also buying/replacing monitor won't help with laptops..

This is actually a real good point, has anyone here in Europe bought a laptop in the last few years and the screen does indeed support 50Hz? I'm from the UK and got my laptop custom built here so it's actually surprising to learn it's 60Hz only (even more surprising is that it's taken me 6 years to notice this is the case!) but wondering if that's just 'laptop standard'

[mark_k]

There's a difference between the panel actually being 60Hz only, and Windows only sending a 60Hz signal to it. If you're able to edit the EDID data used, you can often get the graphics driver to output a 50Hz signal. [The panel EDID data typically tells the computer that it supports 60Hz (only), but many panels do actually work with a fairly wide range of vertical refresh rates.]

Another issue (which applies to my UHD desktop monitor Acer CB241HQK; don't buy one of those) is that some monitors, while they may accept a wide range of input signals, always refresh the actual panel at 60Hz. Meaning the monitor duplicates every fifth frame if the input signal is 50Hz. Grrrr.

[mark_k]

A couple of demos which have large horizontally-scrolling regions:
Scroll Demo (Perfect Cracking Team)
Jump Jet cracktro (Bamiga Sector One & The Kent Team) (there are various other intros which use the same code but different graphics on that page)

If I remember correctly, the BS1/TKT demos allow you to change scroll speed & direction of foreground and background using the joystick.

[Mclane]

For those getting ultra fast play ie double speed then 100 make sure you have set the monitor freq, if its not set to either 50 or 60 (depending on ability) it will play at double speed..

[Dr.Venom]

Originally Posted by mark_k

Another issue (which applies to my UHD desktop monitor Acer CB241HQK; don't buy one of those) is that some monitors, while they may accept a wide range of input signals, always refresh the actual panel at 60Hz. Meaning the monitor duplicates every fifth frame if the input signal is 50Hz. Grrrr.

Ouch, that sucks..

What are you using for overriding the EDID? I guess CRU by ToastyX?

The video driver has to support it though. Since about mid-2017 Intel has finally been supporting EDID overrides in their drivers.

Unfortunately I haven't found a way to override or force custom refresh rates on older Intel integrated graphics. I've been trying to add 50hz to an Atom based portable but had no luck so far...

Hacking tips welcome

[mark_k]

Standard vsync in D3D11 windowed mode doesn't seem to work correctly. Config and small ScrollTest program (more on that in this thread) in The Zone and uploaded to:

http://www.media!fire.com/file/qncjbp8xxthpiep/Bad_D3D11_vsync.zip

Config is A500 cycle-exact, windowed, standard vsync, D3D11, "double, fields+" line mode. With WinUAE 3.6.1 that works fine. You can change to D3D9 mode and it still looks fine.

With WinUAE 4.0.0b3 vsync doesn't work in D3D11 mode; it seems execution speed is uncapped since the bars move much quicker. The display is correct (slow-moving bars) in D3D9 mode.

[Toni Wilen]

http://www.winuae.net/files/b/winuae_4000b4.7z
http://www.winuae.net/files/b/winuae64_4000b4.7z

Beta 4:

- Show only every 10th frame in D3D11 warp mode. For some reason Present() blocks if rate is higher than current max monitor refresh rate, not even DXGI_PRESENT_ALLOW_TEARING or DXGI_PRESENT_DO_NOT_WAIT help.
- Normal windowed D3D11 vsync mode should work correctly again.
- Default WASAPI audio device now follows Windows default audio device if default gets changed and emulation is already running.
- Renamed new low latency vsync to official "Lagless VSYNC (Beamraced)".
- Flip first slice early, before vblank (Early flip won't cause tearing as long as it happens during last slice). This should fix tearing in topmost slice when flip gets delayed (which for some unknown reason seems to regularly happen if flipping is done during vblank). This change makes last debug color bar shorter which is normal.
- Use NtDelayExecution and ZwSetTimerResolution (if available) for sub 1ms delays in non-fastest possible CPU low latency vsync modes.
- Replaced FastLane ROM with full 32k dump.
- Emulated (partially) C-Ltd Kronos.
- Removed CDTV SCSI from Advanced Chipset. It is optional hardware module and should be only in Expansion panel. Old CDTV SCSI configured config files are still supported but this and future versions won't write old CDTV SCSI config file entry to config file anymore.

C-Ltd Kronos:
- 5380 based SCSI controller with buffer RAM.
- Boot ROM added ("CLtd RomBoot 3.4, Copyright 1989, Wayne E. Miller")
- Boot ROM is only small driver loader from drive's custom partition table.
- SCSI settings are stored in 256 bit 93C06 serial EEPROM. EEPROM is emulated but data is static (boot enabled, SCSI ID=7)
- Install disk is MIA: Emulation is not yet complete, for example buffer RAM/fake DMA is not emulated.

Lagless VSync still does not support autoscale or other scaling options. Amiga overscan display height must still match (mostly) monitor height.

VariableSpeedLowRes in the zone can be used for tearing testing.

[mark_k]

I noticed a couple of issues (which may be related) with lagless vsync.

The bottom-most scanline (which contains only the background colour except for A1000 Agnus configs) is not shown when lagless vsync is used. It is shown with non-vsync and standard vsync.

There's a problem related to the way slices are positioned. If you run the VariableSpeedLowRes test program using "double, fields+" line mode, you'll see a number of brighter lines. Those correspond to being white in every frame, as opposed to alternately black/white. The number of lines matches the number of slices. The bottom line is always brighter. Increase the number of slices and the number of brighter lines increases to match.

Also: Maybe this is a graphics driver issue, but in windowed mode with lagless vsync (double, fields+ line mode again), there is a tear exactly between the top two slices. The vertical position of the tear is rock-solid. If you move the emulation window, the tear position moves to remain exactly between the top two slices (i.e. at the same Amiga scanline). Happens in both D3D9 and D3D11 modes. [I didn't think tearing was possible in Windowed mode due to DWM???]

[Toni Wilen]

Originally Posted by mark_k

The bottom-most scanline (which contains only the background colour except for A1000 Agnus configs) is not shown when lagless vsync is used. It is shown with non-vsync and standard vsync.

Last line may be a bit too special for lagless vsync without some hacks, not sure whats the problem and how to fix it..

There's a problem related to the way slices are positioned. If you run the VariableSpeedLowRes test program using "double, fields+" line mode, you'll see a number of brighter lines. Those correspond to being white in every frame, as opposed to alternately black/white. The number of lines matches the number of slices. The bottom line is always brighter. Increase the number of slices and the number of brighter lines increases to match.

This is fixed now.

Also: Maybe this is a graphics driver issue, but in windowed mode with lagless vsync (double, fields+ line mode again), there is a tear exactly between the top two slices. The vertical position of the tear is rock-solid. If you move the emulation window, the tear position moves to remain exactly between the top two slices (i.e. at the same Amiga scanline). Happens in both D3D9 and D3D11 modes. [I didn't think tearing was possible in Windowed mode due to DWM???]

Windowed mode fixes/updates will come later.

[mark_k]

About the tear in windowed mode. Maybe the reason for that is, DWM copies the surface (or back buffer or whatever it's called) at the first Present() in each frame. At that point WinUAE has rendered the top slice so the rest of the surface is data from the previous Amiga frame. Hence the tear line between the top two slices.

[I see the tear regardless of graphics API, DirectDraw, D3D9 or D3D11. That's on Windows 10 1709. I'll test on Windows 7 with DWM disabled later.]

Setting the number of slices to 1, the tear is either right at the bottom of the window or not visible.

Is the old low-latency vsync mode definitely not coming back? I was wondering about how lagless vsync will look when the monitor is in portrait orientation. There of course, the direction of the PC "raster" is perpendicular to the Amiga raster, so the slices concept probably won't look too great. I didn't test that yet.

[Toni Wilen]

I thought you meant borderless windowed (full-window) which seems to work correctly (same as real fullscreen). Normal windowed is almost guaranteed incompatible.

[Toni Wilen]

http://www.winuae.net/files/b/winuae_4000b5.7z
http://www.winuae.net/files/b/winuae64_4000b5.7z

Beta 5:

- Single scan line off by one fix in lagless vsync, frames+ mode now works correctly without static horizontal lines.
- Single slice lagless vsync had blank display (b4)
- Automatic scaling and some other scaling modes had very strange corrupted display in lagless vsync mode. Some small tearing is still possible if scaling is large enough.
- END+F9 lagless vsync debug mode now also adds small flickering markers that show where Amiga-side slices are positioned (Optimally they should be in the middle of large color bars). Switching screen modes does not anymore automatically disable debug colors.
- Reduced amount of data copied in lagless vsync if null filter or d3d shader is enabled.
- Overlay leds (b2) are now also supported in D3D9 mode.
- BPLCON1 delay logic fix when single scanline had at least one odd plane delay not equaling even plane delay and then one or more odd == even delays. (Very rare situation)
- Debugger fa command didn't find anything.
- Disassembler crashed if it disassembled FMOVECR instruction and statefile was loaded without enabled FPU.
- Switching from non-cycle exact to cycle exact mode stopped interrupts if only single INTENA interrupt was enabled.
- Moved CDTV SRAM from Advanced chipset to Expansions and added size selection.

Lagless vsync is now mostly complete. Tweaking to do, depending on feedback.

[mark_k]

Originally Posted by Toni Wilen

I thought you meant borderless windowed (full-window) which seems to work correctly (same as real fullscreen). Normal windowed is almost guaranteed incompatible.

It does actually seem to work as long as DWM is disabled (so realistically, only on Windows XP/Vista/7). Probably works best when the window occupies most of the screen height.