08:42 <Stas[m]1> hello! just a shout in the dark, but you never know! :)

08:42 <Stas[m]1> Does anyone know of or have done a video line scaler? I am doing one for PC Engine with separate input and otput clock domains and it is blowing my mind :D

08:45 <Stas[m]1> i built the PCE digital input part with palette ram and so on. It outputs a super crisp picture over RGB in standard PCE console timings.

08:46 <Stas[m]1> After that success, I fed the pixel output to a packetizer denoting ends of lines, and start of frame. This goes into a async FIFO as a CDC into VGA 640x480 clock domain. The clocks are unrelated to each other, but timings in the end go to the same 60Hz vertical refresh

08:47 <Stas[m]1> to make the picture fit, I repeat the same pixel twice, and the same line twice

08:48 <Stas[m]1> pixel repetition is done using valid/ready twiddling, and vertical repetition with a sync FIFO containing a full line. It is fed by the FSM at the same time the first line is output, then FSM switches the output from line fifo

08:51 <Stas[m]1> I am having doubts if even the concept would work. How close the vertical refresh clocks can be away from each other for the CDC FIFO to keep up?

08:53 <zyp[m]> I haven't, but I have a friend who wanted to make one, so we did some talking and thinking about the problem a few years ago

08:59 <Stas[m]1> AFAIK, something like OSSC plays with dynamic PLL settings to lock on that way

08:59 <Stas[m]1> and dereive the output clock

09:00 <zyp[m]> why do you have separate clock domains?

09:00 <Stas[m]1> i wanted to generate a clean video timing mode to be compatible with more displays

09:01 <Stas[m]1> and PCE can change the pixel clock divider, so I would have to change PLL dividers on the fly to keep the same pixel clock

09:05 <zyp[m]> can you simply double the amount of lines during the vblank interval too? if not you'll have to buffer more than a single line

09:07 <zyp[m]> I think the way you're doubling lines sounds reasonable, the challenge lies in synchronizing the output to the input so that any fifos neither underrun nor overrun

10:00 <Stas[m]1> I sync by looking at start of frame mark and resetting the output timing generator to the value for that first pixel of frame

10:01 <Stas[m]1> You are right for sure, there is some fifo sync issue going on

10:01 <whitequark[cis]> oh hey, cool project! good luck with it :3

10:03 <Stas[m]1> Made a board and everything. I will look more into why my fifos underrun

10:03 <Stas[m]1> Maybe something will clear up

10:03 <whitequark[cis]> really nice!

11:46 <zyp[m]> I'm working on reinventing litescope in amaranth, and since I need a way to access it, I'm also reinventing litex' uartbone and friends: https://gist.github.com/zyp/db01ad1349231694fd4db1ff09095518

11:48 <zyp[m]> currently have a simple bridge that works for an 8b wide CSR bus, and a decent test case for it: https://paste.jvnv.net/view/95Rax

11:54 <whitequark[cis]> that's something i'm interested in having upstream in amaranth-soc eventually

11:54 <whitequark[cis]> although regretfully right now i'm not in a position to participate in design work