-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible Hold bug #32
Comments
Sorry, just got around to this. If you're sure you're mistaken I'll close the bug. Feel free to re-open it if you later discover similar problems. |
Yeah I saw that in the readme. I'm not sure where that has come from because it starts a row early and has extra text at the bottom that I've never seen on any photographs or screenshots. I'm trying to get hold of a proper dump of that version of the test page as transmitted and if so I'll put together a proper version of that one too as I'm interested to see whether it avoids using the problematic control codes that stop the original from displaying on modern TV sets that respond to some level 2.5+ codes. |
I've had a quick look through the SAA5050 and ETS300706 specs and they seem to imply (but not explicitly state) that any character between 0x00 and 0x1F is a spacing/control character, which I think is your opinion too. I'll try to implement this soon. About the testcards, it would be useful to have a definitive testcard that also includes all the really fiendish corner cases. I was wondering how you had constructed the test cards that you linked? |
Well the very early one comes from this photograph: https://web.archive.org/web/20160117232136/http://www.pembers.freeserve.co.uk/Teletext/Ceefax1-Engineering2.jpg |
After having looked at the code I noticed the actual behaviour we're after is to only ignore these codes (0xA, 0xB, 0xE, 0xF, 0x1B) if we're in text mode. In graphics mode we go through to the held graphics handling, which should fix this. If you have a chance, perhaps you can verify that this works in the way you'd expect. About the testcards, I think it might be useful to make a small collection of them in a subdirectory with the expected display as a graphics file. What do you think? |
What should actually happen is kind of undefined for level 1. 0x0E and 0x0F have meanings at level 2.5+ but are "interpreted by some existing level 1 and level 1.5 decoders" as with alpha black and mosaics black. 0x0A and 0x0B have no effect unless a page is a newsflash or subtitles page but held mosaics should be displayed for them. 0x1B toggles character set so that accents can be displayed etc. but again that's something that's not implemented so it can just be left as a no-op with held mosaics displayed. My TV makes a mess of displaying the test card, and the BBC's in vision decoder has at least one held mosaics bug too as far as I can make out. A gallery of testcards along with expected output is a good idea though. Sort of an Acid rendering test for teletext. I've been meaning to do that on my website for a while and still not got around to it. |
Thanks for the information. It sounds like things are at least improved with the fixed today. The following frame demonstrates that all the control characters display held mosaics now, well, except for the for 'new background' (0x1D), which is 'set at'. Still not sure what to do about 0x0E and 0x0F. I've read documentation that says they can also be interpreted by some decoders as double height. I don't think they should do these things in edit-tf, but since they are both set-after, I think it makes sense to substitute mosaic graphics as in the other cases. Do you agree? The gallery of testcards would be very useful, I think. |
What about Conceal? The specification isn't explicit about what happens to concealed held mosaics. 0x0E and 0x0F do double width and double size at level 2.5 so presumably out of scope for edit.tf. The spec says that some decoders interpret 0x0F as double height, but that's just a warning note, I don't think that should be implemented. The other question is whether the double width and double size codes would count as a "change of size" to a level 1 decoder and thus clear the held mosaic. Again the specification doesn't say. I think on balance I would lean towards them not doing, and just treating them as a no-op. |
As it stands, in the editor you can set a held graphics character in concealed text and then use it outside of the concealed block (which you'd need to terminate with a mosaic control character). The following frame shows this behaviour, and also happily appears to show compliance with the European standard, at least for some aspects of held graphics. |
Nice! Thanks for exposing all these bugs! The ETS spec says "At a screen location where substitution is permitted, the 'Held-Mosaic' character inserted is the most recent mosaics character with bit 6 = '1' in its code on that row.". I guess that's whether the character is concealed or not. Should those NH characters be showing up in the block of concealed characters, though? |
That's the thing. It also says "The following characters up to the end of the row, or until a Colour Code attribute is encountered, are to be displayed as SPACES until revealed by a decoder or user operation." |
I could test these cases out on a BBC Micro this week and see what the SAA5050 does, report back here, and try to match its behaviour in the editor. I think it might be useful for people implementing editors, frame renderers, etc., to have a page somewhere detailing what various decoders do in these cases. We could make a mini-project for this - like you say, an Acid rendering test for teletext. |
Edit: disregard this, I'm an idiot who can't count...
The text was updated successfully, but these errors were encountered: