WinUAE 5.0.0 beta series (was 4.10.2)

[Toni Wilen]

It is working correctly.

Agnus DMA limit is now configurable (Advanced chipset panel) and by default restricted by chip model.

OCS Agnus with 1M chip is possible in real world but OCS Agnus can still only access first 512k of it.

But if these kinds of "bad" configurations really exist, it probably is good idea to adjust DMA limit if old config is loaded with OCS Agnus configured.

[kremiso]

sound like an achievement, i mean wasn't the game itself supposed to work in past with that config, like is doing instead?

Originally Posted by Toni Wilen

Agnus DMA limit is now configurable (Advanced chipset panel) and by default restricted by chip model.

so if i set an OCS system with more than 512KB Chip RAM, the [1MB/0.5+0.5] option in the advanced chipset panel will be disabled like in the pic?
or its another thing that i need to select/deselect, to change the DMA limit?

[Toni Wilen]

Originally Posted by kremiso

sound like an achievement, i mean wasn't the game itself supposed to work in past with that config, like is doing instead?

Technically it is correct. No OCS Agnus can address more than 512k Chip RAM even if there are more RAM that looks like Chip RAM.

so if i set an OCS system with more than 512KB Chip RAM, the [1MB/0.5+0.5] option in the advanced chipset panel will be disabled like in the pic?
or its another thing that i need to select/deselect, to change the DMA limit?

Set second auto to >512k. Or wait for next beta, I'll change default option to match Agnus addressing capatibility with selected Chip RAM size. Even if it is technically wrong.

[kremiso]

oh great, it would be awesome for my crazy attempts
thank you very much as always!

[Toni Wilen]

https://download.abime.net/winuae/fi...uae_41020b3.7z
https://download.abime.net/winuae/fi...e64_41020b3.7z

Beta 3:

- Changed keyboard reset warning again: when reset keys are pressed, reset warning starts, when reset warning ends, system is reset but reset is kept active until at least one key is released. Keeping reset keys pressed more than 5 seconds force hard reset like non-reset warning config already did. Both keyboard reset modes now work identically.
- Programmed mode "do not include hidden lines" (b1) removed one too many line, breaking some programmed modes interlace field order.
- Interlace automatic LOF toggle cycle was still using pre-4.9 horizontal position origin. (Toggled 3 cycles too early, correct position is cycle 1 of line 0)
- LOL (NTSC long line) was toggled 1 cycle too early. Both LOF and LOL toggle when HPOS=1.
- COPJMP1+COPJMP2 strobe when Copper DMA is off stops the copper: this was not correct, if both strobes are generated, Copper instruction pointer is loaded with COP1PT OR'd with COP2PT. This usually indirectly stops the copper because it will sooner or later does MOVE to "dangerous" register. This is same address OR behavior as any other DMA pointer if more than one gets activated in same cycle (for example refresh + bitplane conflict). This was done before logic analyzer checks and was forgotten..
- HAM5/HAM7 was incorrectly allowed in AGA mode (broken probably in 4.9?). AGA only enables HAM if 6 or 8 planes.
- Disk image was accidentally opened twice, preventing disk image deletion/editing without closing WinUAE (b1)
- When disk image is ejected using GUI, close image file handle immediately (previously it was closed after returning back to emulation)
- Mounting exe as HD floppy image created broken disk structure if file was larger than 1329664 bytes. Bitmap block used original DD block location but was allocated after HD root block.
- Filter mode "default" now always scales if programmed chipset display mode.
- Debugger breakpoints are now also reported when single stepping (f and fo etc), previously trace override other breakpoint detection.
- Debugger wf didn't fill in binary mode.
- GVP 2040 original ROM image added (No 68060 support). "tekscsi2.device 1.1 (17.4.95)". Filesystem loader has serial debugging enabled. Updated 68060 variant is "tekscsi2.device 1.0 (27.8.95)". For some reason newer version has 1.0 in version string but device internal version is still 1.1.
- Changed new Agnus Chip RAM max addressing advanced chipset option: default equals Chip RAM size. Forcing 512k when OCS can break old configs and cause confusion and result will look like new emulation bug.
- 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)

Probably getting close to final release. Possibly. I did promise to have OCS lores/hires mid screen changes fully emulated in 5.0 but does look like it is not going to happen, it needs major changes that I am not sure I want to change, at least until much later.

[chip]

Thanks for the incredible work

Waiting for the final release

[Waccoon]

I encountered a problem with the SmoothCopper demo and the updated custom.cpp::VHPOSW_delayed() function.

It works fine with a stock 68000 @ 7.1 MHz, but if the CPU is running too fast, hnew and hpos can end up being the same value, which results in hdiff being equal to zero. This causes the emulation to freeze as the hdiff loop never breaks.

I haven't looked into this so I can't say where the sanity check needs to be made, either before or in the call to VHPOSW_delayed().

[Toni Wilen]

Originally Posted by Waccoon

I encountered a problem with the SmoothCopper demo and the updated custom.cpp::VHPOSW_delayed() function.

It works fine with a stock 68000 @ 7.1 MHz, but if the CPU is running too fast, hnew and hpos can end up being the same value, which results in hdiff being equal to zero. This causes the emulation to freeze as the hdiff loop never breaks.

I haven't looked into this so I can't say where the sanity check needs to be made, either before or in the call to VHPOSW_delayed().

Fixed. Loop was supposed to be skipped if nothing changed. It disappeared when hpos becoming >= maxhpos was added later.

[Zarnal]

Originally Posted by Toni Wilen

Probably getting close to final release. Possibly. I did promise to have OCS lores/hires mid screen changes fully emulated in 5.0 but does look like it is not going to happen, it needs major changes that I am not sure I want to change, at least until much later.

Currently, what happens when these cases arise ? Is it partially emulated accurately or are they hacks ?

[Toni Wilen]

Originally Posted by Zarnal

Currently, what happens when these cases arise ? Is it partially emulated accurately or are they hacks ?

It affects almost nothing. No program depend on this because it would mean garbage visible on real HW This is partially correctly emulated but not fully.

It is mainly feature that helps coding weird effects. It is annoying if emulator shows some resolution change effect "cleanly" but real HW shows glitches.

[Toni Wilen]

https://download.abime.net/winuae/fi...uae_41020b4.7z
https://download.abime.net/winuae/fi...e64_41020b4.7z

Beta 4:

- VHPOSW updates, copper special odd/even last cycle condition used original maxhpos value, not VHPOSW write "faked" hpos value. Do not do horizontal adjustments if CPU speed is fastest possible and/or JIT is enabled and VHPOSW access was CPU. Copper VHPOSW write is always accepted (which can only work if ECS or AGA).
- ROM rescan in ini mode didn't clear previously detected ROMs. Ini file whole section delete only deleted first entry in section.
- Added new KS ROMs to ROM scanner.
- uaegfx and hardware emulated RTG board and emulation window smaller than RTG resolution: part of right or bottom of display was clipped. (Used window size to check limits instead of internal surface size)
- Statefile restore fixes, 68020+ blitter wait hang after loading statefile, "cpu trace" error dialog shown even when there was nothing wrong.
- If reset was requested, it wasn't processed until next vsync. Between reset request and reset process CPU might have executed random data, temporarily flooding log with invalid access errors, exceptions etc.
- CIA synchronize clock drift bug fix (4.10.0)

[Phantasm]

Thanks for including the cia clock fix. It will be great to be able to update to the 4.10 codebase

[Toni Wilen]

https://download.abime.net/winuae/fi...uae_41020b5.7z
https://download.abime.net/winuae/fi...e64_41020b5.7z

Beta 5:

- Programmed mode aspect ratio correction ("VGA mode resolution autoswitch") improved. Programmed modes should now always have correct aspect (no more halved horizontal size)
- Integer scaling now automatically doubles width of display if original width is smaller than height and doubled width still fits.
- GDI mode display position might have been wrong in some situations after switching modes.
- Direct3D 11 mode world matrix coordinate handling fixed (finally, has been wrong since D3D11 mode was introduced). Scanlines etc are not anymore affected by scaling settings. Rotation (gfx_rotation) also now works correctly.
- RTG hardware sprite (mouse cursor) is now properly clipped when near edges of screen.

[vulture]

Hey Toni, weird borders since the first 4.10.2 beta

[Toni Wilen]

Originally Posted by vulture

Hey Toni, weird borders since the first 4.10.2 beta

You have "ultra extreme" debugging mode overscan mode enabled. It now marks blanking regions with grid pattern. Makes it easy to see which part of display can be visible and which part is always blanked.

EDIT: It looks like corruption in your screenshot because it does not have 1:1 pixel mapping.

[vulture]

Ah, ok thx Toni!

[Toni Wilen]

https://download.abime.net/winuae/fi...nuae_5000b6.7z
https://download.abime.net/winuae/fi...ae64_5000b6.7z

Beta 6: (Official: somewhere May 2023)

- Bumped version to 5.0. No more 4.10.x versions.
- Input left/right joystick autoswitching mode is back, disabled by default, add input.autoswitchleftright=true to enable.
- Added input.advancedmultiinput config entry which currently enables inserting same input device in multiple ports (game ports panel) and in future enables multiple input devices in same game port GUI support.
- Enable also JIT FPU when JIT checkbox is getting ticked and FPU emulation (with host CPU mode) is already enabled.
- Fixed possible crash when quitting emulation when RTG mode with hardware sprite is active (b5)
- Inserting supported non-Amiga formatted disk image (for example PC DOS formatted image) in standard Amiga 3.5" DD drive was rejected, drive compatibility check didn't accept standard 3.5" DD drive. Image was accepted if drive was 3.5" HD drive. (Was probably broken when bridgeboard drive support was improved)
- Initial ROM scan window was invisible. (Not sure when it got broken or if it depends on Windows version)
- Added custom data path configuration to Paths panel. Data path = default path where config files, logs, statefiles etc are loaded and saved. This was supposed to have been added ages ago.. (previously available via command line -datapath parameter). Paths panel also now shows currently active data path.
- uaegfx internally generated modes didn't have active flag set and display parameters (total vertical/horizontal and sync lengths, values that are ignored by uaegfx) were technically invalid. Set active flag and made hor/ver totals slightly larger than visible resolution and adjusted sync values. Board type was not set to uaegfx (it was set correctly, then overwritten by wrong value) Some Picasso96 tools might have gotten confused.
- RTG hardware sprite update in b5 added caching that was not properly flushed when cursor shape was updated.

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)

[rhester72]

Originally Posted by Toni Wilen

Beta 6: (Official: somewhere May 2023)

The "Configuration files" (or Configurations? don't recall what it used to say) label before the path is now missing in the Paths pane.

[Cowcat]

There's something that affects Mediator + Voodoo driver in the last beta:

On a classic 68k-warpos emulation: When closing games set at fullscreen (like 640x480), Workbench (with a higher resolution) is only visible in a 640x480 area while the rest of the screen is black.

Emulating OS4.1 (same Mediator+Voodoo), a Workbench screen set at high resolution by default has the same problem only that it doesn't need an app or game at fullscreen to test, as it happens right at the beginning.

Both emulation situations don't have problems with Picasso IV.

Going back to beta 41020b4 this issues don't show up.

[Toni Wilen]

I can't duplicate (at least normal OS 3.1 + PCI bridge + Voodoo config). Screenshot, config file and winuaelog.txt, please.

I assume you mean from WB RTG resolution to some smaller RTG mode? (Not WB to native mode)

EDIT: I can see something similar happening if mode is GDI (not D3D9 or D3D11). Does your reported program also only happen in GDI mode? (Misc panel)