Re: [hatari-devel] Data cache Issues?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On keskiviikko 03 kesäkuu 2015, Nicolas Pomarède wrote:
> Le 02/06/2015 23:33, Eero Tamminen a écrit :
> > After some testing, there are at least some Falcon
> > demos that worked earlier which don't work anymore:
> > - virtual city

There's some other problem with this.  It fails also with
earlier Hatari versions (even v1.6.2).


> > - yepyha

This starts fine with Hatari version just before data cache
was enabled (f6c3a5eb0cf6), but fails right at start with
latest version:
-----------------
....
GEMDOS 0x48 Malloc(0x3E80) at PC 0xFA002A
Videl : $ff8201 Screen base write: 0x02  (screen: 0x2c000)
Videl : $ff8203 Screen base write: 0x63  (screen: 0x26300)
Videl : $ff820d Screen base write: 0xd4  (screen: 0x263d4)
GEMDOS 0x20 Super(0x0) at PC 0xFA002A
M68000 Bus Error reading at address $ff82aa PC=$1cb60.
Exception 2 (1cb60) at 1cb60 -> e00fb6!
-----------------


Shadows' Firestarter demo also works with Hatari version just before
data cache enabling, but causes reset with latest Hatari version:
-----------------
....
Videl : $ff8203 Screen base write: 0xcb  (screen: 0x2acb00)
Videl : $ff820d Screen base write: 0x70  (screen: 0x2acb70)
M68000 Bus Error reading at address $fff603 PC=$213e0.
          Sentry 2.2 by EagleException 2 (213e0) at 213e0 -> e00fb6!
Illegal instruction: 00e0 at 00E00010 -> 00E00FB6
CPU reset PC=e00038 (ROM memory)..
-----------------


> > And Laurent's Beats of Rage freezes (with music playing on bg)
> > to the score table at startup, so I think there may still
> > be problems with cache.
> 
> that's strange, no freeze for me (falcon + CE cpu + 16 MHz + 14 MB RAM),
> the game works correctly.

Now it stop earlier, to this:
....
XBIOS 0x68 Dsp_Lock() at PC 0x1C9A8
GEMDOS 0x3C Fcreate("HALLFAME.DAT", 0x0) at PC 0xFA002A
GEMDOS 0x3D Fopen("HALLFAME.DAT", write-only) at PC=0xFA002A
GEMDOS 0x40 Fwrite(65, 130, 0x46fec) at PC 0xFA002A
GEMDOS 0x3E Fclose(65) at PC 0xFA002A
BIOS 0x01 Bconstat(0x2) at PC 0x1CDFE
GEMDOS 0x07 Crawcin() at PC 0xFA002A
BIOS 0x02 Bconin(0x2) at PC 0xE1C214

And after key press, it terminates.  Laurent, why it doesn't
print an error if it decides to terminate prematurely?


Note, this is regular v1.2 version of Beats of Rage.  2vbl_bug.prg
program for the same B-o-R version starts fine with Hatari + data cache,
as long as Hatari is started with RGB monitor.

Whereas Hatari version before enabling data cache (f6c3a5eb0cf6),
and few earlier builds of WinUAE CPU core & oldUAE CPU core work
fine with _both_ B-o-R programs, _both_ with RGB and VGA monitor.


I think it would be great to have an option to disable data cache
so that one can check whether it affects the issue...


> Regarding msa.c, I think it is misleading to use do_put_mem_xxx (which
> is the low level access to memory in cpu emulation) for other things
> than accessing emulated memory.
....
> As above, if the access to STRam is the result of some DMA access, it
> should be safe (eg hdc.c, fdc.c)

Regarding naming, I noticed that STMemory_SafeCopy() accepts
just normal RAM (not TT-ram) and it doesn't do flush, but it's
only used by fdc.c and hdc.c DMA data copies.

Maybe it should be renamed to STMemory_SafeIOCopy()?


	- Eero

PS. I reviewed debugger code.  That should be fine.  Everything doing
writes to memory does it through STMemory_* function.



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/