68000 clock cycles table

[ljbk]

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.

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.

[ijor]

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]

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]

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.

[ijor]

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]

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)

[ljbk]

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.

Hi Alien !

The major problem with instability is for a 320 pixels pic because for fullscreen lines, the Shifter gets stabilized more than 200 times before the VBL. There are only a few combinations leading to an unstable fullscreen.
I know, since 1990, about some combinations to get the "normal" screen starting 4 or 8 pixels early, but i never found one to have it 12 pixels early or 4 pixels late. But you are right, if this was found, this could lead to the 4 bit syncscroll for an "almost normal" screen.
I don't know about that "NoCrew's 4 cycle enable/disable technique".
Can you explain a bit or send me an email about it ?

Good luck for your project.

[unseenmenace]

ST CNX detected STEs by writing to the microwire register, IIRC. If that caused a bus error, we were on an ST.

Thats probably the best method as if the machine has a microwire system then you also know its not a Falcon.

[ljbk]

ST CNX detected STEs by writing to the microwire register, IIRC. If that caused a bus error, we were on an ST.

Thats probably the best method as if the machine has a microwire system then you also know its not a Falcon.

Please don't for that in this what is needed is do detect STE type video HW.
So if someone modded an STF with a MMU, Glue and Shifter from an STE, it is enough to be considered an STE for this case.
So i guess that the best is still to test $ff82xx registers capabilities.

[unseenmenace]

Please don't for that in this what is needed is do detect STE type video HW. So if someone modded an STF with a MMU, Glue and Shifter from an STE, it is enough to be considered an STE for this case. So i guess that the best is still to test $ff82xx registers capabilities.

I see your point I was just thinking that if you tested for an STE hardware register and found it was there you'd assume it had STE video hardware but it may be a Falcon or a TT and therefore behave very differently.

[alien]

Hi Alien !

I don't know about that "NoCrew's 4 cycle enable/disable technique".
Can you explain a bit or send me an email about it ?

The trick is apparently to exploit the 68000's internal prefetching
Leonard explains it here http://bbs.dhs.nu/coding/index.php?request=2049, based on an explanation by Ijor.
I believe NoCrew discovered it.

I've never tried it... But, if I had the time, I would run some tests, to see if anything new can be discovered with this new microscope!

Good luck for your project.

Thanks!

[ljbk]

Hi Alien !

I don't know about that "NoCrew's 4 cycle enable/disable technique".
Can you explain a bit or send me an email about it ?

The trick is apparently to exploit the 68000's internal prefetching
Leonard explains it here http://bbs.dhs.nu/coding/index.php?request=2049, based on an explanation by Ijor.
I believe NoCrew discovered it.

I've never tried it... But, if I had the time, I would run some tests, to see if anything new can be discovered with this new microscope!

Thanks !

Yes, i remember now about this 4 pixels wide "rasters" demo.
I have to think about it.

[ijor]

Yes, i remember now about this 4 pixels wide "rasters" demo.

I'm not sure it would be useful. What the "trick" essentially achieves is the capability to write twice in a row to any arbitrary address, including the very same one.

It doesn't look like you can get anything from GLUE out of this. Almost all GLUE switches can be performed with plenty of time between one write and the other. Actually, in some cases the second write doesn't need to be done at all.

But who knows, may be somebody can come out with any idea. And it might be useful in some SHIFTER stabilization method.

[ljbk]

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.

Just for your info, and as far i have found out until now, it is possible to have a 4 bit sync scroll with a "normal" screen with GLUE in wake up state 2 but not with GLUE in wake up state 1.
In general terms, wake up state 1 is much more stable than wake up state 2 regarding Shifter behaviour.
Just as timings changed between the CPU and the MMU between the 2 wake up states, they also change between the MMU and the Shifter and so the Shifter behaviour while handling instability (remaining words + resolution switches) is different: i have 1 shift missing until now.
Even for GLUE in wake up state 2, the thing does not work 100% correctly with all Shifter wake up states (delays to the CPU) and as far as i know, unlike GLUE wake up states, Shifter wake up states can not be detected by a running program.

But i have still many things to try, so who knows ...

[ljbk]

Hi !

I have explored a little more the Enchanted Land sync switch.
Here are some of the results:

- the switch spot is located exactly where right border reading from the MMU ends: so if you consider Alien's scale, it is at spot 94(right border) + (44bytes/2)= 116. In my scale it is at pixel 381 (right border spot is at pixel 293)

- a 71/50 switch there has always the following consequences:
a) one line more will be drawn at the bottom of the picture
b) the next lines are slightly distorted

- now depending if the Shifter was reading data or not (right border removed or not at that time), we will have 2 paths:
a) if border was removed, then a complete blank line will start while the Shifter will continue to read data for 512 cycles (reading 256 bytes). Any sync switch during that time is ignored except at the beginning of the line where you can force the sync to 60Hz timing (that leads to even more distorting) and get only 254 bytes to be read. If you then repeat the sync switch at pixel 381, you will have then again 1 extra line at the bottom (that makes 2 now !) and now bitmap is drawn for the next line (no blank) and any terminating sync switch works (like 54 bytes one or 158 bytes one). If nothing is done, bitmap drawing will stop at the normal right border, after 212 bytes have been read. Now you can remove that right border too and force the reading of the complete 256 bytes. If then you do a 3rd time a switch at pixel 381, you will have again 1 extra line at the bottom (that makes 3 now !) and you get again a blank line reading 512 bytes and so on ...
b) if the border was not removed, a blank line will be generated and 0 bytes will be read. Any sync switch during that time is ignored. If you repeat the switch at pixel 381, you will have then again 1 extra line at the bottom (that makes 2 now !) and now bitmap is drawn normally for the next line reading 160 bytes: any known switch can be applied to this line. If then you do a 3rd time a switch at pixel 381, you will have again 1 extra line at the bottom (that makes 3 now !) and you get again a blank line reading 0 bytes and so on ...

This was observed under Glue wake up state 1 and from what i have observed under wake up 2 until now, things are not 100% identical.

Sadly, these behaviours have no real utility for sync scroll because of the slight pixel distorting effect for the first lines after these effect lines.
If that would not be the case, we could have used the line with 254 bytes to get an offset 0 with 4 lines: 204 + 254 + 80 +230 = 768 bytes (0x300).
The only combination leading to 0 with 4 lines with the other know switches is 0+0+0+0 = 0 bytes.
To get a 0 bytes line for the sync line is to my knowledge impossible because you are not synched at the time it is required that you should be.
There are 4 offsets missing in a 1+3 lines sync scroll case:
0x00, 0xE6, 0xEC and 0xFE.


Hi Alien !
You said you could have a 162 and 206 lines for the first line. How could you do that ? Did you just delay the switch back to 50Hz when removing the top border ? But then you should have some slight bitmap distorting as you where not synched, no ?

Anyway, even if 162 bytes and 206 bytes were possible on the 1st line, offset 00 would still be missing. So up to now, 5 lines will still be needed for a vertical fullscreen hard scroll, unless you don't use that offset and scroll only for 127 lines or at bigger speeds than 1 multiple of 2.

Btw, the add/move trick does not improve anything for the tests i have made until now regarding GLUE behaviour.


Edit: in GLUE wake up state 2 the behaviour is identical: i just had the 60 Hz forcing switch to get 254 bytes at the wrong spot for the wake up 2.

[ijor]

I have explored a little more the Enchanted Land sync switch.
...

Very interesting.

...where you can force the sync to 60Hz timing (that leads to even more distorting) and get only 254 bytes to be read.

Sadly, these behaviours have no real utility for sync scroll because of the slight pixel distorting effect for the first lines after these effect lines.
If that would not be the case, we could have used the line with 254 bytes to get an offset 0 with 4 lines: 204 + 254 + 80 +230 = 768 bytes (0x300).

Even if you could avoid the distortion, I'm not sure this would be a good idea. The behavior when alterting sync is not fully predictable. It could vary depending on the monitor, if you use a monitor or a TV, a converter, etc.

But if you insist and don't mind altering sync, then there are a lot of new things you can do. You can use 60 Hz total scan length on any line that removes the right border. You would get then two bytes less. That is, the same idea of getting 254 bytes instead of 256 can be extended for normal switches.

Btw, the add/move trick does not improve anything for the tests i have made until now regarding GLUE behaviour.

It might be "useful" here. Perform the Enchanted Land switch using this trick, to come back to color as quickly as possible. I'm not sure, but possibly you could still get a "complete overscan" without altering sync. The usage of 254 bytes would still need sync to be altered though.

Probably you can get the same result by moving the switch timing slightly and adapting it at run-time according to the wake-up. Because what you need to avoid distortion is not really a short switch, but more precision to control DE without affecting HSYNC.

Hi Alien !You said you could have a 162 and 206 lines for the first line. How could you do that ? Did you just delay the switch back to 50Hz when removing the top border ? But then you should have some slight bitmap distorting as you where not synched, no ?

I think he just is not remembering very well. You can't get those scan lengths without being already in sync.

[ljbk]

Btw, the add/move trick does not improve anything for the tests i have made until now regarding GLUE behaviour.

It might be "useful" here. Perform the Enchanted Land switch using this trick, to come back to color as quickly as possible. I'm not sure, but possibly you could still get a "complete overscan" without altering sync. The usage of 254 bytes would still need sync to be altered though.

Probably you can get the same result by moving the switch timing slightly and adapting it at run-time according to the wake-up. Because what you need to avoid distortion is not really a short switch, but more precision to control DE without affecting HSYNC.

The tests i made were performed automatically, checking for different addresses at the end of the frame, using all the 256 starting positions for the switches per line and 8 possible back to previous switch pieces of code for each case (one of them is that add/move case). That makes 2048 combinations possible sync switches tested.

The idea of using the 60 Hz for the 254 bytes line was to try to fool the GLUE without altering sync and not to try to reach the 4 lines at any price.
If it is not possible then it is not and that's it.

[ijor]

The tests i made were performed automatically, checking for different addresses at the end of the frame, using all the 256 starting positions for the switches per line and 8 possible back to previous switch pieces of code for each case (one of them is that add/move case).

This is possibly more complicated that what you might think. Actually, I'm not sure this is possible at all.

To obtain a short (4 cycles) switch you have to perform the add first, then the move. This means that you can't use something like exg D0,D0 before the add (well, you can, but you won't get a 2 cycles displacement).

And what is more important. Here you are writing to the resolution register, not to the frequency one. This register has a very different behavior regarding the 4 cycles boundary aligment.

[ljbk]

The tests i made were performed automatically, checking for different addresses at the end of the frame, using all the 256 starting positions for the switches per line and 8 possible back to previous switch pieces of code for each case (one of them is that add/move case).

This is possibly more complicated that what you might think. Actually, I'm not sure this is possible at all.

To obtain a short (4 cycles) switch you have to perform the add first, then the move. This means that you can't use something like exg D0,D0 before the add (well, you can, but you won't get a 2 cycles displacement).

And what is more important. Here you are writing to the resolution register, not to the frequency one. This register has a very different behavior regarding the 4 cycles boundary aligment.

I don't even think it is possible to have 2 cycle boundary in this case because the add.b will probably pair with the exg and the results seem to confirm this.

[alien]

Hi Alien !
You said you could have a 162 and 206 lines for the first line. How could you do that ? Did you just delay the switch back to 50Hz when removing the top border ? But then you should have some slight bitmap distorting as you where not synched, no ?

Short answer: I don't remember.

Long answer:

When I get some time I'll see if I can find any source code...

My recollection is that I used HBL's as interrupts, then on the "right one", there was time to switch frequency, sync oneself, and play with the right border...

I also remember using one of the timers (timer A?) to auto measure the amount of time from the end of the VBL to the correct HBL line, and then start the upper overscan there: that way I saved the HBL's rtes.

I may have used another trick: If I remember correctly one can sync a few lines before the point where one would cause a top overscan. This was done by toggling to 70Hz and back again. It caused the video address counter to start incrementing, but did not display anything. Then one can open the top border as usual, but one is already synced... (allowing different line lengths on the first line).

I had quite a sensitive TV, and Ajrarn's monitor was also quite sensitive, so I would think I would have noticed a distortion. But at this point I need to find the source code to contribute anything useful.

[ijor]

I don't even think it is possible to have 2 cycle boundary in this case because the add.b will probably pair with the exg and the results seem to confirm this.

Right. It is not exactly an issue of pairing. The problem is the prefetch cycle of the ADD, right before the write cycle. So the write cycle would be always aligned on a 4 cycles boundary disregarding what happened before (well, unless you are running from ROM).

I was hoping it would be possible to use a different instruction instead of EXG/ADD (it must be a single one). But I couldn't find anyone suitable.

[ijor]

You said you could have a 162 and 206 lines for the first line.

My recollection is that I used HBL's as interrupts, then on the "right one", there was time to switch frequency, sync oneself, and play with the right border...

If I understand what you mean, yes, it is possible. This is basically the same idea that Paulo suggested, delaying switching back to 50 Hz after opening the top border. Both ways would work ...

But in both cases you would be altering sync. You would be putting that scan line on "60 Hz mode" and would have a total length of 508 cycles. Because as I explained earlier in this thread, the decision about 512 vs. 508 cycles is taken at the left border position. Not at the far right.

The only way to get those scan lengths without altering sync, is to be fully synced. And again, if you don't mind putting a few lines (that are not displayed) in 508 cycles, then you could get some more new line lengths.

[alien]

The only way to get those scan lengths without altering sync, is to be fully synced. And again, if you don't mind putting a few lines (that are not displayed) in 508 cycles, then you could get some more new line lengths.

You can be fully synced with the 70Hz "higher" overscan

[ljbk]

The only way to get those scan lengths without altering sync, is to be fully synced. And again, if you don't mind putting a few lines (that are not displayed) in 508 cycles, then you could get some more new line lengths.

You can be fully synced with the 70Hz "higher" overscan

But as you wrote in ST Mag, it seems that it does not work with all STs, right ?

[ijor]

5 scanlines including the syncline which could be in 158/160/162/20x modes ...
You can be fully synced with the 70Hz "higher" overscan

Yes, but you still can't get 162 bytes on the "sync line".

The only thing that the higher top border gives you is to be able to sync earlier. It should be useful only on very special cases. You don't gain free CPU processing time, on the contrary.

But are you sure you used 162 bytes at all? To do that you need to detect wakeup state and adapt the pairing code accordingly? Could you do that back on the day? Or you just used it for a specific wakeup only (whatever was common on your machine)?

But as you wrote in ST Mag, it seems that it does not work with all STs, right ?

I would suppose it should work in all machines. It doesn't?