Re: [hatari-devel] Motion demo Susie screen

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi,


I don't know if this will help, but the bisect of Suzie gives the 
following result (between hatari V1.6.2 and hatari 1.7.0) :


4db18160c6141ef9a74dd0308eee41da3729a33f is the first bad commit
commit 4db18160c6141ef9a74dd0308eee41da3729a33f
Author: Laurent Sallafranque <laurent.sallafranque@xxxxxxx>
Date:   Fri Feb 1 19:55:43 2013 +0100

    change: take into account the 68030 cycles in cache mode ON

 src/cpu/newcpu.c      | 11 +++++------
 src/includes/m68000.h |  2 ++
 2 files changed, 7 insertions(+), 6 deletions(-)


Regards,

Laurent


Le 30/11/2020 à 21:39, Laurent Sallafranque a écrit :
> I'm already bisecting.
>
> For now, it works until hatari 1.6.2
>
> I continue to dig.
>
> regards
>
>
> Le 30/11/2020 à 21:38, Eero Tamminen a écrit :
> > Hi,
> >
> > On 11/30/20 10:26 PM, Laurent Sallafranque wrote:
> > > I've managed to find what I had in mind : with hatari 1.4, I get the 
> > > following image :
> > >
> > > (You have to wait 30 seconds before the image arrives, at first, the 
> > > screen displays garbage and then, the effect starts.
> >
> > Thanks, that does look familiar.
> >
> > Could you bisect it?
> >
> > (I wonder whether it would work with oldUAE code.)
> >
> >
> >     - Eero
> >
> > > Le 30/11/2020 à 21:19, Laurent Sallafranque a écrit :
> > > > I've seen this Suzie demo with a previous version of hatari (it 
> > > > displays some blue and white buildings if I remember correctly).
> > > >
> > > > the demo had a problem with the screen (videl emu I think).
> > > >
> > > > I'll check with previous versions of Hatari if I can let it run again.
> > > >
> > > > Laurent
> > > >
> > > >
> > > > Le 30/11/2020 à 20:22, Eero Tamminen a écrit :
> > > > > Hi,
> > > > >
> > > > > On 11/1/20 4:54 PM, Nicolas Pomarède wrote:
> > > > > > Le 27/10/2020 à 00:12, Eero Tamminen a écrit :
> > > > > > > Only "Susie" doesn't work, it's now stuck
> > > > > > > executing these instructions:
> > > > > > >    $00016690 : btst   #0,$fffffc00.w    50.00%
> > > > > > >    $00016696 : beq.s  $16690            50.00%
> > > > > > >
> > > > > > > Nicolas, any ideas what could be the problem?
> > > > > >
> > > > > > if you look at the code after, you can see that the btst is in 
> > > > > > fact waiting for a byte to be received from the ikbd ; which 
> > > > > > means a key was pressed (or mouse was moved).
> > > > > > then just after, it compares the content of fffc02 with #$01, 
> > > > > > which is the scancode for the 'esc' key.
> > > > > >
> > > > > > So, demo is not stuck ; press 'esc' and it will continue. In fact 
> > > > > > it exits. I don't know it's supposed to run sthg instead of 
> > > > > > exiting > someone would need to test on a real falcon. (or look 
> > > > > > at the source code
> > > > > > with the demo)
> > > > >
> > > > > "Susie" screen description states following:
> > > > > --------------------------------------------
> > > > > Wolfestein/doom routine. Trilinear filtering
> > > > > (mipmaps!) and featuring anti-aliasing of wall
> > > > > edges. The DSP is used just to do the 3d
> > > > > mathematics. Uses blitter in a funny way to read
> > > > > one pixel and write it twice, but this causes
> > > > > problems with the sound DMA. Massive pre-
> > > > > calculations. All wall heights are in memory.
> > > > > Features a nice roll effect. 2x2 pixels, but
> > > > > proper ultra-low resolution screen might speed
> > > > > it up to 50hz. Truecolor.
> > > > > --------------------------------------------
> > > > >
> > > > > Which corresponds to attached image (susie-pouet.png) from pouet.net.
> > > > >
> > > > > But it looks like the attached susie-hatari.png instead.
> > > > >
> > > > > Maybe the blitter stuff is one of the problems?
> > > > >
> > > > > I have no idea how that e.g. interacts with Videl emulation...
> > > > >
> > > > >
> > > > >     - Eero