Yes I got the same ;-)

Every beta series has at least one false positive, sometimes more. It is "normal". I'll just ignore it.

Good to know - won't report on it again.

Now I have a very real bug to report - happened back in b17 as well.

Quickstart A4000, Mediator 4000Mk2 + Voodoo 3 PCI, my A4000's CF mounted in a USB reader.

As soon as my system initialises the RTG system, I can't press "Reset" anymore otherwise WinUAE crashes.

Dump attached.

https://download.abime.net/winuae/fi...uae_4900b22.7z

Still some custom chipset updates to do. Most likely official release will be delayed until autumn 2021.

Beta 22:

- Copper vblank start was delayed by few cycles.
- uaegfx used unsafe (assumes unrecoverable state if invalid address) address translation function without validating the address first. Invalid VRAM address would have crashes emulated Amiga.
- "Add harddrive" tried to incorrectly guess logical geometry and didn't enable full drive mode if drive didn't already have RDB. (and it become weird and useless drive)
- Picasso96 v3.0+ uaegfx screen dragging support fixed.
- Extended window border mode joystick/mouse direction/buttons indicators fixed.
- Overscan blanking filter settings added to filter profiles.
- DMA debugger now shows AGA FMODE>0 bitplane and sprite fetch read values fully (both 32-bit and 64-bit). Previously it was always truncated to 16-bit.
- Memwatch points now fully support AGA FMODE>0 bitplane and sprite fetches.
- Memwatch log only (L) flag was not cleared when memwatch point was replaced or reset.
- Bitplane graphics wrapping around is now emulated (BPLxDAT fetch done before hsync but it is long enough to be partially visible after hsync). Normally can't happen but it can happen in bitplane DMA overrun situations or if weird programmed mode. Not fully working yet.
- Hard reset tried to free hardware emulated RTG VRAM twice causing memory corruption.

More programmed mode/normal mode special case related updates, including really weird never before used modes (Thanks to Ross again :)) Still work to do.

- Many programmed screen modes had corruption.
- Vertical now also supports wraparound (Horizontal added in b18), if vblank starts at line 0 or later (normal PAL/NTSC vblank start is last line), they will be correctly drawn after "real" last line. More lines are shown if VB starts later than normally.
- BPLCON3 EXTBLKEN (horizontal blanking) is now fully emulated and accurate. Note that ECS Denise works differently than AGA:
-* ECS Denise: ECSENA=1 + EXTBLKEN=0: blanking disabled, including vertical (except tiny blanking during hsync to keep display black level detection working), ECSENA=1 + EXTBLKEN=1 and ECSENA=0: hardwired blanking. No programmed blanking, itseems HBSTRT/HBSTOP registers don't exists in ECS Denise.
-* AGA: ECSENA=0 and ECSENA=1 + EXTBLKEN=0: hardwired blanking. ECSENA=1 + EXTBLKEN=1: HBSTRT/HBSTOP programmed horizontal blanking.
-* Note that display devices need blanked signals during part of hsync period (and vsync), it is used to set black levels, without blanking, image might become very dark or have strange colors, have strange brightness pulsing etc. This is not emulated.
- Increased internal max native display width by 2 lores pixels. ECS Denise/AGA can show 1 lores pixel more in right overscan compared to OCS. (Increased by 2 to keep display width even)
- Programmable vertical blanking is now handled accurately. VBSTOP = line when sprites are reset and first loads are done. VBSTOP+1 = first visible line. Sprites are also now emulated correctly even if VBSTRT is after vsync period. Display is now correctly blanked if vertical blank period is in visible part of display. First line of display is also adjusted depending on VBSTOP value when BEAMCON0 VARVBEN is enabled, even if other bits are not set.
- Advanced chipset "OCS H-Blank glitch" implemented (option already existed few betas ago). When enabled, first blanked line has background color visible in right border and last visible line has right border blanked. Not emulated by default because it looks really ugly and it is usually invisible when using real hardware due to overscan.
- Programmable horizontal (HSSTRT and HSSTOP) and vertical sync (VSSTRT and VSSTOP) emulation improved. Previously h/v-sync and h/v-blank was combined, now they are fully separate.

Part of below was already known previously but this time all chipset versions have been tested one by one and fully emulated now:

A1000/OCS Denise/ECS Denise last line differences:
- When A1000 Denise gets VB strobe, vertical blanking starts next line.
- When OCS Denise gets VB strobe, vertical blanking starts after 2 lines.
- When ECS Denise/AGA gets VB strobe, vertical blanking starts next line.

A1000 Agnus sends first VB strobe when current line is first line, line zero. (Which as a side-effect causes delayed vblank interrupt, interrupt is generated when line 1 starts) Other Agnus versions sends first VB strobe when current line is last line.

Bitplane DMA vertical DIW is forced closed when VB starts and sprite DMA is inhibited during all VB lines. Unless ECS/AGA and BEAMCON0 HARDDIS=1 or VARBEAMEN=1 or VARVBEN=1. (Note: DDFSTRT/STOP limits are not same, BEAMCON0 HARDDIS=1 or VARBEAMEN=1 or SHRES=1 or UHRES=1)

A1000: first blanked line is line 1. Line 0 is last visible line at the bottom of screen.
OCS Denise: first blanked line is line 1. Line 0 is last visible line at the bottom of screen. (This was not previously emulated, some programs might suddenly have different colored last line)
ECS Denise/AGA: first blanked line is line 0. Last line (312/313/262/263) is last visible line at the bottom of screen.
(Back in the CRT days last line was almost always invisible)

Normally only COLOR0 changes are visible during last line. All chipset versions have same first visible line. OCS Denise outputs 1 more visible line than ECS Denise/AGA in default PAL/NTSC modes.

Vertical blanking in this context means RGB output DAC (after Denise/Lisa) is in blanked mode. Vertical sync usually is different than vertical blanking in programmed modes.

If anyone thinks that what Toni is saying is difficult or 'weird', they have no idea how big the mess actually is ;)
Getting the hands on the programmed modes was like opening Pandora's box.

Thanks Toni!

Zomo-Sp(i)d

some scenes are corrupted.

Since b22.

Ok in real hardware. Quickstart A1200.

Note : and thank you for all your efforts. :)

Some utilities like Tiny Launcher or Amiga Boot Selector now only have a black screen.

This is not very useful information.

This should only affect 68020 cycle-exact modes. winuae.7z updated and beta will be updated in next few days.

Here is an hdf.



Type " tiny " for Tiny launcher or "abs" for Amiga Boot Selector. A1200 quickstart.


With the b22, there is a black screen, nothing is displayed but the program is executed.



Note: Tiny Launcher (pic 1), AmigaBootSelector (pic 2) when working normally.

Hi Toni


I've noticed my screen shifted to the right and at the wrong size with the latest beta.


b21 is how it used to look. b22 is now. Attached my config also.


I run WinUAE in windowed mode and playing 'ATrain' I can change the height of the WinUAE window (using mouse) and sometimes the amiga screen will resize to fit it properly (like b21), other times it won't.


When trying 'Colonization' the amiga screen was always wider and deeper than the application window and no resizing it would get it to fit.


When WinUAE boots, all the startup screens are also offset, however once at my desktop, which uses UAE Zorro III, that resizes to the application window perfectly.

Edit: I did try your "unnofficial beta" the other week and that exhibited the same problems. I didn't report it at the time as I'm not always sure if I should be using that. I did notice that it was dated 1st June so assume this problem happened between then and b21.

b22: A1200 config, KS 3.1, load original WB 3.1 adf. Move, resize or open windows or menu = intermittent 2 colour shifts/corruptions.

https://download.abime.net/winuae/files/b/winuae.7z should fix all above reported problems. Please confirm. (beta will be updated if fixed)

I confirm for Tiny Launcher, Amiga Boot Selector, Zomo Sp(i)d and workbench 3.1 issues. All is ok now.

Edit : i can't test for Dazzleman issue.

No, not working for me. I can play around with Aspect Ratio Correction to get the Amiga screen to be drawn correctly in its window, but when I resize the WinUAE windows with the mouse it returns to the small offset to the right and being too deep, as my previous example pics.

Can you duplicate without using some specific game? Like Early boot menu or booting without startup-sequence?

EDIT: I managed to duplicate it with WB 1.3 CLI screen, no need for more information anymore.

Autoscale should be fixed now. (also note that you probably need to add something like ?bleh=123 at the end of winuae.7z url or you most likely get previous version)

Yes, that seems to have fixed it.

https://download.abime.net/winuae/fi...uae_4900b23.7z

Beta 23:

- Display positioned was shifted in some programs. (b22)
- Fixed horizontal jitter in some AGA programs. (b22)
- Black screen in some programs. (b22)
- Automatic scaling fixed. (b22)
- Switching from programmed horizontal blanking back to hardwired h-blanking didn't work.
- Added Overscan option to Display panel. Overscan selection is default from previous versions. This probably will replace will TV filter options in the future. Overscan+ and Extreme are even more larger modes, only useful if programmed blanking is enabled, more details later. TV options probably need some calibration.

:-)

Toni with Beta 22/23 with AROS 68k the arrow of the mouse is not more visible, to make visible the arrow of the mouse I must use the option "Install virtual mouse driver".

Sometimes the mouse arrow is invisible even if I use the virtual mouse driver, moreover with the virtual mouse driver I cannot move the windows on the Workbench, the latter problem also happened with previous versions of WinUAE.