English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 30 June 2018, 20:42   #1
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,381
WinUAE 4.0.1 beta series

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.

Last edited by Toni Wilen; 01 July 2018 at 12:13.
Toni Wilen is offline  
AdSense AdSense  
Old 30 June 2018, 21:06   #2
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,071
Works so good and stable using WB now!
PPaint issue fixed too, confirmed.
hexaae is offline  
Old 30 June 2018, 21:34   #3
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,096
FAcos(1) is still not exactly 0.0 in 80 bit non-Jit mode. All other modes are ok.
PeterK is offline  
Old 01 July 2018, 08:09   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,381
Quote:
Originally Posted by PeterK View Post
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

Quote:
Originally Posted by bladecgn View Post
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?
Toni Wilen is offline  
Old 01 July 2018, 11:40   #5
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,096
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.
PeterK is offline  
Old 01 July 2018, 18:38   #6
AC/DC HACKER!
Registered User

 
Join Date: Aug 2016
Location: DigitalCorruption/iNT
Posts: 136
Quote:
Originally Posted by bladecgn View Post
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.
AC/DC HACKER! is offline  
Old 02 July 2018, 15:58   #7
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,096
Quote:
Originally Posted by Toni Wilen View Post
This now uses round to zero temporarily. But you still need to recheck every one of them again
Quote:
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).
Code:
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.

Last edited by PeterK; 02 July 2018 at 16:22.
PeterK is offline  
Old 02 July 2018, 21:12   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,381
Quote:
Originally Posted by PeterK View Post
Please, disable the forced "round to zero" in Jit and non-Jit again
I never changed JIT round to zero..

Code:
static uae_u32 pihalf[] = {0x2168c235, 0xc90fdaa2, 0x3fff};
Changed.

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

Last edited by Toni Wilen; 03 July 2018 at 08:30.
Toni Wilen is offline  
Old 02 July 2018, 21:44   #9
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,096
Quote:
Originally Posted by Toni Wilen View Post
I never changed JIT round to zero..
No, I didn't want to blame you. It was me, I'm guilty!

Quote:
Code:
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).
Attached Files
File Type: lha TestAcos.lha (1.1 KB, 12 views)
PeterK is offline  
Old 03 July 2018, 08:32   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,381
Quote:
Originally Posted by PeterK View Post
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.
Toni Wilen is offline  
Old 03 July 2018, 09:29   #11
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,096
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.
PeterK is offline  
Old 03 July 2018, 12:09   #12
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,381
Quote:
Originally Posted by bladecgn View Post
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 is offline  
Old 03 July 2018, 21:07   #13
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,381
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.
Toni Wilen is offline  
Old 06 July 2018, 08:44   #14
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,096
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:
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
Code:
mov_l_rm (S1, uae_p32(&regs.fpcr));
and_l_ri (S1, 0xf0); /* restore control word */
by just one instruction
Code:
mov_l_ri (S1, (regs.fpcr & 0xF0));
PeterK is offline  
Old 06 July 2018, 11:22   #15
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,381
Quote:
Originally Posted by PeterK View Post
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.

Quote:
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.
Toni Wilen is offline  
Old 06 July 2018, 16:24   #16
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,096
Quote:
Originally Posted by Toni Wilen View Post
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":
Code:
			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.
PeterK is offline  
Old 06 July 2018, 21:09   #17
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,381
What do you exactly mean? I am not going to do anything unclear, only guaranteed fixes in 4.0.1.
Toni Wilen is offline  
Old 06 July 2018, 23:43   #18
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,096
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.
PeterK is offline  
Old 08 July 2018, 12:12   #19
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,381
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 )
Toni Wilen is offline  
Old 08 July 2018, 12:29   #20
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,096
Did you copy the change to WinUAE.7z already?
The contents is still from yesterday 21:06 and doesn't fix it.

Last edited by PeterK; 08 July 2018 at 14:07. Reason: Moved the new comment to a new posting.
PeterK is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
WinUAE 3.6.0 beta series Toni Wilen support.WinUAE 410 27 January 2018 22:19
WinUAE 3.3.0 beta series Toni Wilen support.WinUAE 256 06 June 2016 15:36
WinUAE 2.4.0 beta series Toni Wilen support.WinUAE 342 29 March 2012 09:02
WinUAE 2.0.1 beta series Toni Wilen support.WinUAE 14 22 December 2009 18:46
WinUAE 1.6.1 beta series Toni Wilen support.WinUAE 54 18 June 2009 11:05

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 03:41.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.08748 seconds with 14 queries