Enterprise Forever
:UK => Hardware => Topic started by: TomH on 2021.June.29. 15:43:02
-
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 (https://www.pouet.net/prod.php?which=51358) 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 (https://www.pouet.net/prod.php?which=51358) 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?
-
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
-
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.
-
I couldn't quite figure it out how these things work but you should give a try to the NICK Internal timing (http://enterprise.iko.hu/technical/NICK-Internal-timing-of-VDC-Elite.pdf) document. There are detailed diagrams how, when and what and parts of video signal composition are triggered.
-
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 (http://ep128.hu/Ep_Demo/Demo.htm) place has more demos than Pouët.
-
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 (http://ep128.hu/Ep_Demo/Demo.htm) place has more demos than Pouët.
Copying and pasting is apparently very hard for me. This is Scroll Demo (https://www.pouet.net/prod.php?which=51387).
I couldn't quite figure it out how these things work but you should give a try to the NICK Internal timing (http://enterprise.iko.hu/technical/NICK-Internal-timing-of-VDC-Elite.pdf) 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)
-
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 (http://enterprise.iko.hu/technical/NICK-Old-VDC-ELITE-description.pdf) 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 (http://enterprise.iko.hu/technical/ET1-3_Nick_Chip_Programmers_Guide.pdf) 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.
-
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.
-
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.
-
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>
-
Off- topic: ergoGnomik: Great your recommendation of the DEEPL translator (https://www.deepl.com/translator#en/es/naive). 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.
-
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?
-
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.
-
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.