68000 clock cycles table

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

[ljbk]

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

There are plenty of spots to have +2 bytes around the correct one that does not alter sync. There are probably some that are common to both GLUE wake up states and may be even one that supports a STOP $2100 synchro cycles delta of 0 to 12 cycles. The problem is that you get some distorting of the bitmap and that you can not repeat the syncs on those spots for the next line, may be just because you have now 4 cycles less for the line.
That is why i asked about distorting bitmap effects.
I will have to try it when i have some time.
But anyway, offset 0 would still be missing ...

[ijor]

There are plenty of spots to have +2 bytes around the correct one that does not alter sync.

Hmm. No, there is a single spot.

The problem is that you get some distorting of the bitmap and that you can not repeat the syncs on those spots for the next line, may be just because you have now 4 cycles less for the line.

Yes, and then you altered sync. By altering sync I mean you put that line in 508 cycles, not neccessarily a display distortion.

So may be we are using the "altering sync" expression in two different senses. May be you mean that sync was not altered as long as you don't get any distortion (or any other visible effect). I mean sync was altered because you are producing mixed frames, where the horizontal sync rate is not constant across the whole frame.

You may considering 508 cycles to be harmless. If you do that in the sync line, you have (at least) still 4 more scans until the actual display. Then you probably won't get any visible distortion on most monitors.

But altering sync is always a bit risky, even when you won't get distortion on most systems. If you still consider this valid, then again there are plenty of new things possible.

[ljbk]

There are plenty of spots to have +2 bytes around the correct one that does not alter sync.

Hmm. No, there is a single spot.

Sorry, but i am quite sure of what i am saying. I am not guessing but reporting what i have observed in both GLUE wake up states.
And the same occurs for a 0 bytes line but with much less cases which makes it almost impossible to be triggered at every STOP $2100 cycle case.

[ijor]

Sorry, but i am quite sure of what i am saying.

I suspect we are talking about different things.

Are you saying that there are multiple spots for putting GLUE back in 50 Hz (the time of the initial switch to 60Hz is not important), and yet mantain the total scan length of 512 cycles (and not 508)?

Or are you saying that you do are making the line 508 cycles (which is what I mean by altering sync), but you don't mind because you get no distorsion?

Or are you talking about yet a different method to obtain +2 bytes?

If is the first case, which is what I was talking about all the time, then can you please post code or screen that shows it.

[ljbk]

Sorry, but i am quite sure of what i am saying.

I suspect we are talking about different things.

Are you saying that there are multiple spots for putting GLUE back in 50 Hz (the time of the initial switch to 60Hz is not important), and yet mantain the total scan length of 512 cycles (and not 508)?

Or are you saying that you do are making the line 508 cycles (which is what I mean by altering sync), but you don't mind because you get no distorsion?

Or are you talking about yet a different method to obtain +2 bytes?

If is the first case, which is what I was talking about all the time, then can you please post code or screen that shows it.

Hi !

I am talking about 60/50 timings to get a +2 bytes line no mater if it results in a 508 cycles or 512 cycles line.
To get a 512 cycles line you need a precise timing and there are not many combinations to do so.
To get a 508 cycles is much more easy but again, the first lines will bend to the left and so bitmap is distorted for about 8 lines.
Here are some examples for Glue wake up 2 using my scale (number of dots/cycles before the PAL screen starts) to get a +2 bytes line:
-41/-29 -> you get a 512 cycles line
-41/-27..-19 -> you get a 508 cycles line
-45/-29 -> you get a 512 cycles line
-45/-27..-23 -> you get a 508 cycles line
As there are more cases, it looks possible to have a code synchronized with a STOP, so with a synchro delta between 0 to 12 cycles, that could always trigger a +2 bytes line for the 1st line.
The problem is the bitmap bending.

Hope i was clear now.


Edit:
A rule working for both GLUE wake up states, to get a 508 cycles line with +2 bytes, is: "set 60 before pixel -29 and do not return to 50 before pixel -25".
So you can have your code synchronized with an HBL with a STOP leading always to a +2 bytes line with 508 cycles but with bending bitmap in case 320 pixels lines follow (i do not know yet what occurs if fullscreen lines follow: i have to test it).
By the way, this trick only allows 56 bytes and 162 bytes lines for the first line. As we only have 508 cycles, if you remove the right border, you will read 2 bytes less (42 instead of 44), leading to the same 204 bytes and not 206.
So from my point of view, without full sync, a 206 bytes lines is not possible for the 1st line, not even altering sync.

Edit2:
Bitmap bending also occurs if fullscreens lines follow a +2 bytes 60 Hz 508 cycles line.

[ijor]

Hi Paulo,

I am talking about 60/50 timings to get a +2 bytes line no mater if it results in a 508 cycles or 512 cycles line.

Ah, ok. Glad we cleared up the misunderstanding.

Yes, for 508 cycles you have lot of time. You can leave GLUE at 60Hz since the top border removal, and you can switch back to 50Hz anytime since the left border up to the right one.

code synchronized with a STOP, so with a synchro delta between 0 to 12 cycles

You are using this expression several times and I'm not sure I understand exactly what you mean. Where the value of 12 cycles is coming ???

[ljbk]

Hi Paulo,

I am talking about 60/50 timings to get a +2 bytes line no mater if it results in a 508 cycles or 512 cycles line.

Ah, ok. Glad we cleared up the misunderstanding.

Yes, for 508 cycles you have lot of time. You can leave GLUE at 60Hz since the top border removal, and you can switch back to 50Hz anytime since the left border up to the right one.

code synchronized with a STOP, so with a synchro delta between 0 to 12 cycles

You are using this expression several times and I'm not sure I understand exactly what you mean. Where the value of 12 cycles is coming ???

Hi Jorge !

If i remember right, after a STOP waiting for an HBL, the CPU is not synchronized with the electron beam but the maximum error is 12 cycles.
So if you change the border color after that STOP you will see 12 flickering pixels. I have to confirm the 12 value still.
If you are fully synchronized then of course you see no flickering pixels.
This 12 value leads to the fact that you can not have a 0 bytes line even with bending for the first line has there are only 2 time spots to get it.
For these 12 cycles error, you would need 4 time spots for sync error cycles values 0, 4, 8 and 12.

Another way to explain is the following code:
* here the code is synchronized with the electron beam
...
test.b d1
beq.s label1
not $FF8240.w
bra.s label2
label1
not $FF8240.w
label2
...
This results in a 4 pixels flicker or 4 pixels sync error.

If a nop is inserted after the beq.s, then the code would remain synchronized.

Hope i managed to explain.

[ijor]

If i remember right, after a STOP waiting for an HBL, the CPU is not synchronized with the electron beam but the maximum error is 12 cycles.

I see what you mean. But I don't think interrupt jitter is that big. I'm not sure, but I think it is more like 4 cycles.

[ijor]

Hmm, I need to recheck this. Seems I was wrong (I mixed up a couple of things) and jitter might be actually 16 cycles.

[ljbk]

Hmm, I need to recheck this. Seems I was wrong (I mixed up a couple of things) and jitter might be actually 16 cycles.

As far as i have checked, jitter is of 8 cycles or may be 12 as i was saying.
Anyway, this allows to have left border removal on the sync line !!!
Only line sizes 0, 56, 162 and 206 bytes seem now impossible for the sync line and so only the offset 0 is now missing with 4 lines as the only possible combination is 0,0,0,0 .

I built the following prgs so that anyone can check if the left border removal after an HBL STOP is possible on a real machine. There are 9 programs: GLB368_x, GLB372_x and GLB376_x.
All run with SainT. GLB368_x work with STEem.
On my STF, only GLB372_x work with GLUE wake up state 1 and GLB376_x and GLB372_2 and GLB372_3 work with GLUE wake up state 2.
So i have GLB372_2 and GLB372_3 working with both GLUE wake up states.
Can someone test this on other machines like on STE ?
You should see a stable bee/wasp and no flashing / flickering / skewing / bending at all.

Thanks in advance.

Paulo.

[MiggyMog]

I will give it a bash once I get STE number two down from the attic.

(STE number 1 is in bits at the moment because I finally got round to buying an HD drive upgrade & then abandoned the upgrade half way through after wrecking some of the lines whilst removing the WD1772, now need to re-route from the adjacent chips. I thought I was doing well getting right floppy disk in the fisrt shop I tried too...)

[ljbk]

Hi !

Thanks MiggyMog. I will be looking for your results.

Meanwhile, here are the results of this research that is ending.
The attached program works perfectly on my STF both with GLUE wake up state 1 and 2. I am not sure if it works on all STFs an even less on STE.
It features a vertical scrolling of a 416 pixels wide picture using all 128 offsets simulated by the sync scroll or hard scroll controled by only 4 lines (sync line + 3 normal lines) for 127 of the 128 offsets. For offset 0, the 5th line is partilly used and so the first 48 pixels on the left are missing, but the remaining 368 pixels are displayed normally.
Due to the sync switches used for line sizes 0, 56, 162 and 206, it does not work with the current releases of the emulators.

Have fun,
Paulo.

[C-Rem]

a little feedback :

It works fine with tos stf 1.02 512ko and ste tos 1.06 2mo (both are french versions)

cu

[ljbk]

a little feedback :

It works fine with tos stf 1.02 512ko and ste tos 1.06 2mo (both are french versions)

cu

Thanks.
Nice to know it works at least with one STE.
Btw, the program is of course TOS independent, but HW (GLUE/Shifter) dependent.

Cheers,
Paulo.