If you are using Windows - then you might be interested to try WinTTX...?
If If you use Teletext for DOS within the !PC environment
on a RiscPC's x86 co-processor, you can now (with the help of the ARMEdit module) access the
RISC OS IIC system directly - no more changing leads around!
Sorry, this doesn't work on 'real' PCs, you'll need to build/use the parallel lead described. :-)
I understand the concept of stress - mechanical, mental, whatever. So in order to simply 'look' and see what's on teletext, I don't really fancy powering up my RiscPC unless I plan to use it for a while. That left me with two choices. I could either use one of the myriad of other RISC OS machines; or I could use my laptop...
In favour of the RISC OS machines was that my software already existed, would fit on a floppy,
and would work.
The minus point? No available monitor. I didn't fancy any plug swapping.
In favour of the laptop... Well, it had a built-in display (well, three quarters of a built-in
display, the lower quarter doesn't work!). And, well, that was, like, totally, IT!
No software, no lead, hell this thing didn't even have an IIC port!
Which sounds, to me, like an interesting challenge.
My first step was to construct an IIC lead. After a look at my options, we were down to parallel
or serial. I only needed two inputs and two outputs (yes, I've wired the clock as an input,
it isn't beyond the realms of possibility that the laptop AND the RiscPC will daisy-chain the
IIC bus in the future). Looking at it, I decided on the parallel port. Mainly because I had
a spare printer lead I could cannibalise. That, hooked to half of an old Econet lead, and there
we had it...
I don't know a thing about 80x86 assembler, and after suffering it for a few days at college
(nearly ten years ago), I DON'T even want to learn it. So I cobbled together some
bit-bashing software in C.
I make it sound simple. Actually it was a few days of pure hell, trying to correlate the IIC specification to code, while keeping in mind that control signals on the parallel port are sometimes inverted just to p*ss off us programmers.
One thing went out the window immediately, and that was the whole concept of timing. The
sleep()" function works in seconds, and the
delay()" function works in milliseconds. The BIOS is no good, it's timer
is something really weird like eighteen-and-a-quarter ticks per second.
I tried a couple of experiments. Writing bits to a memory array was fast, writing bits to the parallel control register was slower; this proving to me that the parallel port was clocked slower than the main memory... good.
The IIC bus can operate up to a maximum of 100kbit/s. The minimum LOW period should be
4.7µs and the minimum HIGH period should be 4µs - so obviously I should try
bit-bashing the data right to the port. I had a brief worry that it'd be too slow, but then I
remembered that there was a parallel lead for my teletext receiver when I first bought it. If an
8MHz A3000 (ARM2) and discrete-logic parallel port can fake an IIC bus, surely-to-god this thing
can do it.
[A week later... I ran the IIC stuff in single-stepping mode in the debugger, which must have achieved about one bit per second (and giving me RSI!), and it still worked!
Interestingly running Teletext (for DOS) in a DOS window within Windows 3.11 on the PC co-pro froze Windows nastily. Oh dear! I put this down to an "emulation issue"]
The greatest thing about IIC is that the master (that's us) clocks data received from the slave (that's the teletext receiver). So we don't need to worry about losing sync along the way. If, at the end of a 'line' we spend a few extra processor cycles resetting stuff, it's no big deal, we're providing the clock so it'll wait for us. Not forever, I don't think, but for long enough.
You can't imagine the joy when, after setting the teletext receiver up on the RiscPC (my code didn't tune yet), and then running TELETEXT.EXE after swapping leads, I got a dump of CNN's rolling header. Yay!
This was cobbled together into a basic frame-fetch loop, and thus Rick's Teletext v0.00 was born.
Quite frankly, the rest wasn't difficult. :-)
I don't know if similar software already exists. I like to think this is something a little bit special because, not only does it do colour (and flashing text), it also attempts to convert the teletext 6-block mosaic to something vaguely-akin in the PC-ANSI character set. And, talking of character sets, this supports the "national option" characters for England, Sweden, Germany, France, Spain, and Italy (the 'western european set') - so viewing a German-language page will show the correct thing, like "überbabe" instead of "¾berbabe", or something...
Software name : Teletext (for DOS) Latest version : 0.15 Archive size : 118806 bytes (Zip deflate archive) Classification : Freeware Registration cost : None MS-DOS compatible : Yes Windows 3.xx compat. : Yes, in a DOS window Windows 9x++ compat. : Untested, should work... Requires... : 80286 or later, and DOS with hardware access to the parallel port. This is most 'common' PCs, but there may be 'issues' with NT or DOSEMU if they restrict parallel port access. YOU'LL NEED TO BUILD YOUR OWN PARALLEL LEAD IN ORDER TO USE THIS SOFTWARE... INSTRUCTIONS INCLUDED WITHIN THE ARCHIVE. Written in : C (compiled with TurboC++ v1.0) Libraries : Standard, ARMEdit, and my IIC driver library
|Teletext (for DOS) v0.15 with some examples.|
IT REQUIRES SOME SORT OF PC RUNNING (MS-)DOS.
If you aren't entirely sure about the parallel wiring, here is a diagram (this is also supplied with the software):
wiring.exesoftware, which is why it says to press 'I' or 'PrintScr', etc...
The WinTTX parallel wiring is slightly different - in this case, pins 15 and 16 are joined to allow auto-detection of the teletext cable. WinTTX will work with the lead as detailed above, it will just ask you to check that the lead is connected every time you start the program.