Sync-tricks/fullscreen discussion

[troed]

I've spent some time with the GLUE statemachine for ST/STE not only in 50Hz but also 60Hz (and 71Hz, but I still need to wrap my head around a few things there).

Thanks, I think that's a good improvement.

Regarding 71... is there a LINE = 224 too?

I'm unsure what it is that happens at cycle 28/30 on a low res line (I think but haven't tested that it's the same position for 50/60Hz). I'm equally unsure what it is that happens at cycle 108 on a high res line. I'm currently testing with a flat screen monitor that's very quick to go out of sync at the slightest of sync disturbances and I might need to hook up something analog instead.

So, 28/30 and 108 are unexplained things, which might or might not be relevant to have an opinion on where LINE = 224 happens. It might be cycle 54/56, I simply don't know yet. It would probably be extremely easy to use a logic analyzer to find out, I just don't have one

/Troed

[npomarede]

So, 28/30 and 108 are unexplained things, which might or might not be relevant to have an opinion on where LINE = 224 happens. It might be cycle 54/56, I simply don't know yet. It would probably be extremely easy to use a logic analyzer to find out, I just don't have one
/Troed

Or maybe Ijor could get some details from the decaped glue chip ? But I don't know if it's easy to study some precise time spots using the chip's picture.

[ijor]

I know more or less what is going on. Main problem is that is difficult, at least for me, to express this with a single monolithic state machine. I'm not sure it would even be correct and accurate to do so.

As I already mentioned, GLUE doesn't have just a single horizontal counter but two. One counter controls hsync and line length. The other counter controls hDE and hBLANK. Each counter runs in opposite edges of the 2 MHz clock. That's why sync and length switches are aligned in a different 4 cycles boundary, in relation to hDE and hBLANK ones.

Line length is decided by setting the initial counter value, depending on the frecuency, when it overwraps. That's why it looks like there is some kind of register.

Between 50 Hz and 60 Hz is simple. GLUE uses exactly the same value to decide when to start and when to end hsync in both frequencies (remember that they don't start counting at the same value, that's the trick). But between mono and color is more complicated. In other words, the hsync comparators check only the rez register (mono or color).

I'll try to write some seudo code of the hsync logic alone later.

[ijor]

Ok. This is GLUE horizontal sync video seudo code.Integrating this as a single monolithic state machine is left as an exercise to the reader.

Don't pay too much attention to the absolute value of the counter. Obviously they don't match the positions we used historically just by convention. What matters is the relation. Also remember the counters run at 2 MHz, so you have to multiply by four to convert it to 8 MHz cycles.

Code: Select all

// Divide 8 Mhz clock into 2 MHz
// Two opposite edges, two (8 Mhz) cycles apart
CLOCK_DIVISOR_2MHZ = 0
DO
	IF CLK_8MHZ_TICK
		IF CLOCK_DIVISOR_2MHZ == 0  THEN HS_TICK = TRUE
		ELSE HS_TICK = FALSE

		IF CLOCK_DIVISOR_2MHZ == 2  THEN HV_TICK = TRUE
		ELSE HV_TICK = FALSE

		IF CLOCK_DIVISOR_2MHZ == 3 THEN
			CLOCK_DIVISOR_2MHZ = 0
		ELSE
			CLOCK_DIVISOR_2MHZ++	
	ENDIF
LOOP

// Horizontal sync process
HSYNC_COUNTER = 0
DO
	IF HS_TICK
		IF HSYNC_COUNTER == 101 && REZ[1] == 0 THEN HSYNC = TRUE
		IF HSYNC_COUNTER == 111 && REZ[1] == 0 THEN HSYNC = FALSE
		IF HSYNC_COUNTER == 121 && REZ[1] == 1 THEN HSYNC = TRUE
		IF HSYNC_COUNTER == 127 && REZ[1] == 1 THEN HSYNC = FALSE

		IF HSYNC_COUNTER == 127
			IF REZ[1] == 1 THEN          HSYNC_COUNTER = 72
			ELSEIF FREQ[1] == 0 THEN     HSYNC_COUNTER = 1
			ELSE                         HSYNC_COUNTER = 0
		ELSE
			HSYNC_COUNTER++
		ENDIF
	ENDIF
LOOP

// Horizontal video process
HVID_COUNTER = 0
DO
	IF HSYNC THEN HVID_COUNTER = 0
	ELSE IF HV_TICK
		// hDE and hBLANK COMPARATORS here
		HVID_COUNTER++
	ENDIF
LOOP

[troed]

"28/30" is "108"* Thanks Ijor!!! I can't express enough how satisfying it is to have a hypothesis based on black box reverse engineering and then to be able to have it verified instead of just sitting on it for many years without ever knowing! This is from my notes after the latest batch of testing:

Q: Why isn’t there something similar to cycle 460 for 71Hz? Is its HSYNC handling so different? Also, no BLANK = FALSE for mono.
- or is this what ~cycle 30 is about?
- hmm, rather cycle 108 according to tests in mono!

(And for the ones keeping track: This means Paulo's "14 byte line" with the associated "strange logic analyzer diagram" by Dio is indeed due to triggering a new hsync in the middle of the left border in low res .. )

I'll get it into the state machine shortly. Indeed I created the "LINE" variable knowing full well that its purpose was to capture what you had already described as being two counters, not one. Whatever makes for the easiest explanation - I think linking to your exact description of how the hw works will be mandatory later ...

/Troed

edit: The answer to "Don't pay too much attention to the absolute value of the counter. Obviously they don't match the positions we used historically just by convention" is that cycle 54 (ST) by our convention is where the hsync counter is reset.

*) Reading that again it made no sense Cycle 30 (ST) in low res is the high res HSYNC position. Cycle 108 in high res is the low res HSYNC position. I'm not sure the state machine description will survive incorporating this. The easiest description of the behavior might be something like Ijor's pseudo-code. Let's see.

[ijor]

Minor update to the hsync seudo code

Code: Select all

// Divide 8 Mhz clock into 2 MHz
// Two opposite edges, two (8 Mhz) cycles apart
CLOCK_DIVISOR_2MHZ = 0
DO
   IF CLK_8MHZ_TICK
      IF CLOCK_DIVISOR_2MHZ == 0  THEN HS_TICK = TRUE
      ELSE HS_TICK = FALSE

      IF CLOCK_DIVISOR_2MHZ == 2  THEN HV_TICK = TRUE
      ELSE HV_TICK = FALSE

      IF CLOCK_DIVISOR_2MHZ == 3 THEN
         CLOCK_DIVISOR_2MHZ = 0
      ELSE
         CLOCK_DIVISOR_2MHZ++   
   ENDIF
LOOP

// Horizontal sync process
HSYNC_COUNTER = 0
DO
   IF HS_TICK
      IF HSYNC_COUNTER == 101 && REZ[1] == 0 THEN HSYNC = TRUE
      IF HSYNC_COUNTER == 111 && REZ[1] == 0 THEN HSYNC = FALSE
      IF HSYNC_COUNTER == 121 && REZ[1] == 1 THEN HSYNC = TRUE
      IF HSYNC_COUNTER == 127 && REZ[1] == 1 THEN HSYNC = FALSE

      IF HSYNC_COUNTER == 127
         IF REZ[1] == 1 THEN          HSYNC_COUNTER = 72
         ELSEIF FREQ[1] == 0 THEN     HSYNC_COUNTER = 1
         ELSE                         HSYNC_COUNTER = 0
      ELSE
         HSYNC_COUNTER++
      ENDIF
   ENDIF
LOOP

// SYNC MUX
IF FREQ[0] THEN		HSYNC_MUX = EXTERNAL_HSYNC
ELSE 				HSYNC_MUX = INTERNAL_HSYNC

// Horizontal video process
HVID_COUNTER = 0
DO
	IF HSYNC_MUX THEN
	// These resets happen asynchronously,
	// disregarding any clock.
	// And have higher priority than synchronous changes
		HVID_COUNTER = 0
		hDE = FALSE
		hBLANK = TRUE
	ELSE IF HV_TICK
		// hDE and hBLANK COMPARATORS here
		HVID_COUNTER++
	ENDIF
LOOP

[npomarede]

Hi
regarding the hi/lo switch in "no buddies land" at pos 500/508, we know it creates a blank line but also shift the display 1 line down (so bottom border would start at hbl 264 instead of 263). If 10 lines are used at 500/508, display will ends 10 lines later, which I suspected when emulating this in Hatari was due to a counter not incrementing.
From you pseudo code above, I guess it's this part that doesn't get executed in that case ?

Code: Select all

ELSE IF HV_TICK
      // hDE and hBLANK COMPARATORS here
      HVID_COUNTER++
   ENDIF

Nicolas

[ijor]

Hi
regarding the hi/lo switch in "no buddies land" at pos 500/508, we know it creates a blank line but also shift the display 1 line down (so bottom border would start at hbl 264 instead of 263). If 10 lines are used at 500/508, display will ends 10 lines later, which I suspected when emulating this in Hatari was due to a counter not incrementing.
From you pseudo code above, I guess it's this part that doesn't get executed in that case ?

Code: Select all

ELSE IF HV_TICK
      // hDE and hBLANK COMPARATORS here
      HVID_COUNTER++
   ENDIF

Nicolas

Not exactly. That counter is only for the horizontal hDE and hBLANK processing. Probably the name I used is a bit misleading. I was thinking in HorizontalVideo (in comparison to the other counter as HorizontalSync).

The effect you mention comes from the vertical process, which I didn't include at all in the seudo code, so far. One of the counters (there are also two vertical counters), the one that controls the borders, is incremented on every HSYNC edge. In the case of No Buddies Land, there are no HSYNC edges on those lines, so that vertical counter is not incremented.

[troed]

Of interest to people participating here should be that the Hatari emulator, v2.0.0 released today, now supports emulating all four GLUE-MMU wakestates This is selectable (or use "random" for extra fun when developing - like the real hardware) so that you now can verify the TCB snow screen in SNYD1 behaving differently in WS2 compared to the others etc.

- video emulation now supports the 4 STF wakeup states for MMU/GLUE
and a much more accurate state machine for border removal

Many thanks to Nicolas having taken the time to rewrite the internals to allow this to happen.

http://hatari.tuxfamily.org/download.html

/Troed

[Steven Seagal]

To be more precise it's not one cycle, but one and a half cycle. GLUE latches the resolution register at the start of the CPU strobe. But it latches the freq/sync register bits at the end of the strobe.

So precise emulation could require using a unit smaller than the CPU cycle.
But what is this CPU strobe? RAS? CAS?
Is there a difference if the program writes the resolution register on a misaligned cycle (in the MMU slice)? In that case, GLUE would latch it sooner?

It is the same thing. Or perhaps more accurately, as I said in the other thread the CPU shift is a side effect. The 0-3 cycles difference are between GLUE and MMU, and they reflect the relation between both counters I described. MMU gets the CPU aligned with its own timing whenever it attempts a RAM (or SHIFTER) access. And this is because RAM access can only happen at the cycle slots allocated by the given MMU DRAM process.

Apparently, when we "round up to 4", we imply that MMU gets the first 2 cycles, CPU the last 2.
And this seems to agree with the official timing sheets.

[ijor]

So precise emulation could require using a unit smaller than the CPU cycle.
But what is this CPU strobe? RAS? CAS?
Is there a difference if the program writes the resolution register on a misaligned cycle (in the MMU slice)? In that case, GLUE would latch it sooner?

You don't need half a cycle resolution here because GLUE internally won't care about half a cycle.

The CPU data strobe is UDS in this case. RAS/CAS don't reach GLUE and are generated by MMU.

Yes, if you make a misaligned write to the rez register, it will alter the timing relation between the change being processed by GLUE and SHIFTER.

Apparently, when we "round up to 4", we imply that MMU gets the first 2 cycles, CPU the last 2. And this seems to agree with the official timing sheets.

I'm not sure that makes much sense. Which ones are the two first and which ones are the two last? How, when you start to count? I don't think the concept of first and last makes much sense here.

You round up because a misaligned access will take more cycles. Not because they are before or after.

[Steven Seagal]

You don't need half a cycle resolution here because GLUE internally won't care about half a cycle.

The CPU data strobe is UDS in this case. RAS/CAS don't reach GLUE and are generated by MMU.

Yes, if you make a misaligned write to the rez register, it will alter the timing relation between the change being processed by GLUE and SHIFTER.

I see. I was trying to situate the strobe on the MMU/GLUE timing graphics (last pages of the ASIC MCU-GLUE schematics) but you were talking about a CPU timing. Generally it can land on two zones of the MCU timings. That's what I meant with the question.

I'm not sure that makes much sense. Which ones are the two first and which ones are the two last? How, when you start to count? I don't think the concept of first and last makes much sense here.

You round up because a misaligned access will take more cycles. Not because they are before or after.

Yes we start emulation from 0 and from then on, for every 4 cycles, the first 2 cycles are for MMU, the next 2 cycles are for CPU.
But also on the timing graphics, the MMU slot comes first, so I guess that's how the MMU starts at power-up.
A CPU bus cycle takes 4 cycles, so if it starts at 0+n*4, the bus access proper happens at 0+n*4+2. In fact, if aligned, the CPU starts a bus access cycle right before the MMU will use the bus for video/refresh. Fascinating!

[ijor]

Generally it can land on two zones of the MCU timings. That's what I meant with the question.

The CPU strobe pulse can start absolutely on any cycle. It doesn't have to align with any MMU slot.

Yes we start emulation from 0 and from then on, for every 4 cycles, the first 2 cycles are for MMU, the next 2 cycles are for CPU.

That's just your own convention. You could reverse the time slots and nothing would change at all. Actually even the notion of cycle 0 is a convention, there is no such a thing.

But also on the timing graphics, the MMU slot comes first, so I guess that's how the MMU starts at power-up.

No. There is no guaranteed MMU power up state. The numbers on the waveform are just an easier way to identify the slots. They are not meant to be taken as absolute cycle numbers, because again, there is no such a thing.

It is the same as the video/scan line cycle numbers. The absolute numbers are just a convention. Trying to take absolute cycle numbers as if they would exist at the hardware would lead you to a wrong concept.

[Steven Seagal]

The CPU strobe pulse can start absolutely on any cycle. It doesn't have to align with any MMU slot.

But in practice, since the CPU is so often aligned with the MMU, it should always hit at one or two timings relative to the MMU?
For example, a program changing the Shifter palettes with a MOVEM, I expect the strobe to always happen at the same MMU subcycle (0-15).

That's just your own convention. You could reverse the time slots and nothing would change at all. Actually even the notion of cycle 0 is a convention, there is no such a thing.

.

No. There is no guaranteed MMU power up state. The numbers on the waveform are just an easier way to identify the slots. They are not meant to be taken as absolute cycle numbers, because again, there is no such a thing.

Ah, OK, I thought I found some hardware justification for our convention.
EDIT: unless it's different on the STE?

It is the same as the video/scan line cycle numbers. The absolute numbers are just a convention. Trying to take absolute cycle numbers as if they would exist at the hardware would lead you to a wrong concept.

Yes, in Steem, scan_y is 0 for the first normal (no overscan) scanline using the video memory, whatever the frequency.
But now we have chip-based numbers for DE, BLANK, SYNC!

[ijor]

The CPU strobe pulse can start absolutely on any cycle. It doesn't have to align with any MMU slot.

But in practice, since the CPU is so often aligned with the MMU, it should always hit at one or two timings relative to the MMU?
For example, a program changing the Shifter palettes with a MOVEM, I expect the strobe to always happen at the same MMU subcycle (0-15).

(Bolding Above is mine)

Hmm. Often (even so often) and always are contradictory, aren't they?

Yes, the CPU is often aligned to the MMU, not always. That's exactly why I said, "it doesn't have to align". Sometimes/often/manytimes it will, not always.

[Steven Seagal]

Hmm. Often (even so often) and always are contradictory, aren't they?

"almost always" then

[Gunstick]

Hey, let's revive this thread
I tried to develop some overscan code using hatari and it was a complete failure. We are far from simulating the hardware

Is this also the right thread to geek out about sync scrolling?
I came across Troed's caclulator https://github.com/troed/synctable/blob ... ables.java
so I was wondering how this +2 thing works and spend 2 hours reading that other horizontal scrolling thread. http://www.atari-forum.com/viewtopic.ph ... &start=350

Then I was digging out my own hardwarescroll calculator (the actual code to generate the table for the DSOTS).
Interestingly, ULM (i.e. me) calculated in differences, so the 160 byte line is for me a 0 byte change line.
Here is the table, using the descriptions from my awk program:

Code: Select all

switches
|      diff
|      |   length
|      |   |    comment
0000     0 160  # normal line
1001   +70 230  # overscan line
0001   +44 204  # open right border
1000   +26 186  # open left border
0010    -2 158  # close right border
0100  -106  54  # close middle
1010   +24 184  # open left border and close right border
1100   -80  80  # open left border and close middle

Now adding the "early start switch" just before end of left border to start the screen 2 bytes earlier. Who found that, and when?

Code: Select all

0t000   +2 162  #  early start line
0e001  +46 206  # early start and open right border
0e010    0 160  # early start and close right border (LOL)
0e100 -104  56  # early start and close middle

My code is now online here (I once published it, but could not find where, so now it's github, that should be good). Soon there will be a version calculating with the 12 line lengths instead of the 8. It's quite fast (instaneneous). So I'll see how it copes with 12 possibilities.
https://github.com/Gunstick/hwscroll/bl ... rolltab.sh

[Cyprian]

nice tool.
what about adding 0 byte line length?

[Gunstick]

I found that the 0 byte length was unstable, so I never used id. I knew about it when DSOTS came out, but it was dismissed as unusable.
I don't know why I never found the +2 at the beginning of the screen, because I wrote a program which could put the 50/60 switch at any position sequentially so to test everything.

[ijor]

Hi Gunstick!

I found that the 0 byte length was unstable, so I never used id.

This switch requires code that considers the current wakeup state and adapts the timing accordingly.

[Gunstick]

Hi

I updated my calculator with the 0 byte line. Also gave it some options to change if you use eclock-sync or classic sync and to change the number of different line lengths and on how many scanlines you want to fit the hardware scroller.
https://github.com/gunstick/hwscroll

It effectively calculates that all offsets are possible with 4 lines using eclock and 0 bytes line.
I added some example outputs too.

The program's output is instant. Almost no CPU usage code base from 1989 ...

[Cyprian]

nice

[Gunstick]

Here is the sync-explorer.

A liittle tool to have fun placing a frequency or resolution toggle somewhere on screen.
Behaviour is different between hatari (newest version) and a real STE. Especially with the Hi/Lo switch.
It uses Troed's eclock jitter compensation to stabilize. But on VBL instead of HBL, as I just have a lot of CPU to burn.
https://github.com/Gunstick/syncexplorer

[slingshot]

Here is the sync-explorer.

A liittle tool to have fun placing a frequency or resolution toggle somewhere on screen.
Behaviour is different between hatari (newest version) and a real STE. Especially with the Hi/Lo switch.
It uses Troed's eclock jitter compensation to stabilize. But on VBL instead of HBL, as I just have a lot of CPU to burn.
https://github.com/Gunstick/syncexplorer

I wonder if there should be a difference between ST and STe (vbl position is the same?).
Is there any reference screenshots avaliable from real hardware?
These are made on MiST, STe mode:

Photo0071.jpg

Photo0072.jpg

These are very differnt from Hatari (length of the light blue/purple bars - and the main area recoloring, looks like the shifter is de-synced, and the bitplanes are shifted - upd: it's only desynced when TOS in medium mode)

Photo0073.jpg

Photo0074.jpg

[Cyprian]

Hi

I updated my calculator with the 0 byte line. Also gave it some options to change if you use eclock-sync or classic sync and to change the number of different line lengths and on how many scanlines you want to fit the hardware scroller.
https://github.com/gunstick/hwscroll

It effectively calculates that all offsets are possible with 4 lines using eclock and 0 bytes line.
I added some example outputs too.

The program's output is instant. Almost no CPU usage code base from 1989 ...

BTW.
that part would not work as expected:
https://github.com/Gunstick/syncexplore ... ini-init.s

Code: Select all

        move.w  #$07ff,$ffff8924.w
        move.w  #%0000010011101000,$ffff8922.w ;set volume
        move.w  #%0000010101010100,$ffff8922.w ;set left channel volume
        move.w  #%0000010100010100,$ffff8922.w ;set right channel volume
        move.w  #%0000010010000110,$ffff8922.w ;set treble
        move.w  #%0000010001000110,$ffff8922.w ;set bass
        move.w  #%0000010000000001,$ffff8922.w ;set mix GI sound chip output

Micorwire needs about (worst case) 132 CPU cycles to transfer one parameter.
Therefore between "move.w" should be inserted a mask: "move.w #$07ff,$ffff8924.w" and: inserted a appropriate delay or verification whether data was sent ($ffff8924.w)

More details there: https://listengine.tuxfamily.org/lists. ... 00001.html