Understanding the Union Demo's Opening of left and right borders

[TomH]

I have read the wiki's summary of the horizontal state machine plus various threads here. I decided to disassemble the segment of code in the Union Demo's menu screen that opens both left and right borders — that's the segment where you control Charly and walk into whichever room you desire, and it opens the left and right borders for a brief period at the bottom of the display in order to show a full-width scroller.

I got:

Code: Select all

;
;	Prior to entry:
;
;		a1 = $ffff8260	(i.e. 72Hz override)
;		a0 = $ffff820a	(i.e. 50/60Hz mode selection)
;
;		d2 = 4, d4 = 0
;
;		(and a3 = $ffff8240, the start of the palette, a5 = pointer to a colour table, d0 = line count-1)
;

begin:
	0:	nop
	4:	move.b	d2, (a1)	; switch to 72Hz at n = 8
	12:	move.b	d4, (a1)	; switch to 50Hz at n = 16

	20:	moveq	#20, d1
loop:
	24...:	nop
	28...:	dbf	d1, loop

; d1 was loaded with 20, so loop occurs 21 times; in net,
; factoring in Dtack delay on the first access in the dbf each
; time, it costs:
;
;	20 * 
;		np [nop], n np np [dbf, branching] = 16 
;	+ 1 *
;		np [nop], n np np np [dbf, no branch due to counter expiry] = 20
;
;	= 340 cycles total, and it started at n = 24
;	=> it ends at n = 364

	364:	nop
	368:	nop
	372:	nop

	376:	move.b	d4, (a0)	; switch to 60Hz at n = 380 [+ 1] = 381
	384:	move.b	d3, (a0)	; switch to 50Hz at n = 388 [+ 1] = 389

	392:	nop
	396:	nop
	400:	nop
	404:	nop
	408:	nop
	412:	nop
	416:	nop
	420:	nop
	424:	nop
	428:	nop
	432:	nop
	436:	nop
	440:	nop

	444:	move.b	d2, (a1)	; switch to 72Hz at n = 448
	452:	nop
	456:	move.b	d4, (a1)	; switch to 50Hz at n = 460

	464:	move.w (a5)+, $1e(a3)	; palette change

	480:	nop
	484:	nop
	488:	nop
	492:	nop
	496:	nop

	500:	dbf	d0, begin	; branch taken, so +12 = 512, as expected.

Slightly weird formatting — I've added the number of cycles since the loop began as a first column. The +1s attributed to the moves at 376 and 384 are because the Wiki appears to attribute a one-cycle latency to `820a` changes.

Pulling out just the mode changes, I get relative spacings:

• 8: switch to 72Hz;
• 16: switch to 50Hz;
• 381: switch to 60Hz;
• 389: switch to 50Hz;
• 448: switch to 72Hz;
• 460: switch to 50Hz.

The demo synchronises itself to the state machine prior to entering this loop by watching for a change in current video address. You could probably guess, but specifically:

• the switch to 72Hz at the 8th cycle of the loop and to 50Hz on the 16th opens the left border by toggling into 72Hz mode across wiki cycle 4;
• the switch to 60Hz at 381 and back to 50Hz at 389 opens the right border by switching from 50 to 60 between wiki cycles 372 and 376; and
• the switch to 72Hz at 448 and back to 50Hz again at 460 removes horizontal blank by being in 72Hz mode during wiki cycle 450.

Actual questions, then:

If all of the above is correct, and the wiki information is sufficiently complete, DE will first go active at wiki cycle 4, and will remain active until hsync begins at wiki cycle 462.

That seems to imply 462 - 4 = 458 cycles of load being active. So 114 loads (and partway towards a 115th, but without reaching it).

114 isn't a multiple of four. It's 28 columns of four words, plus another two words.

So, question one: is 114 loads correct according to that evidence? Have I made any errors in my workings so far?

Questions two and onward: if 114 words is correct, what happens to the dangling two words? The wiki mentions a check as to whether the FIFO is full every 16 cycles — is that 16 cycles while load is active (rather than in geeneral), and is the count to 16 reset when load goes inactive? If so then is it correct to think the dangling two words will be fetched but not used?

I can't see how a model where the two words get used on the next line works, without ending up with pixels over the retrace period that would really mess up the output. But maybe my complete understanding of the Shifter side of things is amiss?

[ijor]

At a "normal" fullscreen, like the Level 16 screen at Union Demo, DE is active for 460 cycles, not 458. You can't infer the exact DE timing from the switches timing. It doesn't work like that. A switch doesn't provoke a DE edge immediately. It just puts GLUE on a state that it will trigger or skip the edge at its own timing.

460 cycles means 115 words loaded by Shifter. Still not divisible by four. That's exactly the reason that the stabilizer is needed. Otherwise Shifter will mix the remaining words with the first ones at the next line. With the stabilizer the remaining words are read but discarded and not displayed.

[TomH]

I didn't infer DE timing from the switch timing. The wiki lists the relevant events as:

• cycle 4: IF(71) H = TRUE
• LINE-50: IF(!71) HSYNC = TRUE && H = FALSE

LINE is 512. So LINE-50 = 462.

462 - 4 = 458.

I'm tempted to guess that the horizontal timing given in the wiki is probably wrong about HSYNC placement? That it should probably list LINE-48 and LINE-8 as the start and end of HSYNC?

I also have to plead ignorance as to how stabilisation works, as: (i) words are always fetched at the same rate, regardless of mode; and (ii) the FIFO always needs to have four words in it before the shifter is loaded, regardless of mode. That's not covered on the wiki page at all though, so I dare imagine more forum trawling will allow me to answer my own questions.

[ijor]

I didn't infer DE timing from the switch timing. The wiki lists the relevant events as:

• cycle 4: IF(71) H = TRUE
• LINE-50: IF(!71) HSYNC = TRUE && H = FALSE

LINE is 512. So LINE-50 = 462.

I can't comment too much on the wiki rationale. It is written from a programmer point of view. And I'm looking at this from the hardware side. But that line seems to be wrong in anycase, HSYNC and DE don't change simultaneously at the same cycle.

I also have to plead ignorance as to how stabilisation works, as: (i) words are always fetched at the same rate, regardless of mode; and (ii) the FIFO always needs to have four words in it before the shifter is loaded, regardless of mode.

Yes, words are always loaded every four cycle. This doesn't depend on Shifter but on MMU instead, and MMU is not aware about the current resolution or video mode. And yes, Shifter "normally" reloads the shift registers every four loads.

But Shifter might get confused and produce some weird behavior. See this for more details: http://www.atari-forum.com/viewtopic.ph ... 58#p292507

[TomH]

Oh, fantastic, thanks!

I think that was my main error then: taking those numbers from the top of the wiki page as if they were definitely hardware numbers, and not probably a mix of confirmed hardware things and observed software things. I'll imagine for myself that probably there's something like a two-cycle latency in sync being activated and a sync interrupt being signalled to the 68000, as that seems like the simplest way to explain the discrepancy.

Just one more question though, if you'll tolerate it:

If DE remains active 460 cycles, running right up against HSYNC, even if you ignore the latency in LOAD relative to DE, why does that not result in pixels being output during the blanking period?

The best explanation I can guess for myself: SYNC usurps the shifter — it can keep shifting if it likes, but the output isn't used — so the sync level still gets through to the composite signal, it usurps it for long enough to completely hide any output tail, and if you've been careful to keep your syncs steady then you can be confident that a screen isn't going to predict a retrace ahead of the one you actually signal?

[ijor]

If DE remains active 460 cycles, running right up against HSYNC, even if you ignore the latency in LOAD relative to DE, why does that not result in pixels being output during the blanking period?

Shifter, or DE for that matter, has nothing to do with blanking. Even on a normal non fullscreen, Shifter keeps outputting the background color (that doesn't even have to be black) during blank.

Blanking is implemented separately with dedicated discrete hardware. See the schematics. It is possible, though, to alter blanking because it depends on the BLANK signal produced by GLUE. A few demos use this feature to hide some lines.

[TomH]

I explained myself poorly, though you probably answered my question anyway; it was more a concern that if you’ve done away with the blanking period as this demo appears to, and you’re still outputting pixels right up until sync begins, it seems to me that you run the risk of not outputting blank during retrace.

But I guess what’s happening here is that the final pixels are obscured by the sync level, and after that output is in 72Hz mode, so the border colour is the blank level, and by the time 50Hz is reestablished the retrace is over.

[ijor]

But I guess what’s happening here is that the final pixels are obscured by the sync level, and after that output is in 72Hz mode, so the border colour is the blank level, and by the time 50Hz is reestablished the retrace is over.

Blanking is only indirectly related to sync. The hardware performs blanking as long as the BLANK signal is asserted. The blank pulse is much wider than the HSYNC pulse. See the charts here: http://dev-docs.exxoshost.co.uk/Monitor ... 4-1986.pdf

[TomH]

Again, I might be relying too much on the wiki as hardware documentation rather than an observed-from-the-CPU documentation, but it has the blank level never being activated by the loop as from that demo — it’s in 72Hz mode as the raster crosses that test, and if it’s true then there is no special blanking period for 72Hz mode, which is why I assume the border black is close enough to the blanking level to satisfy Atari’s engineers.

So that was my concern, though I think I already answered it: why the machine wouldn’t put non-black levels onto the wire during the period when we can assume the CRT is in retrace.

[ijor]

Again, I might be relying too much on the wiki as hardware documentation rather than an observed-from-the-CPU documentation, but it has the blank level never being activated by the loop as from that demo — it’s in 72Hz mode as the raster crosses that test ...

I thought it used the other style of stabilization that doesn't switch to mono. Doesn't matter ...

GLUE forces BLANK at the start of hsync at the same time it negates DE. That seems to be missing at the wiki. Probably because it is difficult to determine by software.

Edit: Fixed typo (negates DE)

[Eero Tamminen]

TomH, once things are clear, could you update/clarify the wiki? Separate HW & SW side of the matter etc...

[TomH]

Cool, I see now that my earlier statement about blank not existing in high-resolution mode was false; the wiki thinks that in that mode, with no other intervention, blank will go active 20 cycles after DE was deactivated (and 180 cycles after DE was activated). Though it doesn't think it will ever be deactivated, and doesn't have anything to say about hsync in high-resolution mode so clearly it's very partial.

I mean, that makes more sense as if memory serves the blank level is supposed to be even blacker than ordinary black and is used for calibrating signal amplitude. So you don't want to try to hand wave that away.

I had made some edits to that wiki page for readability even before starting this thread; I'll try to fold what I've learnt back in. I mean, those HSYNC times look wrong because they'd result in only 458 cycles of DE active, which doesn't seem to give the 115 word fetches that are not only definitely correct but also mentioned in the same article under 'sync line lengths'.

[ijor]

I had made some edits to that wiki page for readability even before starting this thread; I'll try to fold what I've learnt back in. I mean, those HSYNC times look wrong because they'd result in only 458 cycles of DE active, which doesn't seem to give the 115 word fetches that are not only definitely correct but also mentioned in the same article under 'sync line lengths'.

I'm not sure it is actually wrong. Again, it is a matter of perspective. In first place, the HSYNC timing seems to be right. The discrepancy is with the DE timing. But the cycles on the wiki table DO NOT represent the actual timing of the signals. The table shows at which cycle GLUE checks the value of the current frequency. They are not the same thing:

Code: Select all

LINE-50 	IF(!71) HSYNC = TRUE && H = FALSE 

This line might be wrong if you interpret it as HSYNC and DE are both triggered simultaneously at the same cycle. But that's not what it means. Remember it was compiled (by Troed) from a software analysis. What that rows means (or at least, what Troed meant), is: If at cycle LINE-50, resolution is not high, then GLUE will assert HSYNC and deassert DE (eventually).

GLUE will negate DE two cycles after asserting HSYNC. But this will happen only if resolution wasn't high already two cycles before. To be more precise, GLUE negates DE as an indirect consequence of HSYNC being already asserted. This produces the internal delay.

I do agree that this is not very clear at the wiki. And perhaps it should be.

Edit: Typo again at the DE polarity

[TomH]

But the cycles on the wiki table DO NOT represent the actual timing of the signals. The table shows at which cycle GLUE checks the value of the current frequency. They are not the same thing

I don't think the Wiki takes a clear position on what it's documenting, and if anything implies itself to be a hardware documentation:

"The following is a pseudo code description of how the circuitry involved in creating scanlines, including sync pulses and displaying of pixel data, functions in the Atari ST and STE."

Plus of course: "At any specific comparison cycle this means the GLUE will use the FREQ value written one cycle before RES.", which doesn't quite make perfect sense in context† but treating it as meaning to say that writes to FREQ have a one-cycle latency, would indicate sub-four-cycle precision. So not exclusively from the CPU's point of view.

Though, taking the opposite argument — again, I'm voting for lack of clarity more than anything else — it does also feature a discussion of precision clearly aimed directly at emulator authors that should put a reader on alert that there's a limited precision at play.

† it literally implies that changes to FREQ after a change to RES are ineffective — "GLUE will use the FREQ written [...] before RES".

[ijor]

I don't think the Wiki takes a clear position on what it's documenting, and if anything implies itself to be a hardware documentation:

It might be not clear, but I know from talks with Troed what's exactly the meaning of that table. Furthermore, the whole philosophy of the article is, obviously, from a software point of view, at least most parts of it. Even if you would change the table entry we are talking about (DE at HSYNC start), it would still be mostly a software interpretation. The hardware doesn't really work like that. For starters, those cycle numbers have no meaning at the hardware.

But yes, it is misleading and even sometimes contradictory because some other parts of the article are more hardware oriented. But the table we are talking about it is definitely a software concept.

[TomH]

Okay, so then I think I will plan to edit the Wiki to make it explicit that the timings in that table are given only to a four-cycle precision and may show some inaccurate aliasing* — i.e. they're those that are observable from the CPU** and that's all.

* specifically, if the two events lumped together at LINE-50 in the table really occur at least one cycle's duration apart, then it feels like it should be possible they'd fall into different buckets depending on wakestate.

** or, rather, observably altered by a human based on CPU activity, I guess. Which isn't that easy to phrase concisely.

[ijor]

Okay, so then I think I will plan to edit the Wiki to make it explicit that the timings in that table are given only to a four-cycle precision and may show some inaccurate aliasing* — i.e. they're those that are observable from the CPU** and that's all.

No. I don't think that is an accurate description of the table. The table is cycle accurate, there are no aliases. You are just misinterpreting the meaning of the table. May be it is my fault that I'm not explaining this good enough (in addition that this is not explained at the article either). Let me try again:

The table shows at which cycle GLUE checks the current frequency to decide if it will take certain actions on the SYNC, BLANK & DE signals. The values don't necessarily represent at which cycle GLUE will actually trigger the action. It is only the cycle at which the decision will be made.

Find a better wording and put that paragraph in the wiki

For instance, let's take a simple case:

Code: Select all

cycle         Action
52 	        IF(60) H = TRUE 

What the above row means is that at cycle 52, if frequency is 60Hz, then GLUE takes the decision to enable hDE. This doesn't mean that (if vDE is on) DE will be raised immediately. It just means that if by cycle 52, frequency is not 60Hz, then the action would not take place.

To be precise at the specific case of what exactly happens the start of HSYNC:

Code: Select all

cycle      Action
LINE-50 	IF(!71) HSYNC = TRUE && H = FALSE 

This means that if resolution is not high at cycle LINE-50, then GLUE makes the decision to assert HSYNC and to negate DE. Again, the actions themselves are not immediate, and in this specific case they even have different delays. But the decision, for both actions, is taken at precisely that cycle, together. In other words, you can say if you want, that GLUE negates DE at LINE-48. But the decision is taken at cycle LINE-50.

And the real description of what happens at the hardware is as I posted in a previous message. DE here is negated as an indirect consequence. GLUE first asserts HSYNC. Then, two cycles later, only because HSYNC is asserted and disregarding the value of the counter, it negates DE. But if HSYNC wasn't asserted in the first place, then DE would not be negated.

Just for the record, the hardware is even more complicated than that. There are two separated horizontal counters, one for SYNC and other for BLANK/DE. But again, the article, or at the very least, this table, is from a software point of view.

[uko]

Thanks ijor for this very clear explanation !

[TomH]

I understand what you're saying (at last!), which I would boil down as: the table lists the times at which tests occur on CPU-accessible state. It does not specify the times at which actions will occur as a result. Further, where it lists two results from one check it does not mean to suggest that those actions are atomic.

And, formally, precision of the test times is unspecified, though the aside discussion on emulation implies it to be two-cycle precision (subject to the caveat about a FREQ delay).

One more follow-up then: it also seems implicit that the actions listed in the table will occur in close proximity to the tests, but is that valid? If so, can a threshold be put on that proximity? Which I guess is the same question as: which of those consequences is most distant from its corresponding test?

[ijor]

the table lists the times at which tests occur on CPU-accessible state.

I'm not sure I understand the meaning of "on CPU-accessible state" in this context. I'm not sure it is needed.

It does not specify the times at which actions will occur as a result. Further, where it lists two results from one check it does not mean to suggest that those actions are atomic.

Correct. Not sure the term "atomic" is the best wording, but the concept is correct.

And, formally, precision of the test times is unspecified, though the aside discussion on emulation implies it to be two-cycle precision (subject to the caveat about a FREQ delay).

I didn't actually check the values, but I think the precision of the table should be a single cycle. Otherwise it would not match at least one wakestate, and probably Troed tested all the wakestates. Also GLUE video processing has a two cycle precision only.

One more follow-up then: it also seems implicit that the actions listed in the table will occur in close proximity to the tests, but is that valid? If so, can a threshold be put on that proximity? Which I guess is the same question as: which of those consequences is most distant from its corresponding test?

The exact absolute timing has no strict defined meaning on the hardware. The hardware has pipelines and all soft of internal delays. What is cycle #68? How exactly you define at which cycle GLUE performs the test? What matters is the pipeline flow and the relative distances. This is why hardware timing is usually defined with waveforms.

I would need to check the table to be more precise. But in general the delay is always the same for all the entries in the table with the exception that we discussed (DE on LINE-50). And again, the delay in that case is different for the reason I already explained.

[Playmobil]

sorry for my ignorance (and my poor english) : I keep an eye on this topic, I understand HSYNC, GLUE, etc etc, but what is DE ?

[TomH]

I'm not sure I understand the meaning of "on CPU-accessible state" in this context. I'm not sure it is needed. ... Not sure the term "atomic" is the best wording, but the concept is correct.

In a conversation where each of us has repeatedly misunderstood the other, I don't know how helpful it is to start picking at language now that there seems to be some clarity. But, constructively, I've started chipping away at the Wiki page so if you're in the mood for linguistic review then that might be an appropriate avenue.

sorry for my ignorance (and my poor english) : I keep an eye on this topic, I understand HSYNC, GLUE, etc etc, but what is DE ?

I think DE is an actual hardware signal, which might explain the slight redundancy in the programmer's model of this part of the subsystem, but to my understanding, in the model:

• the vertical state machine has an output, V, which is active on lines that should have pixels on them;
• the horizontal state machine has an output, H, which is active for a portion of the line closely related to the portion which would have pixels on it;
• DE is the logical AND of those two outputs, and actually dictates where pixels are.

Heavy caveat: there will be a wakestate-dependent delay of 3–6 cycles between a change in DE and a change in whether Shifter is currently loading data. And, at the start of a line its FIFO will be empty, so it'll then take a further four loads before it has enough data to start outputting any pixels, and there will be two more cycles of work before any of those pixels actually makes it onto the wire.

(With the caveat's caveat that the FIFO should be empty in the normal order of things, but if you deliberately play sync tricks then it might not be)

[ijor]

In a conversation where each of us has repeatedly misunderstood the other, I don't know how helpful it is to start picking at language now that there seems to be some clarity. But, constructively, I've started chipping away at the Wiki page so if you're in the mood for linguistic review then that might be an appropriate avenue.

Didn't mean to be picky. Sorry. I'm not native English speaker, I won't make semantic or grammar editions to the wiki.

sorry for my ignorance (and my poor english) : I keep an eye on this topic, I understand HSYNC, GLUE, etc etc, but what is DE ?

DE stands for "Display Enable" and id a signal produced by GLUE. As implied by its name, it indicates to the system when display is active. As noted by TomH, there are several delays from DE edge to actual video output.

[alien]

In a conversation where each of us has repeatedly misunderstood the other, I don't know how helpful it is to start picking at language now that there seems to be some clarity

Ijor's English is much better than is being suggested above. And Ijor knows what he is talking about since he reimplemented the entire Atari ST on the MIST in VHDL.

In particular I find the following sentence perfectly clear, and it states precisely what the table is supposed to show.

The table shows at which cycle GLUE checks the current frequency to decide if it will take certain actions on the SYNC, BLANK & DE signals. The values don't necessarily represent at which cycle GLUE will actually trigger the action. It is only the cycle at which the decision will be made.

Out of perfectionism, and to prevent any further confusion, I suppose one could add the following to the Wiki

The table shows at which cycle the GLUE tests the current frequency to decide if it will change the SYNC, BLANK & DE signals. The signals will actually change a little later, not necessarily synchronously.

However I am not convinced it is necessary. The table assumes people know that no physical process is instantaneous. This is particularly true for electronic circuits, since it takes them a while to stabilize on an output value. That is why one samples signals on each clock (or half clock) edge in synchronous circuits.

Further, where it lists two results from one check it does not mean to suggest that those actions are atomic.

The correct terms here are test and synchronous. Atomic means indivisible. An atomic operation can take multiple cycles.

The table lists the times at which tests occur on CPU-accessible state.

This is incorrect. The Glue and the Shifter both contain a copy of the resolution register $FFFF8260. One of these copies is not "CPU-accessible" in the sense it is not readable by the CPU, but it changes its chip's behaviour nevertheless.

[TomH]

Ijor's English is much better than is being suggested above. And Ijor knows what he is talking about since he reimplemented the entire Atari ST on the MIST in VHDL.

The quoted statement makes no qualitative claim about Ijor’s English at all, and indeed there are no grounds on which to do so. I can’t fault it, and haven’t. This is my first comment on it at all.

However I stand by what the quoted statement actually says — that editing each other’s posts is not constructive, and therefore won’t engage on that.

Out of perfectionism, and to prevent any further confusion, I suppose one could add the following to the Wiki

The table shows at which cycle the GLUE tests the current frequency to decide if it will change the SYNC, BLANK & DE signals. The signals will actually change a little later, not necessarily synchronously.

Added many hours before you posted:

“The table below lists the times at which certain tests are applied. If a test is passed, the consequence or consequences will apply at a time shortly afterwards. They will not necessarily occur simultaneously”.