68000 clock cycles table

[keops]

Back in the days, Starlion made a great document featuring all the 68000 instructions, all their possible addressing modes along with the number of cycles each one took.

Unfortunately it seems that 15 years later, we can't find it anymore.


Hence my question: does anybody have an ACCURATE 68000 clock cycle table (I guess some fullscreen coders or emulator authors must have one somewhere).

Thanks in advance.

[keili]

Looking through the docs on my HD, i've found these 2.

[ASYLvM]

The POV source CD has these:.. (attached)

One of them is credited to Equinox and the other Mac Sys Data.



/|\

[keops]

I will check, thanks. I hope they are accurate because back in the days we made our own tables because all the ones we found had mistakes here and there, which can be a problem when coding a fullscreen effect

[alexh]

Verification of such a table may be of use to the STEEM authors do you not think? And SainT

[leonard]

I often used the "equinox document" to coded my fullscreen.

Unfortunatly, to code SainT, I just enderstood there is too some instructions timing you simply can't write on a table. (just because the timing depend of the previous instructions).

But the accuracy of these tables are very good, I don't think there is error if you execute only one of these instruction.

[ijor]

It is a common mistake to believe that Motorola official documentation is full of errors. This is not true, it is almost 100% accurate. As Leonard mentioned, the whole issue in the ST is all about pairing.

If you correctly understand pairing, then using Motorola manuals is your best resource. If you don’t, then you should better avoid instructions where pairing is involved.

Unfortunately, pairing is one of the aspects less known and worse understood in the ST. For quite some time I wanted to publish an article about it, but never found the time. It is more complex than most people think.

If the above Equinox table is the same I checked some time ago, it does have some mistakes.

[keops]

Leonard: do you have this table we made 15 years ago? If so, I really would like to have it back I'm very surprised you have it though, I did not know Starlion spread the MS Excel document (or maybe was it MS Word)

Ijor: If doubt that you have this one and I also doubt it's full of errors as well. This document was used hundreds of times to code the numerous fullscreen screens in the Vodka demo and afair, it never failed, that's why I'm so annoyed to have lost it

[ijor]

Ijor: If doubt that you have this one and I also doubt it's full of errors as well.

I can't say if it is the same or not. I do remember checking a few tables, included one titled and credited to Equinox, so I suppose it is the same. It seems to be the same, but I would need to check this whole table again to tell you.

I didn't say it is full of errors, only that it has some errors.

This document was used hundreds of times to code the numerous fullscreen screens in the Vodka demo and afair, it never failed

This doesn't mean it doesn't have errors. Many instructions are seldomly used if at all. And sometimes a specific code can work even when you counted cycles wrong. Not too long ago I found that the whole full screen technique in Enchanted Land is completely wrong. It works, but not because of the reasons the authors thought it works.

[leonard]

keops: I attached the document I have, credited by "equinox", but it's an ascci one (I guess it's the same posted here)

Other: I wrote many fullscreen, and very often I "tested" it by adding or removing nops, till fullscreen works (without count cycles exactly). So you *can* write fullscreen without accurate table (to be honest I wrote a instruction time-testing using shifter at that period).

Ijor: If you find any strange code in "enchanted lands", I'm very interested, because that game never worked in SainT and the code is quite complicated, I never debugged it. In fact, it seems there is an "self-tuning" fullscreen routine at the beginning of the game (when screen is black) and that test fail on SainT. any help would be welcome

[leonard]

keops: as always, I forgot the add the document

[keops]

It's not the one I was looking for but I guess this one is totally ok as well (maybe older than the one I was looking for). With the one Keili posted, that makes 3 versions!. Thanks.

I don't remember about other people's fullscreens but I remember ours ran on all Ataris, even the old tricky ones. It even ran on some ST Connexion's machine that was famous for not running most fullscreens properly back at the time (1990-1991)

[leonard]

I know there is an obscure science to make fullscreen work on all machines. In practice it's not as hard as it seems.

First of all, take care of the upper border removal technic. Better use HBL interrupt instead of MFP timer (because MFP is not exaclty the same clock on every ST).

Once your upper border is removed, make "classic" fullscreen lines, with the shifter reset at the end of the line (high/low res). Without it, the fullscreen is not stable on every ST.

And last but not least, the low border must be opened at two different position, depending of the ST. Ziggy stardust opens border two times, so he don't have to test ST model.

Maybe I forgot something, Alien may correct me if I forgot one stuff!

Of course, I personnaly wrote many fullscreen that does not work on every st (because I don't repesct these rules )

[NiceGuyUK]

If you correctly understand pairing, then using Motorola manuals is your best resource.

And you can get it from me at http://www.niceguyuk.ukshells.co.uk/dmg/68000.pdf

[keops]

To be honest, I forgot most of these tricks over the years (I haven't coded any 68000 stuff since 1999). Thanks for the reminders

[ijor]

Ijor: If you find any strange code in "enchanted lands", I'm very interested, because that game never worked in SainT

I'm not suprised. I'm sure it's the same reason that doesn't work on Steem...

In fact, it seems there is an "self-tuning" fullscreen routine at the beginning of the game (when screen is black) and that test fail on SainT.

You need to emulate opening the right border a second time. Which is what the calibration routine does, by mistake and not by design, instead of opening the left border.

[leonard]

You need to emulate opening the right border a second time. Which is what the calibration routine does, by mistake and not by design, instead of opening the left border.

Sorry? What do you mean exactly? Is there a new line size?

I already see some common "design" mistake when writing saint. for exemple in some holocaust syncscroller , they open the right border in a "stoped line" (so there is no effect on real ST, the code is useless )

In enchanted lands, what append on real hardware when "opening" right border a second time? Opening right is done with frequency, and left with resolution. I don't endestand how it could be mixed/confused?

Any help appreciated

[ijor]

Sorry? What do you mean exactly? Is there a new line size?

Yes.

In enchanted lands, what append on real hardware when "opening" right border a second time?

You get a complete overscan. The video pointer never stops until the right border of the next line.

Opening right is done with frequency, and left with resolution. I don't endestand how it could be mixed/confused?

You can open the right border switching rez if you want. Not very useful for displaying purposes because the display is blacked while on mono, but it is possible. Anyway, here it is not done in purpose.

[leonard]

a new line?? really? How many bytes is that line?

Hemm I'll to find my syncscroller table generator to compute a new one with a new line size, maybe I can get one scanline less !

[ijor]

a new line?? really? How many bytes is that line?

It doesn't have a specific length that you can assign to the current line. The two lines are merged from the point of view of the video pointer.

Assuming the current line has a normal left border and the next one has a normal right one, then the total combined length of both lines is 416 bytes. 416 is obtained by 512/2+160.

Hemm I'll to find my syncscroller table generator to compute a new one with a new line size, maybe I can get one scanline less !

It is possible to sync-scroll with one scan line less ... but not with this technique ... you'll need to wait a bit more to see how

[leonard]

It is possible to sync-scroll with one scan line less ... but not with this technique ... you'll need to wait a bit more to see how

hé hé I like this Are you working on a new syncscroll technic?

By the "one less" than what? What is the record actually? (I speak of a synscroll with every even adress boundary to do fullscreen scroll (non fullscreen scroll can use only 8bytes multiple adress).

I think ULM one is 5 raster lines. Do you think 4 is possible? (I assume the "0 byte" line can't be used because it does not work on every shifters)

[atari_mark]

The POV source CD has these:.. (attached)

/|\

My POV CD seems to be a major source of information, never realised I had put that much stuff on it

[ijor]

Are you working on a new syncscroll technic?

Well, not really working on this. I just studied several ST issues lately. Combining all of them I reaching that conclusion. I didn’t actually test it, but I have no reason to believe it won’t work.

(I speak of a synscroll with every even adress boundary to do fullscreen scroll (non fullscreen scroll can use only 8bytes multiple adress).

Yes, of course. We are talking about shifting the screen in every word (two bytes) boundary.

By the "one less" than what? What is the record actually? I think ULM one is 5 raster lines. Do you think 4 is possible?

I understand that the current record is 6 lines, not 5. If I understand correctly, the ULM 5 lines scroller is for non-fullscreen only.

I found a way to do fullscreen sycn-scroll in 5 lines (4 lines plus the sync one). I can even do it in 4 scan lines if I don’t need to resync on every VBL.

(I assume the "0 byte" line can't be used because it does not work on every shifters)

May be you are assuming wrong and it does is possible to make it work on every ST ...

But, as you can test with a sync-croll table generator, using scans of zero bytes is not enough to hard-scroll with one scan less. You need something else …

[leonard]

I understand that the current record is 6 lines, not 5. If I understand correctly, the ULM 5 lines scroller is for non-fullscreen only.

yes you're right, many people don't know this. the smallest syncscroll actually is 6 lines, and can be seen as 1+5 lines (that's why ULM told 5 lines but it's 6).

But, as you can test with a sync-croll table generator, using scans of zero bytes is not enough to hard-scroll with one scan less. You need something else

Wow I like this !! thinking about new ST technic in 2006 is very exiting ! (to me at least ! )

So you will make a screen to show us?

[leonard]

I just find my "fullscreen" line tester I wrote to try fullscreen stuff when coding SainT. (I include it if someone wanna play on real st: just press keys 1 to 9 to test different fullscreen lines)

When searching new lines, I find two ones that works only on my STE:

180 bytes and 178 bytes.

If anyone wanna try these two strange lines on their hardware let me know if it works (key 5 and 6 of my program). If it works, the picture is correctly displayed.

With these two lines, I have a 5 lines syncscroll (instead of 6), and the first line is always a normal 160bytes line. (so only 4 lines need resolution and frequency toggle)