Is the Amiga capable of Teletext?

[chb]

Originally Posted by Gorf

They would need some input connectors I could actually use ... otherwise I would need a RF-modulator for my A3000 to feed that dongle.

It is also unclear if rgb would work ... the RaspPi it the video outputs composite ... so would BW-composite be enough?

Hmm... I guess BW-composite would be sufficient, as it would simplify the decoder a lot. I cannot imagine they used the color signal, too. But that's just a guess. Some of the Cinergy hybrid sticks (e.g. hybrid T XS) have s-video inputs - I guess it should accept BW composite on the Y input. But no idea if teletext works there too or not.

Originally Posted by Gorf

PS:

that link is just for "DVB-T" dongles ... they expect a digital signal to begin with...

There are also the analog Cinergy ones included (just search for "hybrid"in that list), but you're right, they do not state if the analog part is actually supported or not. From some googling it seems to be the case at least for some of them, but you may be better off with an old Windows box if you choose to go down that route. Or maybe a VM with USB support.

[Gorf]

might be easier to hunt down an old CRT somewhere ... I will keep an eye open.

[Retro1234]

Doesn't have to be CRT

[Gorf]

Originally Posted by Retro1234

Doesn't have to be CRT

to decode and display a correct teletext signal, any TV set will do.
to test overscan modes, blanking intervals, timings ... a CRT is probably more forgiving and you have a more direct feedback.
A flat panel will probably just go blank and/or give you error codes.

[Retro1234]

might still be interesting to use a raspberry pi to get and send the Teletext like Teefax and use the Amiga as the Teletext decoder.

[Gorf]

Originally Posted by Retro1234

might still be interesting to use a raspberry pi to get and send the Teletext like Teefax and use the Amiga as the Teletext decoder.

well - that does require additional decoder hardware for the Amiga.

(and has been done before multiple times ... see hardware book and aminet ...)

[bwldrbst]

Originally Posted by Gorf

to decode and display a correct teletext signal, any TV set will do.
to test overscan modes, blanking intervals, timings ... a CRT is probably more forgiving and you have a more direct feedback.
A flat panel will probably just go blank and/or give you error codes.

I had no problem using that Raspberry Pi solution with flat panel TVs however I doubt any teletext decoder will give you useful messages. Either it successfully decodes lines of text or it doesn't.

The only TVs I have are large ones bolted to walls in rooms where I can't set up an Amiga. I might be able to get my hands on a small one to try this out though...

The teletext decoding is forgiving enough that it works over RF so I think an Amiga in hi-res mode should be able to produce the bitmap.

[Gorf]

Originally Posted by bwldrbst

I had no problem using that Raspberry Pi solution with flat panel TVs however I doubt any teletext decoder will give you useful messages. Either it successfully decodes lines of text or it doesn't.

Not talking about the teletext decoder of course, but about the usual "no signal" message of a modern LCD-TV if there is something not in the normal range..

The only TVs I have are large ones bolted to walls in rooms where I can't set up an Amiga. I might be able to get my hands on a small one to try this out though...

The teletext decoding is forgiving enough that it works over RF so I think an Amiga in hi-res mode should be able to produce the bitmap.

Yes ... the tricky part is to produce it at the right time...

[Retro1234]

Going Completely off-topic I assume you can skip part if you don't have a Teletext TV and use the Raspberry to just display it.

And.......

Apparently BBC is going to stop its Digital Red Button Teletext - they never did replace TeleText with a Good service ok we have the internet but on CeeFax you could display Headlines/New Flash and Sport Scores on Top of the picture and few other things that never got properly replaced.

[Gorf]

Originally Posted by Retro1234

Going Completely off-topic I assume you can skip part if you don't have a Teletext TV and use the Raspberry to just display it.

Well this is completely besides the point...

It is about broadcasting teletext signals FROM the Amiga onto a TV.
Generate on the Amiga, send to video out, into the TV and decode it there!

[ross]

Is the Amiga capable of Teletext?

Yes, it is
https://www.pouet.net/prod.php?which=94736

They encoded Teletext data during vertical blank, awesome!

[pandy71]

Originally Posted by ross

Is the Amiga capable of Teletext?

Yes, it is
https://www.pouet.net/prod.php?which=94736

They encoded Teletext data during vertical blank, awesome!

Only if they created custom video mode compatible with TV standard (PAL?) - explain why AGA worls and ECS may work, or they use different lines (as in theory TXT decoder may start decoding on every line, even in active video).

[ross]

Originally Posted by pandy71

Only if they created custom video mode compatible with TV standard (PAL?) - explain why AGA worls and ECS may work, or they use different lines (as in theory TXT decoder may start decoding on every line, even in active video).

Nah, losso 'opened' the vertical blank to output 'digital' data using bitplanes data.
It is also possible to open the horizontal blank, I have already done it in the past: https://eab.abime.net/showpost.php?p...2&postcount=11
All the sync values are the usual untouched hardwired PAL ones.

EDIT: the super-nice thing here is not the 'VB open' but the Teletext encoder!
Kudos to losso

[drHirudo]

Originally Posted by pandy71

Only if they created custom video mode compatible with TV standard (PAL?) - explain why AGA worls and ECS may work, or they use different lines (as in theory TXT decoder may start decoding on every line, even in active video).

The game runs on the Apollo Core V4+ SA [AGA compatible/SAGA]. Sadly no color is presented, but the game is playable. No music/sound as well.

[ Show youtube player ]

[ross]

Originally Posted by drHirudo

The game runs on the Apollo Core V4+ SA [AGA compatible/SAGA]. Sadly no color is presented, but the game is playable. No music/sound as well.

[ Show youtube player ]

Because this is only the Amiga overlay data (the Teletext data is obviously uninterpreted lacking a decoder).
About the audio, there could be an explaination: the core probably do not rightly emulate the differences for VERTB using VARVBEN.

[ross]

@pandy71
Some technical details.
The hardwired values for vertical blank in PAL are: start at line 0 (inclusive) and stop at line 25 (inclusive).

In ECS and AGA you can decide to change those values (without touching anything about the sync signals!).
So you don't have to create a custom video mode compatible with TV (it's not that trivial to do that), but simply 'extend' the available one

Of course each device is free to behave differently in this regard (thus deciding whether to display video data or interpret 'digital data' for 'other').
The PAL standard defines datas are valid only after 25 blank lines, OSSC instead requires only about 10/11 lines (from here my 408x302 pixels image).
TVs with Teletext decoders as early as line 8 can interpret digital data.

There is a reason for this: A valid PAL frame is defined by 5+5+5 half-lines composed by pre-equs/serrations/post-equs signals.
As you can start with an half line difference (to define long and short frames, ie interlace) you need at least 0.5+7.5 video lines.
Starting counting from 0 you have that the first valid line for any type of output data is line 8 and it is exactly the one used in this case.

This perhaps means that OCS too can manage to do the same since the Agnus y counter can be manually programmed, but we are probably going to open a big can of Worms

[pandy71]

Originally Posted by ross

@pandy71
Some technical details.
The hardwired values for vertical blank in PAL are: start at line 0 (inclusive) and stop at line 25 (inclusive).

In ECS and AGA you can decide to change those values (without touching anything about the sync signals!).
So you don't have to create a custom video mode compatible with TV (it's not that trivial to do that), but simply 'extend' the available one

Of course each device is free to behave differently in this regard (thus deciding whether to display video data or interpret 'digital data' for 'other').
The PAL standard defines datas are valid only after 25 blank lines, OSSC instead requires only about 10/11 lines (from here my 408x302 pixels image).
TVs with Teletext decoders as early as line 8 can interpret digital data.

There is a reason for this: A valid PAL frame is defined by 5+5+5 half-lines composed by pre-equs/serrations/post-equs signals.
As you can start with an half line difference (to define long and short frames, ie interlace) you need at least 0.5+7.5 video lines.
Starting counting from 0 you have that the first valid line for any type of output data is line 8 and it is exactly the one used in this case.

This perhaps means that OCS too can manage to do the same since the Agnus y counter can be manually programmed, but we are probably going to open a big can of Worms

Ok, allow me to rephrase my question - normally PAL active video start in second half of line 23, Amiga has hardcoded first possible active video from line 25 - by creating compatible TV mode i mean using ECS/AGA VARBEAM functionality to reprogram internal sequence so display can be started in line 23 (or in case of TXT occupying normally VBI part of video from line for example 17) so removing hardcoded values and allowing Amiga to start output normally not visible (as digital display will probably not show anything earlier than line 23 - in PAL this line is used for WSS and CGMS), CRT's are different topic as they can be adjusted to show VBI quite easily...

This is also quite interesting as it should allow Amiga to for example produce correct WSS and signal it to display.

Asking because it would be interesting to me to transmit PCM data in VBI to external DAC over videoport.

And to confirm - just checked EN300706 so normally lines "from 6 to 22 and 318 to 335 may be used to carry Teletext data packets" but standard allow use all video lines "except those occurring during the field
synchronization and equalizing pulse periods" so technically to get TXT on screen you may transmit it in visible part of video.

with some remarks:

F.4
Allocation of Teletext packets to VBI lines
Some existing Level 1 and 1.5 decoders may not decode Teletext signals on lines 6, 318 and 319. Thus
these lines should be used for Level 2.5 or 3.5 enhancement data only, or non-Teletext signals
(see annex P). Further information can be found in TR 101 233 [7].
F.5
Use of lines 22 and 335
Some existing decoders will not display the text (usually real time clock information) contained in bytes 39
to 45 of packets with Y = 0 if these packets are transmitted exclusively on lines 22 or 335. Thus if a packet
M/0 is broadcast on either of these lines it may be beneficial to transmit at least once per second an
additional packet M/0 on a line other than 22 or 335. This packet M/0 should not have the Interrupted
Sequence bit set (C9 = 0) and the text part of the header (bytes 14-45) should be consistent with other
page headers in the same magazine. This requirement may be satisfied by a repeated packet X/0 (i.e. a
time filling header) or the page header for enhancement data and under these circumstances a specific
additional packet may not be required.
F.6
Teletext transmissions outside of the VBI
Teletext packets may be inserted on any or all of the lines outside of the VBI. This is referred to as Full
Field or Full Channel transmission. The following points should be noted:
1)
The LSB of the designation code (byte 6) of a packet 8/30 (Format 1 or 2) should be set to 1 to
indicate to a decoder that Teletext packets can occur outside of the VBI.
2)
The packet 8/30 should be transmitted in the VBI period so that it can be detected by a decoder
working in its default mode after power-up or a change of channel (see annex D.3).
3)
Once enabled to receive Teletext packets from any line in the field, some existing decoders will not
attempt to clear explicitly the old page from memory prior to receiving a new page, either on first
reception of a page or in response to the C4 (Erase Page) control bit. Consequently, row adaptive
transmission techniques should not be adopted and the C4 control bit should not be used.
Thus it is necessary to arrange that the old page in the decoder's memory will be erased fully by the
arrival of a new page. It is recommended that packets X/0 to X/23 (and X/24 where applicable) are
broadcast for every page in the service. If a packet X/26 is used by any page within the service then
such a packet should be transmitted for every page, even if it contains only Termination Markers
triplets (i.e. no information). Packets X/27 and X/28 containing dummy or default information may
also be required for each page.
If it is known that all decoders can erase the old page immediately on receiving an appropriate page
header then pages can be broadcast row adaptively and the C4 control bit can be set.
4)
The transmission rules of annexes B.2 to B.8 inclusive apply, apart from the need for a page
erasure interval with a MIP (annex B.8, point 2) when the recommendations in point 3 above should
be considered.

[drHirudo]

Any video link to this presentation:

[ross]

Originally Posted by pandy71

Asking because it would be interesting to me to transmit PCM data in VBI to external DAC over videoport.

This is a bit different than Teletext signals: it use the 'display' part of the line (the famous ~52us).
For PCM signals I imagine that you have a regular frequency flux and therefore you could potentially fall on the (unusable) synchronisms/horizontal blanking part (or can you use spaced regular packets?).
In experiments I was able to use at most about 204 out of 227 CCK/line for output data on OSSC.
Probably some devices could do a little more but then we collide with the impossibility for Agnus to use all the cycles for the bitplane fetch.
But I have no idea what you want to do so I wouldn't know

And beware: Amiga line counting is different from PAL standard counting.
The hardwired 0 line is where the pre-EQ pulses begin (at start or half line position).
In PAL you can see 311 or 623 because it count always as interlace and it start from '1' by serration pulses from first field..
Amiga instead always counts from 0 and restarts from 0 also from the second field (one long and one short).
So to all intents and purposes the first line after the post-EQ on the Amiga is line 8.
The same goes for when you calculate line '25'.

[losso]

Why, hello there!

Originally Posted by drHirudo

Any video link to this presentation:

The party's seminars are supposed to be up on YouTube soon, I am told. Apart from that, I'm preparing a little write-up and test tool, and will post an update here.

Cheers