[hatari-devel] Some more demos that fail with 1.4

[Nicolas Pomarède]

Le 25/03/2011 22:17, Eero Tamminen a écrit :

Hello,

here're some reports on some of those demos

> * Pixel Twin's Mental Hangover actually crashes Hatari:
>     http://www.pouet.net/prod.php?which=11181
>
> Valgrind says:
> ==4016== Invalid write of size 1
> ==4016==    at 0x40264DC: memset (mc_replace_strmem.c:602)
> ==4016==    by 0x80D18DC: Video_InterruptHandler_HBL (video.c:1942)
> ==4016==    by 0x810CB30: m68k_go (newcpu.c:1758)
> ==4016==    by 0x80B3A33: M68000_Start (m68000.c:241)
> ==4016==    by 0x80B4823: main (main.c:773)
> ==4016==  Address 0x4981d00 is 0 bytes after a block of size 614,400 alloc'd
> ==4016==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
> ==4016==    by 0x80C2E81: Screen_Init (screen.c:517)
> ==4016==    by 0x80B46C9: main (main.c:585)
>
> (when it gets 4 bytes past the screen buffer, Hatari crashes)

Tough one, I spent some time figuring what was wrong. In fact, due to a 
very buggy loader in the boot sector, this demo can sometime consider it 
needs to load $c18f sectors with xbios(8) ! Since memory location for 
the sector is incremented by 512 bytes on each sector, you end up 
filling the whole ram (as well as the IO space !) with garbage read from 
wrong sectors.

The problem is that at the start of the boot sector D1=3e7bxxxx (number 
of sectors to read) and the loader doesn't clear the upper 16 bits...
Now, since it works under Steem with the same TOS, I needed to 
understand why the upper 16 bits were 0 on a real STE.
In fact, those bits in D1 are the result of initializing the TOS 
date/time by reading the real time clock at $fffc21-3f.

Since normal STF/STE didn't have an RTC, this loader worked (more or 
less by luck). When there's no RTC, D1=0 at the start of the boot.

Note that it depends on the TOS : with 1.04 or 1.62, D1!=0 but with 2.06 
the loader starts.

But after that, when all sectors are loaded, the demo check there's no 
cardridge connected to the ST (at $fa0000). Since HD emulation is at the 
same space under Hatari, it's considered as an ripping cardridge and the 
demo wipes the whole RAM with the blitter -> bus errors again.

So, to run this demo, you need to disable RTC and HD emulation.

I added a note for this in compatibility.html.


> * Songs of the Unexpected gets double bus error after playing the first song
>     in the main demo for a while:
> 	http://www.pouet.net/prod.php?which=22398

I can reproduce, it's quite random and never at the same time, so a 
little hard to fix for now.


> * Aura's Hifidelity dreams seems now fine:
> 	http://www.pouet.net/prod.php?which=996

It was an FDC problem that I fixed in 2008/12

>
>
> * As does Hemoroids Necrosys (it's music is something truly
>    horrible though):
> 	http://www.pouet.net/prod.php?which=14395

Music is crap, but it's how it sound on a real STE :(


> * Delirious 3 crashes on startup:
>    http://www.pouet.net/prod.php?which=21347

Worked for me. Have you tried in STE mode ?

>
> * Once the actual demo starts:
>    http://www.pouet.net/prod.php?which=15437
>
>    Bad taste dies to:
>    Your Atari program just did something terribly stupid:
>    VoidMem_xlate($533b0aa5)
>
>

I get this a few seconds after the yellow/red vector balls appear. Do 
you get the error at the same point ?
 From what I see, the demo code seems to be altered by a bad write at 
address $404c2. The resulting wrong instruction tries to add.w on an odd 
address, which creates this crash.

I will need to add some code in Hatari to track what part of the demo is 
producing this bad write.


>
> * AFL pro fooball doesn't anymore freeze on startup:
>    http://lists.berlios.de/pipermail/hatari-devel/2010q2/002284.html
>
>    But there's some screen update/color issue between the game halves
>    (when running a demo game) when panels from top&  bottom are scrolled
>    towards screen center.
>
>
> * GGN's Kuovadis game (Daleks clone) dies at startup after screen goes blank
>    and it tries to scan disk for mods.  I'm not sure where I got the program,
>    GGN's page seems to be missing a link:
> 	http://users.hol.gr/~ggn/

Havent't tested these 2 ones for now.


Nicolas