WinUAE 5.0.0

[alexh]

Thank you for all the hard work. This release and years of others

[groundplayer]

Thank you and keep up the good work !

[Avanze]

5.0.0 amazing achievement. Thank you, Toni.

[amilo3438]

Also, a big thank you to Ross for his significant contribution to this version!

Originally Posted by Toni Wilen

- Chipset internal delay events are now accurately saved with state files. (Test cases by ross as usual)

- Ultra extreme overscan mode now includes blanking regions drawn using grid pattern. Added new HV ultra extreme overscan mode that shows HSYNC, VSYNC, Blank and Borderblank regions. Can be useful when creating/debugging programmed display modes. C mode shows CSYNC pattern, which is accurate enough to correctly handle at least some weird modes by ross

- Some VHPOSW horizontal change support improvements. It is still a hack but it is simpler hack and generic, required changes are now dynamically calculated. It is not anymore hardwired to Smooth Copper / Up Front specific VHPOSW horizontal position changes. Demo specific hacks removed. Also now horizontal position moves beyond maxhpos is also emulated, hpos counts until to 0xFF before wrapping around. DMA debugger also updated to support skipped or doubled cycles. VHSPOW behavior needs future undocumented feature thread post. (Weird test cases by ross)

Some new "ross test" edge case chipset fixes:

- If chipset timing event was queued in same cycle as hsync event, hsync event was executed last. Hsync event should always have priority. This was "optimized" some time ago but it was wrong. (BPL1DAT write during same cycle didn't enable sprites in ECS Denise config)
- Very early BPL1DAT write didn't update sprite minimum visible horizontal position correctly, in some situations sprite that was "hidden" behind border didn't become fully visible.
- If BPL1DAT enables sprite(s) and "bordersprite" condition was possible (ECS Denise or AGA), enabled sprites activated border sprite state even if new visible sprite pixel would have been hidden by HDIW start. AGA 0.5 pixel lores "bordersprite" condition + borderblank enabled: "bordersprite's" complete pixel (1 lores) become visible.
- Bitplane DMA BPL1DAT access does not anymore open border if OCS Denise and BPL1DAT position was before HBLANK end. (OCS Denise undocumented feature, does not exist in ECS Denise or AGA which allows border open after HSYNC start). Manual BPL1DAT write already did this. ECS Denise earliest possible BPL1DAT access that opens border was 2 cycles too late.
- ECS Denise superhires sprite more accurate color selection emulation ("scrambled" odd/even palette access). Attached sprites are not yet correct (it does something in this mode but it can't be what normally working attachment does). Also it appears first pixel column of ECS superhires sprite is invisible (not transparent, appears as COLOR0, not background bitplane), this is not yet emulated. Sprites 4 to 7 are not working (nothing appears on screen) when in ECS superhires mode. (Agnus still does normal SPRxPOS/CTL and SPRxDATA/B writes)

@Toni

Originally Posted by Toni Wilen

WinUAE 5.0.0 (31.05.2023) released.

VHPOSW/VPOSW mid-screen vertical and horizontal changes are now more accurately emulated. Smooth Copper / Up front demo specific hack is (finally!) not needed anymore and was removed.

It is not anymore hardwired to Smooth Copper / Up Front but it is still a hack! ("simpler hack and generic, required changes are now dynamically calculated") EDIT: And I would add specific to 68000 cpu, right!?

[ross]

Originally Posted by amilo3438

And I would add specific to 68000 cpu, right!?

Right.
Smooth Copper use a complex hard-sync method (requires accuracy between 68k CPU cycles, bus cycles, and Agnus counter 'reprogramming').
If there is even one cycle of difference there are video glitches.
So for processors other than pure 68k or at different frequencies it wouldn't work.

In theory it is possible to make it run with the same method on other Amigas, but the ECS chipset and the rewriting of the synchronization code are required.

[amilo3438]

@ross
Thank you for the additional clarification.
Since there is probably no other problem similar to this (at least as far as I know), rewriting of the synchronization would not be worth the extra effort.
(I'm glad you're back again)

[eXeler0]

Many Thanx,

[Anubis]

Thank you for new release!!!

[fxgogo]

Brilliant. Thanks Toni, my Sunday got even brighter.

[Angus]

You are an Amiga Hero, Toni. Very many thanks. :-)

[Rock'n Roll]

Toni, thank you for your tireless work. What would our hobby be without you?

[Rene_1974]

Thank you for keeping updating the Winuae Toni.

[tygre]

Thanks you!

[punkrulesok]

Thanks for this - jeeze - I remember around 1996 playing with this on Windows Pentium 120 - Beast would nearly hit 50fps

Is it possible to get a working CRT shader on WinUAE right now? I have tried in the past, but not got far.

[Retroplay]

It sure is.
https://github.com/guestrr/WinUAE-Shaders