[SOLVED] No Sync after attempting 1.00 bodge wire on 1.6 hardware
NewHome › Forums › OSSC, OSSC Pro and DExx-vd isl › OSSC – Discussion and support › [SOLVED] No Sync after attempting 1.00 bodge wire on 1.6 hardware
- This topic has 11 replies, 2 voices, and was last updated August 9, 2025 at 3:18 AM by
bobrocks95.
-
AuthorPosts
-
July 20, 2025 at 9:11 PM #66611
Hi there, looking for a sanity check or debugging steps I can take for updating to the latest firmware on an older OSSC model.
Haven’t used the OSSC in quite awhile, but I removed R35 and installed the bodge wire to the far leg on the video chip as described in the firmware v1.xx thread. I verified with a multimeter that the pins on the chip weren’t bridged and that the closer pad to R35 had connectivity.
After getting home (it really sucks but my soldering equipment is elsewhere), flashing firmware v1.12, and trying out NES lumacode I’m getting a solid No Sync message for the AV2 RGsB input. Not knowing if the OSSC update or the lumacode install was the issue, I hooked the VGA output from my Extron VGA switch to AV3 and tried some other sources (namely SNES via RGBS) and still got a no sync message. I’m forgetting what the OSSC supports but this would be TTL RGBS with sync on the HSync pin, which should be correct? EDIT: Also tried Dreamcast RGBHV for something more standard and still had the No Sync message.
Anyways, does this sound like it’s definitely a bad install of the bodge wire? I still get the test pattern and everything else seems to be working on the OSSC side, other than sync input processing.
Is there a test point further on from the R35 pad where I can check continuity between the video chip’s end pin and said test point? I exposed a bit of solder mask near R35 so maybe I managed to sever a trace or something???
-
This topic was modified 9 months ago by
bobrocks95.
-
This topic was modified 9 months ago by
bobrocks95. Reason: Tested Dreamcast RGBHV
-
This topic was modified 8 months, 1 week ago by
bobrocks95.
July 22, 2025 at 8:43 AM #66633I recommend downgrading to 0.xx firmware and testing if that still works (no need to revert the mod).
July 23, 2025 at 12:17 AM #66653Hi marqs,
Just flashed 0.90 to test and I get a very flickery/jittery image seemingly regardless of output modes and settings, though some are better than others. This is feeding into a Tink 4K’s HDMI input.
July 25, 2025 at 3:08 AM #66665Some crummy installation photos- never have been able to get good zoom/closeup shots of anything with a phone camera.
https://photos.app.goo.gl/ZsxXaMcJe4E1eU4V7
Checked continuity again for fun, and the chip pins aren’t bridged and things are beeping fine to the inner R35 pad… Still curious if there’s a better place up the board or anything to confirm continuity, or whatever else you can tell me marqs. Thanks!
July 25, 2025 at 10:49 AM #66670So 0.xx still detects sync which at least indicates the board has not been damaged. I’d use something other than NES/SNES (unless dejittered) and/or a display directly to test stability. Did you test that nothing is shorted on the resistor side?
July 25, 2025 at 9:52 PM #66675Good point- things look perfectly fine with PS1, PC Engine, and dejittered Famicom. This is again back on firmware 0.90 with the wire still installed.
No shorts apparent on the resistor side between any of the 4 pads.
August 1, 2025 at 12:31 AM #66717Any thoughts on what I can check marqs? Hoping to try and square it away this weekend while I have access to my soldering stuff. I suppose I’ll flux and touch up both points if I don’t hear anything else specific.
August 1, 2025 at 9:47 AM #66718Can you verify that FPGA pin 126 is grounded? If it’s floating due to manufacturing fault etc., then the firmware presumes it’s v1.8 board and excepts sync on a different pin.
August 1, 2025 at 8:27 PM #66725Difficult to measure with no help from the silkscreen, but if the below pinout is correct (model number does differ slightly), then pin 126 is grounded. It was around the 2 on the U2 marking, and I counted in from both directions verifying other ground points as I went.

-
This reply was modified 8 months, 2 weeks ago by
bobrocks95.
August 7, 2025 at 11:46 PM #66767Going to take another stab at this tomorrow. Wanted to ask again though, if I remove the wire, do you know where the far pin on U1 connects to test, or is it left floating on the stock PCB? Same question for the pad on R35, if there’s a way to verify either of those are still in-circuit and good.
Thanks for the help so far marqs.
August 7, 2025 at 11:55 PM #66768Well here’s something that might actually be helpful- that pin on U1 and the closer pad on R35 appear to be connected to ground. Is that expected or did I maybe hit a via near the pin on U1 or something? I’d assume if you just needed to ground the pin or pad there’d be a much closer connection point for the mod.
EDIT: Duh, open source project with gerbers available. Looks like the U1 pin is normally floating, and then after the bodge wire, should connect to pin 46 on the FPGA, IO_16 if that earlier diagram is right?

Still don’t know how I managed to ground it all- the R35 pad I guess is surrounded by ground plane, maybe I need to check if I scraped some soldermask off and managed to short to it???
-
This reply was modified 8 months, 1 week ago by
bobrocks95.
-
This reply was modified 8 months, 1 week ago by
bobrocks95.
August 9, 2025 at 3:18 AM #66781Issue resolved, sorry for the trouble. No clue what was doing it but I was grounded over by the R35 pad to something. OSSC is working now (though my NES Lumacode install is not)
-
This topic was modified 9 months ago by
-
AuthorPosts
- You must be logged in to reply to this topic.
