Possible Hold bug - Githubissues

ZXGuesser commented 8 years ago

Edit: disregard this, I'm an idiot who can't count...

rawles commented 8 years ago

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.

ZXGuesser commented 8 years ago

This isn't really the same bug but it is to do with held mosaics;

What is the reasoning behind ignoring character 0x1B (ESC) when considering held mosiacs? I understand that that control character isn't implemented to do anything, but even if it was it is set-after so the held character should be displayed I think. My TV does display it for what that is worth.

It also resets the held character to the space on the level 2.5+ size control codes (0x0E and 0x0F). It would be nice to have an option to select this behaviour, like with the allowing and ignoring of codes 0x00 and 0x10. I realise that this is all a bit academic to most people since you can't currently enter any of these control codes in the editor :)

Edit: updated url to fix error on row 7

rawles commented 8 years ago

Thanks, I'll look into this later. In the meantime, here's the engineering test card that I've been using:

ZXGuesser commented 8 years ago

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.

ZXGuesser commented 8 years ago

The example posted above and in the readme is a dump from a BBC micro which explains the repeated double height rows. The green text at the bottom was added by the micro and was not part of the transmitted page.

rawles commented 8 years ago

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?

ZXGuesser commented 8 years ago

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 The later one is based on a combination of that, and a couple of data captures people have sent me. I created everything in edit-tf and added the few unavailable codes by setting a breakpoint in the debugger and changing values manually.

rawles commented 8 years ago

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?

ZXGuesser commented 8 years ago

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.

rawles commented 8 years ago

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.

ZXGuesser commented 8 years ago

What about Conceal? The specification isn't explicit about what happens to concealed held mosaics. In my rendering software I don't display the held mosaics when concealed. This was also the behaviour of the BBC's in-vision decoder: https://i.ytimg.com/vi/b1ZKzh7LgF4/hqdefault.jpg

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. My rubbish "Level 1 with foreground black" TV does reset the hold graphic on these, but the BBC in vision decoder apparently did not.

rawles commented 8 years ago

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.

ZXGuesser commented 8 years ago

That all looks good to me. The case that the specification isn't clear about is what gets displayed for something like this:

rawles commented 8 years ago

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?

ZXGuesser commented 8 years ago

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." Nowhere does it say which of those statements has priority or whether the SPACE substituted by conceal still counts as a "SPACE corresponding to a control character" as a "location where substitution is permitted" If it was anywhere I'd expect it to be in Annex G where it gives the example of held mosaics not being affected by switching to separated mosaics etc.

rawles commented 8 years ago

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.

rawles / edit.tf

Possible Hold bug #32