Loonies' "Hotstyle Takeover" breaks on 3.5.0 - Page 2

amilo3438 · 15 September 2017, 16:51

Quote:

Originally Posted by amilo3438

WinUAE 3.4.1b1 (2017.02.11) - fine
WinUAE 3.4.1b2 (2017.02.25) - fine
WinUAE 3.4.1b3 (2017.03.13) - problem -> http://eab.abime.net/showpost.php?p=...7&postcount=29
WinUAE 3.4.1b4 (2017.03.25) - problem
WinUAE 3.4.1b5 (2017.04.02) - problem

PS. Btw. find test config I used for this demo in "The Zone"! (works w/o glitches)

So it starts from 3.4.1b3...
Hmm, I wonder if the problem has something with: "- Final MSVC 2017 compiled".
(because it doesn't happen on newer CPU - as Toni probably have!?)

Toni Wilen · 15 September 2017, 16:55

Quote:

Originally Posted by StingRay

Is it possible to set breakpoints on register conditions? So that I could f.e. trigger a breakpoint when loopcounter (d7) contains a certain value.

"fo" (listed in debugger help)

Does softfloat mode crash identically?

Quote:

So it starts from 3.4.1b3...

First versions had huge amount of FPU related changes. Don't jump to conclusions so soon.

amilo3438 · 15 September 2017, 17:01

Quote:

Originally Posted by Toni Wilen

First versions had huge amount of FPU related changes. Don't jump to conclusions so soon.

I just wonder because you mentioned in the post#8 that you cannot duplicate the problem!
(hmm, so just wonder how is that possible)

Can you try to test again with configuration I used in post #18 !? (In the zone.)
(In df0 mount WB3.1 and as HD archive mount the demo file - start the demo from workbench)

StingRay · 15 September 2017, 17:07

Quote:

Originally Posted by Toni Wilen

"fo" (listed in debugger help)

Yeah, I just found the "fo" command too when checking debugger help.

Quote:

Does softfloat mode crash identically?

No, in softfloat mode there is no crash.

amilo3438 · 15 September 2017, 17:28

With my test configuration:

- If "FPU support" is off = get guru 8000 0006.
- If "FPU support" is off but Softfloat is on = it works fine.

Tested in 3600b4. (get same also if tested on the 1st problematic WinUAE 3.4.1b3 2017.03.13)

Foebane · 15 September 2017, 18:03

Could there be a faulty part of the FPU code affecting the 3D animation (jumping around the screen) and causing the crash at the tunnel? This whole situation reminds me of the Pentium FDIV bug.

amilo3438 · 15 September 2017, 18:15

Quote:

Originally Posted by Foebane

Could there be a faulty part of the FPU code affecting the 3D animation (jumping around the screen) and causing the crash at the tunnel? This whole situation reminds me of the Pentium FDIV bug.

You have a test at the bottom of the link you gave...
In Windows calculator my cpu pass the test.

Foebane · 15 September 2017, 18:24

I passed the test too. I just thought the situation was similar: a bug in floating-point code.

ross · 15 September 2017, 19:11

Code:

HH
  D0 00000068   D1 00000000   D2 00000002   D3 00000008 
  D4 00000022   D5 00000020   D6 0000000A   D7 4741C3FC 
  A0 47456EA4   A1 4755BB98   A2 47CACFF8   A3 47CACBF8 
  A4 47454220   A5 4741708C   A6 47C9D1F8   A7 4742080C 
USP  4742080C ISP  00202350 SFC  00000000 DFC  00000000 
CACR 00002111 VBR  00000000 CAAR 00000000 MSP  00000000 
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
0: 400F-FC42DE9C-EE7A2000 #1.291577e+05 C00F-B7160000-00000000 #9.374000e+04 
2: FFFF-7FFFFFFF-FFFFF800 -nan FFFF-7FFFFFFF-FFFFF800 -nan 
4: FFFF-7FFFFFFF-FFFFF800 -nan FFFF-7FFFFFFF-FFFFF800 -nan 
6: FFFF-7FFFFFFF-FFFFF800 -nan FFFF-7FFFFFFF-FFFFF800 -nan 
FPSR: 00000080 FPCR: 00000090 FPIAR: 009fae1e N=0 Z=0 I=0 NAN=0
Prefetch 47449110 15812800 (1) e6a1 (1) 1581 (1) 2800 (1)
4744910C 6de4                     BLT.B #$e4 == $474490f2 (F) <-- demo code
  D0 FFFFF0C1   D1 00000004   D2 00000000   D3 00000000 
  D4 00000000   D5 FFFFFFFA   D6 00000000   D7 8000000B 
  A0 00000104   A1 00000000   A2 474665E0   A3 00000000 
  A4 474665E0   A5 00202308   A6 FBE90779   A7 00202308 
USP  4742079C ISP  00202308 SFC  00000000 DFC  00000000 
CACR 00002111 VBR  00000000 CAAR 00000000 MSP  00000000 
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=7 STP=0
0: 4002-C0000000-00000000 #1.200000e+01 0000-00000000-00000000 #0.000000e+00 
2: 3FFF-E7DFD700-00000000 #1.811519e+00 C00F-9036587D-82A55000 #7.383669e+04 
4: 3FFF-A0000000-00000000 #1.250000e+00 4000-80000000-00000000 #2.000000e+00 
6: C000-B2B22ECA-62213800 #2.792125e+00 BFF9-9A563692-94459000 #1.883994e-02 
FPSR: 04000088 FPCR: 00000090 FPIAR: 4744be44 N=0 Z=1 I=0 NAN=0
Prefetch 009fd844 fff63039 (2) fff6 (1) 3039 (1) fff6 (1)
009FD842 51c8 fff6                DBF .W D0,#$fff6 == $009fd83a (F) <-- reloc OS39 EXEC 45.20
  D0 00000002   D1 00000020   D2 00000000   D3 00000000 
  D4 00000000   D5 FFFFFFFA   D6 00000000   D7 0000E490 
  A0 00DFF000   A1 00000000   A2 474665D0   A3 00000000 
  A4 474665D0   A5 00000000   A6 01FF0D8F   A7 00202320 
USP  47421354 ISP  00202320 SFC  00000000 DFC  00000000 
CACR 00002111 VBR  00000000 CAAR 00000000 MSP  00000000 
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=7 STP=0
0: 4002-C0000000-00000000 #1.200000e+01 0000-00000000-00000000 #0.000000e+00 
2: 3FFF-E7DFD700-00000000 #1.811519e+00 C00F-9036587D-82A55000 #7.383669e+04 
4: 3FFF-A0000000-00000000 #1.250000e+00 4000-80000000-00000000 #2.000000e+00 
6: C000-B2B22ECA-62213800 #2.792125e+00 BFF9-9A563692-94459000 #1.883994e-02 
FPSR: 04000088 FPCR: 00000090 FPIAR: 4744be34 N=0 Z=1 I=0 NAN=0
Prefetch 04754004 00000000 (1) 0000 (1) 0000 (1) 0000 (1)
04754000 0000 0000                OR.B #$ff,D0 <-- non-mapped mem. freerun

Code:

d 474490f2
474490F2 7200                     MOVE.L #$00,D1
474490F4 1233 2800                MOVE.B (A3, D2.L*1, $00) == $00000000 [00],D1
474490F8 4c00 1800                MULL.L D0,D1
474490FC 7608                     MOVE.L #$08,D3
474490FE e6a1                     ASR.L D3,D1
47449100 1581 2800                MOVE.B D1,(A2, D2.L*1, $00) == $474665d0 [00]
47449104 5282                     ADD.L #$01,D2
47449106 0c82 0000 0400           CMP.L #$00000400,D2
4744910C 6de4                     BLT.B #$e4 == $474490f2

Toni Wilen · 16 September 2017, 11:34

Please explain..

ross · 16 September 2017, 14:50

Quote:

Originally Posted by Toni Wilen

Please explain..

These are the crash triggering events.
This is a cut from StingRay's snippet:

Code:

47449A3C f200 00a0                FDIV.X FP0,FP1
47449A40 4cf7 000b 5806           MOVEM.L (A7, D5.L*1, $06) == $474206d8,D0-D1/D3
47449A46 2c71 1400                MOVEA.L (A1, D1.W*4, $00) == $474693d8 [00000000],A6
47449A4A 2401                     MOVE.L D1,D2
47449A4C 3ccb                     MOVE.W A3,(A6)+ [0000]
47449A4E e180                     ASL.L #$08,D0
47449A50 3cc3                     MOVE.W D3,(A6)+ [0000]

D1 is negative and need to be positive (a1 is an array of pointers): a6 got wrong values and normally the first wrong value is $2.
Then successive (A6)+ cover chip ram with some A3/D3 values (repeating).

Usually (on my config.) the loop is over and the crash is in another loop (see my previous message), depends on scan lines remaining to VBL.

At this point the memory is corrupted and the VBL Exec code scheduler grab A5=$0 and jmp to chip RAM.
After some instruction an illegal is encountered, vector table is corrupted from previous write and jmp to non-mapped ram (and a freerun start..).

I did not check why D1 got a negative and makes all the successive issues.

ross · 16 September 2017, 15:55

Well, there isn't to much FPU instructions in loop, only a few

FMOVE

and

FDIV.X fp0,fp1

so the problem highly likely to be here

Toni Wilen · 16 September 2017, 19:48

I can duplicate this, I just misunderstood what "tunnel sequence" means..

Seems to be rounding related as usual and there is again some native/6888x difference (there is always some differences).

Foebane · 16 September 2017, 20:50

Quote:

Originally Posted by Toni Wilen

I can duplicate this, I just misunderstood what "tunnel sequence" means..

Sorry, my bad, I didn't describe more precisely, seeing as there's a few tunnel sequences of different kinds in the whole demo. I meant the large blue tunnel with the quotation at the beginning, right after the title screen.

Foebane · 19 September 2017, 18:30

Any fixes yet?

Toni Wilen · 20 September 2017, 21:23

Quote:

Originally Posted by ross

These are the crash triggering events.
This is a cut from StingRay's snippet:

Problem is not there. It happens previously in a loop that has 10+ FPU instructions, probably some pre-calculation.

I logged FDIV values and compare native vs softfloat. Very first FDIV in above loop had totally different second parameter (100x+ larger) in native mode.

Quote:

Originally Posted by Foebane

Any fixes yet?

No. And so far it seems there is nothing obvious to fix without breaking other programs. Rounding/precision modes have always been problematic when using native FPU via C functions because it can't match real 6888x. For some strange reason it is mainly few demos that fail..

Foebane · 20 September 2017, 21:32

Quote:

Originally Posted by Toni Wilen

And so far it seems there is nothing obvious to fix without breaking other programs. Rounding/precision modes have always been problematic when using native FPU via C functions because it can't match real 6888x. For some strange reason it is mainly few demos that fail..

So there is nothing you can do, and this demo will become one of the problematic ones that should be included in the thread "Problematic Demos" here (If it hasn't been already, that is)?

Toni Wilen · 22 September 2017, 21:37

Problem found. Some C-library trigonometric functions return bogus values if FPU rounding mode is not round to nearest.

Demo uses fsin and fcos to calculate some tables and cos() returned something totally wrong.

Foebane · 22 September 2017, 21:53

Cool! So it'll be working again by 3.6.0? At least you tracked down the problem, your hard work is much appreciated.

Toni Wilen · 24 September 2017, 17:01

Of course it will be in next version

15 September 2017, 17:28	#25
amilo3438 Amiga 500 User Join Date: Jun 2013 Location: EU Posts: 1,506	With my test configuration: - If "FPU support" is off = get guru 8000 0006. - If "FPU support" is off but Softfloat is on = it works fine. Tested in 3600b4. (get same also if tested on the 1st problematic WinUAE 3.4.1b3 2017.03.13) Last edited by amilo3438; 15 September 2017 at 17:42.

16 September 2017, 15:55	#32
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,474	Well, there isn't to much FPU instructions in loop, only a few FMOVE and FDIV.X fp0,fp1 so the problem highly likely to be here Last edited by ross; 14 November 2017 at 22:54.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
"Voices8" 8 Channel Soundtracker "DemoSongI" song - "This is the Amiga with 8 Voices"	DemosongIHunter	request.Music	45	23 May 2022 20:07
"Screech!! v2.41" & "Screech!! [AGA] v2.51" - "HD install" --> "ADFs"	DamienD	request.Old Rare Games	45	15 June 2020 12:42
"Reminder "Lincs Amiga User Group aka "LAG" Meet Sat 5th of January 2013"	rockape	News	4	30 January 2013 00:06
CD32 Image-Name-Bug: "...(bla)[!].zip" -> "...(bla)[" / "...[test].zip" -> "...[tes"	cfTrio	support.WinUAE	8	18 December 2012 16:31
Problems with "Thespywholovedme", "Flood", "Shinobi"	sareks	support.Games	12	03 May 2006 14:52

15 September 2017, 18:03	#26
Foebane Banned Join Date: Sep 2011 Location: Cardiff, UK Age: 51 Posts: 2,871	Could there be a faulty part of the FPU code affecting the 3D animation (jumping around the screen) and causing the crash at the tunnel? This whole situation reminds me of the Pentium FDIV bug.

15 September 2017, 18:24	#28
Foebane Banned Join Date: Sep 2011 Location: Cardiff, UK Age: 51 Posts: 2,871	I passed the test too. I just thought the situation was similar: a bug in floating-point code.

16 September 2017, 11:34	#30
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,516	Please explain..

16 September 2017, 19:48	#33
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,516	I can duplicate this, I just misunderstood what "tunnel sequence" means.. Seems to be rounding related as usual and there is again some native/6888x difference (there is always some differences).

19 September 2017, 18:30	#35
Foebane Banned Join Date: Sep 2011 Location: Cardiff, UK Age: 51 Posts: 2,871	Any fixes yet?

22 September 2017, 21:37	#38
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,516	Problem found. Some C-library trigonometric functions return bogus values if FPU rounding mode is not round to nearest. Demo uses fsin and fcos to calculate some tables and cos() returned something totally wrong.

22 September 2017, 21:53	#39
Foebane Banned Join Date: Sep 2011 Location: Cardiff, UK Age: 51 Posts: 2,871	Cool! So it'll be working again by 3.6.0? At least you tracked down the problem, your hard work is much appreciated.

24 September 2017, 17:01	#40
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,516	Of course it will be in next version

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