ENTERPRISE KLUB
2021. október 2., 1055 Budapest, Nyugati tér 9. 14-19 óráig
Belépés kizárólag klubtagok részére! (Klubkártyával vagy előfizetéssel!)
Welcome, Guest. Please login or register.


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

Offline TomH

  • Newbie
  • Posts: 23
  • OS:
  • Mac OS X 10.14.6 Mac OS X 10.14.6
  • Browser:
  • Safari 14.1.1 Safari 14.1.1
    • View Profile
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: 6289
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 89.0.4389.86 Chrome 89.0.4389.86
    • View Profile
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
  • OS:
  • Mac OS X 10.14.6 Mac OS X 10.14.6
  • Browser:
  • Safari 14.1.1 Safari 14.1.1
    • View Profile
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: 1058
  • Country: hu
  • Stray cat from Commodore alley
  • OS:
  • Windows NT 6.3 Windows NT 6.3
  • Browser:
  • Firefox 78.0 Firefox 78.0
    • View Profile
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: 1058
  • Country: hu
  • Stray cat from Commodore alley
  • OS:
  • Windows NT 6.3 Windows NT 6.3
  • Browser:
  • Firefox 78.0 Firefox 78.0
    • View Profile
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
  • OS:
  • Mac OS X 10.14.6 Mac OS X 10.14.6
  • Browser:
  • Safari 14.1.1 Safari 14.1.1
    • View Profile
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
  • OS:
  • Mac OS X 10.14.6 Mac OS X 10.14.6
  • Browser:
  • Safari 14.1.1 Safari 14.1.1
    • View Profile
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

  • User
  • *
  • Posts: 99
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 89.0 Firefox 89.0
    • View Profile
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

  • EP addict
  • *
  • Posts: 14023
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 89.0 Firefox 89.0
    • View Profile
    • 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: 1058
  • Country: hu
  • Stray cat from Commodore alley
  • OS:
  • Windows NT 6.3 Windows NT 6.3
  • Browser:
  • Firefox 78.0 Firefox 78.0
    • View Profile
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>

Online gflorez

  • EP addict
  • *
  • Posts: 3191
  • Country: es
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 89.0 Firefox 89.0
    • View Profile
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: 6289
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Chrome 89.0.4389.86 Chrome 89.0.4389.86
    • View Profile
As i remember ep can display max 46 char screen width.

Offline ergoGnomik

  • EP addict
  • *
  • Posts: 1058
  • Country: hu
  • Stray cat from Commodore alley
  • OS:
  • Windows NT 6.3 Windows NT 6.3
  • Browser:
  • Firefox 78.0 Firefox 78.0
    • View Profile
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
  • OS:
  • Mac OS X 10.14.6 Mac OS X 10.14.6
  • Browser:
  • Safari 14.1.1 Safari 14.1.1
    • View Profile
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
  • OS:
  • Mac OS X 10.14.6 Mac OS X 10.14.6
  • Browser:
  • Safari 14.1.1 Safari 14.1.1
    • View Profile
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.