English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   support.WinUAE (http://eab.abime.net/forumdisplay.php?f=5)
-   -   WinUAE 4.9.0 beta series (Was 4.5.0) (http://eab.abime.net/showthread.php?t=104099)

Toni Wilen 23 August 2021 19:37

[QUOTE=hexaae;1502242]Another crash (sprites issue again?): https://1drv.ms/u/s!ApMUGr0cuN39gf81...yWAag?e=vaS5bC

It is same. I need to find out how to debug this before things go wrong when it is already too late.

Quote:

Originally Posted by mcbpete (Post 1502418)
Definitely not a show stopper but just updated to b30 from a much older 4.5/4.9 beta and noticed some slight garbage graphics on the right of the screen when running in fullscreen. Downloaded earlier betas to place when it started and b20 seemed to be the last version without this glitch on the right hand side (b21 I was unable to download due to it flagging my virus scanner but from b22 onwards it displays like this):

http://www.ilovecubus.co.uk/pete/winuae_b22.png

http://www.ilovecubus.co.uk/pete/winuae_b22_2.png

Alt-Tabbing away and then back to UAE seems to clear it however. Running in direct 3d11/Hardware d3d11 on an nVidia rtx2080

Here's the logs and config used (seems to happen regardless of using a d3d filter): http://www.ilovecubus.co.uk/pete/winuaelogs.zip

Does it also happen if you use very large windowed mode before starting emulation?
EDIT: and without the d3d shader?

mcbpete 23 August 2021 20:04

Yes to both :)
1920x1080 windowed mode with all filters set to none: http://www.ilovecubus.co.uk/pete/win...0_windowed.png

Toni Wilen 23 August 2021 21:04

Quote:

Originally Posted by mcbpete (Post 1502606)
Yes to both :)
1920x1080 windowed mode with all filters set to none: http://www.ilovecubus.co.uk/pete/win...0_windowed.png

Confirmed, it was horizontal centering combined with other changes. Will be fixed in next beta.

jotd 25 August 2021 17:39

in the debugger, seems that "il" option isn't working. Either 0 of full $FFFFFFFF$FFFFFFFF doesn"t break...

Toni Wilen 27 August 2021 21:33

Quote:

Originally Posted by jotd (Post 1502893)
in the debugger, seems that "il" option isn't working. Either 0 of full $FFFFFFFF$FFFFFFFF doesn"t break...

Is that really 4.5+ bug? Don't see anything obvious.

Toni Wilen 29 August 2021 20:08

https://download.abime.net/winuae/fi...uae_4900b31.7z
https://download.abime.net/winuae/fi...e64_4900b31.7z

Beta 31:

This version updated superhires resolution accuracy (hblank, sprites, bitplanes, borderblank etc..). Note that superhires can be only seen fully accurately in subpixel mode (chipset panel) + superhires emulation resolution (display panel) and SVGA/x86 bridgeboard updates to latest (and final?) PCem.

All currently known weird chipset (including programmed mode) features are also fully implemented. (I know I have said same previously but really this time.. I know who to blame if something new is found :D)

- Sprite right overscan fixes.
- Programmed mode adjustments. HSSTOP does not affect display position. HSSTRT - HSSTOP only needs to be long enough for display device to detect it. Note that WinUAE will accept invalid HSSTOP and other impossible in real world programmed modes, there is no validation against real world video signal standards.
- HBSTRT/STOP accuracy improved in really weird situations (like having multiple HBLANK regions in single scanline..). Undocumented special case emulated: if HBSTRT to HBSTOP is less than 1 lores pixel (4 shres pixels), 4-(HBSTOP-HBSTRT) shres pixels of bitplane is visible before COLOR0 starts. Subpixel mode required. Apparently switching border on takes 1 lores pixel. (HB is Denise/Lisa internal trigger for border on state)
- Bitplane to refresh strobe vs refresh-only slot conflict behavior fixed (Water intro / Acme, Vectors Again / Armada etc, glitches are now correct if ECS Agnus)
- Optimized bitplane allocation now works correctly in NTSC mode, needs 2 alternating buffers because line length alternates in NTSC.
- Writing to horizontal DIWSTRT/STOP just before it would match missed the check.
- DIWHIGH full AGA hires/shres positioning bit support.
- Line buffer size was not large enough to fit "extreme" overscan superhires mode.
- HCENTER 8/9 CCK horizontal blanking period emulated. HCENTER generates extra sync pulse when it matches and current line is vsync line and long field. This is normally invisible but it can be visible in (weird or badly configured) programmed modes. Visible result is small black box, about at the middle of last line(s), ECS Denise only. This is never visible on AGA because blanking is generated by Lisa using internal registers. ECS Denise uses CSYNC pin to detect blanking condition. OCS Denise does not have CSYNC pin and uses internal hardwired blanking only.
- Fixed wrong border color/black color in right border when horizontal centering was enabled. Probably also possible in some other situations.
- ECS Denise hires resolution sprite horizontal position bit works strangely if bitplane resolution is lores or hires: first pixel row of sprite becomes transparent. Horizontal bit only works correctly if bitplane resolution is superhires.
- Subpixel emulation mode + superhires had single shres pixel offset in horizontal hblank and borderblank positioning. This change also means borderblank/border bug can't be anymore visible without subpixel mode + superhires resolution.
- DMA debugger uses first refresh slot to show if line is vertical blanking (B), vertical sync (S) or vertical diw is open (=), second refresh slot is used for long field (F) and long line (L). These special slots are marked with '*' to not (too easily) confuse them with same symbols in other slots. Horizontal diw ('(' and ')'), programmed horizontal blanking ('[' and ']') and programmed horizontal sync ('{' and '}') are also marked.
- PCem v17 merge. Some SVGA updates, Voodoo 3 updates, x86 CPU updates. (Probably moving to 86box in the future, PCem is not updated anymore.)
- Misc panel statefile text box was empty (might be Windows version specific or something) even when loaded config had statefile configured.
- fs debugger command fixed, display emulation updates made it randomly inaccurate.
- Seems to run normally under Windows 11 insider build.

Zarnal 29 August 2021 21:42

Hello,

I just noticed a small problem during my test of the AGA "Passion-Alien Inspiration " demo with b31. After a while a window appears (pic 1). The demo continues to run normally and WinUae does not crash.

Note : 1 to start it. Quickstart A1200.

hexaae 29 August 2021 21:49

b31 x64
Leander WHDLoad sprites broken... black siluette etc. using ttypes:
Code:


ExecuteStartup=
ExecutePostDisk=uae-configuration cachesize 0 win32.cpu_idle 105 cpu_speed real

2 mins later:
Mmmh, runs fine with:
uae-configuration cachesize 0 cpu_compatible false cpu_cycle_exact true immediate_blits false
or
uae-configuration cachesize 0 cpu_speed real

(Was working fine with both in b30...)

paraj 29 August 2021 22:48

2 Attachment(s)
This might not be a bug, since I unfortunately don't have real HW available to test ATM, but since b21 it seems like vblank interrupt latency is unstable if cia registers are accessed? (probably due to this from changelog "- Cycle-exact mode CPU to CIA E-clock syncronization was not accurate." change).

This is using quickstart a500+chipset->cycle exact (full). (Also tested in b31)

I've attached (hopefully) minimal repro (display sync from vAmiga test suite is only to show changes, doesn't seem to make a difference) that basically just waits for VBLANK interrupt using STOP. If CIA's are accessed (instruction type doesn't seem to matter) vblank interrupt is delayed by 2 CCKs every other frame (HPOS=25/27 when adding breakpoint to interrupt handler).

Since I've been playing around with my own emulator code (for fun^H^H^H pain), I'm quite curious how CIA synchronization is actually supposed to work. From looking at schematics/docs it seems like accesses should be independent from chip/custom registers and only need to line up with correct eclock timing (and stay in sync for some number of 7MHz cycles ?).

Code:

Code:

vposr=$004
vhposr=$006
dmacon=$096
intena=$09a
intreq=$09c
color=$180


        section code_c, code_c

main:
        move.l  #$dff000, a6
        move.w  #$7fff, intena(a6)
        move.w  #$7fff, dmacon(a6)
        move.l  #level3, $6c.w
        move.l  #supercode, $80.w
        trap    #0
supercode:
        move.w  #$7fff, intreq(a6)
        move.w  #$c020, intena(a6)

        lea    vhposr(a6),a3
.loop:
        stop    #$2000 ; wait for vblank interrupt
        move.w  #$000, color(a6)

        tst.b    $bfd000.l ; <-- Comment out this to get stable image

        bra    .loop

level3:
        move.w  #$0020, intreq(a6) ; ack interrupt

        ; Sync code from https://github.com/dirkwhoffmann/vAmigaTS
.waitvpos:
        move.w  (a3),d2
        and    #$FF00,d2
        cmp.w  #$3000,d2
        bne    .waitvpos
        and    #1,vposr(a6)
        bne    .waitvpos
        move.w  #$F0F,color(a6)
.synccpu1:
        andi.w  #$F,(a3)          ; 16 cycles
        bne    .synccpu1        ; 10 cycles
        move.w  #$606,color(a6)
.synccpu2:
        andi.w  #$1F,(a3)        ; 16 cycles
        bne    .synccpu2        ; 10 cycles
        move.w  #$A0A,color(a6)
.synccpu3:
        andi.w  #$FF,(a3)        ; 16 cycles
        nop                      ;  4 cycles
        nop                      ;  4 cycles
        nop                      ;  4 cycles
        bne    .synccpu3        ; 10 cycles (if taken)
        rte


Toni Wilen 30 August 2021 10:16

Quote:

Originally Posted by hexaae (Post 1503603)
b31 x64
Leander WHDLoad sprites broken... black siluette etc. using ttypes:
Code:


ExecuteStartup=
ExecutePostDisk=uae-configuration cachesize 0 win32.cpu_idle 105 cpu_speed real

2 mins later:
Mmmh, runs fine with:
uae-configuration cachesize 0 cpu_compatible false cpu_cycle_exact true immediate_blits false
or
uae-configuration cachesize 0 cpu_speed real

(Was working fine with both in b30...)

Does only removing cpu_idle also fix it?
Screen shot please.

hexaae 30 August 2021 12:32

Marvin's Adventure: half pixel border on the left disappeared again in b31

Toni Wilen 30 August 2021 12:42

Quote:

Originally Posted by hexaae (Post 1503683)
Marvin's Adventure: half pixel border on the left disappeared again in b31

This is mentioned in changelog. Superhires pixel size errors are now only visible in subpixel+superhires mode.

EDIT: this is difficult issue because if there are odd number of superhires pixels and when emulator "rounds" it to hires, result might or might not be visible. Sometimes it even might be incorrect, sometimes correct. Fortunately single superhires differences are rare.

amilo3438 30 August 2021 16:03

Agony (1992)(Psygnosis)[cr CSL](Disk 1 of 3).adf

The Psygnosys logo is not shown during the starting part! (b31)

Toni Wilen 30 August 2021 20:09

Quote:

Originally Posted by Zarnal (Post 1503601)
Hello,

I just noticed a small problem during my test of the AGA "Passion-Alien Inspiration " demo with b31. After a while a window appears (pic 1). The demo continues to run normally and WinUae does not crash.

Note : 1 to start it. Quickstart A1200.

I added some more blitter debugging when programs do bad things but it used wrong output calls which forces debugger window open..

Harmless but can be annoying.

Quote:

Originally Posted by paraj (Post 1503611)
This might not be a bug, since I unfortunately don't have real HW available to test ATM, but since b21 it seems like vblank interrupt latency is unstable if cia registers are accessed? (probably due to this from changelog "- Cycle-exact mode CPU to CIA E-clock syncronization was not accurate." change).

It is a bug. CIA fix was not exactly right but not fully wrong either, fixed :)
But width of color bars are not 100% identical on UAE vs ECS A500 (And A1000 also has different widths and they don't match either). Not sure what goes wrong (or if it even goes wrong) because that code does not really explain what those AND tests expect to read :)

Quote:

Originally Posted by amilo3438 (Post 1503709)
Agony (1992)(Psygnosis)[cr CSL](Disk 1 of 3).adf

The Psygnosys logo is not shown during the starting part! (b31)

Fixed, thanks :)

It writes out of bounds vertical position to VPOSW (probably accidentally sets ECS only bits) which confused emulation if it happened mid screen.

Toni Wilen 31 August 2021 19:32

Quote:

Originally Posted by hexaae (Post 1503603)
b31 x64
Leander WHDLoad sprites broken... black siluette etc. using ttypes:

Does this also happen with 32-bit version? If it does, there might be an explanation.

On the fly config changes now happen after line 0 which could cause side-effects, next version will change this back to how it worked previously.

hexaae 31 August 2021 23:11

Quote:

Originally Posted by Toni Wilen (Post 1504019)
Does this also happen with 32-bit version? If it does, there might be an explanation.

On the fly config changes now happen after line 0 which could cause side-effects, next version will change this back to how it worked previously.

I'm trying hard to reproduce it but I can't ATM, and what I thought it could be the cause is not... still trying... As far as I can tell (but I'm not an Amiga coder) it looked like the typical BPLCON4 in a bad status situation where bitplanes had wrong black silhouette color instead of std multicolor, including some sprites but only with Leander WHD... This with the x64 exe.

During these days happened in the meanwhile another of my strange cases ;) : emu was still running in bg for a long time (21 hours of uptime from WB!), after running also demos, WHD games & demos, WB friendly games like UFO Enemy Unknown..., and some programs I run for testing like PPaint 7.3c, ChaosPro, ArtEffect, Elastic Dream... (very stable this b31 BTW). Then something strange happened: all native modes were trashed with the screen rendering compressed in 10-20 horizontal lines in the upper border of the screen (audio was ok, games/apps were working fine as I could still move through menus and blind-quit etc.). This persisted even after WB reboots (!?), everything looked fine, WB RTG was running fine, and also programs, delitracker mods playing etc... but still all native modes (including SYS:Prefs/ScreenMode opening NTSC/PAL) were incorrectly displayed as described above with the squashed upper lines rendering only! Obviously WinUAE Chipset, Display, Filter and RTG settings were ok as usual, I checked this. Even F12 + Restart button didn't solve it on next boot... it looked like something screwed up deeply in the native mode emulator part. I've had to completely quit WinUAE in this case.
I tried this too (I'm testing all recent betas on the long run...) but I couldn't reproduce anymore.
BTW, during those 21 hours, with WinUAE iconified but still running, I also switched to the UWQHD 144Hz free/g-sync (display port connected) external monitor, watched some movies and then switched back to the 1920x1080 144Hz g-sync laptop display and resumed emu uniconifying WinUAE, so I thought it could have been that... but I tried to reproduce those steps unsuccessfully (= it didn't seem different screen-switch related)....

Will report back if I'll find a reproducible pattern or if they happen again...

Viceroy 01 September 2021 23:10

1 Attachment(s)
Hi Toni,

Tested with the latest official 32-bit beta i.e. 31.

Managed to solve the "Aladdin [AGA]" pops / cracks in the intro... played with all settings. What worked in the end was changing from "WASAPI" --> "DSOUND". "WASAPI EX" also works but the volume is much quiter than other modes; why is that?

Also, still the 1 pixel far left and far bottom flashing line in RTG mode for "Quake II", see attached. Doesn't happen in "Windowed" but does in in "Fullscreen".

ross 03 September 2021 23:13

Quote:

Originally Posted by Toni Wilen (Post 1503586)
.. I know who to blame if something new is found :D)

Famous last words :D

amilo3438 04 September 2021 00:07

Quote:

Originally Posted by ross (Post 1504735)
Famous last words :D

Quote:

Originally Posted by toni wilen (Post 1498984)
Chipset updates are almost done.

:)

ross 04 September 2021 00:47

Quote:

Originally Posted by Toni Wilen
Chipset updates are almost done.
Quote:

Originally Posted by amilo3438 (Post 1504744)
:)

Trust me, you have no idea how many oddities there are ;)


All times are GMT +2. The time now is 13:59.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, vBulletin Solutions Inc.

Page generated in 0.11949 seconds with 11 queries