In this blog I share my observations, thoughts and experience about computers, linguistics, philosophy and many other things that interest me.

Showing posts with label txtmode-ucs2-video. Show all posts
Showing posts with label txtmode-ucs2-video. Show all posts

Friday, December 05, 2025

First Light

Today I sat down and didn't get up until something worked

The first issue was embarrassingly simple: my PLL configuration specified 50 MHz as the input frequency, but the GateMate board has a 10 MHz oscillator. This is clearly visible in the board schematics, and also in Michael Schroeder's SpaceInvaders project for GateMate, which I should have looked at more carefully months ago.

Speaking of SpaceInvaders - I built and uploaded it first, just to verify the entire toolchain and hardware path was functional. The Dell monitor showed the game. Proof that the magic is possible.

Next discovery: my Dell TFT monitor apparently doesn't like 720×400 at 70 Hz. Whether it's the refresh rate or something else, I couldn't get a stable image with those timings. So I made a pragmatic decision: stick with the canonical 640×480 at 60 Hz, 25.175 MHz pixel clock. This is the most widely supported VGA mode in existence. Sometimes compatibility beats nostalgia.

Then came several hours of debugging, patching, and one commit.

And then - this:

It's not pretty. The characters are from some test pattern - card suits and symbols, repeating. The display shows two horizontal bands with the same glyphs, one inverted color scheme, one normal. There are visible timing issues, alignment problems, and the whole thing looks rather rough.

But it's my VHDL code generating this. The VGA timing module, the character lookup, the pixel generation - all of it synthesized and running on the GateMate. After four months of accumulating code and theory, something finally exists on a screen.

The real work starts now.


Friday, October 10, 2025

Black Boxes


The semester is in full swing. The VHDL verification course at ESISAR is focused on testbenches - how to simulate your designs before committing them to hardware. Useful stuff, and I'm finally starting to understand why people write so much infrastructure code that never ends up in the final synthesis

This week we were introduced to the Digilent Zybo Z7-010 board and the Xilinx Vivado/Vitis toolchain. The workflow is impressive, in a way: you drag blocks onto a diagram, connect them with wires, and the tools generate everything - including C header files with register addresses so your ARM code can talk to the hardware you just "designed." Click, click, done.

Powerful? Certainly. But watching the demonstration, I felt a growing unease. The diagram was full of IP blocks - black boxes with inputs and outputs, doing... something. What exactly? How? The tools hide this from you, and you're expected to trust them.

I've spent too many years in software development to be comfortable with that. The methodologies I value - open source, understanding what your code does, being able to trace problems to their source - these don't stop applying just because we've moved from software to hardware.

So I've been reading about the GateMate toolchain instead. Synthesis with Yosys and GHDL. Verification with the same open tools. Place-and-route with nextpnr. Flashing with openFPGALoader. Everything open, everything inspectable. No vendor lock-in, no black boxes, no "trust us, it works."

The GateMate board is still sitting on my desk at home. I haven't touched it since August. But the approach is becoming clearer: when I do start working on it seriously, I want to understand every bit.

December is approaching.


Tuesday, August 05, 2025

Slowly getting to the basics

A few more commits this week. Still haven't tried to synthesize anything, and honestly, I'm not in any rush.

I added a PLL module - Phase-Locked Loops are how you generate precise clock frequencies from whatever reference oscillator your board provides. The GateMate has a crystal oscillator on board; VGA text mode at 720×400@70Hz needs 28.322 MHz. The GateMate's CC_PLL primitive handles this, though I confess I don't understand half the parameters I'm setting. PERF_MD => "ECONOMY"? Sure, why not. I'm copying from examples and trusting the process.

Why 720×400? That's the original IBM VGA text mode resolution. 80 columns × 9 pixels = 720. 25 rows × 16 pixels = 400. There's a pleasing logic to these classic systems.

I also created a constraints file, gatemate1a-evb.ccf, mapping signals to physical pins. It would take me months to realize that "CC" in the extension stands for CologneChip. The file already has pin assignments for things I haven't built yet: PS/2 keyboard, PSRAM, 4-bit-per-channel RGB output. Planning ahead, or wishful thinking -- hard to say which.

Saturday, August 02, 2025

The Board is on the Table

Yesterday, a small package from Bulgaria arrived. Inside: an Olimex GateMate A1-EVB board, in red, with VGA and PS/2 connectors. Today, I registered my project on gitlab and made my first commit: txtmode-ucs2-video on GitLab. After thirty years of thinking about this, the journey has finally begun.

Let me explain.

For as long as I can remember, I've been fascinated by the early personal computers - particularly the IBM PC and its successors. There was something beautiful about those machines: they were comprehensible. You could understand the whole system, from the CPU to the video controller to the keyboard interface. Everything had a reason, everything fit together.

But those machines also had limitations that always bothered me. The video controllers - MDA, CGA, EGA - were brilliant for their time, but they were constrained by the 8-bit character encodings of the era. Code page 437. Code page 850. Cyrillic code pages where you had to sacrifice box-drawing characters. If you wanted to display Russian and French in the same document, you were out of luck.

What if we could build something that kept the elegance of those classic systems but removed those limitations? A text-mode video controller with 16-bit UCS-2 character encoding - thousands of glyphs available simultaneously. And if the glyph is 16-bit, why not make the attribute 16-bit as well? 32-bit cells. Full RGB colors for each character. No more compromises.

This has been my vision for three decades. And now I have the hardware to make it real.

The GateMate A1-EVB is a modest FPGA board, but it's enough. The plan: build a complete personal computer around a RISC-V core. Text-mode video. PS/2 keyboard. Something that feels like sitting in front of an IBM AT, but with a modern processor and proper Unicode support.

Today's commit is laughably primitive. I took a Verilog VGA timing core from an open-source project called OGEGE and converted it to VHDL. Nothing works yet. Nothing has been tested or even simulated. I don't actually know VHDL - my copy of "Circuit Design with VHDL" hasn't even arrived yet, and my semester at ESISAR doesn't start for weeks.

But the first commit is there: vga_core.vhd. The journey of a thousand miles begins with a single step, and this is mine.

The board is on the table. Let's see where this goes.