30 June 2018, 20:42 | #1 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
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. |
30 June 2018, 21:06 | #2 |
Bug hunter
Join Date: Jul 2006
Location: Italy
Age: 48
Posts: 2,171
|
Works so good and stable using WB now!
PPaint issue fixed too, confirmed. |
30 June 2018, 21:34 | #3 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,385
|
FAcos(1) is still not exactly 0.0 in 80 bit non-Jit mode. All other modes are ok.
|
01 July 2018, 08:09 | #4 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Quote:
No? |
|
01 July 2018, 11:40 | #5 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,385
|
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.
|
01 July 2018, 18:38 | #6 | |
Registered User
Join Date: Aug 2016
Location: Earth
Posts: 891
|
Quote:
I haven't used Admin with Windows 7 x64 in a long time. But that also does fine so far. |
|
02 July 2018, 15:58 | #7 | ||
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,385
|
Quote:
Quote:
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}; 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. |
||
02 July 2018, 21:12 | #8 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Quote:
Code:
static uae_u32 pihalf[] = {0x2168c235, 0xc90fdaa2, 0x3fff}; Temporarily attached here because winuae (eab) ftp refuses connection. Last edited by Toni Wilen; 03 July 2018 at 08:30. |
|
02 July 2018, 21:44 | #9 | |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,385
|
No, I didn't want to blame you. It was me, I'm guilty!
Quote:
My test should give 0 for all lines with ACOS(1) and Pi for all with ACOS(-1). |
|
03 July 2018, 08:32 | #10 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Quote:
|
|
03 July 2018, 09:29 | #11 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,385
|
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. |
03 July 2018, 12:09 | #12 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
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)
|
03 July 2018, 21:07 | #13 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
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. |
06 July 2018, 08:44 | #14 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,385
|
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(®s.fpcr)); and_l_ri (S1, 0xf0); /* restore control word */ fldcw_m_indexed (S1, uae_p32(x86_fpucw)); break; } #endif facos_rr (dreg, sreg); break; Code:
mov_l_rm (S1, uae_p32(®s.fpcr)); and_l_ri (S1, 0xf0); /* restore control word */ Code:
mov_l_ri (S1, (regs.fpcr & 0xF0)); |
06 July 2018, 11:22 | #15 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Quote:
Quote:
|
||
06 July 2018, 16:24 | #16 | |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,385
|
Quote:
Code:
case 0x1c: /* FACOS */ #if USE_X86_FPUCW { mov_l_rm (S1, uae_p32(®s.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(®s.fpcr)); and_l_ri (S1, 0xf0); /* restore control word */ fldcw_m_indexed (S1, uae_p32(x86_fpucw)); break; } #endif facos_rr (dreg, sreg); break; |
|
06 July 2018, 21:09 | #17 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
What do you exactly mean? I am not going to do anything unclear, only guaranteed fixes in 4.0.1.
|
06 July 2018, 23:43 | #18 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,385
|
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. |
08 July 2018, 12:12 | #19 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
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 ) |
08 July 2018, 12:29 | #20 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,385
|
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. |
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 |
|
|