Re: [hatari-devel] Sync byte on Falcon

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Reviving this thread ...

On 9 Sep 2023 at 12:00, Roger Burrows wrote:

> On 9 Sep 2023 at 5:15, Thomas Huth wrote:
> > 
> > I think this comes from "HE AUTHORITATIVE GUIDE TO THE FALCON VIDEO
> > HARDWARE BY AURA AND ANIMAL MINE", see e.g.:
> > 
> >  https://bus-error.nokturnal.pl/dl124
> > 
> > It says:
> > 
> > $FFFF820A [R/W] _______0  .................................. SYNC-MODE
> >                       ||
> >                       |+--Synchronisation [ 0:internal / 1:external ]
> >                       +---Vertical frequency [ Read-only bit ]
> >                           [ Monochrome monitor:0 / Colour monitor:1 ]
> > 
> It's possible this is a misinterpretation of test results.  If bit 1 is the
> PAL 
> bit, someone doing a test in Europe would naturally see this as 1 when a
> colour 
> monitor is plugged in.
> 
> > Is anyone with a Falcon able to reproduce this?
> > 
> I may be able to test this in a week or so with NTSC, I need to get my RGB 
> monitor out of storage.  
> 
The following results were all gathered using TOS 4.04.l

With both an RGB monitor and plain old VGA, reading 0xff820a on my Falcon 
returns 0x00, which indicates 60Hz.  Looking at the Hatari source 
(VIDEL_SyncMode_WriteByte() in Hatari 2.3.0), if there isn't a mono monitor 
connected, whenever you write to 0xff820a, Hatari kindly ORs it with 0x02, 
which is then always returned to a program reading that byte.

I think Hatari is clearly wrong: bit 1 on a Falcon means exactly the same as it 
does on an ST(e) and should be handled in a similar fashion.

If anyone needs further info or testing, let me know.

Roger
P.S. Vincent's FPS.TOS program, which Eero referred me to and which is 
marginally relevant to all this, also indicates 60 fps on both RGB and VGA 
monitors on my system, and 50 fps under Hatari.




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/