Having some trouble getting these to work…not sure which is the culprit. Looks like I had a blank sync gen chip, which I’ve since flashed, I’m now getting something on screen. Can’t seem to get beyond this rolling mess. Not sure if it’s a Sync Gen problem or RGB Encoder problem. I get this result with nothing plugged into anything other than the video sync distro cable. Similar results when I plug in the Vidiot’s RGB out into the RGB Encoder. Anyone recognize this symptom?
Did you enable the Fuse settings when you programmed the *.elf file onto the atmega? What frequency are you reading on the hsync output, if you measure it?
also: post some pictures of the pcb’s!
I’m getting about 1.19-1.20 kHz on hsync.
I think I enabled the fuse settings…
Sounds like the fuse setting for the clock is set to use the internal clock rather than the external one (from the VCXO). You should read 15.734KHz approximately, on the HSYNC, when things are set correctly
Ok, I’ll try reflashing and make sure fuses are enabled.
Found the command line I used to flash (I think):
avrdude -V -p m88p -c usbasp -P usb -B 1 -U flash:w:LZX-C1-SW-V1.0.elf
Out of curiosity where’d you get the ELF file? And does this mean you could generate some interesting glitchy effects by messing with the sync generator firmware? Any chance there is source available for the Cadet I firmware? I think the manual suggests it’s written with assembly, so I guess I could just disassemble it in a pinch.
I’ve just used Atmel Studio in the past, so I’m not sure what avrdude commands are necessary to install the fuse settings. Can you try to use Atmel Studio?
The elf file is in the firmware repository:
We don’t have source code available, I’m sorry. Think of it like a black box NTSC/PAL sync generator implementation, like a very cost effective dedicated IC for that purpose. Messing with the source code is going to effect the stability of the whole system that comes after it. There are plenty of ways to mess up and glitch your sync signals or make a glitchy sync generator (Arduino, etc) if you want to do that. 
1 Like
If you want to build a weird sync generator/glitch processor, my thoughts are it’s best done with logic processing of valid sync outputs. So you could expand the existing C1 design to include some CMOS logic (XOR, NAND, etc) on the hsync and vsync outs before they are distributed thru the system. That’s going to give you compositional control over the resulting glitches while still being able to instantly revert to stable sync selectively.
A couple hours installing Atmel Studio + dependencies, beginning to figure out how to get my USBasp programmer working with this, and how to even open .elf files…this is kind of a hellride. 
Is there any way to dig up fuse settings so I can try AVRdude, a known working programming setup?
Awesome, I’ve been planning to do this with the 1V outputs from the sync generator and using Castle for logic ever since I found these VGA to BNC breakout cables. VGA should accept 0.7V signals for RGB, and I can use the x5 mults on Bridge to adapt the sync pulses to 5V, so I think this should work, I just need to get an analog VGA display to get properly weird with the sync. My LCD monitor has a CVBS input that accepts output from the Cadet II, so I guess it must deinterlace somewhere in there, but when I try this with the VGA input it tells me the format is unsupported. Exciting idea though!
1 Like
Sure, here are the correct settings (you can see the yellow icon on the ones that are changed vs the defaults):
1 Like
Success on the Syn Gen! Getting 15.7 on hsync. 
Here’s the command line I used for AVRdude:
avrdude -V -p m88p -c usbasp -P usb -B 1 -U flash:w:LZX-C1-SW-V1.0.elf -U efuse:w:0xF9:m -U hfuse:w:0xDF:m -U lfuse:w:0xFF:m
Thanks for your help!
7 Likes
Awesome. Thank YOU for asking the questions. The reason we provide this community forum space is so that we can solve issues like this and retain the data in an easily searchable environment, so it helps us build up a documentation archive in a way.
2 Likes