exxos's Atari, Amiga & retro forum

Got some stuff to play around with CPLDs. Now I have to motivate myself into downloading an humonguous archive with Quartus...

Will I finally develop something on the Raspberry pico ? Well, I bought a "pico probe" to have a ready to use and **neat** device to program the pico, instead of having to picos on the breadboard.

Problem is, I have only one available USB port, and I would need 2 : one for the probe, the other for the pico to program and test. And even if I had two available ports, I DO want to use only one, because some projects need the pico to play the role of USB host.

Fortunately, the pico probe is just a fancy pico, and fortunately again, there are test points on the back of the PCB, that allow to tap power from the USB port of the probe (vbus) and ground. And fortunately again, those test points are neighbours.

So, I just hacked the pico probe (bye bye neat looking device) and voilà !


Now, I still need to setup the toolchain, and manually, as I want to do some step myself instead of relying on VSCode and the Raspberry pico extention for raspberry pico.

My steps are covered there

sporniket wrote: 21 Sep 2023 21:14 Those last weeks, I was working on HDL stuff, and I succeeded to output something on screen through the HDMI port (technically I output DVI frames, not HDMI frames).

All the code (tmds encoding and all) was written with Amaranth-hdl.


blinky-hdmi.gif


I will tidy up my code a little before switching back to retro stuff.

I took time to rewrite some logic better

• especially the shift register, where I tried to be clever, and now I wonder how that could even work, went back to simple, like a simple counter to schedule the loading of the input value.
• most importantly, I stopped converting regular signals (like e.g. "vsync") into clock signals (this seems to be bad practice on fpga), using amaranth's EnableInserter and ResetInserter, and a custom logic emitting a single 1-clock long impulsion, to emulate the equivalent use case (e.g. running the logic of the target module only once each time vsync is asserted). This allows to use the same base clock throughout the design

This time, I could implement a pair of gradients for the red and green channel.


Also, the timing now report regularly states that the logic feeding the HDMI/DVI link may support around 370, (instead of maxing around 330 MHz), that will allow me to attempt higher resolution like SVGA 800×600 (requires 360 MHz), and maybe quarter HD 960×540 (requires 372.5 MHz)

The project is here : https://github.com/sporniket/the-cradle ... ranth-hdl/

I almost gave up, but I finally could get a quarterHD resolution (960x540 at 50Hz), using CVT-RBv2 timings (Coordinated Video Timing - Reduced Blanking v2), requiring a TMDS clock of "only" 290MHz (using that timing calculator : https://tomverbeure.github.io/video_timings_calculator)

It turns out that depending of the setting of the PLL, the max frequency of the dvi logic varies enormously (and not in my favor). Ironically, with the current setting, the timing report states that the logic could work up to 407MHz... right...

Anyway, happy to have the biggest resolution that can output my FPGA, with square pixels on a 16:9 screen.


(each square of the pattern is 256×256 pixels)

Refactored the python code and task runner to select the target video mode to build through the command line, instead of commenting in/out the correct lines.

And did a little demo video.