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

[Eero Tamminen]

Hi,

On torstai 31 maaliskuu 2011, Nicolas Pomarède wrote:
> Le 25/03/2011 22:17, Eero Tamminen a écrit :
> 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.

How that can cause *Hatari* to crash here:
         else
               /* left border not removed, clear to color '0' */
               memset(pSTScreen,0,SCREENBYTES_LEFT);
?

Is pSTscreen address taken from emulated RAM without checking that
the pointed screen actually is within the emulated RAM?

Hatari crash is much more serious than demo crash. :-)


> 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.

Verified.  Without these the demo works and Hatari doesn't segfault.


> I added a note for this in compatibility.html.

I don't see this in repo, did you remember to push it?


> > * 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

It's a nice demo, maybe it should be listed in compat list? :-)


> > * Delirious 3 crashes on startup:
> >    http://www.pouet.net/prod.php?which=21347
> 
> Worked for me. Have you tried in STE mode ?

Yes, but actually the Pouet demo seems to be a different one than what
I had. Pouet version file name is delir_3.msa and it doesn't react where it
asks me to press either 1) or 2) i.e. demo is stuck in that screen.

The file name for version I had was delirs3a.msa.  I have no idea where
I got it (i.e. whether it's even supposed to work), sorry about that.


> > * 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 ?

Yes.


>  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.


	- Eero