OSSC with Amstrad cpc - some timing or sync problems

[jesusdelmas]

Hello guys!! After some checking. I expose here my problem with my ossc and my computer amstrad cpc 464.
In this video you will see that i have some interference with the video LFP. Being worse at off or 95 MHz and better in 9 MZh or auto. Also has a little horizontan shake but hard to see.
Also i attached a picture of the components of the cpc 464 scart conexion to the ossc.
About the monitor i have nothing to say. It works perfect with my other sistems in 2x 3x 4x or 5x with perfect sync. Nothing to complain about it.
I want to know what i could use to fix this. I have a sync strike it maybe work? I would like to know the roots of the problem, would be good for the amstrad comunitty 🙂
Here are a picture explanation of the scart componentes of the amstrad cpc and also a video explanation of the timing or lpf problem that im having (shows what happen)


here is the video:

https://scontent.fscl10-1.fna.fbcdn.net/v/t66.18014-6/10000000_927682680955004_8591853697263481593_n.mp4?_nc_cat=109&vs=8bb40aebff7013ee&_nc_vs=HBksFQAYJEdJQ1dtQUI4b0tuMHVFc0RBUGt5aElOcVpUeDNibDVHQUFBRhUAABUAGCRHR1g0QXdMNDNnQlVka2tCQUFBQUFBQXotaEY2YnFkQkFBQUYVAgBLAYgScHJvZ3Jlc3NpdmVfcmVjaXBlATAVAAAYCTc5MTMyMDQxNhbS1bmuyd2MJBUCGQUYAkMzGAt2dHNfcHJldmlldxwXQGoX1wo9cKQYGWRhc2hfb2VwX2hxMl9mcmFnXzJfdmlkZW8RABgYdmlkZW9zLnZ0cy5jYWxsYmFjay5wcm9kGRwVABW8mQIAKBJWSURFT19WSUVXX1JFUVVFU1QbAogVb2VtX3RhcmdldF9lbmNvZGVfdGFnGW9lcF9oZF9yZWNpcGVzX3FlX2NvbnRyb2wTb2VtX3JlcXVlc3RfdGltZV9tcw0xNTQ4MDA3NzE0NzQyAA%3D%3D&efg=eyJ2ZW5jb2RlX3RhZyI6Im9lcF9oZF9yZWNpcGVzX3FlX2NvbnRyb2wifQ%3D%3D&_nc_ht=scontent.fscl10-1.fna&oh=82cc659e2313e7c8fc40c4c960d19334&oe=5CBFEE09&_nc_rid=d76f87f10a23f42

[Audronic]

@jesusdelmas


The 30 Ohm resistor is miles to LOW Try 300 Ohms.
See how that goes




Ray

[jesusdelmas]

@jesusdelmas


The 30 Ohm resistor is miles to LOW Try 300 Ohms.
See how that goes




Ray

It uses Vsync. Here is the complete.information


The display is controlled by the CRTC and the Gate Array.
The CRTC generates horizontal and vertical sync signals, and can be used to generate a variety of screen displays.
The Gate-Array converts bytes into pixels using the current screen-mode and palette settings.
Therefore we can synchronise with the CRTC, to an exact point where the internal counters are exactly what we want, or to a exact position on the display.
By synchronising to the display cycle any effect using the CRTC and Gate-Array is possible:rasters (Gate-Array)

• split-rasters (Gate-Array)

• diagonal-rasters (Gate-Array)

• vertical rupture/splitting (CRTC)

• horizontal rupture/splitting (CRTC)

• multiple modes (Gate-Array)

• Synchronising using the VSYNC

• The VSYNC signal of the CRTC is connected directly to PPI port B, therefore it is possible to test the state of the VSYNC.
  It is possible to synchronise to the start of the VSYNC using the following code: e.g.
  [size=inherit]ld b,&f5            ;; PPI port B input .wait_vsync in a,(c)            ;; [4] read PPI port B input  ;; (bit 0 = "1" if vsync is active,  ;;  or bit 0 = "0" if vsync is in-active) rra                 ;; [1] put bit 0 into carry flag jp nc,wait_vsync    ;; [3] if carry not set, loop, otherwise continue .continue [/size][size=inherit]Note[/size] This code assumes that the VSYNC is not already active before the code is executed.
  However, this will not be accurate enough:
  At the best, VSYNC will become active exactly when PPI port B is read (on the final execution cycle of the "in a,(c)" instruction), and at the program-counter defined by the "continue" label, we will then be synchronised to 4 cycles (the time for "rra" and "jp" instructions) from the start of the VSYNC signal.
  At the worst, we will just miss seeing the VSYNC become active the first time PPI port B is read (since it would become active just after "in a,(c)" has executed), and then it will be another 7 cycles (time for "rra", "jp nc" and all but the last execution cycle of "in a,(c)"), before the VSYNC is detected. Then when we get to the program-counter defined by "continue" label, we will then be synchronised to 11 cycles from the start of the VSYNC signal. Therefore the timing can differ.
  In reality the timing can vary each frame, and depends on the program code following the synchronisation code.
  Therefore, if we relied on VSYNC alone our effect would not be stable. For rasters this would mean they would "shake" which is useless for for split rasters

[rpalmer]

@jesusdelmas

The V-SYNC signal comes out of the CRTC and is stable for a long enough time to be detected by the CPC when polling the PPI. This means all effects timed to start from V-SYNC are not going to go out of whack.
Also dont forget that PORT B is latched as well.
rpalmer