Re: [hatari-devel] Data cache Issues?

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi

For beats of Rage :

Just to be sure, can you remove the file HALLFAME.DAT, then copy the 
file DATAS.DAT and rename it HALLFAME.DAT
I have a bug here that sometimes freeze the main menu just before 
displying the high scores and I added a "virgin" DATAS.DAT file in case of.

This may explain the problem you encounter with Beats of Rage.
Remenber that it was my first game on Falcon and I had to take care of 
many things. Racer 2 was easier to develop as I already had the 
"squeletton" of a game.

There are some "printf" in the code (in fact, gemdos/xbios functions to 
display text, as my games are 68030 only (no C) ) when the DSP can't be 
started, when there's not enough memory, ... But not everything is printed.
I know I should try to fix a few bugs in this game, but I think I've 
already spent too much time on it, sorry ;)


> - yepyha

I don't remenber having seen this one working with any hatari version.

> - virtual city

This one should work perfectly.
It was the second program that worked under hatari+DSP when I did the 
DSP integration after a DOT bowl.


Regards

Laurent



Le 03/06/2015 22:01, Eero Tamminen a écrit :
> 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.