Re: [hatari-devel] Re: Hatari + TC + Falcon palette?

Hi,

Thanks Eero, Laurent for the reply.

The main reason I wanted 'rasters' is to confirm approximate visual timing and spacing of audio interrupts in different scenarios (i.e. accurate emulation isn't an issue - nearest scanline would have been enough).

However I can see now why it is not supported and not likely to change so I won't ask any more :-)

On 26 June 2013 20:40, Laurent Sallafranque <laurent.sallafranque@xxxxxxx> wrote:

Hi,

That's not that trivial.
The main problem with the Falcon emulation is accuracy.

It's not possible yet to detect a correct end of line for example, because cycles are wrong (not like in the ST(e) emulation which is accurate).

I did a special version of hatari (for my own purposes and tests) that runs well pinball dreams on Falcon, but I had to trick and fix the hbl for this special one (which means it won't work for any other program).

There's still a lot of work in the falcon emulation ;)

Regards

Laurent

Le 26/06/2013 21:08, Eero Tamminen a écrit :

Hi,

(CCing hatari-devel, Laurent has been doing Videl stuff)

On keskiviikko 26 kesäkuu 2013, Douglas Little wrote:

....actually it seems to me that the border colour is picked up by Hatari
on the vblank, and propagated to the whole frame, it's not possible to
change the colour during the refresh (i.e. no rasters possible).

Is there a way to configure Hatari to pick up the border colour on each
new displayline?

No. Falcon screen is converted in one go, using whatever palette entries
that are there at vblank. Palette changes before that aren't recorded nor
taken into account while doing the conversion (from given Falcon color
mode to current host/SDL framebuffer mode).

If border color (palette 0?) would be stored and used while converting
the screen, at what exact moment it should be stored? When hblank happens?

- Eero