horizontal scrolling on ST

[troed]

What matters is what you see. This line -29 should be 60hz (NTSC) but you see that it starts at the 50hz position (PAL), so that's what happens, right?
You couldn't know, but there's a hack in Steem for precisely this program at this scanline, when the shifter counter is read, the value has to be as for a 50hz line (starting at cycle 56), if it's 2 bytes higher (starting at cycle 52), the screen is broken.
I thought it had something to do with Steem internal problems, but your visual inspection implies that it's a ST issue.

Working:
-30 - 388:S0000 474:S0000 496:r0900 512:T0100 512:#0000
-29 - 004:r0900 024:r0900 044:r0900 064:r0900 084:r0908

Is line -29 508 or 512 cycles in the working scenario? I've redone my visual check and there's a very obvious 4 pixel difference between line -29 and -28 that the only explanation I can think of I really should just write code to test.

Anyway,

It's relatively straight forward to convert Paolo's Excel-sheet into a pseudo-code state machine. I might do that later.

This is a first stab at it - and mostly just to show what I mean. It's not fully complete (STE lacking, doesn't use H to trigger actual line starts/ends), and currently only deal with line lengths. It's very similar to Alien's pseudo-code state machines for a reason - those were pretty complete besides the new wakestate knowledge.

Code: Select all

VAR H; H signal as per Alien's doc
VAR LINE; PAL = 512 cycle 50Hz, NTSC = 508 cycle 60Hz, HIRES = 224 cycle 71Hz
VAR RES; $ff8260, 0 = LO, 2 = HI
VAR FREQ; $ff820a, 0 = 60, 2 = 50
VAR BLANK; Activate blank (? Alien's doc says it isn't used in high res but obviously is causative)

Cycle values are for WS3/4. In WS1 all ff8260 state checks happen 2 cycles earlier, in WS2 2 cycles later.

6     IF(RES == HI) H = TRUE
[lots of checks relating to blank skipped]
(32     IF(RES == HI) LINE = HIRES // todo, there must be a matching position for LORES, if it isn't default)
58     IF(RES == LO) H = TRUE // todo, "unique spot"
166     IF(RES == HI) H = FALSE
186     IF(RES == HI) BLANK = TRUE
378     IF(RES == LO) H = FALSE
["no line 1" and "no line 2" not handled - want to understand what checks cause them]

Cycle values are for WS1/3, in WS2/4 all ff820a state checks happen 2 cycles later

[checks relating to blank skipped]
52     IF(FREQ == 60) H = TRUE
54     IF(FREQ == 50) LINE = PAL // todo, there must be a matching position for NTSC, if it isn't default
56     IF(FREQ == 50) H = TRUE // todo, "unique spot"
372     IF(FREQ == 60) H = FALSE
376     IF(FREQ == 50) H = FALSE

For emulator use I would see the above implemented in a single loop triggering when the emulated cycle hits the checks - offset with -2,0,+2 and 0,+2 respectively for 8260 and 820a either randomly (lol) or configurable. While the above is a naïve and very incomplete version I believe it's closer to the real hardware and a better way to emulate the known wakestates. I'm hugely impressed with the current state of emulators - reading through shifter.cpp in Steem and video.c in Hatari is a fun way to spend an evening (I mean it ) - but there are a lot of checks for "switching to and from" which really should be closer to states at specific cycles.

Opinions - Steven and Nicolas?

[npomarede]

For emulator use I would see the above implemented in a single loop triggering when the emulated cycle hits the checks - offset with -2,0,+2 and 0,+2 respectively for 8260 and 820a either randomly (lol) or configurable. While the above is a naïve and very incomplete version I believe it's closer to the real hardware and a better way to emulate the known wakestates. I'm hugely impressed with the current state of emulators - reading through shifter.cpp in Steem and video.c in Hatari is a fun way to spend an evening (I mean it ) - but there are a lot of checks for "switching to and from" which really should be closer to states at specific cycles.

Opinions - Steven and Nicolas?

Hello
that's my intention since some months to rewrite video.c in a more state machine way, but there're other parts I'd like to split more cleanly in Hatari before doing it. In some cases Hatari behaves like a state machine, it can handle ranges of changes instead of changes at the precise cycles (for example if you do 60 Hz at line 20 and 50 Hz at line 40, it will remove top border (and create some 508 cycles lines also), top border detection is not limited to line 33).
But in the case of Hatari it would not be implemented as a loop, because it would decrease emulation's speed too much. Instead of looping in the state machine every 4 cycles and see what is changing, it's more efficient to update the state machine only when a write to ff820a/ff8260 is made (plus some other updates at end of hbl/vbl).

Nicolas

[troed]

But in the case of Hatari it would not be implemented as a loop, because it would decrease emulation's speed too much. Instead of looping in the state machine every 4 cycles and see what is changing, it's more efficient to update the state machine only when a write to ff820a/ff8260 is made (plus some other updates at end of hbl/vbl)

Thanks - yes I remember when we talked about STE switches this summer you mentioned wanting to have another go at video.c I'll concede that there are two aspects in play - one being able to as accurately as possible emulate (to the border of simulating) the real hardware - and the other being able to implement something that works in realtime on suitable hardware at each point in time. The second goal post is always in motion - the first is pretty much stable.

Another good reason for separating this into two activities would be that FPGA implementations like Suska and MiST and high level emulation on computer platforms differ vastly in what's an efficient implementation path.

So, I think it'll be a worthwhile activity to keep documenting the workings of the hardware with pseudo state machine notation and then optimize those implementations for target platforms. In this specific case the loop even needs to run every 2 cycles - something I know emulators aren't currently.

With that said. From the above state machines we should create the DE signal, add Dio's measurements of DE-to-LOAD and then the Shifter register behaviour as described by Alien (which seems complete). This will give us the correct starting positions of the screen (including wakestate differences) as well as, I believe, sync scrolling due to the fact that we'll keep track of when the Shifter's registers are fully read and it starts to display data. I even think that's enough for emulators to be able to start emulating "unstable sync scroll combinations"

I haven't written the pseudo code for the above yet - I'm somewhat sure of the previous pseudo code - but everything below should be seen as a thought experiment. I'd love input on it.

My thoughts got stuck on how come signal H is activated on cycle 56 in PAL yet Steven wrote that that's where the screen starts displaying. There should be DE-to-LOAD for the different wakestates and then 16 cycles of LOAD before the Shifter starts displaying something* so there are obviously a few things I need to wrap my head around first. There's also a delay from frequency changes in the Shifter to when those hit GLUE (controls DE) which is either 0 or 2 depending on wakestate .. I think.

My incomplete train of thought was, for WS4:
DE activate on cycle 6, add DE-to-LOAD 4, add LOAD 16 -> Left border screen position should be cycle 26.
DE activate on cycle 54, DL4, LOAD 16 -> 56/162/206 line screen start position 74.
DE activate on cycle 58, DL4, LOAD 16 -> PAL 160 line screen start position 78.

/Troed

*) Alien: "In the usual non-overscan scenario, DE is activated and disactivated 16 pixels before and after each line of the useable screen."

[npomarede]

My incomplete train of thought was, for WS4:
DE activate on cycle 6, add DE-to-LOAD 4, add LOAD 16 -> Left border screen position should be cycle 26.
DE activate on cycle 54, DL4, LOAD 16 -> 56/162/206 line screen start position 74.
DE activate on cycle 58, DL4, LOAD 16 -> PAL 160 line screen start position 78.

Are you sure ? On a normal 160 bytes PAL lines, 1st displayed pixel is on cycle 56, not around 78. So for me, screen start position is 56 and load from memory to shifter needs to be done at least 16 cycles before, ie DE activates at or before cycle 40.

Nicolas

[troed]

Are you sure ? On a normal 160 bytes PAL lines, 1st displayed pixel is on cycle 56, not around 78. So for me, screen start position is 56 and load from memory to shifter needs to be done at least 16 cycles before, ie DE activates at or before cycle 40.

No Thus the "incomplete-got-stuck" disclaimer - something is wrong with my model when it tries to incorporate DLx and LOAD. What I'm trying to do is making sense of Alien's articles, Dio's measurements and Paolo's Excel sheet and produce state machines that function according to those descriptions and produces the expected output for the different wakestates

For reference, GLUE creating DL, BLANK etc:
http://alive.atari.org/alive9/ovrscn1.php
DE from signal H:
http://alive.atari.org/alive11/oscan2a.php

So, if signal H (thus DE) is activated at cycle 56, there's no time for a DL-to-LOAD delay nor LOAD itself if the screen also starts at cycle 56. The other option* is that DE (thus LOAD) is activated at or before cycle 40 - but how can we then change starting positions by manipulating signal H with a frequency switch at cycle 52/56? That's what I don't get my head around atm.

I'm guessing Dio might have relevant input from his measuring here.

*) A third option is that DE is activated decoupled from when the Shifter considers it's time to start displaying the screen. That would be a very interesting outcome but it's more likely there's a simple solution I just don't see atm.

[Dio]

The basic output path of the Shifter is almost certainly pretty simple:
- it has a shift register which runs continuously
- data is loaded into that from the staging registers when they are full (this is almost certainly a huge simplification, there are details here we don't quite understand)
- The data gets shifted out; once it's all gone, everything is colour 0 again (i.e. the border colour).

So the Shifter starts outputting data after it receives 4 /LOAD signals from MMU, plus possibly up to a few cycles of latency for the transfer and / or any output pipelining (e.g. for the colour lookup). In my emulator I measure DE to visible pixel as a 19 cycle latency to make Spectrum 512 work right, but it's possible that the extra 3 cycles are due to the timing of the colour register write being rounded down to the nearest 4-clock boundary. Therefore I think the 'extra' latency might be zero, which implies that there are only 3 staging registers, and the 4th LOAD writes the shift register directly. Or it could be 1 - which might mean an extra staging reg, or might mean a single cycle on output of the shift reg, either in a latch there or after the colour lookup.

Although the Shifter sees DE, I don't know why, it doesn't seem necessary for me. One possibility is that it's used to manage the border in 70Hz. Another is that it forms part of the Shifter's reset condition (it may explain why the DL6 case won't hold a single word in the shifter over line end, for example).

What I need to do next is write a test that will probe exactly how the H counter works, by simply flipping from one resolution to another at a given cycle on the line and seeing what that does to the following timing. That hopefully will give much better insight as to how the counter behaves.

[troed]

(This post is of the speculative kind)

In my emulator I measure DE to visible pixel as a 19 cycle latency to make Spectrum 512 work right

Alright, let's speculate a bit I believe Alien was correct in that there's a signal H that decides when the screen should start to display - but it doesn't seem possible that it's used to create DE due to there simply being no time for the Shifter to start receiving the data that should be shown.

If we count backwards from cycle 52, around 19 cycles, we end up at one the interesting locations in Paolo's Excel sheet. There are a few of those, and they're usually identified by "first possible move back" or similar comments. I used those to create the state machines for 8260 and 820a above, and I think they're pretty much correct. This location I had marked, in parentheses, as:

(32 IF(RES == HI) LINE = HIRES // todo, there must be a matching position for LORES, if it isn't default)

The reason for the parenthesis was that I wasn't really sure what happens there. It's the position separating a normal opened left border and the 14 byte line - which we know thanks to your probing distorts sync. I speculated that it's because if 8260 is HI res at that precise moment the decision is taken to use 71Hz timing for the line*. If not, the line defaults (?) to low/mid res timing.

My speculation could of course be off. Maybe it's related to DE instead.

However. Let's say we open the left border - a decision taken at cycle 6 (on ST). How can it start displaying pixels immediately (actually, where DOES it start?) if we need ~20 cycles to load up the Shifter?

So, when I keep subtracting I end up at the end of the previous line - where we have "No Line 1" and "No Line 2" in Paolo's document. I'm guessing those are BLANK locations, and by poking them it's possible to extend BLANK for the whole next line.

Being able to disturb DE should produce a 0-byte line** - and it might even be pretty blank. There is one such position - and now we're back to cycle 32 again. Being in HI res there seems to cause something I would expect a cancelled DE to result in. For a normal PAL or NTSC 160 that seems fine timing wise.

Although the Shifter sees DE, I don't know why, it doesn't seem necessary for me. One possibility is that it's used to manage the border in 70Hz. Another is that it forms part of the Shifter's reset condition (it may explain why the DL6 case won't hold a single word in the shifter over line end, for example).

(FYI, for one subsequent line it's possible to skew the Shifter even in DL6 - however - on the next line it will have corrected itself)

There's also a delay from frequency changes in the Shifter to when those hit GLUE (controls DE) which is either 0 or 2 depending on wakestate .. I think.

To get back to this: Opening the right border by poking 8260 is done at cycle 376 in WS1, 378 in WS3/4 and 380 in WS2. Opening the right border is done by poking 820a 376 in WS1/WS3, 378 in WS2/WS4.

We see the same with "the good" 0-byte line, it can be produced with 8260 at 56 in WS1, 58 in WS3/4 and 60 in WS2. It's done with 820a at cycle 56 in WS1/WS3, 58 in WS2/WS4.

Thus, for states which can be effected by both chips there's a wakestate dependent lag from Shifter to GLUE:

WS1 (DL6): 0 cycles lag
WS4 (DL4): 0 cycles lag
WS3 (DL5): 2 cycles lag
WS2 (DL3): 2 cycles lag

Just an observation, I don't know what if anything it could influence.

/Troed

*) And if switched back to 0 before cycle 56 the GLUE will end up being extremely confused - it had decided the line was started and with HIRES timings - and now finds itself claiming it should start a LORES line. I believe the 14 byte line is an artefact of an "unreachable" state being set that is then the reason for the long HSYNC Dio measured (which aborts any further LOAD - thus 14 bytes).

**) Different from the 0-byte line caused by making sure no line start condition is ever met

[Dio]

I don't think it tells the Shifter when to display. It tells MMU when to start sending data to Shifter. That's all the timing that's needed, because Shifter just reacts to the data it's given.

And if switched back to 0 before cycle 56 the GLUE will end up being extremely confused - it had decided the line was started and with HIRES timings - and now finds itself claiming it should start a LORES line. I believe the 14 byte line is an artefact of an "unreachable" state being set that is then the reason for the long HSYNC Dio measured (which aborts any further LOAD - thus 14 bytes).

Yeah. I'm trying to shed light on something in theory simple: "What's the reset condition for the counter"? This is particularly interesting when thinking about 70Hz, where the counter only has 224/4 values rather than 512/4. But there doesn't appear to be anywhere where having the counter briefly in the 'wrong' state causes a 224 byte line. However, having it briefly in 60Hz does appear to (later) cause the line to be the 'wrong' length.

I think I should be able to test that, by scanning a line, switching the timing and watching what happens. (However, it does rely on being able to reset the shifter into a sane state, in order that it's repeatable). But it's questions like "At some point in the line, switching must cause the line to reset, but what?"

And that then leads on to questions like "What could go wrong when the counter is outside the range that it expects during a 70Hz line"?

I think the bad 14 line proves that there's multiple different hsync conditions going on in there though, since you can start two hsyncs per line.

[troed]

I don't think it tells the Shifter when to display. It tells MMU when to start sending data to Shifter. That's all the timing that's needed, because Shifter just reacts to the data it's given.

Of course, but, poking the Shifter (820a) at cycle 52 will produce an NTSC starting position instead of PAL - and if the actual pixels also are displayed at cycle 52 (and 56 respectively) then I can't imagine how there would be time for anything else to be involved.

So, if Alien's wrong about signal H being combined with V to produce DE then at least there's an earlier DE sent to the MMU (thanks) which loads up the Shifter in advance and _then_ signal H (state machine boundary condition) will cause pixels to be displayed.

How this explains there being a good 0-byte line being possible at cycle 56 in the Shifter and 58 in GLUE I'm less sure of though. It's as if some decisions are taken by the Shifter alone and some are deferred (with a 0 or 2 cycle delay) to GLUE. I also don't see how a PAL line 160 with pixels starting at 56 can become a 0-byte line by anything that happens at cycle 58 (GLUE) ..

I feel like there's something obvious regarding switch cycle positions and where pixels start to be displayed I don't understand here.

Yeah. I'm trying to shed light on something in theory simple: "What's the reset condition for the counter"? This is particularly interesting when thinking about 70Hz, where the counter only has 224/4 values rather than 512/4. But there doesn't appear to be anywhere where having the counter briefly in the 'wrong' state causes a 224 byte line. However, having it briefly in 60Hz does appear to (later) cause the line to be the 'wrong' length.

Cycle 32 looked to me to be such a place, however, the 14 byte line is due to switching back again and thus it triggers more states that are impossible for a 71Hz line. This doesn't happen with the position for 508 cycles (well, it seems inverted, there's one for 512) because it's so close to line start that there will be nothing else that can be switched back to.

(I'm not sure that hypothesis was easy to follow, sorry, it's based off the state machines for 8260 and 820a I posted above)

I think the bad 14 line proves that there's multiple different hsync conditions going on in there though, since you can start two hsyncs per line.

Alien claims that when stopping a low res line with the 71Hz line boundary (54/56/80 byte lines) condition you shouldn't stay in 71Hz long because "one has to quickly return to low or medium resolution to avoid causing an Hsync and a new line.". If we now look at the ancient 80-byte line I kept in LoSTE it indeeds stays in 71Hz for a very long time (see Steven's question to me earlier, with timings) but I know of no sync problems or double lines caused by it. I think Alien's wrong here It's a state machine - it's not "in" 71Hz, the line (and counter) is still 512 cycles.

It's much more obvious why it happens in the 14 byte line case because it switches back early enough.

Finding a place to cause a 224/4 counter would indeed be very interesting - although I'm guessing it would initially cause the exact same 54 and maybe 80 byte lengths as by using the end condition alone. Being able to _skip_ a subsequent HBL and HSYNC and only create yet another line of that length - on the same displayed line - however. It would involve very detailed knowledge about exactly at which all cycles the different BLANK and HSYNC intervals are.

The best description of those that I have are yours - did you make pictures as well? I'd like to be able to assign cause to "No Line 1", "No Line 2" and both "Just Blank" (8260 and 820a).

/Troed

[Dio]

Of course, but, poking the Shifter (820a) at cycle 52 will produce an NTSC starting position instead of PAL - and if the actual pixels also are displayed at cycle 52 (and 56 respectively) then I can't imagine how there would be time for anything else to be involved.

They're not. They appear on the monitor 16-19 cycles after that, it's the latency you have to program into an emulator to make Spectrum 512 work.

I've got all the pngs and the logic traces but I need to find time to put them on the net somewhere .

[mc6809e]

Of course, but, poking the Shifter (820a) at cycle 52 will produce an NTSC starting position instead of PAL - and if the actual pixels also are displayed at cycle 52 (and 56 respectively) then I can't imagine how there would be time for anything else to be involved.

They're not. They appear on the monitor 16-19 cycles after that, it's the latency you have to program into an emulator to make Spectrum 512 work.

I've got all the pngs and the logic traces but I need to find time to put them on the net somewhere .

Oh boy oh boy oh boy!

I've been Jonesin' for traces since I gave up my old LeCroy. (They've even got a 100 GHz scope now.)

[troed]

They're not. They appear on the monitor 16-19 cycles after that, it's the latency you have to program into an emulator to make Spectrum 512 work.

I've got all the pngs and the logic traces but I need to find time to put them on the net somewhere .

Perfect - thanks! So, just to be clear, the DE-to-LOAD you've measured (DL3-DL6) gets swallowed up there as well?

As for _where_ - just open an account at Dropbox, or Wuala, or .. anywhere

[Dio]

Good point - the DE to load latency must shift the timing slightly (after all, it's visible on the monitor).

I have plenty of webspace. I just need to get organised .

[Dio]

OK, blizzard of diagrams. Note that these are mostly captured at a quite heavily quantised sampling rate - for example, in the DE to screen latency capture it's 20MS/S so there's 50ns quantisation, hence why the 8MHz clock looks ropy as hell and signals which should be nominally pretty simultaneous shuffle about a bit:

50Hz video vertical timing:


50Hz video DE to load to display latency:


Normal 160-byte PAL line:


0-byte line:


54-byte line:


80-byte line:


158-byte line:


The faulty 14-byte line:


If anyone wants the actual logic traces to zoom around in I can supply them.

[troed]

OK, blizzard of diagrams.

THANK YOU!!

Revised state machine hypotheses coming up when I've had the opportunity to take a detailed look incl. some pixel counting (which they are detailed enough for - excellent).

[Dio]

If you really want to get that detailed I can give you a zip of all the traces, which you can load into the software even without the OLS board...?

[troed]

If you really want to get that detailed I can give you a zip of all the traces, which you can load into the software even without the OLS board...?

Well more information is seldom worse, I assume others are interested as well, although for the moment I think there's a lot I can gain from these. What I did just now was to overlay the 14 byte line on top of both 160 and 80 to see where the differences are. The description you wrote earlier in this thread actually seems to lack one interesting tidbit - BLANK is shorter on 14 than on the others and is thus an earlier "oddity" compared to the second HSYNC.

(I also did a quick cycle count of DE to screen and it looked to be 6 cycles DE-to-LOAD, 16 cycles LOAD and 2 cycles latency until color change. Does it look reasonable to you?)

Many thanks for creating these

[Dio]

Yes, that's what I measured on that case.

[troed]

The best description of those that I have are yours - did you make pictures as well? I'd like to be able to assign cause to "No Line 1", "No Line 2" and both "Just Blank" (8260 and 820a).

... and as promised here's the first stab at combining Paolo's Excel sheet with Dio's traces Let's begin at a known position and count backwards. I'm going to be liberal with some 2 cycle differences for the time being since they're wakestate sensitive and I'm only assuming Dio made the measurements in WS1. "Subtract the timing" refers to Dio's diagrams and the timing between the visible lines going high and low. "Matches" is a reference to Paolo's document.

Cycle 58: DE activated (GLUE timing)

Subtract the timing between end of BLANK and DE, 28 cycles:

Cycle 32 (30 really, but this is where I'm being liberal with a 2 cycle difference): BLANK end

Matches "0 byte line + BLANK" - I assume a switch here causes an extended BLANK over the whole line and no DE.

Subtract the timing between HSYNC end and BLANK end, 40 cycles:

Cycle 504: HSYNC end

Matches "No Line 2" - I assume a switch here causes an extended HSYNC over the whole line .. but with DE? Sorry I forgot what "No Line" means.

Subtract the timing between HSYNC end and HSYNC start, 40 cycles:

Cycle 464: HSYNC start

Matches "No Line 1 end" - I assume a switch here causes no HSYNC to appear at this position (or the whole line?)

Subtract the timing between BLANK start and HSYNC start, 12 cycles:

Cycle 452: BLANK start

Matches "No Line 1 start" - I assume a switch here will cause BLANK to not happen at this position.

Subtract the timing between BLANK start and previous line DE deactivated, 72 cycles:

Cycle 378 (380 really, I'm liberal again with the 2 cycle difference): DE deactivated

Matches - hey could you guess - right border switch, GLUE timing

Subtract length of DE - 320 cycles:

Cycle 58 ... and we're back

It all matches up rather nicely, don't you think?

Another observation I found interesting: When opening the left border both DE as well as LOAD happens while BLANK is still active.

Of interest: Left border opening is being done by immediately after HSYNC end going to high res. I'm eyeballing that to be 16 cycles after HSYNC end DE is activated. HSYNC end 504 + 16 = 8. So, "0 bytes + blank" happens exactly at an opened left border DE - and if kept at HI since we're on our way to a 14 byte line. This supports, I think, that line length really being about HIRES timing - especially since BLANK ends early, at 24 instead of at 32 (which is within the "Just Blank" territory)

Of interest: A previous comment from Dio

VSYNC starts 104 cycles after the start of the previous line's HSYNC, so that's 4 cycles before DE would be activated. It is likely that this is the point at which the H counter is reset (and V incremented) so one would expect that the horizontal period would be determined at about this point.

I concur - GLUE decides DE which is done at cycle 58. 4 cycles before in the Shifter is the specific position where 50Hz means the line is PAL.

Btw, I think something interesting happens between cycle 8 and cycle 20. An early switch causes a 0-byte line+BLANK later at cycle 32 (BLANK end), but a late switch only causes BLANK. So, being in low res at cycle 18 (?) causes DE to become active at 58?

That's all for this evening

[troed]

for states which can be effected by both chips there's a wakestate dependent lag from Shifter to GLUE:

WS1 (DL6): 0 cycles lag
WS4 (DL4): 0 cycles lag
WS3 (DL5): 2 cycles lag
WS2 (DL3): 2 cycles lag

Just an observation, I don't know what if anything it could influence.

I couldn't make heads or tails of this btw, there's no way I know of for one chip to communicate with another in 0 cycles. Today, I found this:

The configuration register for synchro (50/60 Hz and synchro int. /ext.) is in GST MCU (and GLUE of the STF) and not in the Shifter, as the localization of the address of this register (see figure 10) could let it think . It is for this register that the GLUE of the STF is provided with two data pins connected to bits 8 and 9 of the bus, which corresponds well to the 2 modifiable bits of the register.

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

If 820a and 8260 both are in GLUE then it becomes rather obvious though. The Shifter, according to the article, only has access to 8260.

[Steven Seagal]

50Hz video DE to load to display latency:

There is a lot of interesting info in this thread, the most amazing so far being those traces by Dio (thx a lot ).
Troed already commented some, for now I would like to interpret this one, supposing DE signal is the same for the shifter and GLUE, MMU, and ignoring wake-up state problems.

- DE of normal PAL line starts at emulator cycle 56.
- When DE starts, the shifter isn't preloaded. Indeed there's a latency of apparently 6 cycles before the MMU prefetches the first word. This is reflected in the emulator function "read shifter counter".
- After the shifter is loaded, there's another delay for the first rotation to take place, 2 cycles.
- So between DE and first pixel sent to display, we compute a latency of 6+16+2=24 cycles in this graph.
This is 3 cycles left than the latency needed to have Overscan Demos screen 6 display fine in Steem. But here we're looking at a normal line, the demo is, of course, in overscan, perhaps it could change timings.

[Dio]

There's a subtlety here: there is no "Emulator cycle 56". It is "MMU/CPU cycle 56" and DE is not synchronised to it.

The MMU operates a 4 (8MHz) clock state machine. For two of those cycles it gives the DRAM bus to the CPU and for the other two it gives them to video or refresh. Let's call these cycles (MC1, MC2, MM1, MM2). This means the CPU and MMU operate in phase so they share a common view of what the current clock cycle is. This is also what current-VAP synchronisation locks on to (since the counter is in the MMU and locked to the state machine).

However, the Glue state machine that controls DE is not in sync with this. So DE doesn't go high at 'emulator cycle 56'. Instead, DE goes high, and then the MMU recognises it. It's not clear if this is checked during MM2, or on the downward clock edge of MC1 with DE going high just far enough behind that it's not recognised, but the latter seems probable to me. That case would therefore be the 6-cycle latency, with the other three cases being 3, 4 and 5 (that's also possibly indicated if WS1/DL6 is the most likely waitstate from cold; that's the 'in sync' case).

Therefore I think all timing should be considered relative to the MMU / CPU view of things, with the Glue being the asynchronous component. And when we typically talk about 'emulator cycle 56' it's actually typically shorthand for 'MMU/CPU cycles 56-59'.

[Steven Seagal]

'Emulator cycle' is just a reckoning so that we understand each other, it's the "linecycle" in both Hatari and Steem.
eg cycle 376 sync 0 -> right border off
When you say "DE is not synchronised to it", does it mean that the delay between DE and shifter LOAD is variable?
That DE is more or less irrelevant?
It's important to be able to pinpoint 'emulator cycles' on those graphs.

[Dio]

So firstly, the DE to shifter LOAD is variable depending on the wakeup state. Hence my notation DL3-DL6 for each wakeup state.

Then if you look at the traces, you can see where the writes to the registers are happening. Look at the A23 line - those indicate accesses to memory addresses with the top bit set - i.e. hardware registers or ROM. If you can also see R/W low, then it's a write. So if you look at, say, the 158-byte line, you can see a pair of writes either side of the disabling of DE, which must be the two writes to the syncmode register. Similarly, the 14-byte line shows two HW register writes either side of the small block of DE. So you can use those to correlate emulator time with the traces.

But there's a deeper can of worms here: what is the accurate definition of 'cycle 376'?

You say "cycle 376 sync 0 -> right border off". But that's a huge simplification of what actually happens. If we consider the emulator cycle to start at the beginning of that state machine (MC1) then the CPU write hits the Glue in MC1 or MC2 (assuming it's in normal phase and not on the normally unavailable half cycles). The Glue then does the comparison - but not immediately, but at some later point (probably 1-4 cycles later depending on the wakeup state). 1-4 cycles after that the MMU sees DE, and probably 3 cycles after that it issues the first /LOAD.

At the moment emulators perform the simplification, and it almost works because in general wakeup states are ignored, everything quantises to a nice 4-cycle boundary, the effects of the two variable delays are inverted and so cancel out, and it 'just works'. But that's not a true simulation of what's going on - it's just a HLE (High Level Emulation) that emulates the effect rather than the signals in any great detail.

In particular, it doesn't lead to any greater insights about the hardware. In order to gain those, it's necessary to unpick all the fiddly little details and properly consider all the wakeup states. Especially when it comes to considering the +2 cases where the write to the Glue happens half-way between two CPU phases.

So what I'm trying to answer is the root hardware defining "what is cycle 376'"? What does zero mean in this numbering system? Is the write actually happening on cycle 376, or is it cycle 377? Where does Glue do its comparisons? At what point does MMU react? What is the logic - and latency - in the Shifter?

This may lead to the ability to do a genuine low level simulation, rather than just trapping write addresses, looking up a table and seeing what's supposed to happen.

[mc6809e]

But there's a deeper can of worms here: what is the accurate definition of 'cycle 376'?

...

So what I'm trying to answer is the root hardware defining "what is cycle 376'"? What does zero mean in this numbering system? Is the write actually happening on cycle 376, or is it cycle 377? Where does Glue do its comparisons? At what point does MMU react? What is the logic - and latency - in the Shifter?

This may lead to the ability to do a genuine low level simulation, rather than just trapping write addresses, looking up a table and seeing what's supposed to happen.

I think HSYNC is by convention the beginning of a scanline. Maybe the falling edge of HSYNC could be considered the start of cycle zero. It does seem that register changes need to be done relative to electron beam position, even though accessible positions depend on MMU phase.