Date : Sun, 26 Jul 2009 17:58:45 +0100
From : philpem@... (Philip Pemberton)
Subject: Fw: Fwd: ITV Teletext to shut down in January
Rick Murray wrote:
> Philip Pemberton wrote:
>> (1)- Adding VBI data to an existing video signal. For this you need a
>> composite input and a sync separator. The LM1881 costs about ?3 and
>> needs three or four external parts. Simple!
>
> Whoo - custom teletext subtitling! :-)
Indeed.
Or a way to overlay ORACLE onto a live ITV signal, if you just happen to
have a complete grab of ORACLE from a particular day, that is. Speaking
of which, I don't think anyone ever bothered doing that...
I'm tempted to have a go at building a timestamped Teletext receiver (as
in, it tracks the frame number and time each page was transmitted),
although getting the signal in the first place might be "interesting".
I've got a couple of UV916MD receivers, but sadly they output the
38.9MHz IF; splitting off the composite video signal might be "interesting".
>> (2)- Creating your own video signal as well. Bit more complex, now you
>> need a framebuffer and a sync generator.
>
> Why do you need a frame buffer? If we are interested in playing with
> TELETEXT, surely the picture part is of less consequence? Yes, you could
> have a nice rendered JPEG saying "Press [text] now", but it would likely
> be easier for you to say that.
True, I just thought it'd be nice to be able to choose what was on
screen as well :)
> Okay, got some veroboard and warming up my soldering iron... but I have
> a horrible feeling you have skipped over the complicated bit - namely
> you said with two RAMs you could write one while displaying from the
> other - how will we manage that - is there enough available bandwidth to
> 1MHz bus it? How much data are we talking here anyway?
I never said you could do it with a BBC over the 1MHz bus :)
Basically you have two data/address buses -- "Load" and "Run". Load is
used to write to the RAMs, Run is used to put stuff on the Teletext stream.
You also have two 2:1 multiplexers, which switch the data and address
lines between the two RAMs. If LOAD is active, then you read from RAM2
and write to RAM1. If it isn't active, then you do things the other way
round. In effect you're switching between two RAM chips.
Another (cheaper) way to do it would be to have a small buffer in the
controller FPGA, then write stuff to RAM when a pixel is *not* being
output. In other words:
_ _ _ _ _ _ _ _ _ _ _ _ _
Main clock: __| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_
___ ___ ___ ___ ___ ___ ___
Pixel clock: __| |___| |___| |___| |___| |___| |___| |
__ ___ ___ ___ ___ ___ ___
RAM enable: |___| |___| |___| |___| |___| |___| |___|
OK, so when Pixel Clock rises, you output a pixel. When RAM Enable
rises, you either change a byte of RAM or leave the RAM bus idle. The
disadvantage being that this is both very slow, and the data rate is
tied to your video rate. If the video rate is fixed (circuit generating
both sync and Teletext data) then it's not an issue. If you're syncing
off an external signal, then your data rate is going to vary over time
(unless your sync signal is very, VERY stable, i.e. off-air broadcast).
Fun!
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.
Amount of data depends on how many pages you want to broadcast.
One teletext packet consists of 45 bytes, 40 of which can store
character data. You can use up to 16 lines of the VBI for Teletext;
assuming interlaced video, there are two fields thus two VBIs, meaning
you can transmit 32 lines of Teletext data per frame. 25 frames per
second video results in a line rate of 800 lines per second. On
progressive-scan video, you'd get 400 lines per second. Essentially one
packet = one teletext line, or one header row.
Transmission of an entire Teletext page requires one header row, and 24
lines of text. That's 25 packets total, meaning your 800 lines (or
rather packets) now gets you a transmission rate of about 32 pages per
second. This is for a standard Level 1 teletext page; a Level 1.5 page
with FASTEXT information is 4 lines longer (29 packets total). In that
case, you'd be able to transmit 27 complete pages, and 17 lines of the
next page.
Valid page numbers range from 100 to 8FE -- magazines 1 thru 8, pages 00
thru FE in each magazine (FF is reserved as a null page code). That
means 8 magazines and 255 pages per magazine. So you could have a
maximum of (8*255) = 2040 pages. 2040 pages times 29 packets is 59160
packets to transmit a full Teletext suite.
Those 59160 packets will take:
(59160/32) = 1849 seconds (nearly 31 minutes) to transmit on an
interlaced stream, or...
(59160/16) = 3712 seconds (over an hour!) to transmit on a
progressive scan stream
As far as RAM requirements go, we can be a bit sneaky. A full Teletext
line is 40 characters long, plus a 3-byte preamble and 2-byte
magazine/page number, for a total of 45 bytes. The clock run-in and
preamble is always the same, which saves us 3 bytes. We still need 42
bytes of RAM -- per line -- to store the line data.
If we have a full TTX suite (2040 pages), we need:
2040 pages * 29 lines * 42 bytes per line = 2.37 MiB (binary megabytes)
Let's be reasonable. What about if we just store enough data for a
second of video. That would be:
42 bytes per line * 16 VBI lines * 2 fields per frame * 25 frames per
second = 33600 bytes per second
This is slightly more than a 32KiB (256Kbit) RAM chip stores, assuming
we pack the data lines together in RAM. If we use that chip, then we can
store a total of:
65536 / 25 / 2 / 16 / 42 = 1.95 seconds of TTX data
If we don't pack the data, then our next binary power of two (from 42)
is 64. We'd waste 22 bytes per packet, and we'd be able to store:
65536 / 25 / 2 / 16 / 64 = 1.28 seconds of TTX data
Lastly, I may as well figure out if this could be reloaded over the 1MHz
bus... 1MHz is one million cycles per second. If we assume that every
one of those cycles could be a write cycle, then we can write a million
bytes to the TTX RAM every second. Problem is, the 6502 isn't that fast.
IMHO, you're more likely to see a write rate of maybe a quarter or an
eighth of that. If we're pessimistic and say we can write every 16
cycles, that's:
1e6 / 16 = 62500 bytes per second
In other words, it can be done with a few conditions:
- The copy loop must be incredibly tight. Thinking about using BASIC?
Think again.
- The hardware is going to need an auto-incrementing address counter
for RAM writes (i.e. not a pair of latches, a proper presettable
counter). Not really a big deal unless you're breadboarding out of 74LS
chips.
Has anyone got any figures for sustained data rate on the 1MHz bus?
Going the PC route, if you used USB2 High Speed and -- say -- a Cypress
EZ-USB/FX2lp chip, you could easily get a few megabytes a second
unoptimised, assuming your RAM chips and logic could handle that. So
definitely possible on a PC. If you want internal hardware (why?), then
either PCI or PCIexpress should be able to handle it. Heck, even the ISA
bus should be able to do it, if you rigged the hardware to do DMA. IIRC
the PC DMA controller was clocked at 8MHz and clock-shared 1:1 with the
CPU, meaning you could get a theoretical data rate of about 4Mbytes/sec.
Assuming, of course, nothing else was trying to run a DMA transfer (disk
drives?) at the same time.
I prefer USB though. Much easy to code for. And test. And do the PCB
layout...
--
Phil.
philpem@...
http://www.philpem.me.uk/