68000 clock cycles table

[ljbk]

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.

Hi !

The screen flickers with GLUE wake up state 1 so i guess i can say it does not work.
For GLUE wake up state 2, i have a stable screen.
I have no error messages in both cases.

I will do my own tests anyway in a few days as i figured out that this could be the last chance to get that complete 4 line hardscroll.

Yesterday, with the top border tests, i found out something i did not know: you can disable the complete screen with a 60/50 switch done before the normal top border removal. Did you knew that ?

Cheers,
Paulo.

Edit:
Just tested the STOP jitter behaviour.
It is identical with GLUE wake up state 1 and 2: it is cyclic with 5 positions [8,0,4,0,4],8,0,4,0,4,8, ...
So the error with GLUE wake up state 1 should be somewhere within your implementation.
How do you know this does not work with the STE ?
Did you test with Steem and got a different pattern or are you assuming the HBL interrupt works in a different way ?

[ijor]

Hi Paulo,

Just tested the STOP jitter behaviour.
It is identical with GLUE wake up state 1 and 2: it is cyclic with 5 positions [8,0,4,0,4],8,0,4,0,4,8, ...

Yes, it should be identical in both wake ups. The jitter pattern seems to be fixed. But in my program I doesn't assume is always identical in all cases (even when it probably is), and then it measures the jitter pattern at run time.

So the error with GLUE wake up state 1 should be somewhere within your implementation.

Probably, but I have no idea why considering that is does work for me. The only thing that comes to mind, is that for some reason under some conditions I'm losing a frame. Then the jitter table would be out of sync.

How do you know this does not work with the STE ?
Did you test with Steem and got a different pattern or are you assuming the HBL interrupt works in a different way ?

The jitter pattern and HBL behavior is probably identical. What is different in the STe is the 50/60 Hz switch timing. We already know how to make the switch work in the STe. I was just lazy to implement it without no possibility to testing.

you can disable the complete screen with a 60/50 switch done before the normal top border removal. Did you knew that ?

No, I had no idea. I could expect everything from a switch to mono. But not from a 50/60 one. What is exactly the behavior, screen is blacked but video pointer advances, or video pointer never advances?

Where more or less is this switch, in the same line that you open the top border, or in a previous line?

[ljbk]

No, I had no idea. I could expect everything from a switch to mono. But not from a 50/60 one. What is exactly the behavior, screen is blacked but video pointer advances, or video pointer never advances?

Where more or less is this switch, in the same line that you open the top border, or in a previous line?

Hi !

The switch has to be done 9 lines before the normal top border switch.
No bitmap seems to be displayed but i can not say for sure that the memory counter is not incremented. It would need some test.

Cheers,
Paulo.

[ljbk]

Hi !

I have just checked the jitter pattern refered and managed to get synched both with wake up state 1 and 2. So again, you should have a problem with your implementation.
I also checked STEem 3.2 and SainT 1.99 and i found out that none of them emulates correctly the STOP pattern i have with my machine.

Cheers,
Paulo.

[ijor]

The switch has to be done 9 lines before the normal top border switch. No bitmap seems to be displayed but i can not say for sure that the memory counter is not incremented.

Ah, yes, of course. Probably video fetching is active, only display is blacked.

This switch is the vertical analog, to your own switch to blank a particular scan. GLUE must assert Blank during vertical retrace. If you switch 50/60 on the right place, then GLUE would never deassert Blank. And then the whole frame would be black.

Btw, you have PM

[alien]

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.

Yes it's quite possible it didn't work on all ST's. I'd have to go back and read my articles

Note though: If my memory is correct it didn't open a new border, just started the memory fetching. You would expect the screen to go up... but I don't remember if it did that or not. The point I do remember was that you could sync to it. At this point I'd have to get my ST working to find it again.

Alien / ST-CNX

[alien]

Yesterday, with the top border tests, i found out something i did not know: you can disable the complete screen with a 60/50 switch done before the normal top border removal. Did you knew that ?

I knew that. It happened to me when I was trying to find top overscan. I was very upset. I thought I had broken my parents TV, and I would catch hell from them. Funny now, not then!

Alien / ST-CNX

[alien]

Of the 10 lines
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

From memory, my test code went like this:
- Figure out the number of cycles in a VBL (160256 from memory?)
- sync up to the last line on the screen
- Delay 1: wait until... switch mono/back
- Delay 2: see if the counter was different from zero. If not change the delays
- Delay 3: wait a whole screen until Delay 1 arrives. (Delay 3 = 160256 - constant - delay 1 - delay 2)

Then I let it go find it.

I don't remember how long the switch was, but I'm pretty sure it was much smaller than 512 cycles.

[alien]

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.

Wow! That's interesting

[ljbk]

Hi !

For those that might be interested, i am including here the source code for the SHFORSTV program that sync scrolls a pic in 4 lines (only for 1 offset (0) is a 5th line needed).
It was done with Devpac.
Please remember that emulators like STEem and SainT do no support this at the moment.

Enjoy,
Paulo.

[larsbrinkhoff]

Of course another avenue of research, which may/may not be fruitful, is trying NoCrew's 4 cycle enable/disable technique.

Yes, i remember now about this 4 pixels wide "rasters" demo.

Credit where credit is due! It was TOS-Crew, not NoCrew.