Welcome, Guest. Please login or register.


Author Topic: Line timing questions arising from Scroll Demo and The Time's Hand (Read 8535 times)

Offline TomH

  • Newbie
  • Posts: 23
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?

Offline geco

  • EP addict
  • *
  • Posts: 7219
  • Country: hu
    • Támogató Támogató
left margin 9 with right margin 35h should work, it gives  44 character wide screen, if i remember well the maximum displayable screel width is 46 character, left margin 08h right margin 36h

Offline TomH

  • Newbie
  • Posts: 23
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.

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1342
  • Country: hu
  • Stray cat from Commodore alley
I couldn't quite figure it out how these things work but you should give a try to the NICK Internal timing document. There are detailed diagrams how, when and what and parts of video signal composition are triggered.

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1342
  • Country: hu
  • Stray cat from Commodore alley
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.

Offline TomH

  • Newbie
  • Posts: 23
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.

Copying and pasting is apparently very hard for me. This is Scroll Demo.

I couldn't quite figure it out how these things work but you should give a try to the NICK Internal timing document. There are detailed diagrams how, when and what and parts of video signal composition are triggered.

That's one of my sources — check out the top of page 12. /BURST is depicted running from the start of slot 6 to the end of slot 9. Conversely, Time's Hand starts graphics at the beginning of slot 9.

(Unless I've misunderstood the way the comparitors work for effecting left and right margin values)
« Last Edit: 2021.June.29. 23:05:22 by TomH »

Offline TomH

  • Newbie
  • Posts: 23
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.

Offline dangerman

  • EP fan
  • *
  • Posts: 100
Unfortunately I don't have a suitable monitor to hand, but back in the day I used several RGB monitors with the Enterprise and it was definitely possible to get a display that was wider than 42 slots.

I also seem to remember some weird bug with extreme overscan, where the very last slot visible on the right would be a duplicate of the previous slot.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14776
  • Country: hu
    • http://enterprise.iko.hu/
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.

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1342
  • Country: hu
  • Stray cat from Commodore alley
The really interesting thing to know would be what actually real hardware does. Someone should do some oscilloscope measurements on /BLANK /HSYNC /BURST and other possibly relevant signals in cases of 40, 44 and 46 cycle wide raster lines.

<HUNGARIAN>Zozo! Ha szépen kérnénk tudnál oszcilloszkópos ábrákat berakni a /BLANK /HSYNC /BURST és esetleg egyéb a képfelépítésnél fontos jelekről 40, 44 és 46 ciklus széles rasztersorokban?</HUNGARIAN>

Offline gflorez

  • EP addict
  • *
  • Posts: 3615
  • Country: es
    • Támogató Támogató
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.

Offline geco

  • EP addict
  • *
  • Posts: 7219
  • Country: hu
    • Támogató Támogató
As i remember ep can display max 46 char screen width.

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1342
  • Country: hu
  • Stray cat from Commodore alley
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?

Offline TomH

  • Newbie
  • Posts: 23
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?

Yes, exactly that.

For now, for the purposes of my emulator, I have a colour burst being generated when in composite mode through until the end of column 9. So pixels can start in column 10 at the earliest. In RGB mode pixels can start in column 8, the first eight output being four cycles of sync and then four of blank. Though that's under-spec for PAL timing, regardless of the colour burst issue.

It's definitely possible that somebody pulled sync and the burst backwards by two or three cycles, to overlap the refresh fetches in the final three columns of the display, but if that's what happened then it's weird that there's no documentary evidence.

Offline TomH

  • Newbie
  • Posts: 23
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.