Re: [hatari-devel] Falcon raster emulation

[laurent.sallafranque@xxxxxxx]

Hi,

I second this too ;)

This is feasible. I've done a hacked version of Hatari that allows me to play to pinball Dream.
Pinball dream uses the timer-b on the Falcon to change the video base address.

It works well, but Pinball dreams detects the line 90 (it's probably not the exact value, I do it from head) to change the video base address and I had to tell hatari to change at address 65. So, hatari runs faster than the real computer.

Why this ? 
Because hatari's falcon timings are not accurate.

Hatari's main clock is based on the 68030 cycles.
The DSP clock, the Videl clock, the sound clock, the DMA clock, ... are all derived from the cycles of the CPU.

I think the CPU cycles are quite precise now (except for some instructions like MMU, DIV, MUL and copro instructions).
You can, see it with the DSP <-> 68030 transfers.
But hatari lacks many cycles like the cycles of the Videl, DMA, (maybe Waitstates too ?) ... and maybe some more I don't think of

Another example : Racer runs in 5 VBLs on my Falcon, but in 3 VBLs on Hatari (Yes, 2 VBLs difference !).
How can the HBL of the videl be precise with such a difference ?

If we manage to give a better cycle base to Hatari, the Videl Emulation is not a problem (I've already done it, it's on my hard drive since 2 years)
Accurate cycles is nearly impossible (at least, we don't know the exact div/mul algo), but much better approx should be OK for a complete VIDEL emu.


I think the most cycle eater is the Videl itself. Maybe adding 19 cycles every xxx cycles should do it. I'll have to read again the Videl text on Mikro's page and give this a try.


Best regards

Laurent



----- Mail original -----
De: "Douglas Little" <doug694@xxxxxxxxxxxxxx>
À: hatari-devel@xxxxxxxxxxxxxxxxxxx
Envoyé: Jeudi 12 Décembre 2013 01:11:58
Objet: [hatari-devel] Falcon raster emulation


I have started using timer-b on the Falcon to change the video base address, which provides split-screen for my game's status bar. It's a useful way to cheaply update random bits of the status bar under double-buffering without having to duplicate those changes between buffers (expensive in truecolour, and it seems to happen a lot in this game). 


Obviously this trick doesn't work in Hatari at the moment - the display is converted independent of time-critical events and rasters get missed. 


So I'd like to know if Falcon emulation is likely to go down to the scanline-level in future to emulate effects like this? On the one hand I don't want to write code for emulators - but on the other hand I don't want to do stuff that lots of people will never be able to use because Hatari is all they have. 


(It could be solved by implementing a second code path which handles the status bar in double-buffered form but I'd rather not if I can avoid it) 


D