68000 clock cycles table

[leonard]

humm don't remember well what was the question... but to determine Y let's try...

there is no tons of possibilities, so maybe you could try all values of Y (I guess it's noticed in NOP in the alien's article). do try some 60/50hz flip at 128 possible position. you can for exemple set to 60 at Y+3 and restore 50 at Y+4 maybe. so If I follow your pseudo code, the Hsync is not desactivated, so new line is not starting? Try 128 possibilities, if if some one line is not started (don't know what kind of visual effect it could do), then you know the Y value.

Is it the same Y value for all ST ?

[ijor]

humm don't remember well what was the question...

The question was:

Why the new switches require a precision of 2 cycles (all the other overscan switches require a precision of 4 or more cycles)?

but to determine Y let's try...

That was a hint. Because if you determine Y, then you would find the answer to the original question.

so If I follow your pseudo code, the Hsync is not desactivated, so new line is not starting?

It is not my seudocode, it is Alien's one.

[MiggyMog]

I just got to testing hard162e.prg on my 4MB STE and

Get the same as Daeghnao. I.E. just flickering Black & White with no pic.

[ljbk]

Hi !

We have seen that it seems that HARD162E does not work on the STE.
Well in order to find out if there is a timing working for some of the STEs, i built a set os programs that test all the logical possibilities to have 162 bytes lines on STE.
You can find these 44(!) cases in the file in attach.
Out of these, 24 work with Steem v3.2 but none of these 24 work on my STF in any of the wake-up states.
2 of the combinations are the working ones on STFs depending on the wake-up state, included in HARD162E, but they do not work with Steem and also not on real STE as it seems.

If anyone that has an STE wants to test this set of programs, here what should happen:
- if it works a stable "bee" appears
- if it does not work, a flashing screen appears
If there is any one working, please refer the name of the program(s).

Cheers,
Paulo.

[leonard]

Hi Paulo !

Unfortunatly I don't have my real STE anymore..

Out of these, 24 work with Steem v3.2

Do you mean Steem 3.2 is already supporting 162 bytes line?? Dawn these guys are pretty fast !!

[ljbk]

Hi Paulo !

Unfortunatly I don't have my real STE anymore..

Out of these, 24 work with Steem v3.2

Do you mean Steem 3.2 is already supporting 162 bytes line?? Dawn these guys are pretty fast !!

Yes they do but not at the STF time spots.
So either their SW supports this because there are some STEs doing so (Steem is STE emulator) or just by pure luck due to their NTSC screen emulation.

Out of the 44 cases, 5 work with STF wake-up 2 and 1 with STF wake-up 1.

[MiggyMog]

STE 1.62 4MB (wake up mode 1) on colour TV

2507 border flashes as B & W Distorted pic skews lines 2-10 approx
2509 border flashes as B & W Distorted pic skews lines 2-10 approx
2511 border flashes as B & W Distorted pic skews lines 2-10 approx
2515 border flashes as B & W Distorted pic skews lines 2-10 approx
2711 border flashes as B & W Distorted pic skews lines 2-10 approx
2713 border flashes as B & W Distorted pic skews lines 2-10 approx
2715 border flashes as B & W Distorted pic skews lines 2-10 approx
2719 border flashes as B & W Distorted pic skews lines 2-10 approx
2911 border flashes as B & W Distorted pic skews lines 2-10 approx
2913 border flashes as B & W Distorted pic skews lines 2-10 approx
2915 border flashes as B & W Distorted pic skews lines 2-10 approx
2919 border flashes as B & W Distorted pic skews lines 2-10 approx
3115 border flashes as B & W Distorted pic skews lines 2-10 approx
3117 border flashes as B & W Distorted pic skews lines 2-10 approx
3119 border flashes as B & W Distorted pic skews lines 2-10 approx
3123 border flashes as B & W Distorted pic skews lines 2-10 approx
3315 border flashes as B & W Distorted pic skews lines 2-10 approx
3317 border flashes as B & W Distorted pic skews lines 2-10 approx
3319 border flashes as B & W Distorted pic skews lines 2-10 approx
3323 border flashes as B & W Distorted pic skews lines 2-10 approx
3519 border flashes as B & W Distorted pic skews lines 2-10 approx
3521 border flashes as B & W Distorted pic skews lines 2-10 approx
3523 border flashes as B & W Distorted pic skews lines 2-10 approx
3527 stable but pic corrupt border flashes
3719 border flashes as B & W Distorted pic skews lines 2-10 approx
3721 border flashes as B & W Distorted pic skews lines 2-10 approx
3723 border flashes as B & W Distorted pic skews lines 2-10 approx
3727 stable but pic corrupt border flashes
3923 border flashes as B & W Distorted pic skews lines 2-10 approx
3925 stable but pic corrupt border flashes
3927 stable but pic corrupt border flashes
3931 stable but pic corrupt border flashes
4123 border flashes as B & W Distorted pic skews lines 2-10 approx
4125 stable but pic corrupt border flashes
4127 stable but pic corrupt border flashes
4131 stable but pic corrupt border flashes
4327 no image just b& W flashing background
4329 no image just b& W flashing background
4331 no image just b& W flashing background
4335 no image just b& W flashing background
4731 shows a picture of a bee!!! stable & not skewed no flash
4733 shows a picture of a bee!!! stable & not skewed no flash
4735 shows a picture of a bee!!! stable & not skewed no flash
4739 shows a picture of a bee!!! stable & not skewed no flash


The ones which skew on the early lines seem to skew by different amounts

[ljbk]

STE 1.62 4MB (wake up mode 1) on colour TV

2507 border flashes as B & W Distorted pic skews lines 2-10 approx
2509 border flashes as B & W Distorted pic skews lines 2-10 approx
2511 border flashes as B & W Distorted pic skews lines 2-10 approx
2515 border flashes as B & W Distorted pic skews lines 2-10 approx
2711 border flashes as B & W Distorted pic skews lines 2-10 approx
2713 border flashes as B & W Distorted pic skews lines 2-10 approx
2715 border flashes as B & W Distorted pic skews lines 2-10 approx
2719 border flashes as B & W Distorted pic skews lines 2-10 approx
2911 border flashes as B & W Distorted pic skews lines 2-10 approx
2913 border flashes as B & W Distorted pic skews lines 2-10 approx
2915 border flashes as B & W Distorted pic skews lines 2-10 approx
2919 border flashes as B & W Distorted pic skews lines 2-10 approx
3115 border flashes as B & W Distorted pic skews lines 2-10 approx
3117 border flashes as B & W Distorted pic skews lines 2-10 approx
3119 border flashes as B & W Distorted pic skews lines 2-10 approx
3123 border flashes as B & W Distorted pic skews lines 2-10 approx
3315 border flashes as B & W Distorted pic skews lines 2-10 approx
3317 border flashes as B & W Distorted pic skews lines 2-10 approx
3319 border flashes as B & W Distorted pic skews lines 2-10 approx
3323 border flashes as B & W Distorted pic skews lines 2-10 approx
3519 border flashes as B & W Distorted pic skews lines 2-10 approx
3521 border flashes as B & W Distorted pic skews lines 2-10 approx
3523 border flashes as B & W Distorted pic skews lines 2-10 approx
3527 stable but pic corrupt border flashes
3719 border flashes as B & W Distorted pic skews lines 2-10 approx
3721 border flashes as B & W Distorted pic skews lines 2-10 approx
3723 border flashes as B & W Distorted pic skews lines 2-10 approx
3727 stable but pic corrupt border flashes
3923 border flashes as B & W Distorted pic skews lines 2-10 approx
3925 stable but pic corrupt border flashes
3927 stable but pic corrupt border flashes
3931 stable but pic corrupt border flashes
4123 border flashes as B & W Distorted pic skews lines 2-10 approx
4125 stable but pic corrupt border flashes
4127 stable but pic corrupt border flashes
4131 stable but pic corrupt border flashes
4327 no image just b& W flashing background
4329 no image just b& W flashing background
4331 no image just b& W flashing background
4335 no image just b& W flashing background
4731 shows a picture of a bee!!! stable & not skewed no flash
4733 shows a picture of a bee!!! stable & not skewed no flash
4735 shows a picture of a bee!!! stable & not skewed no flash
4739 shows a picture of a bee!!! stable & not skewed no flash


The ones which skew on the early lines seem to skew by different amounts

Hello !

Many thanks indeed !

This means that the STE needs the switch to 60 Hz to be done at pixel -47 and does not care when we switch back to 50 Hz !!!
If you run the 47xx in Steem 3.2, they will not work.
I have to produce two prgs starting at pixel 47 and compatible with the STF that cares mainly about the switch back to 50 Hz.

Edit:
Here are the 2 progs in attach.
One, 4729, should work on STF with wake up state 1 (i could not test it as it is quite dificult to reach that wake up state).
The other, 4727, works on my STF with wake up state 2.

[ijor]

4731 shows a picture of a bee!!! stable & not skewed no flash
4733 shows a picture of a bee!!! stable & not skewed no flash
4735 shows a picture of a bee!!! stable & not skewed no flash
4739 shows a picture of a bee!!! stable & not skewed no flash

But of course!

Wow, congratulations to Paulo. Honestly, after the initial test failed, I thought the new scan lengths wouldn't be possible on the STe. But Paulo really amazes me. He doesn't seem to understand all the theory behind. He doesn't care about the why. He only cares about the how. And he has an amazing talent to finding the right way.

I think I now understand why the initial test didn't work in the STe, and why this one does work. It is actually even obvious if you want. But it obvious, only after somebody like Paulo finds how to do it. Hats off.

I would need to code a small STe test to confirm my theory. But in the meantime let's go back to the behavior in the ST. Why the new switches require more precision than all the other ones? What is the value of Y in Alien's seudo-code?

What Alien couldn't find, is a 50/60 Hz switch that would alter the end of the line. Probably he didn't attempt to avoid HSYNC. But I guess he at least tried to change the length line from 512 cycles (60 Hz) to 508 cycles (50 Hz).

From different sources you can estimate the position of the theoretical end of the line. And if you try to make a 50/60 switch anywhere nearby, you won't be able to alter the sync position. As a matter of fact, any 50/60 switches that could conceivable is close to the end of the line, seems to be completely ignored.

Well, the answer is that there is no exact Y value that fits Alien's model of GLUE. Alien made a wonderful model of GLUE video state machine. But it is not perfect. In his model, GLUE makes a number of comparisons each 4 cycles. The comparisons check the current horizontal position and the current frequency. All the comparisons are made simultaneously (that's how normally hardware works). And if any of those matches, then a given signal is raised or lowered.

A fundamental aspect of this model is that GLUE doesn't keep any history. All decisions are taken according to the current state. This is so important, because otherwise overscan wouldn't work at all. If GLUE would work more like a software code, then all decisions could be done at the same time. Once per line, or even once per frame. Then this whole thread would have not existed, because full-screen and sync-scroll wouldn't be possible at all.

But the model is not perfect and GLUE does keep some history. So the decision for the whole length of the scan is decided much earlier … precisely where our new switches work. To be more precise, the decision about the end of the line is taken exactly between the point that GLUE decides to start the display at 60Hz, and the one to start the display at 50Hz.

And that's why the window in the left border is reduced and the new switches require more precision. Because otherwise, if the switch is two us later or earlier, GLUE would produce a line of 508 cycles.

Note btw that this mean that there is no 50/60 switch that could skip HSYNC. Contrary to the other GLUE decisions, the decision for either the 50 or 60 Hz length are decided at the same point.

Somebody might note that other aspect of Alien's model is broken. A minor one in this case. This decision is not taken in a 4 cycles boundary in relation to all the other ones. This is actually not the only case. But too late now and this is going too far. May be next time I'll elaborate on this

[ljbk]

STE 1.62 4MB (wake up mode 1) on colour TV
4327 no image just b& W flashing background
4329 no image just b& W flashing background
4331 no image just b& W flashing background
4335 no image just b& W flashing background

Hello again !

Theses lines make me think that may be you have just found the 0 bytes line case for the STE ...

In order to test it, i provided in attach 6 programs, all with a sync switch at pixel -43 and a different spot for the switch back + the 2 cases working on the STF depending on the wake up mode (those will almost surely not work on STEs).
In case the 0 bytes line works, you will see a stable scrolling bee up and down like it happens on my STF.
If you have an STF, the 0STE43xx stuff will not work, but one of the other two should work.


Have fun,
Paulo.

[ijor]

Theses lines make me think that may be you have just found the 0 bytes line case for the STE ...

Hi Paulo,

Did you receive my latest email earlier today? From my description of the STe behavior you could compute the exact timing required for a scan of 0 bytes.

[ljbk]

Theses lines make me think that may be you have just found the 0 bytes line case for the STE ...

Hi Paulo,

Did you receive my latest email earlier today? From my description of the STe behavior you could compute the exact timing required for a scan of 0 bytes.

For wake-up 1, your theory also gives the value 43.
For wake-up 2, your theory leads to the value 41.
I don't know it there are STEs with wake-up 2.

[MiggyMog]

Still wake up state 1 4MB STE tos 1.62

HSTE4727 shows wasp ( I was tired last night ) ,stable
HSTE4729 shows wasp stable

0STE4315 stable apart from lines 3 to about 20, is flicking in & out sometimes too! Line 2 is blank.
0STE4319 as 4315
0STE4323 as 4315
0STE4327 line 1 stays still, rest of picture sync scrolls up and down!!!
0STE4331 line 1 stays still, rest of picture sync scrolls up and down!
0STE4335 line 1 stays still, rest of picture sync scrolls up and down!

BTW
STFwak1 shows stable pic except skew on about line 3 to 5
STFwak2 does the same as STF wak1

Can we do experiments on the STE registers for paralax scrolling/split screens next this is fun!

[ljbk]

Still wake up state 1 4MB STE tos 1.62

HSTE4727 shows wasp ( I was tired last night ) ,stable
HSTE4729 shows wasp stable

0STE4315 stable apart from lines 3 to about 20, is flicking in & out sometimes too! Line 2 is blank.
0STE4319 as 4315
0STE4323 as 4315
0STE4327 line 1 stays still, rest of picture sync scrolls up and down!!!
0STE4331 line 1 stays still, rest of picture sync scrolls up and down!
0STE4335 line 1 stays still, rest of picture sync scrolls up and down!

BTW
STFwak1 shows stable pic except skew on about line 3 to 5
STFwak2 does the same as STF wak1

Can we do experiments on the STE registers for paralax scrolling/split screens next this is fun!

Well, again many thanks MiggyMog !
Thanks to your tests we are now able to have the +2 bytes lines and the 0 bytes lines also on the STEs.

I will now explain the timings, so that anyone can make use of them.
If you know how to do a tipical fullscreen line, then you will not have any problems.
Let's assume some registers:
d0=0 ; d2=2 ; a5=ff820a ; a6=ff8260
The tipical fullscreen line is as follows both for STF and STE:

move.b d0,(a5) right border switch
move.b d2,(a5)
... 13 nops / 52 cycles
move.b d2,(a6) stabilization
... nop / 4 cycles
move.b d0,(a6)
... 12 nops / 48 cycles
move.b d2,(a6) left border switch
... nop / 4 cycles
move.b d0,(a6)
... 89 nops / 356 cycles

Each move.b takes 2 nops time = 8 cycles.
The second move.b from the left border switch ends at pixel -71 in the scale i use (an update to color 0 register ending here would cause that the background color would change 71 pixels before the normal PAL screen starts)
Both the 0 bytes line and the + 2 bytes effect are obtained with a switch similar to the right border one: a 60/50.

a) the + 2 bytes effect

On STF, the switch back to 50Hz (second move.b of the pair) has to be done at pixel -27 or -29 depending on the wake-up state: 11 nops or 9nop+1exg after pixel -71
On STE, for wake-up state 1 (it is not clear if there is a second one on STE), the switch to 60 Hz has to be done at pixel -47: 6 nops after pixel -71
=> So a combination 47/27 or 47/29 works on both !

b) the 0 bytes line : only border color is displayed => cutting pic effect

On STF, the switch to 60 Hz has to be done at pixel -25 or -27 depending on the wake-up state. The switch back can only occur at pixel -15 or -19 depending on the wake-up state or a bit after.
On STE, for wake-up state 1, the switch to 60 Hz has to be done at pixel -43 and the switch back has to be done until pixel -27.
=> So, there is no common combination to STF and STE but it is always possible to detect STE/STF and patch the code.

These effects allow, that scrolling/cutting picture effect, but also, together with the other known effects, theorically, as refered above, to :
- sync-scroll a fullscreen in 1sync_line+4lines
- sync-scroll a fullscreen in 4 lines without syncing
- sync-scroll a 320 pixels wide screen in 1sync_line+3lines
- sync-scroll vertically a 320 pixels wide screen in 3 lines without syncing

You can now start programing some new demos ...

Have fun,
Paulo.

[Lando_C]

A_MAZ_ING_!

*new* demo tachniques on tHE ST in 2006...

Kudos, ppl

[leonard]

thanks Paulo and Ijor for all these great explains !

You can now start programing some new demos

finding spare time to write demo is even harder than before today

Well, I sometimes try to make somthing with my old amiga Paula emulator. It's a generic emulator, which can play amiga exotic music with ease (don't need to change anything in data, unrolling loop etc...). It just work with the original amiga code and data (well you juts have to change the access to "dff0a0" to custom pointers.

It works at 25khz on STE. I wanted to do something with but I don't succeed in finding a right amiga turrican2 TFMX source code player

[DrCoolZic]

Extremely interesting thread with a lot of usefull information. The main focus of the thread has somewhat derived from instruction timing to overscan ... and therefore ...

I am sure that most of the people doing overscan are aware of the great article written by Alien and published in three parts in ST Magazine.

You can find the original article in French at http://www.abandonware-magazines.org/af ... .php?mag=6 and a good English translation at http://alive.atari.org/ (Unfortunately the part III is missing in the English version).

For reference I thought it would be interesting to attach this article to this thread. I have therefore Edited the different html pages in one clean pdf file that I am attaching here.

Also attached is the far less complete but interesting "Fullscreen"-Programming on the Atari ST by Flix of Delta Force http://en.wikipedia.org/wiki/Delta_Forc ... mogroup%29

Enjoy
Jean

[DrCoolZic]

Code: Select all

note that the determination of the exact moment of the HBL triggering was impossible...furthermore, the determination of Y is not interesting at all ...

SEUDO-CODE
...
IF Position ==  13   AND display_freq=60 THEN Activate signal H
IF Position ==  14   AND display_freq=50 THEN Activate signal H
IF Position ==  93   AND display_freq=60 THEN de-activate signal H
IF Position ==  94   AND display_freq=50 THEN de-activate signal H
IF Position ==   Y   AND display_freq=60 THEN Activate Hsync
IF Position == Y+1   AND display_freq=60 THEN de-activate Hsync, start new line
IF Position == Y+2   AND display_freq=50 THEN Activate Hsync
IF Position == Y+3   AND display_freq=50 THEN de-activate Hsync, start new line

Are you sure? If Alien is right the code (presented in page 10 of the Overscan Technique part II) is shown as:

Code: Select all

note that the determination of the exact moment of the HBL triggering was impossible...furthermore, the determination of Y is not interesting at all ...


PSEUDO-CODE
...
IF Position ==  13   AND display_freq=60 THEN Activate signal H
IF Position ==  14   AND display_freq=50 THEN Activate signal H
IF Position ==  93   AND display_freq=60 THEN de-activate signal H
IF Position ==  94   AND display_freq=50 THEN de-activate signal H
IF Position ==   Y   AND display_freq=60 THEN Activate Hsync
IF Position == Y+1   AND display_freq=60 THEN de-activate Hsync, start new line
IF Position == Y+1   AND display_freq=50 THEN Activate Hsync
IF Position == Y+2   AND display_freq=50 THEN de-activate Hsync, start new line

Jean

[ijor]

Are you sure? If Alien is right the code (presented in page 10 of the Overscan Technique part II) is shown as:

You are right, I made a typo. But as I explained, Alien was completely wrong about the behavior of "Y". So the whole seudo-code (and not just the values) regarding the activation of Hsync and starting a new line, is wrong.

[ljbk]

Hi !

Now that timings are more or less clear, let's talk about Shifter unstability and possible explains.
If you use the 12 possible line sizes you have many combinations to get the simulated offset required.
The problem is that sometimes you get an unstable image: at some VBLs it start at the right position, then sometimes 4 pixels before, even sometimes 8 pixels before and also sometimes with messed up bitplanes.
As i am looking to put the theory refered above into practice here is an example with 4 scan lines:
To get offset 32H, you can use 2 lines with 160 bytes, 1 line with 162 bytes and another one with 80 bytes. Sum =562 or 232H.
The problem is that this combination of line sizes no matter the order you use them results in an unstable picture with my STF in wake up state 2 ...
But if i use 160, 162, 56 and 184, it is all ok.

In some other cases, i also get a stable picture starting 4 pixels earlier but with the wrong bitplanes like the simple case: 160,160,160,162.
That unstability is not always the same as it changes with the amount of time my STF has been turned on and probably also with heat, etc ...

Order is also important:
160,80,184,186 -> unstable
160,80,186,184 -> stable ok
160,184,80,186 -> stable starting 4 pixels early
160,184,186,80 -> stable but with 1st pic line messed up
160,186,184,80 -> stable ok
160,186,80,184 -> stable ok

By the way, all the above written changes completely if we always use the stabilizer switch for all 4 lines. Some stable cases become unstable and vice-versa ...

What i have learned so far from my experience is that the last line of the sync lines that is different from 160 is the most important one to influence the stability of the 320 pixels wide pic following.

Ijor, do you have an explain for this ?

[ijor]

Hi Paulo,

The problem is that sometimes you get an unstable image:
... By the way, all the above written changes completely if we always use the stabilizer switch for all 4 lines. Some stable cases become unstable and vice-versa ...

I don't remember if I mentioned it already. But I was suspecting all the time this is a Shifter stabilization issue. I was expecting/hoping that if you would stabilize on all lines (even those that are supposed to be stable), then the problem would go away.

Unfortunately Shifter stabilization is a topic I don't know much about it. I still think that stabilization switches should provide a fix. From you description I realize however that the stabilization timing might be wrong. Some scan lengths might require the stabilization switch to be performed at a different spot. It is also likely that using a med rez. switch would have a different effect than a mono one.

I would need to study the issue a bit.

[ljbk]

Hi !

Here's a little program that takes advantage of our recent findings.
I included the file version and an ST image disk version.
It "should" run on all real machines.
At least it runs for sure on an STF(wake up 2).
I could not test it with wake up 1 as it is real dificult to reach with my STF.
Of course it does not run with the current releases of the emulators as the sync switches are not emulated there.
STE detection is done via the bits 3/7/11 of the color registers: writing there, reading and comparing bits with 0 and 1.
SainT does not seem to support such a test as it returns always the written value even for an STF ...
My STF returns these bits always at 1.

Enjoy it.

[unseenmenace]

STE detection is done via the bits 3/7/11 of the color registers: writing there, reading and comparing bits with 0 and 1.
SainT does not seem to support such a test as it returns always the written value even for an STF ...
My STF returns these bits always at 1.

If you had an STF with a 4096 or 32768 colour hardware mod presumably that would also get detected as an STE? Just a thought

[ljbk]

STE detection is done via the bits 3/7/11 of the color registers: writing there, reading and comparing bits with 0 and 1.
SainT does not seem to support such a test as it returns always the written value even for an STF ...
My STF returns these bits always at 1.

If you had an STF with a 4096 or 32768 colour hardware mod presumably that would also get detected as an STE? Just a thought

Ok, you are right. But as i am saying in the prg, it is not optimized.
The complete set of $FF82xx registers can be tested, especially $FF820D/0E/0F/65, writing $55 and $AA and then reading and comparing.
Also the hardware can be checked via controlling the video counters using the specific STE HW registers $FF820D/0E/0F/65.
That would be for a fully optimized STE video HW detection.
Cookie Jar variable at $5A0 is no solution as you can set the STE value in an STF.
If you have better ideas for an STE detection, please write them as it is always dificult to deal with hardware mods trying to identify the HW in use.

[ijor]

Hi Paulo,

I could not test it with wake up 1 as it is real dificult to reach with my STF.

If your machine behaves like mine, then you should get that wake up when it is cold. Make sure the computer was left off overnight. Then run all your tests under this wakeup without power cycling the computer.

Here's a little program that takes advantage of our recent findings.

Great work! Did you fix the stability issue? Or the problem doesn't happen in non full-screen pics?

If you have better ideas for an STE detection...

I agree with unseenmenace. Checking the unused bits in the palette registers doesn't sound like the best method. As you say there are multiple ways, but probably the simplest is to to put the screen in a non 256 bytes boundary.