On a Windows 10 machine, using 7zip to extract winuae_4900b38.7z is OK, but extracting winuae64_4900b38.7z throws an error:

Does anybody else have this issue?

False positive as usual. :)

Apologies if this already a known/common issue. Is there a workaround other than disabling AV?

Never disable AV, just add the file to the AV's exclusion / Whitelist..

This false positive happens along the way with Winuae... When it's coming from the author or his site then the file is fine, if it's from a different site then always double check on here..

I meant disabling AV just to do the extraction for this particular ZIP file. I can't find a whitelist option on the AV on my machine.

I figured out that it was Windows Security that is giving this false positive, not another AV solution that was running on my machine.

I was able to temporarily disable "Real-time protection" in "Virus & threat protection settings", do the extraction and enable it again.

Great to hear, tis just one of those little hurdles in the software world..

I've just forwarded the false positive .zip to Microsoft av file submission: https://www.microsoft.com/en-us/wdsi/filesubmission

If you have anything similar in future I recommend doing the same, the response time is usually pretty speedy (usually sorted by the signature update a day or two later)

EDIT: Windows Defender signatures now updated and false positive removed :)

one thing I can't solve: the list of roms only shows me the base ones, the roms I added (e.g. 3.2) don't show up in the selector, I have to load them manually (obviously I did the ROM SCAN several times)

@DiabloV: that is by design. Toni's been on record about this before back when 3.1.4 came out as well.

ok but i dont understand why just not scan the *.ROM ? and voila !

I don't want to have anything to do with with 3.1.4+ ROM versions (reasons should be quite obvious). If someone generates required rommgr.cpp lines for _all_ 3.1.4+ ROMs, I can add it.

https://download.abime.net/winuae/fi...uae_4900b39.7z
https://download.abime.net/winuae/fi...e64_4900b39.7z

This hopefully is last beta before few release candidates..

Beta 39:

- Executable as a disk image mounting now supports FFS and HD disks. Uses DD+OFS if selected file fits (like previously), then DD+FFS, finally HD+FFS (if drive is HD).
- Fixed empty formatted standard HD ADF creation, broken in 4.3.0 (bitmap block used DD size)
- If A1200 config had PCMCIA emulation and 4M or larger Z2 RAM enabled, end of Z2 RAM didn't have "safety barrier" which caused long or word access that crosses end of RAM to crash the emulator.
- Some audio debugging was accidentally left enabled in b38
- Adjusted UAE Boot ROM variable locations, freeing more space for ROM code.
- UAE Boot ROM level 2 interrupt server priority changed to -1 if KS 1.x, workaround for old SoundTracker (and clones) broken keyboard handling that breaks completely if KS ROM level 2 interrupt server isn't first in chain.
- Fixed last line of bitmap missing or flickering if very tall interlace mode and interlace artifact removal was enabled.
- Blitter line mode didn't clear BLTZERO if line pixel was skipped because of onedot mode. (vAmiga test case)
- Blitter line mode didn't update global state of shift values and SIGN bit. (vAmiga test case where next blit is started without updating BLTCON0/1)
- Yet another small interrupt timing adjustment.
- Chipset emulation could get confused in non-ce configurations when BPL1DAT was modified with a copper.
- Reinitialize all selected FloppyBridges when exiting FloppyBridge UI.
- Change to memory card (CF/SD/etc) added as a harddrive: if you wanted to use same config with Amiga formatted cards and FAT formatted cards and Windows/driver allowed direct access even when FAT formatted card (without partition table) was inserted (oddly enough Windows 10 and older didn't allow it on my PC but after updating to Windows 11, direct access is possible), FAT card wasn't anymore mounted as a directory drive after re-insert because direct access has priority and it did succeed. Now direct harddrive mode is only used if drive does not have any PC partitions (no drive letter) or if Lock option is ticked.
- Experimental HDR support added. (This is not going to be fully implemented in next official release, it is only side project)

HDR mode details:
- Requirements: HDR capable monitor. Windows HDR mode enabled. Direct 3D 11.
- New Graphics API option: "Direct3D 11 HDR".
- Original 8-bit RGB values are converted to HDR color space using shaders.
- Brightness/contrast adjustments are now done in shader code which prevents usual SDR black crush or white clipping. (Work more like CRT). Gamma adjustment is not yet supported.
- "Blacker than black" option behavior is also changed, because HDR by design support blacker than SDR black, it does not need to affect normal color range like in SDR mode. It is also always enabled in HDR mode.

Thank you ;-)

Hi, trying to use the grease weasel in latest Winuae, I have downloaded the floppybridge0.10.zip file, it says to copy the .dll files into Wi uae's PLUGINS folder. BUt I can't find this folder withing the winuae installed directory. So where exactly do I need to make this dir?

Cheers

The "plugins" directory should be in the same directory as winuae.exe (or winuae64.exe) itself.

On my Windows 10 setup, I had to put them in:

C:\Users\Public\Documents\Amiga Files\WinUAE\plugins\

well, I have made a "plugins" folder in both the C:\Users\Public\Documents\Amiga Files\WinUAE/ and in the same folder as the .exe file, and still no greasweasel listed. Done a reboot and run as admin. still nothing. Just confirming that the floppybridge0.10.zip just contains 2 .dll files plus license & readme.txt file?

You need to go to Hardware->Floppy drives and select "Configure Floppybridge" from the drop down options list for each drive.

This has changed/moved from the unofficial preview build.

https://download.abime.net/winuae/fi...uae_4900b40.7z
https://download.abime.net/winuae/fi...e64_4900b40.7z

Beta 40 (RC1):

- A2065 emulation quit/reset crash fix, A2065 RAM was freed too early, when it was still possible to receive new ethernet frames.
- Blitter final D write does not happen if D channel gets disabled, line mode gets enabled or new blit starts before pending D write has finished. This mainly affects copper blitter wait bug behavior, if new blit is setup before blitter gets its last cycle, last D write never happens which can prevent the glitch from happening. (Last write getting skipped might not cause any visible glitches) Fixes Andy & Blondie / Finity second to last part's glitch. Note that final part has many glitches, happens also on real A500 if system does not have any real Fast RAM.
- Log warning message if BLTDPTx is written to while blitter final D write is still pending.
- Removed wrong INTENA write optimization. Fixes Expiration / Mayhem cube corruption. (Problem wasn't directly blitter related)
- If programmed mode was in use that didn't require configured VSSTRT/VSSTOP registers, display was blank. (Contactro / Illusion)
- Screen mode with even horizontal cycle length (programmed and normal NTSC mode) copper timing fix. Copper can use cycle 0 (previously incorrectly calculated as cycle $e0) if previous line's last cycle was odd cycle (even total length). (Contactro / Illusion)
- Programmed mode registers are again zeroed at startup (was all ones) because JtxRules / Illusion only sets VBSTOP and HBSTOP and expects zeroed HBSTRT and VBSTRT. (Programmed mode comparators don't have reset line connected but they still power up with zeroed contents. At least usually..)

This update fixes remaining chipset related issues in my "should be fixed before official release" list.