Re: [hatari-devel] Sync byte on Falcon

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Wed, 15 Nov 2023 22:35:42 -0500
schrieb "Roger Burrows" <anodyne@xxxxxxxxxxxx>:

> 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.

Ok, that really sounds like the documentation (and thus Hatari) was wrong.
I just also had a look what TOS is doing during boot:

$00e0833e 3a7c 820a                          movea.w   #$820a,a5
$00e08342 0807 0005                          btst.b    #$5,d7
$00e08346 6706                               beq.b     $e0834e
$00e08348 08d5 0001                          bset.b    #$1,(a5)
$00e0834c 6004                               bra.b     $e08352
$00e0834e 0895 0001                          bclr.b    #$1,(a5)
$00e08352 4cdf 38f8                          movem.l   (a7)+,d3-d7/a3-a5

I believe this is part of the VSetMode() XBIOS function, i.e. d7 contains
the mode word where bit 5 is the PAL/NTSC flag, indeed.

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

I can change the source code in Hatari, but I'd like to have a better
understanding how this register really behaves.

So if you've got some spare minutes, could you write a little test program
that:

- Reads ff820a to back up the original value
- Write 0xfc to ff820a and read back the value from the register
- Write 0x02 to ff820a and read back the value from the register
- Write 0x01 to ff820a and read back the value from the register
- Restore the original value to the register
- Print out the three values that have been read back after altering the
  register

and then run it with your RGB monitor (or let me know if you want me to
write such a program instead).
I think it shouldn't harm the monitor if ff820a is just changed for some
few cycles (but to be sure, you could also switch the monitor off before
starting the program with a double click). If you're sure that your monitor
could also handle 50 Hz, you could also write 0x02 or 0x01 to ff820a and
leave it there for some frames to see whether it makes a difference in the
output at all...

Then please tell me the three values - this will help me to understand
which bits are implemented at all, and which are rather hard-wired to 0.

> 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.

Yes, it's a known deficiency of Hatari - Videl video timings are not
emulated at all yet.

 Thomas