Apologies; this'll probably just reveal that I've misread or misunderstood documentation. But here we go. These are a couple of demos that superficially appear to be doing nonsensical or incorrect things, to this observer.

The relevant parts of my understanding of a single Nick line are:

• slots 0–9 are unusable for pixel output because that's where sync and the colour burst occur; and
• mode line parameters are fetched during slots 0–7.

So then can anybody explain how Scroll Demo is acting correctly in defining its vertical sync mode line as being two scan lines long, with a left margin of 0 and a right margin of 63? That's given that the mode line is entered from a region of the border colour.

To my understanding that should produce only a single line of the sync level. By the time the left margin has been read from the mode line, Nick is in column 1. Therefore at no point on the first line will the current column be equal to the left margin, so sync output won't begin. It'll begin at the start of the second line but then end slightly less than a line later when the next mode line is read in, with a different mode byte.

Therefore total sync time will surely be less than a line, not enough to trigger vertical sync on most screens? The PAL standard is 2.5 lines.

My question for The Time's Hand is somewhat more straightforward: it defines a left margin of 9. So am I correct to conclude that its first column simply isn't visible on composite and RF connections? That column should be occupied by colour burst.

I guess an underlying question is whether the numbers given for Nick above were true in production. In theory you could have moved up the sync to overlap the three slots at the end of each line reserved for refresh, and then have finished the colour burst before the mode line is even done. Which would explain Time's Hand, albeit make the problem slightly worse for Scroll Demo. Though an alternative explanation for the former could just be that the developer used an RGB connection, and that route gets pixels from slot 8 onwards, having no colour burst to include?

So I guess probably the answer is that a composite output will not display column 9, since the colour burst is still ongoing, but if you've covered the entire display in pixels then it's not a surprise that some are off-screen. I guess the RGB path ignores the colour burst trigger and can generate pixels from column 8.

Alternatively, it does seem strange to me that there are 11 slots occupied by non-pixel fetches, and — in composite — 10 slots in which pixels cannot be output, but per the documentation the 10 is not wholly inside the 11. There's only 8 slots of overlap.

Oh, and at the time of writing this post both links in you OP point to the same demo. Furthermore, my guess would be that this place has more demos than Pouët.

Slightly to answer my own question on this, I'm pretty confident that Time's Hand (and, I've subsequently discovered, also SIDBASIC) do indeed just specify more graphics than can be expected to appear.

The pre-release technical information is the most explicit, stating that "In practice this value will not be below 10 for the left-hand edge of the CRT"; the final, 1985-era documentation is slightly more oblique but stipulates that "a practical limit to the display width is 42 slots, using a left margin value of 10 and a right margin of 52", although some of that's implied to be due to overscan rather than the front and back porches.

So, no, it probably wouldn't have appeared odd to the authors if they tried their code on a real machine with a composite connection and noticed left clipping.

42 are supported by EXOS/BASIC. It is still have some borders on both side. In machine code program if you want to make borderless screen then need to use 44 or 46 slots.

Off- topic: ergoGnomik: Great your recommendation of the DEEPL translator. It seems to do much better Hungarian translations than google, even on Spanish, the two directions.

As i remember ep can display max 46 char screen width.

Yes, but according to the linked document it is completely incompatible with the standard composite signal format. I guess, Tom would like to know if composite and RGB video differs when display area width is larger than 42 cycles or how does NICK corrupts signal generation if it looks the same?

Apologies; editing seems not to be working. So, briefly to add:

... though there is perhaps a clue in the document that "[the actual display] clocks out on screen a bit later". If it were at least a two-column delay on fetched pixels getting into the video stream and no delay on reaction to the colour burst signal then I guess that would satisfy all the constraints simultaneously.