|Re: [hatari-devel] EmuTOS / Vertical Mayhem regresssion|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On sunnuntai 19 helmikuu 2012, Eero Tamminen wrote:
> On lauantai 18 helmikuu 2012, Eero Tamminen wrote:
> > Btw. There's something funny with non-DSP Falcon emulation
> > in regards to EmuTOS.
> > Virtual Mayhem game doesn't work with EmuTOS with latest
> > Hatari, but with Hatari v1.4, it works fine also for EmuTOS.
> > This was one of the first Falcon games ever to work with Hatari,
> > so it's not picky about the emulation accuracy and it doesn't
> > use DSP...
> Seems EmuTOS is now setting _SND bits for things it doesn't
> actually support. Not an Hatari issue.
FYI: Not _SND issue after all as it doesn't seem to care about
the bits, but calls the non-implemented EmuTOS OS functions
regardless of them.
This one's wierd as with the same game and EmuTOS version the game
starts fine when using Hatari v1.4.
GEMDOS HD emu doesn't affect it because the same issue happens
also from HD image.
With Hatari CPU profiling I can see that the code is
spending all it's time in this loop:
$04b78c : 0148 0000 movep.l 0(a0),d0
$04b790 : 4e71 nop
$04b7ac : 4e71 nop
$04b7ae : 0348 0000 movep.l 0(a0),d1
$04b7b2 : e088 lsr.l #8,d0
$04b7b4 : e089 lsr.l #8,d1
$04b7b6 : b280 cmp.l d0,d1
$04b7b8 : 66d2 bne.s $4b78c
Vertical Mayhem calls following OS functions which aren't
supported by EmuTOS:
> XBIOS 89 (VgetMonitor)
> XBIOS 133 (Settracks)
> XBIOS 134 (Setmontracks)
> XBIOS 139 (Devconnect)
But I don't understand why Hatari version affects what happens
as result, the Hatari options were same.
Any comments on that?