|Re: [hatari-devel] EmuTOS / Vertical Mayhem regresssion|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
> I had thought that everything that worked already with Hatari
> v1.0 to be would be pretty much timing insensitive... I guess
> I was wrong. :-)
Yes, because with the v1.0, there was no DSP.
The dsp fake routine used to 'NOT' the registers to simulate a change of state.
With this, all the synchro loops (68030 side) were bypassed.
Now, we use a "real DSP", with data exchanges.
If a data is sent too fast (or too slow), or 2 datas are sent before the 68030 had the time to read the first one, there's a unsynchronization that occurs. The 68030 waits for 20 datas, the DSP send them, but the 68030 miss one data, so it loops forever waiting the 20th one that will never come, because the DSP has already sent it.
That's why 68030 timings are so important (and for the sound quality too).
Maybe VM would still run with "DUMMY DSP emulation" (no sound), I haven't tested.
(But now, there's also the crossbar that is DSP related).
----- Mail Original -----
De: "Eero Tamminen" <oak@xxxxxxxxxxxxxx>
Envoyé: Dimanche 26 Février 2012 23h47:23 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [hatari-devel] EmuTOS / Vertical Mayhem regresssion
On maanantai 27 helmikuu 2012, Laurent Sallafranque wrote:
> Vertical Mayerm runs well with latest hatari, real TOS 4.02fr.
> I think your problem is that you don't run hatari new core with cycle
Could you enable by default anything that should normally be enabled?
> Doesn't a0 points on the DSP registers ?
> In this case, it'a because VM is timing sensitive, and you must test
> with my cycle exact CPU.
I had thought that everything that worked already with Hatari
v1.0 to be would be pretty much timing insensitive... I guess
I was wrong. :-)
> Le 26/02/2012 21:45, Eero Tamminen a écrit :
> > Hi,
> > 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?
> > - Eero