| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Teletext?
Since a TV generates teletext from some black/white pixels on some unused rasterlines, I wonder if it might be possible to make the c64 generate a teletext signal by putting some bordersprites in that area. Granted ofcuz that the vic chip produces a signal on these lines, and that it's possible with the c64's restrictions to get the right pixels in the right place to get the TV to interpret it as teletext.
Anyone who has experimented with this? |
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
I know me, Graham and some other dude had this discussion quite a while ago and IIRC it's not possible because the dot clock on the C64 is no where near what teletext requires. It's not even possible with the VDC chip of a C128, but it was Graham who explained all this and I might remeber him wrong. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
ninja has serious plans with this, he told me that in a way it is possible to approximately follow the dot clock the teletext needs. ask him for details |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Jack: It was probably me who was the third in the IRC-discussion :) But VDC was no real option, you can't connect it to a TV.
cruzer: The VIC's dot clock is 7.88Mhz, the teletext-carrier 6.95Mhz. I tried it nevertheless, without any result. It might work with additional bit-stuffing, but I have to test it somewhen (to-do-project #6423). I have good documentation about this topic, but just in German, dunno it this would help you. Otherwise you may start here:
http://www.mrgsystems.co.uk/info/tutindex.htm
|
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Yep! Finally a teletext-topic on CSDB;))
It was Prince/TOM who came up with that idea a couple of years ago! We had a little talk about creating teletext with the breadbin, but didn't really get deeper into it. I always wanted to explore this field closer, but as I was too lazy to get hold of good docs, nothing ever happend...
Then Ninja also had this idea - and he directly tried, unfortunatly without success:( Ofcourse this was due to the incompatible Dotclocks. We had some mails about it, but what can one do when 1 Hirespixel is too small and two are too large for creating a correct teletext compatible bitpattern?
Skern, our Hardwaredude I regularly meet on tuesdays, nevertheless encouraged us to give it another try - as the teletextdecoders are not too accurate (according to Skern), a bitpattern which looks approximatly like it _should_ might work; hmm, Ninja calls this "bitstuffing"...
Ninja: good to know that we were always talking about "2-do-Project #6423"-we badly need a date for the bunkermeeting;)) |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
copyfault: Bit-Stuffing is quite a common term :)
http://www.webopedia.com/TERM/B/bit_stuffing.html
Well, as the Dot-clock is higher than the carrier for teletext, the idea to put in additional bits might in deed work (I think it was roughly every 20 bits need a stuffed bit). It's definately worth the try...somewhen :) |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Sounds similar to my 56kbps user port routines. For NTSC, a 56k bit comes in every 17.755677083 clock cycles. I calculated which bits need to be rounded to either 17 or 18 cycles. A constant %11011101 is defined for NTSC mode, and during the byte input I do LSR : BCS *+2 so that every bit that has a 1 gets 18 cycles, every bit with a 0 gets 17. Works flawlessly, and an assemble-time flag flips over to PAL. Sending 56k is too slow to include that LSR BCS trick, so I unroll the 8 bits to achieve the 17.75 cycles per bit using macros to differentiate between PAL and NTSC.
Since sampling bits only occurs at a single point in time, and the C64 dot clock runs faster than teletext, just calculate the exact times that the transitions come out of the C64, and the sample times that the teletext decoder reads the bits, for about 80 dots (3-4 bitstuffed periods). The numbers *should* work out. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
IIRC teletext information is located in the VBI field of the signal, all this of course assumes that the VIC render sprites at that area. Anyone who knows if it does? And also speaking of graphics way outside the screen, why doesn't emulators have choosable overscan parameters, I mean why are they locked? Any good reason for this other than it isn't completly known what happens out there on the real thing? |
| |
WVL
Registered: Mar 2002
Posts: 902 |
iirc the vic displays sprites at the correct positions, so that's not the problem.
THE problem (IMO ;) is the fact that you need more than 24 chars wide gfx display to feed the teletext engine!
that's where the problem arises. Maybe it's doable on c128, with graham's upper/lower border routine in RfO? did somebody ever check the teletext to see what was going on there? :) |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
raster lines 300-311 and 0-15 are blanked, as far as I know this won't allow the vic to output anything but the sync signal. Don't know if this changes anything or if these are the raster lines used by teletext? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
"The characters that make up the teletext page are transmitted in the Vertical Blanking Interval (VBI) of the television signal. Lines 6 to 22 in field 1 and 319 to 335 in field 2 are available to carry teletext data. Each character or control code is represented by a 7 bit code plus an error checking parity bit. If the teletext decoder detects a parity error the characters is not displayed."
Source: http://www.mrgsystems.co.uk/info/6.htm
I guess you're fucked even with the use of $d030 on the C128... Since the VIC chip doesn't output data at the lines needed. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
I think it should be possible using the trick to display data in the 2Mhz-mode on a C128. (By the way, I don't know when Graham found this out. At least, Dizzy Devil showed it to me years before RfO).
Plus, I could imagine that at least some teletext decoders don't care in which line teletext data is being displayed. I mean such a check would require extra logic, just checking the run-in-sequence should be way easier. And the German specs say, that those lines for teletext are "recommended". It doesn't say "only there"
Anyway, both approaches are worth a try :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Graham told me how this worked and it's not about 2Mhz (yes 2Mhz option is in that register aswell). It's another bit telling the VIC to increase $d012 every cycle as long as that bit is set. In effect everything if offset due to skipped rasterlines. However, I'm not sure that the VIC will display at correct lines even still. And about teletext decoders... the teletext is located in the VBI data (i.e. when the raster beam is moving to the top-left corner). There is ofcourse already logic for handling vertical blank :D so I don't really agree with you there Ninja.
I will be suprised if it works... :D But then again the ways of the c64 are mysterious. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
jack: I see, this is the other $d030 issue then. So, we were talking about different things before :)
Still, the specs I have do just recommend teletext to be in the VBI. I don't see a "must" there. I hope this is some kind of backdoor...
But talking won't help us, someone has to try it :) I would do it somewhen, only not now. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@ninja: :D I agree, talking won't help and also a teletext demo would certainly shake the foundation of c64/c128 demo coding. |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
Quote: @ninja: :D I agree, talking won't help and also a teletext demo would certainly shake the foundation of c64/c128 demo coding.
That would shake the foundations... All of a sudden everyone will realize that we did it wrong for 20 years ;-) |
