Re: [hatari-devel] Data cache Issues?

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


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.






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