Low Pass Filter Problem – Amstrad CPC 464

NewHome Forums OSSC, OSSC Pro and DExx-vd isl OSSC – Discussion and support Low Pass Filter Problem – Amstrad CPC 464

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #24904
    jesus delmas

    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.

    Scar component diagram amstrad 464

    Video Explanation


    Thanks !!


    This is a closed group, we can’t see the pictures. If you have uploaded them there, right click on the pictures and open them in a new tab (using “open image in a new tab” and NOT “open link in a new tab”). Then you will be able to copy the link in the address bar and post them here using the “img” button.

    jesus delmas

    Thanks for answering!, i think that this time i did it right, i hope someone knows whats going on becasue its really anoying… nobody in the amstrad comunity knows how to fix it.. maybe is a low pass filter problem? maybe a timing problem? jus some ideos but not sure.


    What are the specs of the CPCs sync output?

    jesus delmas

    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


    specifically, is it output at TTL or 75ohm consumer spec?

    jesus delmas

    It is analogic vsync so its not ttl, other thing is that the refresh rate is 50.08 hz and not 50 hz, maybe this is the reason of the vertical color interferences?


    I have an Amstrad CPC6128 from 1986 and I’d love to be able to use it with my 50″ 4K TV in the living room. I’ll buy an OSSC the moment there is a way to make it work flawlessly with my favourite retro-computer. Please keep up the good work!

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.