68000 clock cycles table

[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)

[ijor]

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?

I'm afraid I have no artistic talent for a demo, not even a technical one. I was considering releasing a simple scrolling program, not really a demo. But I never coded anything similar, so even this would require quite some work for me.

The other possibility is to just publish the techniques. Not releasing any actual code. But there are lots of things to explain. This is not just a simple single trick. So this also represent a considerable work.

May be we could team and release a demo?

[leonard]

May be we could team and release a demo?

hé hé why not the hardest thing for a demo is to get a good idea.... I have no idea actually.

Is your trick only usefull to removes some raster line of syncscroll, or do you think we can acheived a *never seen* effect on ST ?

But there are lots of things to explain. This is not just a simple single trick. So this also represent a considerable work

Wow I'm very curious about that trick !! Feel free to explain me anytime

[ijor]

Is your trick only usefull to removes some raster line of syncscroll, or do you think we can acheived a *never seen* effect on ST ?

I'm not sure you can do anything besides sync-sroll with one scan less. You obviously gain one scan processing time, and one more displayed line. If this is significant or not, I can't say. I'm not a demo expert, you are

Wow I'm very curious about that trick !! Feel free to explain me anytime

As I said, it is not a single trick, they are many. Or more precisely, there are many technical aspects that must be considered to achieve it. Most of them are technical details unknown (or at least never disclosed) till now. That's why the whole explanation is rather long. At least if you want to explain everything detailed, as you know I like to do.

Actually, that's why I never mentioned it before. And I wouldn't have mentioned here if it wasn't because you raised the issue. Then I thought I wouldn't be honest if I would make myself the fool and ignore your comment about saving one scan in sync-scroll.

[ijor]

Hi Leonard,

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).

Very strange. On my ST they both show as "REAL=000".

[leonard]

really ?

do you see a bitmap, or only black screen ?

[ijor]

really ?
do you see a bitmap, or only black screen ?

Black.

If I understand what you are doing, it seems you are doing a mono/color switch similar to the standard opening of the left border, but some cycles earlier.

If so, I might have a possible explanation why I get zero length. But I have no idea why you get those lengths on your STe.

The scan lengths you get is like a partial opening the left border. Very Strange. You might be able to get even more lengths by using different right borders.

Can you take a picture on your STe when displaying those strange lengths? I would like to see the aligment of the bitmap with the text lines above.

Btw, it seems there is a bug/problem with your test. The first few tests are wrong. For example, the initial screen, with a standard length, it shows "REAL=161". After a couple of tests it seems to start working right.

[leonard]

Humm no my STE is definitvly in a package since my second daugther is born

Well, yes maybe the counter has a little accuracy pronblem in the "div" (161 instead of 160), but it can't explain the "0" you get. (0 means the line does never start).

I attach the source code if you want.

[ijor]

Humm no my STE is definitvly in a package since my second daugther is born

I understand

Well, yes maybe the counter has a little accuracy problem in the "div" (161 instead of 160), but it can't explain the "0" you get.

It doesn't explain it. I'm not sure why I get 0. But the results on your STe seem to be even stranger.

I'll try to do some tests next week. But I suspect that the behavior you get is STe specific. It would help if somebody else should run your tests.

[leonard]

At the time I found these strange lines, I send the proggy to "Paulo simoes" (m. fullscreen ). These lines don't work on its STF and on its STE too. It's very strange.

You're right, should be cool if many people could test these lines on real hardware.

[ljbk]

Hello all,

The record as far as i know is 5 lines +sync_line for a fullscreen and 4 lines + sync_line for "a normal" with left and right borders (like in YM50K).

It is possible to do less than that but i am not sure if it can work on all STs, especially on STEs, and with all "wake-up" states.
I managed some specific sized lines like a 56 bytes one that does not work with all "wake-up" states or at least not in the same way.
Thurthermore, it seems that they do not work on Leonard's STE.
The same is valid for the 0 bytes line, also found by Alien.
Instruction pairing and "wake-up" states are very important for these special cases.

Anyway, let's resume the possible theorical switches according to the logic of the most common switches:

1- fake high rez to start -> +26 bytes on the left compared to normal
2- fake NTSC to not draw a line -> 0 bytes line
3- fake NTSC to start -> + 2 bytes on the left compared to normal
4- fake high rez to stop -> - 106 bytes on the right compared to normal
5- fake NTSC to stop -> - 2 bytes on the right compared to normal
6- fake NTSC to proceed -> + 44 bytes on the right compared to normal

Switches 1,4,5 and 6 are the base of the actual score.
Switches 2 and 3 are as i said instruction pairing and "wake-up" state dependent as far as i know, but they allow combined to others sizes of: 0, 56, 162 and 206 bytes. This for sure reduces the number of lines to hardscroll.
The problem is making that work on all STs even with a pre-analysis of its current status to generate the code accordingly ...
For the 0 bytes line and for my ST, it is possible, as i have only detected 2 different "wake-up" states. For the others, as far as i remember from my last researches on this field about 1 year ago, it was not possible, but may be i made a mistake

The switch refered by Leonard, that is a high rez switch before the left border one does not work on my ST.


Have fun,
Paulo.

[leonard]

hi Paulo !

How are you since a while?

Well, to enderstand correctly, you mean my "strange and only works on my computer" 180 bytes line can be a 0 byte line on other computer? (high res swith at the beginning of the line)?

btw, YM50K rules ! I hope everyone here have tested that great technical demo.

[ljbk]

hi Paulo !

How are you since a while?

Well, to enderstand correctly, you mean my "strange and only works on my computer" 180 bytes line can be a 0 byte line on other computer? (high res swith at the beginning of the line)?

btw, YM50K rules ! I hope everyone here have tested that great technical demo.

Hi !

Well, as you might have read in another thread, i also have a 2nd daughter now (Clara) that is 11 months old. So, no much time left for the ST.

I don't know if that is the case with your switch, but there is a high res switch to have a 0 bytes line also.
The problem is that area around 96 clock cycles after the normal right border is very sensistive because it is very close to the HBL.
On my ST, a switch there works but sometimes causes the next lines to bend as like it happens when starting the VBL at 60Hz in PAL or result in an unstable image: not the same at every VBL.
The switch to have a 0 bytes line has to be after the end of the right border and before the first words are read by the Shifter.
The 60/50 switch i sent you last year is done precisely when the Shifter wants to start to read from memory.
As the "wake up states" are for sure related to the time slots to acess the memory in the MMU, this would explain why the effect is "wake up state" dependant if the time we have to act is very small.
The 71/50 switch refered above is probably related to the same Shifter reading but for high res.

When/if i have some time in the near future, i will try to put the 0 bytes line to work on my ST for all cases, so that every one here can test it.

Cheers,
Paulo.

[ijor]

Hi Paulo,

I wasn't sure you will be coming back. So I sent you an email about this ...

Anyway, let's resume the possible theorical switches
...
Switches 2 and 3 are as i said instruction pairing and "wake-up" state dependent as far as i know, but they allow combined to others sizes of: 0, 56, 162 and 206 bytes. This for sure reduces the number of lines to hardscroll.

That's exactly the trick.

For the 0 bytes line and for my ST, it is possible, as i have only detected 2 different "wake-up" states.

I am not aware of more than two wakeups. And I don't see how there could be more. Did you find more than two?

don't know if that is the case with your switch, but there is a high res switch to have a 0 bytes line also. The problem is that area around 96 clock cycles after the normal right border is very sensistive because it is very close to the HBL.

It seems to happen right in the middle of HBL.

The 71/50 switch refered above is probably related to the same Shifter reading but for high res.

Hmm, I don't think so. I don't have a full explanation for this effect. I wasn't aware about it until Leonard posted the test program above and I saw the result on my ST.

But doesn't seem to be directly related to the timing of the DE signal. The DE signal activation time on mono correspond to the standard left border removal timing. It is later than this switch. And in anycase, this wouldn't explain why you get a scan of zero bytes.

I am speculating that, being right at the start of the line, GLUE makes some kind of initialization at this time (say, some counter is reset or started). If this switch prevents that initialization, this could explain why DE is never activated.

As the "wake up states" are for sure related to the time slots to acess the memory in the MMU

Not exactly. The wake states actually depends in the phase alignment between an MMU internal clock and a GLUE one. However this doesn't explain why you get a different behavior on the same machine, on the same wakeup, on different frames.

[ljbk]

Hi !

Well, it seems that after all it is possible to have 0 bytes lines (as i said previously) on my ST but also 56 bytes, 162 bytes and 206 bytes lines on both wake up scenarios !!!
In fact, i was already so close the last time i touched this the 25th April 2005 ...

As a test, i leave you this small program in attach that should display 1 sync line with 160 bytes and 199 lines with 162 bytes.

There are 3 output possibilities:

1- Complete flickering like in Steem -> nothing works -> forget it for a full ST compatibility ...

2- You can see a bee like in the pic with black border color -> your machine is in wake up state 1 and it works !

3- You can see a bee like in the pic with white border color -> your machine is in wake up state 2 and it works !

Answers are welcome.

Unfortunately, according to my calculations, it seems that there are 4 offsets missing out of the 128 to go down to sync line + 3 lines for a fullscreen hard scroll, but at least a left border and right border screen can be then done with sync line + 3 lines.
But may be i am wrong ...


Thanks,
Paulo.

[ijor]

As a test, i leave you this small program in attach that should display 1 sync line with 160 bytes and 199 lines with 162 bytes.

Great. Nice to see the theory is working!

Unfortunately, according to my calculations, it seems that there are 4 offsets missing out of the 128 to go down to sync line + 3 lines for a fullscreen hard scroll

Hmm, I made those calculations long ago. In anycase we agree that this is enough for sync+4, which beats the previous fullscreen record (sync+5). My calculations showed that using this technique it's possible to get down just to four full scans (if you never loose sync across frames). And that a single offset was was missing for reaching three scans.

[ijor]

Btw Paulo, are you aware and made tests on the "full overscan" effect I mentioned before in this thread? The one that Enchanted Land creates on the initialization phase (almost sure by mistake and not by design).

I tested only the behavior of the scan length. But I didn't test the effect on such things as the sync signals, or how the display exactly behaves.

I'm not sure this would be useful for sync-scroll, but it might (assuming sync signals are not affected). On one hand you get more combinations. But on the other hand, whenever you use this technique you lose combinations on the next scan (you can't change the left border on the next line).

[ljbk]

Btw Paulo, are you aware and made tests on the "full overscan" effect I mentioned before in this thread? The one that Enchanted Land creates on the initialization phase (almost sure by mistake and not by design).

I tested only the behavior of the scan length. But I didn't test the effect on such things as the sync signals, or how the display exactly behaves.

I'm not sure this would be useful for sync-scroll, but it might (assuming sync signals are not affected). On one hand you get more combinations. But on the other hand, whenever you use this technique you lose combinations on the next scan (you can't change the left border on the next line).

Hi!

I came accross this "Enchanted-Land" effect just when i read this thread.
So unlike the 0/56/162/206 cases i found out a long time ago (i still have the files i sent to Leonard via email to test in 2005 for wake up state 2), i do not know the switch to have that effect.
I also found the wake up state problems when i found out that the Nostalgic main menu was not working most of the time but was working some other times and also when i discovered wrong expect timings in case of instruction pairing.
In this case, from your description, TCB-Nick was removing a second time the right border. I assume it is before HBL and after the normal time spot. I just have to try it.

Regarding combinations, the numbers i obtained are calculated via a simple GFA program that explores all possibilities.
If you use the sync line as a normal one not loosing sync, you can go down as you said to 4 lines, but then you can never loose sync during the VBL or use the Ziggy method for interrupt based fullscreen with a resync at almost every line ... It looks to me like an expensive price.
Anyway, we must be careful on one side: a theorical possibility sometimes turns out to be a flickering one.
I remember that when i built my current hard scroll tables, i found out that a lot of possible combinations would result in a flickering screen and that the result was screen dependent (depending if you had a fullscreen or normal screen to be hard scroll) , wake up state dependent but also complete video synchro dependent.
This last thing is related for example to having funny pixels on Spec 512 pictures: that is not only wake up state dependent. These timing can vary after you boot your ST at least for my ST: may be it depends on heat ...

So theorically we can go to sync line + 4, but a stable combination has to be found for each of the 128 cases both for fullscreen and for "normal" screen.
For the current sync line + 5, i have 2 seperated tables and i think that the same wil be required here also.


Cheers,
Paulo.

[ljbk]

Hi ijor !

I think that i have found your Enchanted Land trick.

The second switch has to be 71/50 otherwise it does not work on my ST.
The switch to 71 has to occur latest on pixel 381 and back to 50 can only occur from pixel 385 on.
For reference right border switch is at pixels 293/301. This compares to the normal start of the screen in PAL.
So i have 2 combinations working without nop in the middle, 3 with 1 nop and 4 with 2 nops.
This area is between the stabilizer switch 361/373 and the left border one 429/441.
May be you are right and Nick made a 20 pixels/cycles mistake setting the stabilizer switch too late.

Anyway, just with these 2 switches (right + yours), i get the following lines to be slightly distorted (by arround 1 pixel maximum).
May be it will not happen if a stabilization is used or next right border is removed. I have to try.
The number of bytes that line consumes is 256 (512 cycles or pixels / 2).
That is not helping at all for sync scroll purposes as it is equivalent to the 0 bytes line.
The line is totally blanked but the bytes are read as i have located my "bee" at normal start + 460 bytes = 160 + 44 + 256.
This is similar for the effect i found and used in the Overscan Demos but just for a 320 pixels line and with a 60/50 switch.

Leonard, may be this can help you to make Enchanted run with SainT 2.0 !



Have fun,
Paulo.

[MiggyMog]

I thought the Spectrum 512 speckles/spots were a known problem only on STE?

I used to have to switch my STE off about 20 times before it would sync properly to show spectum 512 pictures.

Photochrome was able to avoid this problem however as Discussed in the help files which come with it. (even when making spectrum images!)

[ijor]

Hi Paulo,

Hi ijor !
I think that i have found your Enchanted Land trick.

I have to go right now, won't be back until the evening. Will discuss with more details then. Did you receive my email yesterday? In the meantime just two short points.

When calculating the save in one scan for sync-scroll, I considered using both "new" switches. That is, the NTSC left border (with all the possible combinations on the right border), and the scan of zero bytes. The 0 bytes makes calculation a little more complicated because, obviously, it can't combine. It is a new length but for the whole scan.

Yes, the Enchanted Land is a mono switch, not a 50/60 one. And it happens exactly at the point where a "classic" right overscan ends.

[ljbk]

Hi Paulo,

Hi ijor !
I think that i have found your Enchanted Land trick.

I have to go right now, won't be back until the evening. Will discuss with more details then. Did you receive my email yesterday? In the meantime just two short points.

When calculating the save in one scan for sync-scroll, I considered using both "new" switches. That is, the NTSC left border (with all the possible combinations on the right border), and the scan of zero bytes. The 0 bytes makes calculation a little more complicated because, obviously, it can't combine. It is a new length but for the whole scan.

Yes, the Enchanted Land is a mono switch, not a 50/60 one. And it happens exactly at the point where a "classic" right overscan ends.

No email received, so far. (ljbk@oniduo.pt)
My GFA program uses 12 line sizes:
0, 54, 56, 80, 158, 160, 162, 184, 186, 204, 206 and 230 bytes.
All these lines are possible on both wake up states on my ST.
But for the first line when used as a sync line, you can only have 160, 158, 204 and depending on the non synched code you interrupt, 54 bytes.
But again as i told you, these theorical combinations do not have all good results depending also if the screen to scroll is 320 pixels wide or fullscreen.

I don't have much more time today and on sunday i have a family meeting.
I still hope for some more comments on the prog i attached. I mean if it works only on my ST, then it is not worth to do anything more about it.

Cheers,
Paulo.

[ijor]

I think that i have found your Enchanted Land trick.

The switch to 71 has to occur latest on pixel 381 and back to 50 can only occur from pixel 385 on... This area is between the stabilizer switch 361/373 and the left border one 429/441... May be you are right and Nick made a 20 pixels/cycles mistake setting the stabilizer switch too late.

Yes, the switch must be done exactly at the point where a "normal" opened right border ends. Because this switch to mono is what prevents the deactivation of DE that happens in normal overscans. And then DE is never deactivated.

It is not a stabilization switch done too late. It is a left border removal done too early. They tried to implement a calibration routine that would adapt border removal timing to the current machine. They try different timings until detecting that the border was opened, by delaying a bit after the switch and checking if the video pointer keeps advancing. Then the main sync-scroll routines are built at run-time according to the timing obtained here.

Right border is done correctly. But the left one is done wrong. They use a wrong starting point and range. So they end making this switch thas has a similar effect (video pointer doesn't stop). The main code still works fine because they add a constant to the value obtained during the calibration. The constant was likely obtained empirically, a value that just worked.

The number of bytes that line consumes is 256 (512 cycles or pixels / 2). That is not helping at all for sync scroll purposes as it is equivalent to the 0 bytes line.

You are right. I was thinking you could get multiple new scan length depending on the right border you use in the next line. But after all, you always end adding an extra 256 bytes to what you would get if you wouldn't use this switch. So it is indeed useless, at least for this purpose.

The line is totally blanked...

Hmm, interesting you see a blanked line. I was expecting actually the opposite. I was expecting for BLANK never to be active, not even during the horizontal retrace.

This is similar for the effect i found and used in the Overscan Demos but just for a 320 pixels line and with a 60/50 switch.

But in "your" switch it is clear why this happens. Here it is not, at least not for me.

If you use the sync line as a normal one not loosing sync, you can go down as you said to 4 lines...
So theorically we can go to sync line + 4, but ...
But for the first line when used as a sync line, you can only have 160, 158, 204 ...
But again as i told you, these theorical combinations do not have all good results depending also if the screen to scroll is 320 pixels wide or fullscreen.

I'm not sure I understand what you are saying.

You are saying that your calculations don't agree with mine. And that according to your calculations the new switches don't produce all the 128 combinations for sync line + 4? If you agree that we can do 4 full lines (never loosing sync). Then we could obviously do sync+4.

Or you are saying that our calculations do match, but you don't know/not sure/fear that not all combinations are stable?

a theorical possibility sometimes turns out to be a flickering one.

Do you have a screen, code, sample, or whatever to reproduce a "theoretically good" combination that doesn't always work ok (flickering, not stable, or whatever)?

I still hope for some more comments on the prog i attached. I mean if it works only on my ST, then it is not worth to do anything more about it.

Yes, of course. Come on people. Please test Paulo's screen and let us know what you get. Tell us what machine you used.

If this happens to not work on STe, this this is of course only a minor problem. But even if it doesn't work on all pre-STe machines, then don't worry. I still have more tricks to try

[daeghnao]

I tried HARD162E.PRG on a STE with TOS1.62. I got a blank screen that looked to be completely black one frame and completely white the next. Is this the program you wanted testing?

[ljbk]

I tried HARD162E.PRG on a STE with TOS1.62. I got a blank screen that looked to be completely black one frame and completely white the next. Is this the program you wanted testing?

Hello !

Thanks for your test.
This means that at least these switches do not work with all STEs with the time spots used for my STF.
But may be it can your with slightly different time spots.

Anyone with a STF can test this ?

Any more STEs around (as it seems that there also are diffrent generations of STEs) ?