WinUAE 4.0.1 beta series

[Toni Wilen]

4.0.1 beta series. This is quick mainly bug fixes only release. 1-2 weeks to go. EDIT: GUI won't change, so 4.0.0 translations will keep working.

This thread is only for 4.0.0 bugs. Bug in older version: create own bug specific thread.

http://www.winuae.net/files/b/winuae_4010b1.7z
http://www.winuae.net/files/b/winuae64_4010b1.7z

Beta 1:

4.0.0 bugs fixed:

- 80-bit native FPU mode FREM and FMOD had parameters swapped in x86 code.
- 64-bit FPU mode config mode was not loaded from config file.
- "Minimize when focus is lost" could cause crashes.

Older bugs:

- "Minimize when focus is lost" incorrectly activated when switching modes in some situations. (same as above)
- If CPU panel select menu was active and then some other panel was selected: JIT got switched off.
- Don't abort with "tried to seek out of bounds" message when HDF/HD has virtual RDB and writing to too large offset.
- When inserting previously connected USB device, previous device type (Gamepad, CD32 pad etc) and autofire type (if any) was not restored.
- Do not copy data to Amiga side clipboard buffer if filesystem heartbeat signal is missing (=Some program took over the system), clipboard data can overwrite other program's data.
- Directory filesystem/UAE HDF uses indirect mode if new debugger is active. (Indirect is needed for debugger to detect memory reads and writes)
- "Minimize when focus is lost" minimized main emulation window when GUI was open and main window lost focus.
- RTG Multithread mode display refreshing was unreliable in palette modes when palette changed.

Other:

- Resolve hardfile/directory path environmental variables only when needed, loading and saving config now keeps original unresolved variables.
- Save also config file to crash dump file.
- QuikPak XP board emulation, not yet fully implemented.
- Added GVP v3.7, Blizzard 2060 v7.25 and QuikPak v2.1 to ROM scanner.

[hexaae]

Works so good and stable using WB now!
PPaint issue fixed too, confirmed.

[PeterK]

FAcos(1) is still not exactly 0.0 in 80 bit non-Jit mode. All other modes are ok.

[Toni Wilen]

Originally Posted by PeterK

FAcos(1) is still not exactly 0.0 in 80 bit non-Jit mode. All other modes are ok.

This now uses round to zero temporarily. But you still need to recheck every one of them again

Originally Posted by bladecgn

Hi! Tried the 4.0.x branch.

My 32 GF CF (RDB) is not detected / selctable any more.

Of course as always started WinUAE in admin mode. Does anyone have the same issue?

No?

[PeterK]

FACOS(1)=0 and FACOS(-1)=Pi are correct now in all modes. In 80-bit mode the LSB of Extended Precision is rounded to zero for Pi, but that's acceptable. It's more important that a zero point of a function is exactly 0.

[AC/DC HACKER!]

Originally Posted by bladecgn

Hi! Tried the 4.0.x branch.

My 32 GF CF (RDB) is not detected / selctable any more.

Of course as always started WinUAE in admin mode. Does anyone have the same issue?

I'm now using http://www.winuae.net/files/b/winuae_4010b1.7z and my 32GB CF is noticed fine. I have 2 for my A4000 CSPPC, and both are read.. Also used HDToolBox to make changes and so far, is doing as it should.

I haven't used Admin with Windows 7 x64 in a long time. But that also does fine so far.

[PeterK]

Originally Posted by Toni Wilen

This now uses round to zero temporarily. But you still need to recheck every one of them again

FACOS(1)=0 and FACOS(-1)=Pi are correct now in all modes. In 80-bit mode the LSB of Extended Precision is rounded to zero for Pi, but that's acceptable. It's more important that a zero point of a function is exactly 0.

Toni, could you compile another alternative version temporarily?

Please, disable the forced "round to zero" in Jit and non-Jit again and set the LSB in pihalf by changing the "0x2168c234" into a "0x2168c235". I can't see what might go wrong with "round to nearest" then, but that needs some investigation. If it works, it would be the cleanest solution (no forced rounding mode).

static uae_u32 pihalf[] = {0x2168c235, 0xc90fdaa2, 0x3fff};

On my current PC FASIN(1) always returns Pi/2 with the LSB set, so FACOS(1) = Pi/2 - FASIN(1) should give exactly 0.

Maybe there was some inexactness in the FPU of my Pentium II processor once when I decided to set the LSB to 0.

[Toni Wilen]

Originally Posted by PeterK

Please, disable the forced "round to zero" in Jit and non-Jit again

I never changed JIT round to zero..

static uae_u32 pihalf[] = {0x2168c235, 0xc90fdaa2, 0x3fff};

Changed.

Temporarily attached here because winuae (eab) ftp refuses connection.

[PeterK]

Originally Posted by Toni Wilen

I never changed JIT round to zero..

No, I didn't want to blame you. It was me, I'm guilty!

static uae_u32 pihalf[] = {0x2168c235, 0xc90fdaa2, 0x3fff};

Changed.
Temporarily attached here because winuae (eab) ftp refuses connection.

Thanks, the 80-bit non_Jit works correctly, even Pi/2 and Pi are exact. But the Jit is still wrong. That's somewhere at line ~1183 in compemu_fpp.cpp. Just disable the "#if USE_X86_FPUCW" code block for case 0x1c: /* FACOS */. And change pihalf in compemu_raw_x86.cpp, too.

My test should give 0 for all lines with ACOS(1) and Pi for all with ACOS(-1).

[Toni Wilen]

Originally Posted by PeterK

Thanks, the 80-bit non_Jit works correctly, even Pi/2 and Pi are exact. But the Jit is still wrong. That's somewhere at line ~1183 in compemu_fpp.cpp. Just disable the "#if USE_X86_FPUCW" code block for case 0x1c: /* FACOS */. And change pihalf in compemu_raw_x86.cpp, too.

Done. (pihalf was changed previously). Usual winuae.7z again.

[PeterK]

Great, all FPU modes are working 100 % perfectly now.

I just wonder why I once forced "round to zero", but I don't think that I made a fix for something that was not broken. There must have been a different rounding in some cases with my former Pentium II CPU from 1998. That fix seems not to be required anymore nowadays.

[Toni Wilen]

Originally Posted by bladecgn

Thanks for looking into this. Here are the requested logs from the working version.

This is strange.. Could you do another log with non-working and working versions: start winuae (as admin), don't load any config, harddrives -> click add harddrive, check if drive is listed or not. Quit. Save winuaebootlog.txt. Attach both winuaebootlog.txt logs (no other logs needed)

[Toni Wilen]

http://www.winuae.net/files/b/winuae_4010b2.7z
http://www.winuae.net/files/b/winuae64_4010b2.7z

Beta 2:

- QuikPak SCSI working. (Has same bug as tekscsi2.device 1.0: does not load RDB custom filesystems)
- 80-bit FACOS fix. Also removed old unneeded JIT FACOS workaround.
- If drive identity is read and it is CHS-only, don't enable CHS-only mode unless host OS also returns zero drive size. Some (old) Windows IDE drivers do support CHS-only drives. (3.6.0)
- Added checks to prevent crashes when running in lagless vsync under wine. (DISPLAYCONFIG_VIDEO_SIGNAL_INFO and IDXGIOutput1 not implemented)

QuikPak 4060:
- Very similar in high level compared to TekMagic, main difference is SCSI chip, 53C720 (was 53C710 in TekMagic).
- "tekscsi2.device (tekscsi2 2.1 (17.7.97) ©1997 Asimware Innovations Inc.)". Apparently v2.2 also exists.

[PeterK]

Sad, but there are still problems with FACOS(1) when the rounding mode is not the default = "round to nearest". It's impossible to get always exactly zero when you substract the rounded value of ASIN(1) from the non-rounded constant Pi/2. The result of ASIN(1) depends on the rounding mode, but Pi/2 does not.

That was the reason why I once forced a rounding mode (to zero) to fix this problem. The current solution is already perfect for the default rounding to nearest now. But for other user requested global rounding modes it's required to force "round to nearest" now in order to always get zero for FACOS(1) (or we would need different constants for Pi/2 for other modes).

The strange thing is that at the moment it only seems to be necessary for the Jit to force "round to nearest" for FACOS. The non-Jit code seems to ignore the user requested rounding mode. That could really be a general non-Jit bug ??

The new Jit code:

			case 0x1c: /* FACOS */
#if USE_X86_FPUCW
			if (regs.fpcr & 0x30) { /* not round to nearest? */
				mov_l_ri (S1, (regs.fpcr & 0xC0)); /* use round to nearest */
				fldcw_m_indexed (S1, uae_p32(x86_fpucw));
				facos_rr (dreg, sreg);
				mov_l_rm (S1, uae_p32(&regs.fpcr));
				and_l_ri (S1, 0xf0); /* restore control word */
				fldcw_m_indexed (S1, uae_p32(x86_fpucw));
				break;
			}
#endif
			facos_rr (dreg, sreg);
			break;

I just wonder whether the code for restoring the control word could be simplified at several locations by replacing the

mov_l_rm (S1, uae_p32(&regs.fpcr));
and_l_ri (S1, 0xf0); /* restore control word */

by just one instruction

mov_l_ri (S1, (regs.fpcr & 0xF0));

[Toni Wilen]

Originally Posted by PeterK

The strange thing is that at the moment it only seems to be necessary for the Jit to force "round to nearest" for FACOS. The non-Jit code seems to ignore the user requested rounding mode. That could really be a general non-Jit bug ??

Non-jit has always forced to round to nearest when executing trigonometric/logarithmic functions. 64-bit requires it because C-library function expects it (some functions return really wrong results if not round to nearest). I did the some to 80-bit when using multi-instruction code (trigonometric/logaritmic) because "wrong" mid instruction rounding would cause side-effects.

I just wonder whether the code for restoring the control word could be simplified at several locations by replacing the

It is not going to work because regs.fpcr content would become JIT compile time constant. It needs to be pointer to regs.fpcr.

[PeterK]

Originally Posted by Toni Wilen

I did the same to 80-bit when using multi-instruction code (trigonometric/logaritmic) because "wrong" mid instruction rounding would cause side-effects. ...

It is not going to work because regs.fpcr content would become JIT compile time constant. It needs to be pointer to regs.fpcr.

Ok, so it would be better to remove the if clauses completely and also use a pointer to regs.fpcr when setting the mode to "round to nearest":

			case 0x1c: /* FACOS */
#if USE_X86_FPUCW
			{ 
			mov_l_rm (S1, uae_p32(&regs.fpcr));
			and_l_ri (S1, 0xC0);  /* use round to nearest */
			fldcw_m_indexed (S1, uae_p32(x86_fpucw));
			facos_rr (dreg, sreg);
			mov_l_rm (S1, uae_p32(&regs.fpcr));
			and_l_ri (S1, 0xf0); /* restore control word */
			fldcw_m_indexed (S1, uae_p32(x86_fpucw));
			break;
			}
#endif
			facos_rr (dreg, sreg);
			break;

... and you could also remove the already disabled if(0)/else clauses and the dead code from FINTRZ where I wrote the comment that the conditions are checked at compilation time.

[Toni Wilen]

What do you exactly mean? I am not going to do anything unclear, only guaranteed fixes in 4.0.1.

[PeterK]

Hmm, what is unclear now?

The results of FACOS are perfect for round to nearest since beta2, but in Jit mode the results for round to zero are wrong now. Thus I would force rounding to nearest for FACOS to fix that.

My first fix in post #14 still checks the actual rounding mode at compile time whether it is already round to nearest. If not it takes the mode from regs.fpcr at compile time and forces it to nearest. You said, it would be better to read out regs.fpcr at execution time, which is ok, although it's very unlikely that there was a change since compile time.

So my new fix in post #16 won't check the rounding mode at compile time anymore (no if clause). Now, it always reads out regs.fpcr at execution time and forces round to nearest, even if it was already active.

The cleanup in FINTRZ should not change anything except removing dead code from the jit compilation. The current "if 0" construction leaves dead code and the "if ... else" decision is useless now. The code under "else" is always executed and thus should be called directly.

[Toni Wilen]

Ok, JIT FACOS changed again

Others are not touched until 4.0.1 is out. And yes, it should check runtime value but it isn't that important. (I didn't even notice it until now. I did say I don't want to touch JIT )

[PeterK]

Did you copy the change to WinUAE.7z already?
The contents is still from yesterday 21:06 and doesn't fix it.