68000 clock cycles table

MiggyMog · Post by **MiggyMog** » Thu Oct 05, 2006 9:59 pm

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 · Post by **ljbk** » Thu Oct 05, 2006 11:04 pm

MiggyMog wrote: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.

Post by **ijor** » Fri Oct 06, 2006 6:31 am

MiggyMog wrote: 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 · Post by **ljbk** » Fri Oct 06, 2006 2:25 pm

MiggyMog wrote: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.

Post by **ijor** » Fri Oct 06, 2006 3:36 pm

ljbk wrote: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 · Post by **ljbk** » Fri Oct 06, 2006 4:16 pm

ijor wrote:
ljbk wrote: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 · Post by **MiggyMog** » Fri Oct 06, 2006 6:29 pm

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 · Post by **ljbk** » Fri Oct 06, 2006 8:51 pm

MiggyMog wrote: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 · Post by **Lando_C** » Sat Oct 07, 2006 7:58 am

A_MAZ_ING_!

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

Kudos, ppl

leonard · Post by **leonard** » Sat Oct 07, 2006 2:20 pm

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 · Post by **DrCoolZic** » Wed Oct 18, 2006 12:59 pm

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 · Post by **DrCoolZic** » Wed Oct 18, 2006 1:05 pm

ijor wrote:

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

Post by **ijor** » Wed Oct 18, 2006 3:52 pm

DrCoolZic wrote: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 · Post by **ljbk** » Sat Oct 21, 2006 3:09 pm

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 ?

Post by **ijor** » Sun Oct 22, 2006 7:54 pm

Hi Paulo,

ljbk wrote: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 · Post by **ljbk** » Mon Oct 23, 2006 12:02 am

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 · Post by **unseenmenace** » Mon Oct 23, 2006 7:17 am

ljbk wrote: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 · Post by **ljbk** » Mon Oct 23, 2006 9:41 am

unseenmenace wrote:
ljbk wrote: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.

Post by **ijor** » Mon Oct 23, 2006 5:56 pm

Hi Paulo,

ljbk wrote: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.

ljbk · Post by **ljbk** » Mon Oct 23, 2006 8:22 pm

ijor wrote:Hi Paulo,

ljbk wrote: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.

Hi !

Not even with more than 20 hours without running, i get wake up state 1.

The 32 combinations used do not have stability problems, but i do not have a clear explanation why some others do. Stabilizer is not used for every line size as i have noticed that those cases introduce instability.
I hope to get 128 stable combinations for a fullscreen sync scroll with 1+4lines.

Edit: 5 minutes after i wrote the post i managed to get wake up state 1 after some 5 or 6 cold resets, so i think it is pure luck. Btw, the program works perfectly with wake up state 1 as well. I hope it also works with STEs.

Post by **ijor** » Mon Oct 23, 2006 9:08 pm

ljbk wrote:Not even with more than 20 hours without running, i get wake up state 1.

Oh, I see.

Stabilizer is not used for every line size as i have noticed that those cases introduce instability.

You are right. A stabilizer might make a stable line (or combination) unstable. But this should depend on the exact time spot you perform the stabilizer, the time between both switches, and also if it is a med rez or a high rez switch.

I hope to get 128 stable combinations for a fullscreen sync scroll with 1+4lines.

A question that would help me understand how the stabilization mechanism works: What happens if you have a screen where all the lines are 158 bytes long? Do you need a stabilizer? Can you stabilize these lines at all?

ljbk · Post by **ljbk** » Tue Oct 24, 2006 12:09 am

ijor wrote:
ljbk wrote:Not even with more than 20 hours without running, i get wake up state 1.
Oh, I see.

Stabilizer is not used for every line size as i have noticed that those cases introduce instability.
You are right. A stabilizer might make a stable line (or combination) unstable. But this should depend on the exact time spot you perform the stabilizer, the time between both switches, and also if it is a med rez or a high rez switch.

I hope to get 128 stable combinations for a fullscreen sync scroll with 1+4lines.
A question that would help me understand how the stabilization mechanism works: What happens if you have a screen where all the lines are 158 bytes long? Do you need a stabilizer? Can you stabilize these lines at all?

I only stabilize (high rez switch) lines where a high res was faked.
Stabilizing 158 bytes lines leads to unstability.
Btw, with wake up 1, i found out that 3 of the 32 combinations used to get the offsets have a slight unstability. After checking for a solution for these 3 cases and returning to wake up 2, i fount out that one of the changes that lead to a stable pic with wake up 1, leads to an unstable pic with wake up 2.
For this particular offset, i have to test all possibilities to find one that works for both wake ups.
As you can see, stability also depends on the wake up mode ...

Example: 160,162,160,160,184, followed by 230 bytes lines, is stable for wake up 1, but gives a garbage 1st 230 bytes bitmap line in wake up 2 ...

alien · Post by **alien** » Tue Oct 24, 2006 6:04 pm

ijor wrote:
DrCoolZic wrote: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.

Actually... I believe the article said it was a "SIMPLIFIED PRESENTATION". The reason I simplified it was that I knew it did not embody the full truth, but the additional complexity didn't help in understanding stuff. As it was, I was amazed it ever got published. Try publishing something that complex today...

MiggyMog, Spectrum 512 distortion occured on real STs too. There was a program shipped with spectrum 512 that people used to check the wake up state visually, although Paulo's the first person I know to do this automatically without human feedback.

IIRC, my final hardscroll routines were 5 scanlines. 5 scanlines including the syncline which could be in 158/160/162/20x modes. That was for a fullscreen. Because this is a 15 year old memory, it may well be wrong. I'd have to find the source code and check, but that is my recollection. I did use the zero length line back then.

Anyway, bravo to Paulo for continuing this research and bringing it forwards to the STE... I never had one, because I was underwhelmed by it. ST CNX detected STEs by writing to the microwire register, IIRC. If that caused a bus error, we were on an ST.

Since Paulo's into new stuff, one research project I did not complete was: Exploit instability! Remember that sometimes after a mode switch, the screen was distorted (bitplanes shifted). This happens because some of the shifters' RR registers are already full, and VBL doesn't clear that. You may not have noticed, but in this case, the screen is shifted left by 4/8/12 pixels. So can we use this to make a 4bit scroller on an Atari ST in 320x200 mode? I got it working, IIRC, for 3 of the 4 combinations... but again it's a LONG time ago. By NOT using the stabilizer, and finding the right combination of lines in a preceeding hardscroll, one can shift the screen around.

Of course another avenue of research, which may/may not be fruitful, is trying NoCrew's 4 cycle enable/disable technique.

Right now, I can't help because I'm busy readying my first independent product since the days of the ST (the 5 million copies of my sound synthesizer were made for my employer, Cyrix). Find It! Keep It! for the Mac. www.ansemond.com if you're interested.

Post by **ijor** » Tue Oct 24, 2006 6:46 pm

alien wrote:Actually... I believe the article said it was a "SIMPLIFIED PRESENTATION". The reason I simplified it was that I knew it did not embody the full truth, but the additional complexity didn't help in understanding stuff. As it was, I was amazed it ever got published. Try publishing something that complex today...

Hi Alien, Nice to see you here again!

Well, you had a couple of conceptual mistakes. This doesn't detract at all. Your articles are excellent, and are still the best reference in the topic.

MiggyMog · Post by **MiggyMog** » Tue Oct 24, 2006 7:59 pm

MiggyMog, Spectrum 512 distortion occured on real STs too. There was a program shipped with spectrum 512 that people used to check the wake up state visually, although Paulo's the first person I know to do this automatically without human feedback.

I must have been lucky with the first ST I had, an STFM with uk tos 1.2 that always showed spectrum 512 pictures no problem, as did all the my friends STFMS at the time some with older/newer boards & TOS. My first STE was a nightmare however, it showed the speckles nearly all the time.

I knew there was a little program included to check that it was syncing ok but I didn't know that there was an option to do anything about it when it was incorrect? also I didn't know what it should be in either state?

As for use of sync scrolling, I have seen that bugged on demos on both, enchanted land seemed to work fine on either machine however so TCB's check could be counted as an automatic check for this? (I always wondered at the time why you got the 70hz wining noise just after boot up)