68000 clock cycles table

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

[MiggyMog]

Hi

Sorry for not having done the STE testing yet, both STE's are in bits at the moment. I am going to swap the powerpack over tomorrow(hopefuly) so I have one working to run the tests.

I did run them on my FM however in the meantime however...

STFM (Tos 1.2 wake up mode 2)

GLB368_1.PRG distorted at top,unstable & flickering
GLB368_2.PRG distorted at top,unstable & flickering
GLB368_3.PRG distorted at top,unstable & flickering
GLB372_1.PRG distorted at top,unstable & flickering
GLB372_2.PRG stable
GLB372_3.PRG stable
GLB376_1.PRG stable
GLB376_2.PRG stable
GLB276_3.PRG stable

[MiggyMog]

OK Now Tested on STE(Tos 1.62 4MB Board rev3.1, wake up mode 1)

GLB368_1.PRG image shown flickering, vertical bars shown every 16 pixels showing shifted part of image & down by about 2/3 pixels.

GLB368_2.PRG Stable

GLB368_3.PRG Stable
GLB372_1.PRG Flickering/shifted/non shifted & Dist at top+down 4 pixels on one version
GLB372_2.PRG flickering/shifted/non shifted & Dist at top+down 4 pixels on one version
GLB372_3.PRG flickering/shifted/non shifted & Dist at top+down 4 pixels on one version
GLB376_1.PRG flickering/shifted/non shifted & Dist at top+down 4 pixels on one version only shifted image is more prominant this time
GLB376_2.PRG flickering/shifted/non shifted & Dist at top+down 4 pixels on one version
GLB276_3.PRG flickering/shifted/non shifted & Dist at top+down 4 pixels on one version

SHORTSTV.TOS shows fullscreen (less about 10 lines at top)image scrolls UP & DOWN nicely!

[ljbk]

OK Now Tested on STE(Tos 1.62 4MB Board rev3.1, wake up mode 1)

GLB368_1.PRG image shown flickering, vertical bars shown every 16 pixels showing shifted part of image & down by about 2/3 pixels.

GLB368_2.PRG Stable

GLB368_3.PRG Stable
GLB372_1.PRG Flickering/shifted/non shifted & Dist at top+down 4 pixels on one version
GLB372_2.PRG flickering/shifted/non shifted & Dist at top+down 4 pixels on one version
GLB372_3.PRG flickering/shifted/non shifted & Dist at top+down 4 pixels on one version
GLB376_1.PRG flickering/shifted/non shifted & Dist at top+down 4 pixels on one version only shifted image is more prominant this time
GLB376_2.PRG flickering/shifted/non shifted & Dist at top+down 4 pixels on one version
GLB276_3.PRG flickering/shifted/non shifted & Dist at top+down 4 pixels on one version

SHORTSTV.TOS shows fullscreen (less about 10 lines at top)image scrolls UP & DOWN nicely!

Many thanks.

This was what i assumed.
In SHFORSTV, i used 372_2 for STF and 368_2 or STE.

Of the 10 lines you refer, 4 are really bitmap. The remaining 6 are the remainig top border. May be they also can be used with a 71/50 switch to remove the top border instead of the normal 60/50. But Alien wrote in its document that this was not working on all STs. I have to test it.

Cheers,
Paulo.

[C-Rem]

Same results here on my ste

[Gunstick]

Hi, I only read the forum every 6 months or so Well a late answer to an post way up this thread.

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)

Well it's 6, but in reality more or less 5.5 as of course the line where we sync and open the top border also already includes scroll switches.

For the history, here is the unix shell program generating the complete list of all switch combinations for a 6 lines top border scroll routine. And you can get the complete list too.

Now continuing to read this amazing thread.
Georges

[Gunstick]

Without synching at screen start has of course quite a high price in case of fullscreen: complete precisely timed screen with keyboard and so on like one screen of ULM in Darke Side Of The Spoon or Ziggy interrupt method.

Info:

the DSOTS main menu can be controlled by joystick. But we have to read the IKBD 4 times per VBL. Result: there are several resynch parts during the fullscreen. But it has a normal VBL with top sync.

The playfield screen (first one in menu, with the moving girl) has no VBL. The original music routine is fast played (100% cpu) during the time you suspect some decompressing is taking place, producing some YM dump in RAM before the screen starts. The screen has no IKBD reading either. It is just polling the MFP if there is a keyboard interrupt. Result is you can exit that screen by pressing space OR any other key.

Must be one of the rare only-sync-once "full" screens out there if you count the background color scroller. With that scroller it gets "fuller" than usual because the scroller is way up in the top border. It hangs above the hardwarscroll which is in the small black band below the scroller and the actual screen.

[ljbk]

Of the 10 lines you refer, 4 are really bitmap. The remaining 6 are the remainig top border. May be they also can be used with a 71/50 switch to remove the top border instead of the normal 60/50. But Alien wrote in its document that this was not working on all STs. I have to test it.

Cheers,
Paulo.

I just performed the tests for the top border removal with a 71/50 switch on my machine.
Well it does not work.
Here is how i tested it:
- i wait for the VBL
- i wait a variable number of HBLs with STOP
- i switch to High res and almost 512 cycles later to Low res
Nothing happens: the screen starts at the normal place and looks normal.
There is only one part of the line (512 cycles) where you can not do a 71/50 switch because you will cause a HSYNC and the screen will bend.
I have seen that the effect of line disable described some posts above can also be obtained. Mixing thes 2 effects you can get to a streched screen to the top of the monitor but with a complete mess on some of the HSYNCs.
I have tested only with GLUE wake up state 2 but i am almost sure that the same occurs with wake up state 1.
If anyone has a working version, please post it.
That's it for this subject of 71/50 switch and top border removing.

Cheers,
Paulo.

[ijor]

I just performed the tests for the top border removal with a 71/50 switch on my machine.
Well it does not work.

I admit I didn't study this issue too much. But I just checked the ATARI published timing for monochrome monitors. It seems that the mono top border is exactly the same (in scan lines) as the 60 Hz one. So, disregarding if it is doable and/or stable or not, it seems it shouldn't be useful for opening the top border earlier.

[ijor]

Hi Paulo,

Sorry for not contributing here lately. Was too busy and then forgot. The last posts made me remember about this. So here it is a (hopefully) interesting contribution.

Meanwhile, here are the results of this research that is ending.

A research never ends

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

Well, I realized I always had the knowledge to sync scroll with 4 lines only. And I mean without any need of using part of the 5th line. It's amazing I didn't realize before. But this thread was certainly some kind of brainstorming...

The attached program shows how to create a line of zero bytes on the sync line, without altering sync. It doesn't do anything else. But this is what was missing until now for truely sync-scroll with 4 lines only. All the rest is already known.

With the same technique is, of course, possible to do any other line length (that is doable in a non-sync scan) in the very sync scan. This includes the new lengths with two bytes more. Actually this technique almost obsoletes the most basic technique of ST overscan!

ST only, doesn't work (and will refuse to run) on STe. Not too difficult to adapt it for an STe. But I am too lazy for that and have no real STe to test it.

[ljbk]

Hi Paulo,

The attached program shows how to create a line of zero bytes on the sync line, without altering sync. It doesn't do anything else. But this is what was missing until now for truely sync-scroll with 4 lines only. All the rest is already known.

Hi !

Your program says it works with GLUE wake up state 2 but not with GLUE wake up state 1(with correct Spectrum 512 timing and correct fullscreens) where we have flickering.

Can you please explain the technique used ?
Are you analysing the STOP jitter to then be able to guess the expected jitter at every VBL frame assuming that it is cyclic : 0, 4 or 8 ? (this was the next and last thing i was planning to test regarding this matter of reaching anormal syncscroll with 4 lines)


Btw, i tested the 71/50 top border for GLUE wake up state 1 and the results are identical to wake up state 2.

Cheers,
Paulo.

[ijor]

Hi Paulo,

Your program says it works with GLUE wake up state 2 but not with GLUE wake up state 1(with correct Spectrum 512 timing and correct fullscreens) where we have flickering.

I'm not sure what you mean. It doesn't work for you on wake up 1? Do you get an error message, if so which one, or what? Does it work for you on wake up 2?

I works for me on both wakeups.

Are you analysing the STOP jitter to then be able to guess the expected jitter at every VBL frame assuming that it is cyclic : 0, 4 or 8 ?

Exactly The jitter is not random, it is deterministic and predictable (well, at least it is so in my ST). So the program predicts the jitter for each HBL.