Date   : Fri, 31 Jul 2009 22:44:37 +0100
From   : jgh@... (Jonathan Graham Harston)
Subject: Fw: Fwd: ITV Teletext to shut down in January

Rick Murray wrote:
> > I still reckon the hardest part is going to be timing (in general). That
> > is, generating a pixel clock from the sync signals, and outputting data
> > when needed.
> 
> Indeed. For not only are we looking to lines (which isn't hard), but
> pixel positions within a line and with enough accuracy for a teletext
> chip to pick it up again. The teletext bitrate is 6.9375MHz.
 
Each line of data starts with a bit pattern to synchronise the
receiver. It is allowed to wander off at the end of the data line
as the next data line resyncs it.
 
This is probably an egg-sucking masterclass here, but:
 
* Each scan line is 64us long
* This 64us is sampled as 444 bits, a 6.9375MHz bit rate.
* The line sync and colour burst occupies part of the scan line,
  leaving 360 data-carrying bits per scan line
* These 360 bits are arranged into 45 8-bit bytes
* These 45 bytes are arranged into:
    clock run-in %10101010
    clock run-in %10101010
    framing code %11100100
    hamming code magazine number
    hamming code row number
    40 bytes of line data
* bits arrive b7 first, b0 last
* the page number is sent in a row zero packet. Every packet after
  that row zero is a line of that page, until another row zero
  arrives.
 
The receiver syncrhonises with the 1010101010101010 sequence and
when 11100100 arrives 42 bytes are collected. It then returns to
waiting for 10101010... to synchronise and then wait for 11100100
to trigger collecting another 42 bytes.
 
So, a full byte arrives every 1.153us, so bytes arrive at 0.867MHz.
 
Is that slow enough for:
 
.loop
LDA &FCxx
STA (zp),Y
INY
BNE loop
 
Porbably not. Probably need at least 42 bytes of buffer RAM and
read it from there at your leisure.
 
-- 
J.G.Harston - jgh@...                - mdfs.net/User/JGH
PDP-11 BBC BASIC development - http://mdfs.net/PDP11/BBCBasic/blog