horizontal scrolling on ST

[npomarede]

Possibly. When I wrote LoSTE I actually modified my wakestate detection code so that the "failure" to support wakestates in Hatari would result in the demo detecting a suitable wakestate (WS2, IIRC, since that's the closest wakestate to the timings used by Hatari) for the rest of the code. Now naturally no code written before 2006 will try to detect wakestates - but it could be that SFORSTV (would need to be verified) tries to detect the current wakestate and modifies its code according to what Hatari manages to do, or not to do. Which might make things worse/more difficult to handle.

2 cycle accurate statemachine video.c for Hatari 1.9? I promise to help out

I don't think SHFORSTV was specifically tailored to match Hatari by using a specific wakestate, it was more Hatari that was modified to match this demo and happens to be detected as one of the possible/compatible wakestate

As for Hatari 1.9, video and cpu are indeed next on my personnal list of things to get as close as possible as a real STF/STE No doubt your timing synthesis will be useful to compare with what is already used in Hatari.

[Steven Seagal]

About Panic.tos, I mentioned it here:
http://www.atari-forum.com/viewtopic.ph ... 75#p241882

I see that it hits at cycle 56 in Hatari too, I wondered if maybe there was a timing problem in Steem.
Steem has 2 cycles accuracy and handles WU states (of course), and it can run Forest aka SHFORSTV in WU1 or WU2, but it doesn't help in this case. 56 is too late in all states.
My current explanation is CPU speed, because the routine bringing us to y-30 is a CPU-based delay loop, and in some thread Paolo states his ST is slower than our emulated PAL ST.
There's a new option 8,0Mhz in Steem just for that.

[troed]

My current explanation is CPU speed, because the routine bringing us to y-30 is a CPU-based delay loop, and in some thread Paolo states his ST is slower than our emulated PAL ST.

That's of course easy to verify- just run it on a normal 8.02MHz STF and see if it's stable. I've just moved house (and am additionally abroad atm) but if I remember to I can do that when I have my Ataris back up and running.

(I'm actually looking to acquire a "slow ST" for my own curiosity's sake)

[npomarede]

In pouet.net comments, paulo mentions "If you have problems in running this on your ST hardware, try the 1 byte updated version, you can find at Atari-Legend. This is caused by the different ST MMUs that control the top border openning. Both versions work fine on my 1985 ST."
Unfortunately, I couldn't find this version on atari-legend.

But from this comment, I think it's more MMU / wakeup state related (I know Paulo's ST had some problem with Leonard's fullscreen in Nostalgic-o-demo).
Maybe Paulo will read this and could tell us what was modified in the other version of Panic.

[Steven Seagal]

In pouet.net comments, paulo mentions "If you have problems in running this on your ST hardware, try the 1 byte updated version, you can find at Atari-Legend. This is caused by the different ST MMUs that control the top border openning. Both versions work fine on my 1985 ST."
Unfortunately, I couldn't find this version on atari-legend.

Based on Alien's article the different MMUs changed the lines of top/bottom border removal by something like 16, but it could have other differences.
Now that troed mentions it, it seems improbable that this demo would only run on slower STF.
We definitely should have the other version to compare.

[Steven Seagal]

I found the fixed version at atari-legend.
It hits at emulator cycle 24 so there's no chance to trigger a spurious +2 line.
I also saw that comment at pouet:

But for some weird reason it flickered like hell on my 1040 - I can't imagine what went wrong.

which may justify my approach (older, slower STF OK).

[troed]

My current explanation is CPU speed, because the routine bringing us to y-30 is a CPU-based delay loop, and in some thread Paolo states his ST is slower than our emulated PAL ST.

That's of course easy to verify- just run it on a normal 8.02MHz STF and see if it's stable. I've just moved house (and am additionally abroad atm) but if I remember to I can do that when I have my Ataris back up and running.

(I'm actually looking to acquire a "slow ST" for my own curiosity's sake)

I forgot to check, right?

"Normal" STF and all (PAL) STE: 8.02MHz
Some STF: 8.010MHz
Paulo STF: 8.007MHz

(Besides the posts in the hwtest04 thread here I'm asking anyone who sells an Atari in a popular Swedish retro group to test their hardware as well - since I want to buy a non-8.02 machine)

I specified PAL since at least one NTSC (Mega) STE is 8.05MHz but I haven't seen others post theirs to know whether it's a general difference.

"SYNC lore" knew about the different speeds. Our top and bottom border code (triggered by MFP timers) had two separate switches to accommodate real hardware we'd stumbled upon.

/Troed

[Dio]

The master clock crystal and derived CPU clock table is:

Code: Select all

PAL (all variants)	    32.084988	8.021247
NTSC (pre-STE)	        32.0424	  8.0106
NTSC (STE)	            32.215905	8.053976
Peritel (STE) (as PAL)	32.084988	8.021247
Some STFs	             32.02480	 8.0071

There aren't a lot of the 32.02480 ones around; the two I have data on are both 1040STFs manufactured at around Q2 86, probably on the rev C board, and the 1040STFs from late 86 on rev D seem to be on 32.0424. One hypothesis is that it was the standard crystal in early STF machines; the reason behind it I have no idea, since earlier modulator-less STs seem to be on the NTSC standard crystal. That's inferred from only about a dozen motherboards, mind.

STF can be seen with either PAL or NTSC crystal too.

It shouldn't (famous last words) affect the (digital) part of the video timing in the slightest; the main effects are:
- video timing in the analogue domain (the actual output frame rates and line times)
- pitch of the PSG, on non-STEs, since it's fed by a divider
- timing with the 2.4576MHz MFP clock.

I also have no indications that the clock nudger present to align the main clock with the chroma clock in ST(F)Ms and PAL STEs affects video timing at all, although I haven't been able to show on a scope the actual effect of the clock nudger yet.

[troed]

There aren't a lot of the 32.02480 ones around; the two I have data on are both 1040STFs manufactured at around Q2 86, probably on the rev C board, and the 1040STFs from late 86 on rev D seem to be on 32.0424. One hypothesis is that it was the standard crystal in early STF machines; the reason behind it I have no idea, since earlier modulator-less STs seem to be on the NTSC standard crystal. That's inferred from only about a dozen motherboards, mind.

STF can be seen with either PAL or NTSC crystal too.

Many thanks Dio - that'll help me a lot in trying to acquire one of the "slow" machines

[Dio]

I'd definitely focus on the C070523 rev C 1040STFs then.

Actually I do have a couple of theories as to why: the simplest is that Atari saw some cheap crystals that were slightly out, and plumped for 'em; another is that someone misread / miswrote the number and they ended up with a batch of the wrong crystal. 32.0424 vs. 32.0248 is pretty close after all, wouldn't have taken much for a transposition error to occur.

[troed]

Right, so, I've now acquired a "slow" (8.01MHz) ST It's a Mega ST4 - without blitter - making it an early one.

Observations so far: It seems to like WS2. Really really like. I've actually not been able to boot it into any other wakestate yet It also seems to favour a (speculation) Shifter mode that is "banded" compared to the WS2 my other 1040STFM gets into easily.

... and this is what I'm currently researching as well. Speculation:

WS2, being the wakestate with the longest DE-to-LOAD, requires an additional cycle to clear the Shifter when doing sync line tricks. This might also be influenced by the current Shifter state - and the Shifter might additionally migrate between cold/warm.

/Troed

[Steven Seagal]

Right, so, I've now acquired a "slow" (8.01MHz) ST It's a Mega ST4 - without blitter - making it an early one.

It would be cool if you could test panic.tos v1 on your slow Mega.
http://www.pouet.net/prod.php?which=14827

In this thread I mentioned various programs that caused an unwanted "+2" line on STE if we used timings of 36-40.
After some changes in Steem CPU/MFP emulation, that problem disappeared so sorry for those false alerts.

I also ran some tests on a real STE.
Conclusions:
On the STE, prefetch starts 16 cycles earlier only if HSCROLL is non null.
But the Glue makes its starting decision (threshold for +2) 16 cycles before it does on the STF anyway.
So there must be some internal registers to hold the result of this decision, as strange as it may seem.
Why not? We've already seen the same thing for # line cycles.

[troed]

I also ran some tests on a real STE.
Conclusions:
On the STE, prefetch starts 16 cycles earlier only if HSCROLL is non null.
But the Glue makes its starting decision (threshold for +2) 16 cycles before it does on the STF anyway.
So there must be some internal registers to hold the result of this decision, as strange as it may seem.
Why not? We've already seen the same thing for # line cycles.

I'm not sure I understand. The writeup I did on the STE "GLUE" and the impact of pre-fetch is "complete", I think*. What type of register would you mean is needed?

Cycle Action
0 IF(RES == HI) PRELOAD = TRUE
28 IF(RES == LO) BLANK = FALSE
36 IF(FREQ == 60) && (RES == LO) PRELOAD = TRUE
40 IF(FREQ == 50) && (RES == LO) PRELOAD = TRUE
56 IF(FREQ == 50) LINE = PAL
58 Also related to line length similar to above for 50/60Hz. Unknown cause.
164 IF(RES == HI) H = FALSE
184 IF(RES == HI) BLANK = TRUE
372 IF(FREQ == 60) && (RES == LO) H = FALSE
376 IF(FREQ == 50) && (RES == LO) H = FALSE
448 IF(RES == LO) BLANK = TRUE
460 IF(RES == LO) HSYNC = TRUE && H = FALSE
500 IF(RES == LO) HSYNC = FALSE

The following pseudo code describes how PRELOAD gets handled:

WORDS_READ=0
WHILE(PRELOAD == TRUE) {
LOAD
WORDS_READ++
IF(RES == HIGH AND WORDS_READ=>1) PRELOAD = FALSE
IF(RES == LO AND WORDS_READ=>4) PRELOAD = FALSE
}
H = TRUE

In regular HI resolution the routine will exit after four cycles (one word) and in LO resolution it will take 16 cycles (four words). This is what makes the STE timings for raised DE match up with ST.

http://www.atari-wiki.com/?title=ST_STE ... ine.2C_STE

*) "Complete" in that as in science I first formed the hypothesis, then predicted that it should be possible to create +4 and +6 lines on STE - and after that went ahead and tested those line lengths successfully based on my pseudo-code.

[Steven Seagal]

I'm not sure I understand. The writeup I did on the STE "GLUE" and the impact of pre-fetch is "complete", I think*. What type of register would you mean is needed?

A kind of variable, like your LINE=PAL.
Another possibility is that the Glue acts as you say HSCROLL or not, raising LOAD but putting 0 on the bus instead of video memory if HSCROLL=0. Like this we would have fewer strange registers, and it's compatible with your writeup.

[troed]

Another possibility is that the Glue acts as you say HSCROLL or not, raising LOAD but putting 0 on the bus instead of video memory if HSCROLL=0. Like this we would have fewer strange registers, and it's compatible with your writeup.

Hmm. Now I haven't ever done any STE hw scroll coding myself so my knowledge on how it works is based on writeups by others. It's quite telling that it's possible to gain 16 pixels always though.

In the STE there's no separate GLUE/Shifter/MMU anymore. We can speculate as to all the reasons of why - but one reason besides lower cost could be that the amount of signals between these chips was getting high when adding hw scroll. The only "chip" able to do the 1 pixel manipulation needed by hw scroll is the "Shifter", so I don't think there's anything else needed in the GLUE statemachine. It simply raises PRELOAD earlier than on the ST, and the signal PRELOAD is then handled according to the pseudo-code as seen by the "GLUE", but as seen by the "Shifter" it then takes the hw registers into account when deciding when to start outputting pixels. (And since the chips are no longer separate this is of course not separate logic with separate signals). This also suggests the "MMU" puts the video addresses on the bus earlier than on the ST for the information to already be available for the "Shifter" to output - if anyone has scoped that it would be good to verify.

/Troed

[Steven Seagal]

Hmm. Now I haven't ever done any STE hw scroll coding myself so my knowledge on how it works is based on writeups by others. It's quite telling that it's possible to gain 16 pixels always though.

This is handled in Steem and there's also this (simplified) code when the program reads the video counter.

Code: Select all

...
 if (HSCROLL<>0 at cycle 0)
   bytes_ahead=bytes_ahead+8
...
  starts_counting=CYCLES_FROM_HBL_TO_LEFT_BORDER_OPEN/2 - bytes_ahead
...
  c=CyclesIn/2-starts_counting
...
  video_counter=video_counter_at_cycle_0 + c
...
 return video_counter

In short, the value is adapted by 8 if HSCROLL<>0.
That's correct or many programs wouldn't work. And I also (think I) saw this on my STE.
Video counter starts earlier only if HSCROLL<>0, I try to reconcile this with your writeup.

In the STE there's no separate GLUE/Shifter/MMU anymore.

I'd like this to be clarified, I've read MMU+GLUE, or MMU+Shifter, so is it GLUE+MMU+Shifter?

We can speculate as to all the reasons of why - but one reason besides lower cost could be that the amount of signals between these chips was getting high when adding hw scroll. The only "chip" able to do the 1 pixel manipulation needed by hw scroll is the "Shifter", so I don't think there's anything else needed in the GLUE statemachine. It simply raises PRELOAD earlier than on the ST, and the signal PRELOAD is then handled according to the pseudo-code as seen by the "GLUE", but as seen by the "Shifter" it then takes the hw registers into account when deciding when to start outputting pixels. (And since the chips are no longer separate this is of course not separate logic with separate signals). This also suggests the "MMU" puts the video addresses on the bus earlier than on the ST for the information to already be available for the "Shifter" to output - if anyone has scoped that it would be good to verify.

/Troed

In your writeup you state yourself that the video counter doesn't change:

VAR PRELOAD MMU starts LOADing Shifter with words for hardware scroll purposes, no screen address changes

I don't see how the MMU can fetch memory and not change the counter, nor what it does after preload in that case: fetch same memory? Always prefetch 8 bytes in advance of counter?
I think that your fine explanations for those shifter tricks, included 2 novel ones you found:

Code: Select all

4  IF(RES == LO) PRELOAD will run until cycle 16  (56-16)/2 = +20  
44  IF(RES == HI) PRELOAD will exit after 4 cycles  (376-44)/2 = +6  
48  IF(RES == HI) PRELOAD will exit after 8 cycles  (376-48)/2 = +4  

work because the video memory isn't fetched during preload when HSCROLL=0.
If you compare +26 with +20, on a +20 line, there are 12 cycles/6 bytes more of non-fetching during preload.

[troed]

I'd like this to be clarified, I've read MMU+GLUE, or MMU+Shifter, so is it GLUE+MMU+Shifter?

GST MCU == GLUE+MMU - http://info-coach.fr/atari/hardware/STE-HW.php

(The STE Shifter is also modified from the ST, see later)

In your writeup you state yourself that the video counter doesn't change:

I don't see how the MMU can fetch memory and not change the counter, nor what it does after preload in that case: fetch same memory? Always prefetch 8 bytes in advance of counter?
I think that your fine explanations for those shifter tricks, included 2 novel ones you found:

The comment in the STEEM codebase seems correct http://atarilegend.com/viewtopic.php?f=1&t=23461

The MMU is responsible for putting the address of video mem to read on the bus. It's up to the MMU to then advance the video counters - and it's of course able to put an address on the bus if the prefetch register is used without actually changing the video address until 16 cycles later. This is what allows the 16 pixels trick, by turning pre-fetch on and then immediately pretending to not use prefetch.

That's separate from GLUE timings. It always (I assume - I haven't tried sync switching while playing with the hw scroll registers but I don't see a reason for that to affect anything) signals 16 cycles earlier than on the ST to _allow_ the MMU to make the decision depending on the hw scroll register values.

The Shifter reads from video mem when told by the MMU that there's data, and it can then choose to either output pixels directly or to hold them in an internal register until 16 cycles later. This is similar to how its already working with IR and RR registers (as per Alien's writeup). According to the french article linked earlier the STE Shifter indeed has access to HSCROLL:

In fact, if you look at the video addresses (figure 10), you will notice that another register is also on bits 8 and 9: VIDEOMOD which makes it possible to indicate the resolution to the shifter, but also to the GLUE (GST MCU on STE). Thus at address FF8260 correspond two registers one in the shifter and one in the GLUE. The only video registers which are in the shifter of the STF are the COLORS and VIDEOMOD. Indeed, this shifter only has 5 bits of address. The GST SHIFTER is equipped with a sixth address bit address for the additional register HSCROLL and certain registers of its sound DMA, but all the other video registers of figure 10 are in located in the GST MCU.

http://info-coach.fr/atari/hardware/STE-HW.php

If all this sounds like a kludge it's because it is Atari needed to add hw scrolling whilst still being backwards compatible.

(And I'd love to see someone scope this explanation. We know the GLUE makes the screen start decision 16 cycles earlier than on ST - but the explanation of when the MMU puts what address on the bus etc is all logical deduction from my side. It doesn't matter for the applications running on the hardware, but it would be really good to know whether the deduction is correct at the signaling level)

/Troed

[Steven Seagal]

Notice that the "magic" cycle for right off is 376 on the STE like on the STF, HSCROLL or not, as seen in some demos.
From that I draw that real prefetch is advanced only in case of HSCROLL<>0.
One would expect 360 from what you say.

I have another question, about the DE line.
It goes into the MMU and into the Shifter.
To the MMU it says "fetch". To the Shifter it says "shift". But the timing of those events is different. Is it possible that the Glue asserts DE only for one of those chips, using 'chip select'?
In the traces by dio, DE seems to be OK for the MMU, but I noticed that DE is negated while the Shifter still must LOAD its last word, then shift 16 more cycles.

[edit little correction]

[troed]

Notice that the "magic" cycle for right off is 376 on the STE like on the STF, HSCROLL or not, as seen in some demos.
From that I draw that real prefetch is advanced only in case of HSCROLL<>0.
One would expect 360 from what you say.

I don't understand how you came to that conclusion. As is documented in my writeup on the wiki, 376 is the cycle for end of 50Hz line on both STF and STE. It has nothing to do with prefetch.

I'm sorry but I don't understand what problem it is you're trying to solve. Help me out When it comes to HSCROLL I'm certain that's solved completely by the Shifter. In theory the MMU _could_ do things differently depending on HSCROLL but I don't see the need for it.

I have another question, about the DE line.
It goes into the MMU and into the Shifter.
To the MMU it says "fetch". To the Shifter it says "shift". But the timing of those events is different. Is it possible that the Glue asserts DE only for one of those chips, using 'chip select'?
In the traces by dio, DE seems to be OK for the MMU, but I noticed that DE is negated while the Shifter still must LOAD its last word, then shift 16 more cycles.

"Keep it simple". The GLUE is a very simple state machine, there are no indications of any logic as complicated as keeping two different states for MMU and Shifter. That's solved most easily by those chips/functions themselves.

[Steven Seagal]

I don't understand how you came to that conclusion. As is documented in my writeup on the wiki, 376 is the cycle for end of 50Hz line on both STF and STE. It has nothing to do with prefetch.

I'm sorry but I don't understand what problem it is you're trying to solve. Help me out When it comes to HSCROLL I'm certain that's solved completely by the Shifter. In theory the MMU _could_ do things differently depending on HSCROLL but I don't see the need for it.

I understand it so: once the MMU has started fetching video memory, it goes on while DE is asserted, so it would be between cycles 40 and 360 on a normal STE line. DE should stop at cycle 360, not 376 or one raster too many is fetched. But we know it stops at 376.
Or should we understand that during 'preload', the MMU fetches video memory without DE signal, without incrementing the video counter? This may seem "far fetched" (lol ) too.
HSCROLL is probably not handled only by Shifter, when HSCROLL<>0, one more raster must be fetched per scanline, it's not up to the Shifter.

"Keep it simple". The GLUE is a very simple state machine, there are no indications of any logic as complicated as keeping two different states for MMU and Shifter. That's solved most easily by those chips/functions themselves.

I know it makes no sense but otherwise I don't see the use of DE in the Shifter. In his article Alien says it switches border/image, but the timings of DE don't support that.

[troed]

I understand it so: once the MMU has started fetching video memory, it goes on while DE is asserted, so it would be between cycles 40 and 360 on a normal STE line. DE should stop at cycle 360, not 376 or one raster too many is fetched. But we know it stops at 376.
Or should we understand that during 'preload', the MMU fetches video memory without DE signal, without incrementing the video counter? This may seem "far fetched" (lol ) too.

Whatever's easiest to implement in silicon while staying backwards compatible is likely what Atari did. Since we know it's possible to always gain 16 extra pixels to the left we can safely assume that the combination of GLUE screen synchronization, MMU address counters and Shifter display can do scanlines that start at cycle 40 and end at 376.

I would assume the following, but then again, I've never done any STE specific coding. Too new-school for me.

$FFFF8264 r/w |....xxxx| Undocumented STE pixel hard scroll
$FFFF8265 r/w |....xxxx| STE pixel hard scroll

GLUE always asserts PRELOAD at 40. This signal is used by the MMU to put the current videomem address on the bus (*DCYC), the Shifter reads it and fills internal registers. Depending on the hardware scroll registers the Shifter either outputs the pixels immediately (which would cause them to appear 16 pixels early on screen compared to STF) or waits for 16 cycles to "match up". Whether the MMU lags behind in updating the video counters or not I guess we'd need to scope to really know.

The model above fits well with the STE 16-pixel trick, and the comments in the STEEM codebase: http://www.atari-forum.com/viewtopic.php?f=1&t=23461

GLUE always deactivates DE at 376. Either the MMU makes the extra words for a 168 byte lines available and just doesn't increase the video counters for the last 8 bytes depending on HSCROLL (I don't think there's an ack from the Shifter having read words), or the last 8 bytes is only put on the bus when needed.

HSCROLL is probably not handled only by Shifter, when HSCROLL<>0, one more raster must be fetched per scanline, it's not up to the Shifter.

Sure, but these chips are not likely to contain a lot of logic to handle separate functions - the workings are most likely the same as much as possible no matter the hw scroll registers.

I know it makes no sense but otherwise I don't see the use of DE in the Shifter. In his article Alien says it switches border/image, but the timings of DE don't support that.

Well, it's true for the STF, which Alien documented. That some changes (a "delay" function in the Shifter) happened in the STE doesn't take away much from it. I also don't see what you mean by it not being supported by the timings - it seems to fit to me

/Troed

[Steven Seagal]

I also don't see what you mean by it not being supported by the timings - it seems to fit to me

/Troed

I mean, when DE is asserted around cycle 56, the Shifter is still displaying border, and when the Shifter starts shifting around cycle 84, DE was already asserted. When DE is disabled, the Shifter keeps on LOADing and shifting for a few cycles. This is all apparent in Dio's traces. So, DE doesn't seem to be a switch border/image as Alien wrote.

[troed]

I mean, when DE is asserted around cycle 56, the Shifter is still displaying border, and when the Shifter starts shifting around cycle 84, DE was already asserted. When DE is disabled, the Shifter keeps on LOADing and shifting for a few cycles. This is all apparent in Dio's traces. So, DE doesn't seem to be a switch border/image as Alien wrote.

Well, I'd say that's semantics. DE controls border/image but then there's a lag in the Shifter regarding when pixels start and stop being output on the RGB pins.

STF:

Code: Select all

MMU detects GLUE DE at cycle 62 and raises LOAD at cycle 64. From this we can calculate the DL-moniker for the ST wakestates depending on when GLUE raised DE:

64-58 = 6 = DL6
64-59 = 5 = DL5
64-60 = 4 = DL4
64-61 = 3 = DL3

After LOAD it takes 16 cycles, plus 2 due to internal delays, for the Shifter to set the first values on the RGB pins. As long as DE is high LOAD will loop with new data available. For each word read by the Shifter the MMU will increase the video counter.

/Troed

[Steven Seagal]

I checked ST schematics for DE and it's interesting.

It's something like that (admire my ASCII graphix)

Code: Select all

GLUE ----------------T--------- MMU
                     |
                     |
                     +--------- Shifter
                     |
                     |
                     +--------- MFP (timer B in)

We know the timings of 'DE' for MMU and we know the timing of Timer B.
The difference between those timings is 28 cycles.
It doesn't add up.
I would better understand such graphic:

Code: Select all

GLUE ------------DE-----------> MMU
                                 |
                                 | LOAD
                                 |                     
                                 V                    
MFP (timer B in) <-----DE------Shifter

[ijor]

Hi everybody,

This thread caught my attention

I don't know much about the STE, actually, I never owned one. But I think I do know something about the ST chipset. I did some partial reverse engineering of the chipset internals. Unfortunately I never had the time to finish and publish my work. The bad news is that I didn't make anything Atari for some years. So my memory about all this stuff is a bit, ok not just a bit, fuzzy. But i can tell you a couple of things that might be helpful.

GLUE (plain ST) logic is not as simple as you might think. There is more than just a single video horizontal counter, and video sync (HSYNC and VSYNC) and video output (DE) are not driven by the same state machine. This might not make much sense until you remember a small detail ...

The ST is designed to be able to receive external video sync for implementing a gemlock device. Ok, it didn't work very well until the STE added the capability of feeding external clock, and not just external video sync. But good or not so good design is not the point here.

The point is that GLUE is designed to receive external video sync. This, obviously, dictates much of the internal video logic.