WinUAE 4.0.0 beta series

[mark_k]

Here's some more info on the "debug blob" location issue I mentioned. With 16 slices, 3× scaling on 2160-line screen, so each non-interlaced Amiga scanline corresponds to 6 lines on screen.

Table of blob vertical positions:

Line#	Diff.from prev.
206	-
644	438
734	90
824	90
...	...
1814	90
1904	90

So there's the large gap between the top two blobs. Gaps between the other blobs are all identical.

The Amiga display is 574 lines so occupies 574×3 = 1722 lines on the monitor. Thus there are 2160-1722 = 438 unused lines on monitor. Is it a coincidence that 438 is exactly the number of lines between the top two blobs?

[Toni Wilen]

http://www.winuae.net/files/b/winuae_4000b11.7z
http://www.winuae.net/files/b/winuae64_4000b11.7z

Beta 11:

- D3D11 fullscreen mode after alt-tab/gui was not restored properly if emulation was in paused state.
- D3D9 lagless vsync partial updates (introduced in b5) used incorrect (full, D3DLOCK_DISCARD) texture update mode.
- Decrease/increase emulation speed input events didn't do anything.
- Power led dim config option is now integer (0 = fully off, 1 to 100 = brightness level)
- Hardware emulated graphics boards didn't update properly without enabled OSD led (uaegfx was already fixed in b9)
- A2410 didn't support multiple monitor mode.
- Merged Aranym JIT updates.
- Fixed old (since the beginning?) JIT bug: many instructions always cleared V-flag (ADDX, SUBX, NEGX, BTST/BCHG/BCLR/BSET, possibly others). Fix by Thorsten Otto.

[mark_k]

With beta 11, if you start emulation in full-screen D3D11 mode, press F12 then click Quit, WinUAE returns to full-screen mode for a moment before returning to desktop and exiting. Beta 10 was OK.

[PeterK]

•Host mode FPU emulation is finally full extended precision (80-bit) capable. It is also fully JIT compatible.

Two very rarely used things are not yet implemented in the Jit FPU code in comp_fp_get():

1.) "packed decimal real format", fallback at line 67 in comemu_fpp.cpp

2.) some PC relative addressing modes at line 141:

case 3: /* (d8,PC,Xn) or (bd,PC,Xn) or ([bd,PC,Xn],od) or ([bd,PC],Xn,od) */
return -1; /* rarely used, fallback to non-JIT */

And at line 274 in comp_fp_put():

1.) size=3 Packed-Decimal Real with Static k-Factor (P{#k})

2.) size=7 Packed-Decimal Real with Dynamic k-Factor (P{Dn})


Maybe, Aranym or other emulators have that Jit code already implementd?

[mark_k]

The slice position change first occurred (or rather, seemed to get worse) with beta 5.

I took some screenshots to show the differences between b4 and b11 with 4, 8 and 16 slices. Beta 4 didn't have "debug blobs", but due to the slice position bug you can see where the slices are.

http://www.media!fire.com/file/48i82v5saw9esm3/WinUAE_2018-05-22.7z

The change is probably due to this commit: Use scaled display start position when calculating lagless vsync slice positions

static void linesync_first_last_line(int *first, int *last)
 {
+	int x, y, w, h;
 	*first = minfirstline;
 	*last = maxvpos_display;
+	get_custom_raw_limits(&w, &h, &x, &y);
+	if (y > 0)
+		*first += y;
 }

[Toni Wilen]

Originally Posted by PeterK

Two very rarely used things are not yet implemented in the Jit FPU code in comp_fp_get():

1.) "packed decimal real format", fallback at line 67 in comemu_fpp.cpp

2.) some PC relative addressing modes at line 141:

And at line 274 in comp_fp_put():

1.) size=3 Packed-Decimal Real with Static k-Factor (P{#k})

2.) size=7 Packed-Decimal Real with Dynamic k-Factor (P{Dn})


Maybe, Aranym or other emulators have that Jit code already implementd?

Aranym does not, no idea if there are any others. It seems Aranym has become "master" version of 68k JIT since few years ago.

Anyway, no one uses packed decimal format and it still would be really slow, JIT or no JIT.

Originally Posted by mark_k

The slice position change first occurred (or rather, seemed to get worse) with beta 5.

winuae.7z has some extra logging. (include complete log, non-complete log makes it difficult to be sure what is exactly going on because same lines can appear multiple times).

Also try other resolutions and/or filter settings.

[AMIGASYSTEM]

Ciao Toni, i do not know if it depends on my system, with Beta 11 if you start WinUAE by default without any HD or Floppy WinUAE go to Crash (use WinUAE 32Bit Direct3D 9 and other beta do not have the problem)

[Toni Wilen]

Originally Posted by AMIGASYSTEM

Ciao Toni, i do not know if it depends on my system, with Beta 11 if you start WinUAE by default without any HD or Floppy WinUAE go to Crash (use WinUAE 32Bit Direct3D 9 and other beta do not have the problem)

That should be 100% obvious. Why would I release beta that is known to crash!?

-> Not enough information.

[AMIGASYSTEM]

Excuse me Toni i did not understand what you wrote, i attach Log and Dmp, i started WinUAE with QuickStart A1200 Basic nothing HD, nothing floppy, nothing added configuration.

I would like to clarify that if I configure Direct3D 9 in "Graphics API" nothing happens and nothing crashes.

[PeterK]

2.) some PC relative addressing modes at line 141:

Toni, what do you think about the following approach, a mixture from the An relative code at line 113 and the PC relative code at line 133. I hope it's allowed to use S3 for the address. This code is not tested at all, since I have no dev system installed.

case 3: /* (d8,PC,Xn) or (bd,PC,Xn) or ([bd,PC,Xn],od) or ([bd,PC],Xn,od) */
{
	uae_u32 address = start_pc + ((uae_char*) comp_pc_p - (uae_char*) start_pc_p) + m68k_pc_offset;
	uae_u32 dp = comp_get_iword ((m68k_pc_offset += 2) - 2);
	mov_l_ri (S3, address);
	calc_disp_ea_020 (S3, dp, S1, S2);
	break;
}

[Toni Wilen]

Originally Posted by AMIGASYSTEM

Excuse me Toni i did not understand what you wrote, i attach Log and Dmp, i started WinUAE with QuickStart A1200 Basic nothing HD, nothing floppy, nothing added configuration.

I would like to clarify that if I configure Direct3D 9 in "Graphics API" nothing happens and nothing crashes.

You forgot to mention that you get that dialog message which only happens if D3D11 + Windows 7 without some updates.

Anyway, dump helped to find the problem. winuae.7z should fix it.

Originally Posted by PeterK

Toni, what do you think about the following approach, a mixture from the An relative code at line 113 and the PC relative code at line 133. I hope it's allowed to use S3 for the address. This code is not tested at all, since I have no dev system installed.

case 3: /* (d8,PC,Xn) or (bd,PC,Xn) or ([bd,PC,Xn],od) or ([bd,PC],Xn,od) */
{
	uae_u32 address = start_pc + ((uae_char*) comp_pc_p - (uae_char*) start_pc_p) + m68k_pc_offset;
	uae_u32 dp = comp_get_iword ((m68k_pc_offset += 2) - 2);
	mov_l_ri (S3, address);
	calc_disp_ea_020 (S3, dp, S1, S2);
	break;
}

At least "fmove.x something(pc,d0.l),fp0" works (and new code was executed once) but I am not interested in testing any more complex address modes.. winuae.7z includes this change but it needs much more testing before it will appear in any more official versions.

[AMIGASYSTEM]

Originally Posted by Toni Wilen

You forgot to mention that you get that dialog message which only happens if D3D11 + Windows 7 without some updates.
.

Yes, the message only exits on a configuration "New", on the configurations saved with setting Dirct3D 9 no request appears. At the moment i do not want to update Win7 to Sp1, so i can not use Direct3D 11

Anyway, dump helped to find the problem. winuae.7z should fix it.

Ok with winuae.7z Resolved the problem no crash, thanks Toni

[PeterK]

Originally Posted by Toni Wilen

At least "fmove.x something(pc,d0.l),fp0" works (and new code was executed once) but I am not interested in testing any more complex address modes.. winuae.7z includes this change but it needs much more testing before it will appear in any more official versions.

I have to write some small tests for the PC relative addressing modes, since nobody seems to use them.

Meanwhile I found another older FPU bug in ZoneXplorer as reported in the Imagine thread, but I don't know how the correct result should look like.

[Dr.Venom]

I was finally able to test the Lagless VSync (Beamraced) on my CRT setup.

It works great, thanks a lot for implementing this .

But there's one BIG problem, it even works flawless when using the max of 29 slices, so we need more slices! I'm curious to how many slices can be used without it causing issues. Maybe a "custom" option in the list view can be added?

On my CRT setup I use a custom resolution of 744x287 for WinUAE with D3D11 (D3D9 doesn't work as well). For what it's worth, the GPU is a "modest" MSI HD6850 Cyclone with a custom bios that sets the power profile to always use max GPU clock.

[Toni Wilen]

The usual way: edit config file manually.

[PeterK]

Originally Posted by Toni Wilen

At least "fmove.x something(pc,d0.l),fp0" works (and new code was executed once) but I am not interested in testing any more complex address modes.. winuae.7z includes this change but it needs much more testing before it will appear in any more official versions.

All PC relative modes are tested now and are working fine. Every test is done 10 times with 3 different constants and 3 registers. The output shows the constant directly and then the 4 PC relative results. It needs 5 and a half passes before the Jit code gets executed. You can see that with the 64 bit host.

[Dr.Venom]

Originally Posted by Toni Wilen

The usual way: edit config file manually.

Great, I'll give that a try.

[Toni Wilen]

http://www.winuae.net/files/b/winuae_4000b12.7z
http://www.winuae.net/files/b/winuae64_4000b12.7z

1-2 weeks to go, some fixes remaining..

Beta 12:

- Don't allow lagless vsync in normal windowed mode.
- Hide lagless vsync slice count in GUI if lagless vsync is not selected.
- Fixed crash if screen mode open failed and error dialog was shown. (b11)
- D3D11 fullscreen mode opened in primary monitor if selected non-default monitor was connected to another GPU.
- New debugger didn't load 3.1 (and probably older) amiga.lib files.
- Added debugger_options config entry, currently only supported sub entry is pathprefix=x where x is string that gets appended to stabs source file paths.
- Try harder to find working path for stabs source files and when working path combination is found, remember it instead of enumerating all possible variants every time source file is loaded.
- uaedbg now breaks to debugger when debugged application causes unhandled exception via tc_TrapCode.

[Dr.Venom]

Originally Posted by Toni Wilen

http://www.winuae.net/files/b/winuae_4000b12.7z
http://www.winuae.net/files/b/winuae64_4000b12.7z

1-2 weeks to go, some fixes remaining..

Thanks for another beta, 4.0 is going to be one awesome release (if not the greatest release ever) .

Not sure if it's on your radar still, but did you have a chance to take a closer look at the synchronization / swapping method for (forced) 60hz screens we talked about earlier (see here)? It would be much appreciated if you could..

Of course nothing will beat the lagless vsync on the 50hz desktop setup, but hopefully it'll provide a decent way of enjoying WinUAE when on the road. It still irks me why those portable devices (at least the ones I used) don't allow for 50hz refresh rates.

The best thing would be when the "next best" vblank swapping would not be THAT noticable on slower scrolling games, but would allow for the very low input latency... Just curious whether or not it would look any decent or not.

[Toni Wilen]

I am not yet sure if it is possible without too many changes.

It is not that trivial because it would be simultaneously partially vsync and partially not vsync. At least it needs new option because vsync always means "sync emulation speed to refresh rate". ("lagless non-vsync"..)