Re: [hatari-devel] Sync byte on Falcon

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 6.9.2023 3.31, Roger Burrows wrote:
> I always thought that bit 1 of the sync byte (0xff820a) on the Falcon had the
> same meaning as on the ST etc: a 1 bit means PAL (50Hz sync), a zero bit means
> NTSC (60Hz sync).  But Hatari 2.3.0 disagrees: it always sets the 1 bit unless
> a monochrome monitor (71Hz sync) is connected.
>
> If that's really the way the hardware works, I'm extremely puzzled that Atari
> defined a PAL/NTSC bit in the video modes settable for RGB/TV, and that TOS4
> writes 0x02 to the sync byte (indicating 50Hz sync) for an RGB screen when the
> PAL/NTSC bit in the mode set to 1; and 0x00 to the sync byte (indicating 60Hz
> sync) for an RGB screen with the PAL/NTSC bit in the mode set to 0.
>
> This seems like a bug to me.  If so, is it fixed in a later release?

Hatari Falcon Videl emulation is incomplete.

Along with few other things, 50/60hz support is missing.  See Videl 
notes in:
https://git.tuxfamily.org/hatari/hatari.git/plain/doc/todo.txt

FYI: Original Videl emulation code (conversion & scaling functionality) 
came from Aranym.  Laurent did most of the Videl improvements after 
that, but left it somewhat unfinished when he switched back to demo 
coding.  Last thing added by him was Videl border emulation, which was 
*decade* ago (wow, but time flies...). After that, nobody has really 
worked on it.

There have been only some code refactoring (for changes elsewhere in 
code), TT color modes support improvement (as Videl code is used also 
for TT screen emulation) and few minor fixes for different issues.


	- Eero