<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Mon, 27 Jul 2009 19:22:25 +0200
From   : rick@... (Rick Murray)
Subject: Fw: Fwd: ITV Teletext to shut down in January

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


> True, I just thought it'd be nice to be able to choose what was on 
> screen as well :)

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


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

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


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

Count lines. After 'x', generate an interrupt. The controller computer 
will then have at least 200 lines worth of time in which to write a 
kilobyte to RAM. If it doesn't reckon it can manage it this quickly 
(say, caching a new page set off disc), it can just ignore until the 
next IRQ, and so that time around the data output will be another copy 
of what went out the last cycle.


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


> Valid page numbers range from 100 to 8FE -- magazines 1 thru 8,
                                                         ^^^^^^^^
Only in end-user terms, otherwise zero through seven, with the '8xx' 
pages being in reality '0xx'.


>   - The copy loop must be incredibly tight. Thinking about using BASIC? 
> Think again.

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


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

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.


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

:-) 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!


 > So definitely possible on a PC.

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!


> I prefer USB though. Much easy to code for. And test. And do the PCB 
> layout...

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.



Best wishes,

Rick.

-- 
Rick Murray, irregular internet access at local library.
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>