Date   : Wed, 06 Feb 2002 15:51:20 +0000
From   : Richard_Talbot-Watkins@...
Subject: Re: Firetrack

Hiya,

You're thinking of R3, which does indeed contain lower 4 bits as horizontal
sync width and upper 4 bits on vertical sync width (both are valid on the
Beeb's 6845).

I don't believe there's any reason to emulate any of the horizontal stuff
precisely, as I don't know of anything which hacks it in a really nasty way
(as that would be pure evil!), but the vertical stuff is worth getting
right I think.

>From my experimentation, R3 bits 4-7 contain a value which is a number of
*scanlines* during which the VSync signal is held high after having been
initially triggered by the CRTC's character row internal counter becoming
equal to R7.  VDUs seem to respond to the falling edge of the VSync signal,
i.e. the actual vertical retrace of the VDU is triggered when the VSync
signal falls from high back down to low, rather than when it is first held
high.  The reason for being able to change this value at all is because
different monitors require different minimum lengths of VSync pulse for the
signal to be recognised.  In general, it's fine to leave it set to some
constant, e.g. 4 scanlines as it is by default.  The larger this value, the
safer!  This is why other variants of the 6845 which do not permit control
of the vertical sync width default its value to 16 scanlines.

I think you may be confusing this pulse width with the vertical retrace
period (i.e. the number of PAL scanlines during which flyback occurs),
which is a property of the monitor / PAL standard (?), and not related to
the vertical pulse width at all.  The only purpose of the VSync signal is
to *initiate* the vertical flyback in the VDU, at which point it'll just
get on with it!  It's not that the flyback lasts for the duration of the
VSync pulse.

The exact breakdown of the number of scanlines of the total 312 used for
flyback may be documented somewhere, but I was just explaining my thought
processes as to where I got my figures from, and 24 scanlines for flyback
seems to work pretty consistently with my findings.  If anyone can confirm
or deny, please do!

Hope that clarifies?!

(I'm generally gibbering away at work today so I won't be surprised if
that's just lost everyone...  must...have...beer...!)

Rich
PS Continued apologies for the crap quoting.
PPS I just realised there's a 'bug' in my CRTC update algorithm for my last
post too.  The final bit that deals with the total scanline adjust related
to R5 should be doing the same sort of test on each scanline as the main
loop... i.e. either plotting actual screen RAM data or a blank line
depending on the scanline count and whether we're less than R6 or not.
--
Rich Talbot-Watkins,
SCEE Cambridge.
Richard_Talbot-Watkins@...     
All views expressed are mine, not my employer's... blah blah...



                                                                        
                                       
                    "Richard Gellman"                                   
                                       
                    <r.gellman@...            To:     "BBC Micro Mailing
List" <bbc-micro@...         >         
                    net.com>                  cc:                       
                                       
                    Sent by:                  Subject:     RE: [BBC-Micro]
Firetrack                            
                    owner-bbc-micro@...                                  
                                       
                    oud9.co.uk                                          
                                       
                                                                        
                                       
                                                                        
                                       
                    06.02.02 15:04                                      
                                       
                                                                        
                                       
                                                                        
                                       


R2 holds both the vertical sync and horizontal sync widths (one per 4
bits).
I believe the bottom 4 bits is the horizontal sync width.
Note: Only certain variants of the 6845 have vertical sync width support,
I'm led to believe such a variant has been used in the bbc micro, as data
logging
from BeebEm shows some games attempting to write to the top half of this
register.

(The original Motorola 6845 does NOT have programmable vertical sync width)

The Watford Master Advanced Reference manual shows the values programmed to
R2 for
both horizontal and vertical sync widths for each screen mode.

Vertical sync width is character lines (scanlinesPerChar+1), and horizontal
sync width
is in characters. (8-mode 0 pixels for modes 0-3, and 8 mode 4 pixels for
modes 4-7
the difference is due to a 2Mhz clock in modes 0-3, and 1Mhz clock in modes
4-7)




**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
postmaster@...     

This footnote also confirms that this email message has been checked
for all known viruses.

**********************************************************************
 SCEE 2001