Date : Thu, 30 Jul 2009 18:19:26 +0100
From : philpem@... (Philip Pemberton)
Subject: Fw: Fwd: ITV Teletext to shut down in January
Rick Murray wrote:
>> 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),
>
> It would be useful as a grab of the output at any given moment in time
> may be missing rotating pages, newsreel, etc.
Rotating pages *should* be tagged as subpages. Newsreels probably won't
be, and the SAA chip is just going to overwrite the page in-cache every
time it rolls.
> Wire in an SAA5243, use the RGB output functions, gate it to one of the
> memory chips... and on-screen is - duh-duh! Pages from teletext! :-)
I've done that with a teletext card ripped from a Sony TV. Actually that
was an SAA5246, but same idea :)
Had to hack the video output circuitry around a bit, though. Stupid
thing output at 0.3V, my monitor wanted 0V/5V TTL. A bit of wire over
some transistors sorted *that* :)
>> I never said you could do it with a BBC over the 1MHz bus :)
>
> I know you didn't. I'm thinking of how it would be done as it'll be a
> bit time-dependent.
The Magic Box (tm) has its own rolling clock, and timestamps everything
on the way out. Timing between the PC and the box is irrelevant, as long
as you can fill up RAM2 before RAM1 is empty.
> But doesn't the idea write to one RAM while the other is used (via
> various TV sync pulses) to feed the output to the VBI lines? Thus you
> will surely only need one bus along with a method of knowing when it is
> safe to switch RAM?
Um, not quite.
One bus for writing to the "non-current" RAM, which comes from the
microprocessor or FPGA that's dealing with that.
One bus for reading from the "current" RAM, which comes from the output
controller. Address is always driven, data is always Hi-Z (so the RAM
can drive it).
Two 2-way multiplexers, one for each RAM. Input 1 is the "write" bus,
Input 2 is the "read" bus. Output goes to RAM1; the inputs are reversed
for RAM2. Control is the "current RAM" output from the logic.
If you want to limit it to one bus, then you're going to have to play a
few games. Make the bus common to both chips, but leave the RD and WR
lines separate.
The bit rate is ~7MHz for Teletext (actually it's 444 times the line
rate, or 6.9something MHz, but assuming 7 makes the math easier).
Assuming you've got a shift register in the VBI controller logic, you
read one byte every 8 clocks, or 875kHz.
That leaves the RAM idle for the rest of the time. If that 7MHz is your
'main' reference (i.e. the writes occur at the same speed), then you can
use the other 7 clocks to write to the RAM. Meaning you can write stuff
in at (7/8) * 7MHz, or 6.125Mbytes/second.
The catch is you now need a FIFO (or at the very least a 1-byte RAM)
between the logic that's writing to RAM and the bus arbitration logic
(basically: a read has top priority, a write can wait).
So you trade simplicity for using less pins on the gate array. Hmm. It's
a viable (and actually not a bad) idea, just means you have to do more
work to get the timing right. Assuming you wanted to update during the
VBI in the first place...
> That safe, wouldn't there be sufficient time to
> update the RAM during the 300-odd other lines that form the actual part
> of the TV frame?
Good point. I forgot about that part :)
VBI is (say) 20 lines at most, so that leaves another 280 lines to do
RAM reads/writes with, and you'd just need to make sure the read address
counter's outputs can be made high-impedance when the RAM R/W circuitry
is driving the bus.
You're right. Far simpler...
And it also means you wouldn't need two RAMs -- you could just use one
big RAM chip instead (which would most likely be cheaper). Then you can
rewrite pages at the beginning while pages later in memory are being
played out. That is, if the RAM isn't big enough to play your entire
Teletext block out as is.
> 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.
It looks like the Philips IVT (and CCT) chipsets don't mind about the
data clock -- it's locked in from the clock run-in at the beginning of
the VBI line, but it can vary from line-to-line. In real life it
probably doesn't (it's probably generated from the line rate with a
PLL), but the point is not whether it happens, but if it *can* (or at
least if it is *allowed to*) happen.
> Obviously it'll be an assembler routine. We'd need IRQs to say when it
> is safe to write (we *might* get away with one small RAM if we hold it
> in the Beeb and transfer a page before it is due to be output - might
> make the inserter circuitry less complicated too
Truth is, it's not going to be that much easier... You go from using a
RAM address counter to using the frame count and 1/8th of the
bit-counter. You now have two counters instead of one, and some
additional logic to deal with the addressing. Why bother?
> you mention packing
> the data into the RAM but that'll only need to be unpacked again,
> shouldn't we aim to keep the smarts in the software and make the
> hardware only as complicated as it needs to be?
Even on a small FPGA, a binary counter isn't going to consume many logic
cells. But if you go down the discrete logic route, it saves you two,
maybe three 74LS binary counter chips...
Though that said, I don't think I'd even try and build something like
this out of 74LS.
> Anyway, if it is
> feasible to update a smaller RAM during 'picture time' so it can be used
> being VBI time, that might work? A lot more loading on the Beeb though.
I'd worry about wearing the floppy drive out with all the repeated
reading and re-reading...
>> Has anyone got any figures for sustained data rate on the 1MHz bus?
>
> I think this depends on what ELSE is going on. How will we hold our
> pages in memory? A 16KiB array? It is perhaps better to be
> memory-wasteful as it will take less time to 'decode', simply set
> pointers and blat the data across the bus.
Stuff it in the Beeb's RAM in the form it needs to be sent to the TTX
box. Then all you're doing is waiting for an IRQ, sending a block of
data to the box, and waiting for the next IRQ.
OK, so worst case you need to update the clock for each frame --
calculate it beforehand. Or just add an RTC to the Magic Box (tm) and
let it insert the latest date/time whenever it sees a header row being
transmitted.
> :-) I've had little luck in writing an XP-friendly parallel port driver
> for WinTTX (I currently use a hack to permit WinTTX hardware access and
> I bash the parallel port directly), so I'm not sure if I want to
> contemplate talking to USB devices just yet!
It's actually easier to talk to USB devices. You use libusb-win32, which
is a Windows device driver that allows you to talk to USB devices at a
very low level. Basically, you initialise the device, then start reading
and writing USB packets from/to the device.
On Linux you do the same, but you use 'libusb'. Same API, different
implementation, still works the same way.
> Good god - a 1.xGHz PC with a USB port in the region of MeB/sec ought to
> be able to feed a fast DAC in order to totally synthesise a basic video
> frame!
Don't you have a VGA card? :)
> I'd like to rig together a dirt-cheap and dead simple IIC bus to work
> via USB so I can use my teletext receiver via Azumi (no parallel port!).
> Any suggestions? Might also be fun for playing with I/O if there was
> something not unlike a 6522 in capabilities which communicated via USB,
> though as said I worry about the inherent complexity of the driver.
Get an FTDI FT245 development kit. It's basically a USB controllable
8-bit port with two modes -- read/write, and bit-bang. The API is really
easy to use (it's called "FT2XX") and IIRC there's some support in the
chipset for a few common serial buses (like I2C and SPI).
There's also the Hack A Day "Bus Pirate":
http://hackaday.com/the-bus-pirate-universal-serial-interface/
I think it's a bit of an overdone solution (a PIC24F to drive a serial
bus?), and the comms protocol is a bit... verbose. I don't want one, but
I want something like it... :)
--
Phil.
philpem@...
http://www.philpem.me.uk/