Re: [hatari-devel] Hatari/winuae crash

On Thu, Jul 4, 2013 at 6:53 AM, Laurent Sallafranque <laurent.sallafranque@xxxxxxx> wrote:

HI,

I've already given it a look a few month ago.
It's only because of the timings of the 68030 that are wrong (as usual)..
As this demo needs precise timings between the 68030 and the DSP (it doesn't handshake between each transfer), if the 68030 is too fast, the DSP can't finish it's work before sending it's datas (that's the case with the new core).

The new core needs good timings and probably a better BUS cycles (and the videl cycles that are not taken into account yet). That why it is too fast.
Laurent

Le 03/07/2013 22:19, Eero Tamminen a écrit :

Hi,

On maanantai 01 heinäkuu 2013, Miro Kropáček wrote:

On Mon, Jul 1, 2013 at 10:23 AM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

Could you provide details about this in a separate mail:
- Links to test binaries
- Which OS/version you use
- What Hatari build (your own / prebuild, version etc)
- what exactly crashes/when/where

My intro (http://mikro.naprvyraz.sk/files/moai.zip) crashes

Oh, it wasn't Hatari that crashes, but the demo...

on a custom
build on a x64 Linux machine (I think it can't make it even after the
Loading screen). The important thing is the winuae core, it works as
expected (minor sound issues) on the normal build.

I can reproduce it working with old UAE CPU core, and crashing [1]
with WinUAE one. That's even documented in the Hatari compatibility
document.

As there are sources for the demo and nowadays better debugging
facilities in Hatari, maybe Laurent will take a look at it.

Miro, if you want to see where it crashes, best would be re-build
the binary with symbols. Then in debugger:
- load CPU & DSP symbols at program start,
- enable history and CPU & DSP profiling, and
- set breakpoint on suitable exception vector address.

That way you get CPU & DSP backtraces for where it crashes and
see from history the last CPU & DSP instructions done before
the crash.

Tracing program (CPU & DSP) symbols may also help in debugging,
but can produce excessive amount of output.

- Eero

[1] The demo crashes while loading data, after following OS calls:
----------------
GEMDOS 0x30 Sversion()
GEMDOS 0x154 (MiNT?)
XBIOS 0x26 Supexec(0x1CA1C)
B-Trap f4f8 at 1ca40 (0x866fe60)
GEMDOS 0x154 (MiNT?)
XBIOS 0x26 Supexec(0xDFBF5C)
B-Trap f4f8 at dfbf80 (0x944f3a0)
GEMDOS 0x4A Mshrink(0x1C844, 0x88C002)
XBIOS 0x26 Supexec(0x1CD16)
XBIOS 0x68 Dsp_Lock()
XBIOS 0x80 Locksnd()
XBIOS 0x26 Supexec(0x1D6FA)
XBIOS 0x26 Supexec(0x1D4DC)
XBIOS 0x59 VgetMonitor()
GEMDOS 0x44 Mxalloc(0x57F40, 0x0)
GEMDOS 0x2F Fgetdta()
GEMDOS 0x1A Fsetdta(0x8a780c)
GEMDOS 0x20 Super(0x0)
XBIOS 0x25 Vsync()
GEMDOS 0x44 Mxalloc(0x88AC, 0x0)
GEMDOS 0x44 Mxalloc(0x30900, 0x3)
GEMDOS 0x49 Mfree(0x909034)
GEMDOS 0x44 Mxalloc(0x30900, 0x3)
GEMDOS 0x49 Mfree(0x909034)
GEMDOS 0x44 Mxalloc(0x30900, 0x3)
GEMDOS 0x49 Mfree(0x909034)
GEMDOS 0x44 Mxalloc(0x30900, 0x3)
GEMDOS 0x49 Mfree(0x909034)
GEMDOS 0x44 Mxalloc(0x30900, 0x3)
GEMDOS 0x49 Mfree(0x909034)
GEMDOS 0x44 Mxalloc(0x30900, 0x3)
GEMDOS 0x49 Mfree(0x909034)
GEMDOS 0x44 Mxalloc(0x30900, 0x3)
GEMDOS 0x49 Mfree(0x909034)
GEMDOS 0x44 Mxalloc(0x30900, 0x3)
GEMDOS 0x49 Mfree(0x909034)
GEMDOS 0x44 Mxalloc(0x30900, 0x3)
GEMDOS 0x49 Mfree(0x909034)
B-Trap f21a at 1fb7c (0x8672f9c)
A-Trap a000 at e01028 (0x9454448)
A-Trap a000 at e010a0 (0x94544c0)
A-Trap a00e at e010c0 (0x94544e0)
A-Trap a000 at e010a0 (0x94544c0)
A-Trap a00e at e010c0 (0x94544e0)
A-Trap a000 at e010a0 (0x94544c0)
A-Trap a00e at e010c0 (0x94544e0)
A-Trap a000 at e010a0 (0x94544c0)
A-Trap a00e at e010c0 (0x94544e0)
A-Trap a000 at e010a0 (0x94544c0)
A-Trap a00e at e010c0 (0x94544e0)
A-Trap a000 at e010a0 (0x94544c0)
A-Trap a00e at e010c0 (0x94544e0)
GEMDOS 0x4C Pterm(65535)
--------------

(Pterm is called by TOS4.)

--
MiKRO / Mystic Bytes
http://mikro.atari.org