|Re: [hatari-devel] Motion demo Susie screen|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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
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
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.)
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 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...