horizontal scrolling on ST

[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.

[Dio]

There isn't a convention on these things. Indeed, I'm aware of more computers whose counter origin is the top-left screen fetch than it being tied to the sync positions.

The 14-byte line case may demonstrate there isn't one falling edge of HSYNC though. Plus that then creates the problem with needing to determine the line length at an unusual position.

I think it's probable that the correct zero for the time is the point at which the internal counter's length for a given scanline is decided. This may also be the counter reset point. It's why I've been looking at where VSYNC gets incremented, assuming it happens due to counter reset.

[Steven Seagal]

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

I see, I finally understand this DL3-DL6 notation. This would imply that the shifter counter starts running later according to WU.

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.

This is indeed interesting, apparently DE is very close to those writes, around cycle 372.

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.

I didn't mean to explain it all but to illustrate again what's understood by "emulator cycles".
There's a relation between those cycles and pixel cycles ("Paulo cycles"):
emulator cycles = Paulo cycles +83
Paulo cycle 1 = emulator cycle 84.
Here's a constant in Steem:

Code: Select all

#define CYCLES_FROM_HBL_TO_LEFT_BORDER_OPEN 84

This means that a palette change at cycle 84 could affect pixel 1 of a normal 50hz scanline.
In the graph I commented, leaving alone WU states, you would have DE activating around cycle 56, the latency, the prefetch, the latency and then the pixel being rendered around cycle 84, I assumed it's when R2 G2 B2 change but I'm not sure.

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.

Emulator cycles start from 0 at very first frame, then 0 after 512 cycles in a 50hz frame.
In Steem, you have this simple schema for WU:

Code: Select all

State 1
+-----+
| CPU |
+-----+
| MMU |
+-----+


State 2
+-----+
| MMU |
+-----+
| CPU |
+-----+

We generally consider WU1 when talking about cycles.

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.

In current version of Steem, WU isn't generally ignored, but as we don't master this, it's optional.
The 1st goal is to run programs.
In all versions of Steem cycle precision is 2, not 4.

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?

That's what I try to answer, practically. This is the timing when the write happens.
You identified yourself places where we could attach emulator cycles to the graph, around cycle 372 for line -2.
I already hinted at the time when the shifter counter starts running.

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.

You know I like this approoach as I implemented real emulation of PC offset in bus errors.

With a caveat, performance, though the shifter trick tests themselves can be quite taxing, especially in Steem.
Just compare CPU usage for desktop with Overscan Demos #6.
And of course, it must work.

[troed]

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?)

... and going back to the 2006 thread where TCB's faulty auto detection was discussed we can verify this with Paolo's investigation into how that did/did not result in additional line lengths depending on whether right border had been opened

http://www.atari-forum.com/viewtopic.ph ... &start=114

I think the most interesting tidbit from that is that cancelling out HSYNC will not increase the HBL counter (additional lines drawn at the bottom of the screen). It's obvious it will always distort sync and thus cannot be used to create new line lengths. However, I guess it's possible the HBL-increase could be done at another time and just depends on there having been an HSYNC pulse.

Of note: There's a clear example there of how the video counter is increased separately from the Shifter receiving data from the MMU, if I understand Paolo's description correctly.



With regards to the 14-byte line, it doesn't need to be created with a "long left border" switch. A regular left border opening can be done, followed by another HI/LO switch that covers cycle 32:

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.

The result is the same, it still distorts sync. However, I'm guessing the two switch method version wouldn't cause an earlier BLANK end* as is visible in the trace diagram (where it happens on cycle 24, a new HSYNC then follows at cycle 32 which immediately - 4 cycles later - causes BLANK to go off again and at the same time DE is deactivated).

As to _why_ it's possible to get a second HSYNC I think we need to ponder exactly how the hardware is wired up into a state machine. I also thinks it's quite specific to cycle 32. I think this has to do with the hardware being wired to handle both the hi-res and lo-res cases without switching between two modes, i.e, knowing what the pulses look like for a regular hi res scanline would possibly provide new insight.

At this moment I don't think it's possible to create a stable 14 byte line. In my view it's obvious that the second HSYNC is the cause for DE to deactivate. Trying to avoid the second HSYNC would then create a regular 186 byte line. (Yes, I've tried switching to external sync (!) at that position without success).

/Troed

*) Because nothing differs up until cycle 24 compared to an 80 byte line which does not show an early BLANK end in the trace diagram

[Steven Seagal]

Of note: There's a clear example there of how the video counter is increased separately from the Shifter receiving data from the MMU, if I understand Paolo's description correctly.

Normally there's only one counter, so it must point to the correct address before LOAD.

[troed]

Of note: There's a clear example there of how the video counter is increased separately from the Shifter receiving data from the MMU, if I understand Paolo's description correctly.

Normally there's only one counter, so it must point to the correct address before LOAD.

You're right, the described effect is probably just due to alternating BLANK. It's somewhat interesting that it alternates though, and at the same time it controls whether DE can be modified with normal sync switches.

(Again referencing the 14 byte case where the second HSYNC causes BLANK _and_ DE to change)

I wonder if at least BLANK is not set/cleared but inverted by the state machine. Maybe that's even true for other signals.

[Dio]

I wonder if at least BLANK is not set/cleared but inverted by the state machine. Maybe that's even true for other signals.

I reckon this is unlikely. I can't see any sign of it in the traces - plus an S/R flip-flop is two gates while a toggling flip-flop is six.

I agree that it's likely that the state machine clears DE whenever HSYNC is set and that the 14-byte line will probably prove unobtainable without the corrupt HSYNC.

[Steven Seagal]

Coming back to the SNYD/TCB screen...

In the doc by Alien, we have this:

It is therefore sufficient to switch to monochrome to activate H
and DE, and therefore force the MMU and the SHIFTER to start
decoding the useable screen. One returns to low or medium
resolution to actually see the useable screen on the RGB pins.
Thus one obtains at 50Hz lines of 160+26 = 186 bytes. At 60Hz
one obtains lines of 184 bytes. The difference of 2 bytes
corresponds to the difference of 0.5us between the two line
lengths (63.5us at 60Hz and 64us at 50Hz).

I ran some tests in Steem, and emulation of TCB in WU1 (logo on the left) makes more sense with a left off +24 than having a normal left off +26 followed with a spurious "line -2" trick. Spurious because the frequency before and after left border removal is 60hz.
Edit: spurious in Steem, it is the '372:S0000' that is identified as provoking a line-2.

Code: Select all

Before:
-30 - 368:S0000 452:S0000 476:r0900 496:r0900 512:T0100 512:#0000
-29 - 004:r0900 024:r0900 044:r0900 064:r0900 084:r0908
-28 - 000:R0002 008:R0000 372:S0000 380:S0002 440:R0002 452:R0000 508:T2009 508:#0184
T2009 means "left off +26; line -2"

Now:
-30 - 388:S0000 472:S0000 496:r0900 512:T0100 512:#0000
-29 - 004:r0900 024:r0900 044:r0900 064:r0900 084:r0908
-28 - 000:R0002 008:R0000 372:S0000 380:S0002 440:R0002 452:R0000 508:T22000 508:#0184
T22000 means left off +24 (372:S0000 ignored)

In both cases we have a 184 bytes line, but in the first case this is 160+26-2=184, in the second 160+24=184.

But when I check Paolo's sync line tester, line 184 is done with left off, line -2, so I wonder if the line +24 trick described by Alien is relatively unknown or impractical?

[troed]

I ran some tests in Steem, and emulation of TCB in WU1 (logo on the left) makes more sense with a left off +24 than having a normal left off +26 followed with a spurious "line -2" trick. Spurious because the frequency before and after left border removal is 60hz.

In both cases we have a 184 bytes line, but in the first case this is 160+26-2=184, in the second 160+24=184.

But when I check Paolo's sync line tester, line 184 is done with left off, line -2, so I wonder if the line +24 trick described by Alien is relatively unknown or impractical?

In 60Hz the line starts 2 bytes earlier and ends 2 bytes earlier compared to 50Hz. So, it's only what the frequency is at the start and end positions that decides when DE will be activated/deactivated (this beside the position that decides whether it's a 508 or 512 cycle line). The line won't be spuriously "-2" - if it's in 60Hz at that position that's where it'll deactivate DE Since the start of the left border doesn't differ in 50 and 60Hz you could also see it as the width of the left border being 24 bytes in 60Hz vs 26 bytes in 50, but that's still due to the frequency at the +2 position at the start of the line so it doesn't add any new info and shouldn't change anything in your code if it already detects that.

As for the TCB screen specifically if we're talking about the line that's 4 cycles too early a normal right border switch will indeed become a short right (-2). Right?

[Steven Seagal]

You see this 'right' but there are still some details 'left'...

1. The 'spurious' side is at the time of the test at cycle 372, the 'change' to 60hz is taken (in Steem and I think Hatari) even though the line is already at 60hz. At the end of the line, what matters is that we have 184 bytes though.

2. A question is why left off at 60hz isn't generally used to obtain a line 184?

[troed]

You see this 'right' but there are still some details 'left'...

1. The 'spurious' side is at the time of the test at cycle 372, the 'change' to 60hz is taken (in Steem and I think Hatari) even though the line is already at 60hz. At the end of the line, what matters is that we have 184 bytes though.

2. A question is why left off at 60hz isn't generally used to obtain a line 184?

(I will probably have time to update the state machines from the previous page including ff820a and ff8260 both being GLUE and with internal delays due to wakestates, as well as the timing from CPU cycles to pixel display, this weekend btw)

Think state machines instead of switches* The line will end at 372 if the frequency is 60Hz. It will end at 376 if the frequency is 50Hz. Tested at those specific cycles - it doesn't matter when the switch to 60Hz is made - only what the state is when tested.

The reason for not opening the left border with 71Hz and then switching back to 60Hz until line end to get 184 bytes is because the state machine will check for 50Hz at cycle 54 and if true the line is 512 cycles, if it's 60Hz the line will be 508 cycles. We don't want to mix 512 and 508 cycle lines so at that specific position we must be in 50Hz.

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

/Troed

*) I fully realize why for performance reasons emulators look for "switches" but it's conceptually very wrong

[Steven Seagal]

Looking for switches makes sense while knowledge isn't perfect, eg for all the 0-byte lines mess.
And the 'line +2' rules for STF and STE are strange to say the least.
Even for the left border we're still poking, and soon I'll make some revelations!
Conceptually, saying "left off at 60hz=+24 bytes" is nicer than "left off=+26 bytes but if line ends at cycle 372, -2 bytes".
It didn't start as '+26'.
Or maybe with a state machine bytes would be counted +2 every 4 cycles while DE is on. Nice, but a challenge for emulation and for your regular 160 bytes line, lots of useless computations.

[npomarede]

Looking for switches makes sense while knowledge isn't perfect, eg for all the 0-byte lines mess.
And the 'line +2' rules for STF and STE are strange to say the least.
Even for the left border we're still poking, and soon I'll make some revelations!
Conceptually, saying "left off at 60hz=+24 bytes" is nicer than "left off=+26 bytes but if line ends at cycle 372, -2 bytes".
It didn't start as '+26'.
Or maybe with a state machine bytes would be counted +2 every 4 cycles while DE is on. Nice, but a challenge for emulation and for your regular 160 bytes line, lots of useless computations.

It may sound nicer, but it could be wrong too. Final line's length is not the only parameter to emulate, you must also take into account when DE starts and stop.
For example, a normal 160 byte line at 50 Hz is not centered on screen the same way as a 160 byte line at 60 Hz ; the 60 Hz line starts 4 cycles earlier and as a result it's shifted 4 pixels to the left when compared with the 50 Hz line.
Same thing goes when mixing some left/right border, the fact that some +2/-2 bytes compensate each other doesn't mean the line will be centered the same way on screen.
I had to take this into account into Hatari, because if you mix this with color changes in the background they will not be correctly aligned with the bitmap.

Nicolas

[troed]

Looking for switches makes sense while knowledge isn't perfect, eg for all the 0-byte lines mess.
And the 'line +2' rules for STF and STE are strange to say the least.
Even for the left border we're still poking, and soon I'll make some revelations!
Conceptually, saying "left off at 60hz=+24 bytes" is nicer than "left off=+26 bytes but if line ends at cycle 372, -2 bytes".
It didn't start as '+26'.

I agree that there could be many reasons for approximating the state machine (as per target hardware, or as close as we can describe it in pseudo-code as I'm trying to do here) differently in emulators. However, when reasoning around how things work (and possibly in implementing "compatibility-modes" in emulators and FPGAs) it's much easier to have the state machine in mind. Your comment about "line +2 rules for STF and STE being strange" is actually a perfect example.

Excerpt from work in progress - I hope to be able to post a full updated version (includes BLANK, HSYNC etc) of where I'm currently at during the weekend:

Code: Select all

6     IF(RES == HI) H = TRUE
STE 36     IF(FREQ == 60) H = TRUE
STE 40     IF(FREQ == 50) H = TRUE
STF 52     IF(FREQ == 60) H = TRUE
54     IF(FREQ == 50) LINE = PAL
STF 56     IF(FREQ == 50) H = TRUE
372     IF(FREQ == 60) H = FALSE
376     IF(FREQ == 50) H = FALSE

The above explains +2 and 0-byte lines for STF and STE. At those specific cycles you check what the current value of ff820a is and set the values for either "DE active"* and/or whether the linetype is 508 cycles (default) or 512 ("LINE = PAL").

The reason why the state machine checks for STE is different (16 cycles earlier) from STF is completely logical. The STE screen always start 16 pixels earlier - due to its hardware scroll capability - and a separate register then controls which pixel starts where. That's the reason for DHS's (right?) trick with being able to always switch those 16 pixels on and gain screen width.

So, as for the 184 byte line in 60Hz (STF):

At cycle 6 RES=HI and thus we start the screen (activate H). We then stay in 60Hz, which means that at cycle 52 nothing happens, the screen is already started. At cycle 54 a check is made to see if FREQ is 50 (it isn't) which means we stay with a 508 cycle line. Nothing happens at 56 since FREQ is 60 so the next thing that happens is at 372 where the check for FREQ 60 is true and H is deactivated.

Compare this with a 184 byte line in 50Hz (STF):

At cycle 6 RES=HI and we start the screen. We go back to 50Hz which means that the check at cycle 52 is false, the check at 54 is however true and we switch to line type 512 cycles. The check at 56 is also true, but the screen is already started. We now wait until we get to the right border position where we switch frequency to 60Hz before the check at cycle 372 - and thus H is deactivated.

The only difference between these two cases is whether line type will be 508 cycles (60Hz) or 512 cycles (50Hz) - but the state machine accurately captures both cases.

Try walking through the state machine the same way regarding +2 and 0-byte cases. If I haven't made a complete fool out of myself they should trigger correctly (and as Nicolas mentions the 60Hz line will both start and end 4 cycles earlier).

Or maybe with a state machine bytes would be counted +2 every 4 cycles while DE is on. Nice, but a challenge for emulation and for your regular 160 bytes line, lots of useless computations.

The states (GLUE) only have to be checked at the specific cycles in the table - not in between. While the full version I'll post contains checks for BLANK and HSYNC that's above and beyond current emulation - removing them will lessen the amount of computation. A quick look** at my notes indicates that ~nine checks per line will capture all known line lengths for both STF and STE. Separating the code bases will bring that down to ~seven. edit: And since those checks follow the hardware they will work with future demos as well doing switches at different positions compared to current ones

/Troed

*) I'll get back to this, DE becomes active slightly later than H is set to true. There are internal GLUE delays affecting this as well. It's possible to deduce the exact cycle lengths and thus bytes used for the borders in different modes from the full description. You're correct in that a left border in 60Hz is 24 bytes (since a 60Hz regular line starts 4 cycles earlier) - it's the distance between DE active for left border (hires screen start) and DE active for 60Hz line.

**) My first quick look was in error, it captured additional checks that I think no one uses. However, some of the additional checks _are_ probably used by demos even though they likely disrupt sync. In any case, I think it's time for emulation to start looking into running a state machine, at least as an option. It's not that heavy duty.