[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.

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

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.

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.

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.

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.

b31 x64
Leander WHDLoad sprites broken... black siluette etc. using ttypes:
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...)

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:

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

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.

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

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

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.

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 :)

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.

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...

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".

Famous last words :D

:)

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