68000 clock cycles table

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

[ljbk]

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

What i mean is the visual result: an unstable picture.
It happens that a line combination leading to a stable fullscreen pic can lead to an unstable 320 pixels wide pic and vice versa.
For example, if i rember rigth, if the last line of the sync-scroll lines is a 186 bytes one (only left border) it is likely that the pic will be unstable.

That is why i have two tables: one for a 320 pixels wide pic and one for a fullscreen pic. They lead to the same 128 offsets but sometimes with different combinations to try to always get a stable image.

[MetalGuru]

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

I tried HARD162E.PRG on a my 1040ST and i see the bee and a white border.

/MetalGuru

[ljbk]

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

I tried HARD162E.PRG on a my 1040ST and i see the bee and a white border.

/MetalGuru

Many thanks !!!

When you say 1040ST, you mean STF right ?

Can you also test ijor's program to check your clock here:

http://www.atari-forum.com/viewtopic.ph ... 7bb6e871f6


Anyway, this means that the thing does not only work on my machine.
Nice !
So it worth to proceed !

[MetalGuru]

Many thanks !!!

When you say 1040ST, you mean STF right ?

Can you also test ijor's program to check your clock here:

http://www.atari-forum.com/viewtopic.ph ... 7bb6e871f6


Anyway, this means that the thing does not only work on my machine.
Nice !
So it worth to proceed !

Well actually it's a 1040STFM..


/MetalGuru

[leonard]

My GFA program uses 12 line sizes:
0, 54, 56, 80, 158, 160, 162, 184, 186, 204, 206 and 230 bytes.

I confirm with my own small C syncscroller finder that you can acheived a 5 lines hardscroller with these lines (instead of 6). The funny trick is that you use the 1+4 mode, and even better, you don't have to do anything in the first line (160 bytes). For anyone loving strange beauty of numbers, here are the lines combine. Please note the first line could be 160 each time.

Offset required (from 2 to 254) | lines
002:160,230,186,186,184, 80, Ok
004:160,230,230,230,230,204, Ok
006:160,230,230,230,230,206, Ok
008:160,230,230,206,206, 0, Ok
010:160,230,230,230,184, 0, Ok
012:160,230,230,230,186, 0, Ok
014:160,230,230,206,158, 54, Ok
016:160,230,230,206,160, 54, Ok
018:160,230,230,206,162, 54, Ok
020:160,230,230,206,162, 56, Ok
022:160,230,230,186,186, 54, Ok
024:160,230,230,186,186, 56, Ok
026:160,230,186,162, 56, 0, Ok
028:160,230,186,160,158,158, Ok
030:160,230,230,230,230,230, Ok
032:160,230,230,230,206, 0, Ok
034:160,230,206,206, 0, 0, Ok
036:160,230,230,184, 0, 0, Ok
038:160,230,230,230,158, 54, Ok
040:160,230,230,230,160, 54, Ok
042:160,230,230,230,162, 54, Ok
044:160,230,230,230,162, 56, Ok
046:160,230,230,186,184, 80, Ok
048:160,230,230,186,186, 80, Ok
050:160,230,206,162,158,158, Ok
052:160,230,206,162,160,158, Ok
054:160,230,206,162,162,158, Ok
056:160,230,230,230,230, 0, Ok
058:160,230,230,206, 0, 0, Ok
060:160,230,230,206,204, 54, Ok
062:160,230,230,206,206, 54, Ok
064:160,230,230,230,184, 54, Ok
066:160,230,230,230,186, 54, Ok
068:160,230,230,230,186, 56, Ok
070:160,230,230,162, 56, 0, Ok
072:160,230,230,160,158,158, Ok
074:160,230,230,162,158,158, Ok
076:160,230,230,162,160,158, Ok
078:160,230,230,162,162,158, Ok
080:160,230,230,162,162,160, Ok
082:160,230,230,230, 0, 0, Ok
084:160,230,230,230,204, 54, Ok
086:160,230,230,230,206, 54, Ok
088:160,230,230,230,206, 56, Ok
090:160,230,230,230,184, 80, Ok
092:160,230,230,230,186, 80, Ok
094:160,230,230,186, 56, 0, Ok
096:160,230,230,184,158,158, Ok
098:160,230,230,186,158,158, Ok
100:160,230,230,186,160,158, Ok
102:160,230,230,186,162,158, Ok
104:160,230,230,186,162,160, Ok
106:160,230,230,186,162,162, Ok
108:160,230,230, 0, 0, 0, Ok
110:160,230,230,230,230, 54, Ok
112:160,230,230,230,230, 56, Ok
114:160,230,230,206, 56, 0, Ok
116:160,230,230,204,158,158, Ok
118:160,230,230,206,158,158, Ok
120:160,230,230,206,160,158, Ok
122:160,230,230,206,162,158, Ok
124:160,230,230,206,162,160, Ok
126:160,230,230,206,162,162, Ok
128:160,230,230,186,186,160, Ok
130:160,230,230,186,186,162, Ok
132:160,230,186,162,162, 0, Ok
134:160,230, 0, 0, 0, 0, Ok
136:160,230,230,230,230, 80, Ok
138:160,230,230,230, 56, 0, Ok
140:160,230,206,206,204,158, Ok
142:160,230,230,230,158,158, Ok
144:160,230,230,230,160,158, Ok
146:160,230,230,230,162,158, Ok
148:160,230,230,230,162,160, Ok
150:160,230,230,230,162,162, Ok
152:160,230,230,186,186,184, Ok
154:160,230,230,186,186,186, Ok
156:160,230,186,186,162, 0, Ok
158:160,230,162,162,158, 54, Ok
160:160,230,162,162,160, 54, Ok
162:160,230,230,230, 80, 0, Ok
164:160,230,230,206,204,158, Ok
166:160,230,230,206,206,158, Ok
168:160,230,230,230,184,158, Ok
170:160,230,230,230,186,158, Ok
172:160,230,230,230,186,160, Ok
174:160,230,230,230,186,162, Ok
176:160,230,230,162,162, 0, Ok
178:160,230,186,186,184, 0, Ok
180:160,230,186,186,186, 0, Ok
182:160,230,204,204,204,204, Ok
184:160,230,206,204,204,204, Ok
186:160,230,206,206,204,204, Ok
188:160,230,230,230,204,158, Ok
190:160,230,230,230,206,158, Ok
192:160,230,230,230,206,160, Ok
194:160,230,230,230,206,162, Ok
196:160,230,230,230,186,184, Ok
198:160,230,230,230,186,186, Ok
200:160,230,230,186,162, 0, Ok
202:160,230,206,162,158, 54, Ok
204:160,230,206,162,160, 54, Ok
206:160,230,206,162,162, 54, Ok
208:160,230,230,204,204,204, Ok
210:160,230,230,206,204,204, Ok
212:160,230,230,206,206,204, Ok
214:160,230,230,230,230,158, Ok
216:160,230,230,230,230,160, Ok
218:160,230,230,230,230,162, Ok
220:160,230,230,206,162, 0, Ok
222:160,230,230,186,184, 0, Ok
224:160,230,230,186,186, 0, Ok
226:160,230,230,162,158, 54, Ok
228:160,230,230,162,160, 54, Ok
230:160,230,230,162,162, 54, Ok
232:160,230,230,162,162, 56, Ok
234:160,230,230,230,204,204, Ok
236:160,230,230,230,206,204, Ok
238:160,230,230,230,206,206, Ok
240:160,230,230,230,230,184, Ok
242:160,230,230,230,230,186, Ok
244:160,230,230,230,162, 0, Ok
246:160,230,206,206,158, 54, Ok
248:160,230,230,184,158, 54, Ok
250:160,230,230,186,158, 54, Ok
252:160,230,230,186,160, 54, Ok
254:160,230,230,186,162, 54, Ok

[ijor]

What i mean is the visual result: an unstable picture.
It happens that a line combination leading to a stable fullscreen pic can lead to an unstable 320 pixels wide pic and vice versa.
For example, if i rember rigth, if the last line of the sync-scroll lines is a 186 bytes one (only left border) it is likely that the pic will be unstable.

If you ever find in your notes some reference, so that I could try to reproduce the problem, please let me know. I would be very interested to study this.

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.

Hmm, I don't think so. If my theory is correct, then you have a single possible timing to make these switches. So unless you made a mistake, this might mean it won't work at all on STe.

Well, as I said above. I have some idea that I never tested. Assuming the idea works, it might give you a chance to adapt the timing here. But I am suspecting now that the switches are simply not possible (without a distorted picture) in STe machines.

Anyway, this means that the thing does not only work on my machine.

I can't assure you it works on all machines. But I can assure you it works at least in many. I did make some tests some time ago. The tests I did were different than yours. But they both depend on the same issue. If my tests worked, then yours should as well on the same machine.

The funny trick is that you use the 1+4 mode, and even better, you don't have to do anything in the first line (160 bytes).

Exactly. That's what I was saying all the time, that if you never loose sync you can sync-scroll with 4 scan lines only!

[leonard]

Exactly. That's what I was saying all the time, that if you never loose sync you can sync-scroll with 4 scan lines only!

Yes Well, keep "in sync" for the complete screen is quite a pain but few demos use that mode. (I remember a fullscreen demo by mcoder with a 2 bitplan text vertically waving)

4 lines scroller is cool !

btw Paulo, could you explain your trick to get two version of line working for each ST state ?

[MetalGuru]

I've tested ijor's program.
I get:

Computed clock: ~32.08 MHz
Machine: PAL

/MetalGuru

[ljbk]

I've tested ijor's program.
I get:

Computed clock: ~32.08 MHz
Machine: PAL

/MetalGuru

Many thanks !

This means that the 162 bytes line works on a standard PAL STFM machine as it does on a weird NTSC STF machine like mine with a different CPU and video clock.

[ijor]

btw Paulo, could you explain your trick to get two version of line working for each ST state ?

I would try to explain. Because I suspect Paulo doesn't know the full explanation. I mean, he obviously knows how to make it work. But he might not know from the theory, why it has to be done like this, and why exactly it works (it shouldn’t work according to what most people believes the ST works).

The full explanation is rather long. For quite some time I wanted to complete a couple of articles. But I never could find the time. It is likely that I won't be able anytime soon. So here is a short, concise one. Many people probably won't understand it. But other like Leonard and Paulo surely will, and then we'll all be able to answer possible questions.


Why these new switches don't work, or are not stable depending on the wake state?

All the other overscan switches require a precision of 4 machine cycles. That is, you have a window of 4 cycles to apply the switch to be effective. These two new cycles, however, require a precision of 2 cycles.

A precision of 4 cycles is not a problem. It is always possible to find a simple code and timing that would work on all machines and wakeups. But a precision of two cycles is problematic because of two reasons.

The two wakeups produces a shift of two machine cycles between the CPU and GLUE. So a given code that would work in one wakeup, would be 2 cycles earlier (or later) in the other and won't work. So these switches require the code to be adapted at runtime to the current wakeup.

The other problem is that 2 cycles is beyond the NOP resolution. You have to use pairing correctly to shift the code in 2 cycles unit. And put something like EXG D0,D0 (6 machine cycles) right before writing into GLUE.

Up to here I'm sure Paulo knows. But there are still two questions to answer:

1) Why these new switches require a 2 cycles precision? They shouldn't. After all it is a normal 50/60Hz switch. All the horizontal 50/60 switches are based on the 4 cycles distance between the 50/60Hz GLUE timing. This shouldn't be an exception. After all, we are just messing with the left border, the rising edge of DE. And this signal is raised 4 cycles later in 50Hz than in 60Hz. So it would be natural to assume it should require the same 4 cycles precision as say, removing the right border.

A hint: Near the top of the second part of the excellent Alien overscan articles, there is a key sentence. He says that something couldn't be exactly determined. If you can determine what he couldn't determine, then you have the answer to why we need a 2 cycles precision.

2) Pairing should not help according to the theory. The theory is that all CPU bus cycles are aligned on a four cycles boundary. So it doesn't matter what kind of pairing you use, you should never be able to make a bus access two cycles earlier (or later). But the theory is wrong, something that Paulo suspected long ago. I remember he mentioned something like “it seems the CPU can sometimes get two time slots in a row”.

I found the full answer on two completely unrelated topics. One is how the Discovery Cartridge works. As many people know, the DC is not exactly a ROM cartridge, it has a custom ASIC with a low level floppy controller. Back on the old days I found that the DC performs a small piece of code right from the cartridge. So it does have some code. It didn't make much sense to me at the time. The software is rather big, it couldn't be for saving code space. I thought it could be some kind of copy protection to avoid cloning or hacking. But then I didn't care too much and forgot about it for a long time.

Now I know why. So try to answer why the DC might need to run some code off the cartridge, that it couldn't, or would be much more complicated, when run as part of the normal program. Looking at the ST schematics could also give the answer