Re: [hatari-devel] Motion demo Susie screen

[ Thread Index | Date Index | More Archives ]


Thanks for the bisect!  I'll add note about it
being issue with cycle-exactness.

I checked that it doesn't work by disabling cache
emulation and/or prefetch, nor with oldUAE CPU
core either.

	- Eero

On 11/30/20 11:47 PM, Laurent Sallafranque wrote:
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(-)



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.


Le 30/11/2020 à 21:38, Eero Tamminen a écrit :

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.


Le 30/11/2020 à 20:22, Eero Tamminen a écrit :

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

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

Mail converted by MHonArc 2.6.19+