I can only imagine... So I am donating time and effort to help on the way I only know. ;)

Trust me, you have no idea how many demos, intros etc. (many boring ones) is needed to check in order to find anything that could be of help. :crazy

Small issue: when you resume Windows, for example after overnight, Workbench time is not updated to the host machine. You have to force a SetClock LOAD from shell to update the clock.

That's not a WinUAE issue. When you boot the Amiga, it loads the time from the clock chip. It then uses the CIA's to keep track of the time.

If you pause your computer, you pause the emulation and consequently pause the counting of the clock within the virtual Amiga.

When you resume your PC, it resumes the Amiga where it was when you put your PC to sleep, so the Amiga just carries on where it left off counting the time.

I guess a workaround is to run a "SETCLOCK LOAD" every 5 minutes within your installation using some sort of process scheduler like "cron" on Unix systems.

Sure, but maybe a check in WinUAE could be added to track Windows resumes? Not sure such API exists from MS though...

Wrong thread. This has nothing to do with this beta series.

Misc panel has "syncronize clock" that should do what you want.

Yeah, your work (as well as that of other people in this thread) is absolutely commendable.
:great

Thanks and that applies also to "someone who does not need to be mentioned"! :great

Ps.
Okay, we exchanged thank you notes, so enough with emotion and let’s get back to the hard work! ;)

https://download.abime.net/winuae/fi...uae_4900b32.7z
https://download.abime.net/winuae/fi...e64_4900b32.7z

Beta 32:

- HDIW blanking could get stuck in always-on state if VPOSW was written mid screen with out of range values. (Agony Psygnosis title screen become fully border color blanked if ECS)
- Wait 2 fields before updating visible screen after display parameter change. Hides glitches at the bottom of screen that can appear when last visible line is actually line 0 or higher. Direct 3D output is still refreshed normally, only difference is that data comes from old frame. Most "real" displays would either roll (CRT) or blank temporarily (LCD etc) in this situation.
- On the fly config changes are again checked and processed before vertical position 0 starts. Previous display updates moved it to line 1 or later, depending on mode. This might have caused unexpected side-effects.
- Hardwired vertical blanking didn't work correctly if OCS Denise was configured.
- Removed OCS Denise H-blank bug advanced chipset option. It is now always enabled (if OCS Denise configured) but "buggy" top and bottom line is only visible if overscan mode is Overscan+ or Extreme.
- Switching from some other config to/from ECS Agnus 512k/512k configuration where Agnus sees 1M chip RAM (Agnus sees upper half of chip RAM at usual $800000 address but CPU sees it at $c00000) didn't always change config correctly. For example loading statefile that uses ECS 512k/512k config when current config is OCS 512k/512k, didn't switch config correctly. (Very old bug)
- ECS Denise + EXTHBLANK=1: vertical blanking (display blanking only) is fully disabled.
- New undocumented feature: DIGHIGH bits 3 and 11 are vertical start/stop bit 11 in ECS Agnus. AGA replaces them with horizontal H0 bits. It is not documented in HRM ECS chapter documents them, officially V10 bit is highest (and even V10 is almost totally useless). VPOSR/W V11 does not exist and vertical counter is only 11 bits (0 to 10) which makes DIWHIGH V11 feature that makes no sense.
- CIA/CPU timing fix in b21 was partically broken.
- Programmed mode vertical display start/end calculation adjustments.
- Bitplane refresh slot conflict emulation was "too random". Internal behavior is still unknown. (First demo / Starline corruption if ECS)
- INTREQ write that clears interrupt(s) didn't use cycle accurate (delayed) code path. (La Weird / Cave)
- Vblank interrupt horizontal start was not adjusted to new custom chipset emulation (Spectre Party / Phenomena and others)
- VHPOSR was not adjusted to new chipset emulation (hpos=0 reads previous vertical line)
- CD32 NVRAM write that wraps around caused NVRAM file size to increase.

Great work, Toni.
Do you intend to fix this bug in this release?

Toni with latest beta 32 if you restart the same OS a second time, WinUAE crashes.

- Start OS
- F12
- Restart
- Start
-Crash


I also have problems starting Crunch-Mania from an RTG OS, WinuAE freezes, with previous betas no problem at all

Can't reproduce here: tested with my main cfg (OS3.9 customized); OS3.9 bb2 clean fresh install + P96; OS3.2 clean fresh install + P96.
Restart + Start no crashes for me with cfg in signature (060 JIT On system + Z3 gfx board emu). Maybe the issue is in virtual hardware mapping (order)? Here is mine:

https://i.ibb.co/Yyt4dP3/image.png

No it also happens from a QuickStart configuration "without any operating system", see attached video, with previous betas it doesn't happen.


http://eab.abime.net/zone/Test-WinUAE-Beta32.avi

Tried to reproduce it as in your video and it doesn't happen here, really (I know it's annoying)... :-\
Reason for your crash must be more complicated.

Have you tested Beta 32 at 32Bit?

I think this is Direct3D9 only bug that was introduced in b32 (which now has 2 output textures, one "backup" to keep old texture when needed and one normal). I can't duplicate it myself but it should be fixed now.

Just tried both versions of Beta 32 and followed the video, no crash here in either 32 or 64 bit.

This.
I see Win7 UI from the video... while I'm on Win10 (DX11/12).

EDIT: tested again forcing Misc > Graphics API: DX9 mode this time and... bang!
https://i.ibb.co/LC3Dpvz/image.png

Thanks Toni, with today's winuae.7z fix the crash problem has been solved, also Crunch-Mania works fine from an RTG system without causing crashes.

https://download.abime.net/winuae/fi...uae_4900b33.7z
https://download.abime.net/winuae/fi...e64_4900b33.7z

Chipset updates are almost done. Priority is moving to bug hunting, for example previously reported weird crashes need to be confirmed (if it still happens).

Also PCem update graphics boards (Voodoo, CV64, CV3D, Cirrus Logic based) and bridgeboard emulation needs some testing.

Beta 33:

- DMACONR blitter busy bit state is 1 cycle later than copper waking up from blitter finished. (Circle Scroller / United Force)
- Direct3D9 mode crash was possible when switching screen modes (b32).
- Disassembler configuration (upper/lower case options, show calculated EA, show data pointed by EA, condition true/false), hex number prefix, min and max number of opcode/opwords. Currently only available via direct ini or registry editing, first enter debugger, then quit emulator to create default entries. Debugger sub section, debug_disasm_flags is bit mask, bits 0 to 4 are lower case bits (0=instruction name, 1=registers, 2=hex values, 3=instruction size), 4=show T/F, 5=show EA, 6=show EA contents, 7=show instruction opcode/opwords. Currently they only affect disassembler output. Defaults changed to lower case.
- Don't log flood "DMAL error" messages if (totally unusable) programmed mode with HTOTAL smaller than last audio DMA slot.
- DMAL (Serial DMA slot allocation information from Paula to Agnus) start cycle was not updated to match new custom chipset emulation.
- Small audio period causing repeated samples is now fully accurate, including 1 extra cycle delay if DMA request includes pointer reset (sample restart).
- Very strange programmed modes could have made it impossible to quit emulator normally.
- Adjusted behavior of CPU reads from write-only custom registers (Bozebobs / Area08)
- Fixed crash when loading some old A500 statefiles with CD32 CD incorrectly enabled.
- Adjusted "Smooth Copper" hack to work with new custom chipset emulation (not fully correct yet).
- Console log/debugger DPI adjustment.

Just a quick question, has the billinear filter been wired up in the beta's. Can enable it but zero effect..