Re: [hatari-devel] Re: 040/060 emulation issue with Q2

I started looking at this again today and performed a new test with the latest Win Hatari (SDL1/WinUAE build from antarctica.no).

My program still crashes in the same approx location. This is during the loading and setup of bulk integer & float data from a file format. There is no hardware-level stuff going on at this stage of the program. Just memory allocation and calculation.

The original file loader was implemented in C in a haphazard way over time and was quite messy so I recently reimplemented it from scratch in C++. This has had no impact on the crash, which suggests memory allocation is not involved since the allocation model, ownership and order of things has completely changed.

The calculations being performed however remain the same...

New information:

1) The first function in which the crash occurs is calculating polygon extents in texture space from texture UVs. This involves many calls to the standard floor()/ceil() functions but the rest is calculation internal to the function. I removed these calls and implemented them by hand - and the program continues past the crashing point, soon crashing elsewhere.

I should add that the breakpoint I set 'b pc=($8)' does not trigger for this crash, despite Hatari reporting a bus error. The debugger is configured to do so, but it doesn't seem to be happening reliably.

2) The point at which the second crash occurs is also interesting. It is interesting partly (again) because the debugger does not halt on the first breakpoint. There are several breakpoints happening in sequence and the program breaks after *many* of them have occurred.

Unknown FPU instruction F201 0003B656
2. CPU breakpoint condition(s) matched 19 times.
        pc = ( $8 )
3. CPU breakpoint condition(s) matched 3 times.
        pc = ( $c )
4. CPU breakpoint condition(s) matched 10 times.
        pc = ( $10 )

CPU=$e00fb6, VBL=4228, FrameCycles=3558, HBL=6, LineCycles=486, DSP=$583
$00e00fb6 : 48f8 ffff 0384                     movem.l   d0-d7/a0-a7,$0384.w
>

Last of all, the second crash relates to an emulator complaint about an unsupported FPU operation. As usual, the disassembler has trouble disassembling most FPU instructions so I'll need to decode this by hand to find out what it is. BTW this is true of both disassemblers, although the gaps in each are different.

$00e00fb6 : 48f8 ffff 0384                     movem.l   d0-d7/a0-a7,$038
> d $3b656
$0003b656 : f29d                               DC.W      $f29d
$0003b658 : ffca                               DC.W      $ffca
$0003b65a : f200 1528                          fsub.x    fp5,fp2
$0003b65e : f201                               DC.W      $f201
$0003b660 : 6500 f201                          bcs       $3a863
$0003b664 : 4500                               chk.l     d0,d2
$0003b666 : 2081                               move.l    d1,(a0)
$0003b668 : f23c 4538 3fe0 0000                fcmp.s    #$3fe00000,fp2

So while I'm still not exactly sure what's going on, I'm becoming more sure that there is something wrong with the new Hatari's floating point emulation (aside from the disasm gaps - the emulator is broken somehow). Perhaps specific to 881/882 operations which are no longer common in software built for 68060 devices? Or maybe some functionality that the float library calls depend on - e.g. float exceptions - and which the compiled code does not.

(Once again: real HW does not show this issue. Versions of Hatari prior to the 'new core' upgrade do not show this issue either..).

I'm short of time today but will try to look deeper next week.

(Eero - I'll try to get you a test build sometime next week which shows these issues, at least for the debugger breakpoint problem which seems to be a separate thing).

Doug.

On 4 March 2015 at 14:48, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

OK, so back to the opcode ff70, and looking at 68030 user manual chapter 10..1.3 with the format of line F instructions, it is stated that CpID 001 (bit 9 to 11) is used for 68881 and 6882, and 111 is reserved.

So, this really looks like an illegal instruction that should not be used in the 1st place. Is this handmade asm, or the result of a C compiler ?

This case was the result of the C compiler. However, I also noted that the PC addresses were incrementing by strange values in the debugger trace - too big for normal instructions ($00028092 -> $000280ce). So it may well have just run off into dead space by that point. The whole thing looks quite strange TBH.

I'll try to get something a bit more concrete later on after work.

D