litex

litex copied to clipboard

The VideoTextGrid is similar to the VideoTerminal, but instead of receiving a stream of characters from an attached UART, it exposes a csr (YXAC) to allow direct access to the character grid. Writes to this register specify the Y coordinate, X coordinate, Attribute, and Character, encoded in a 32bit value and result in a write to the character/attribute memory.

The attribute memory currently encodes 3bit RGB foreground and background colors. The remaining 2 bits might be useful for an intensity bit (doubling the colorspace) or some other feature like h/v flip.

Two additional registers (SCROLLX, SCROLLY) allow the underlying 128x64 character grid to be scrolled within the 80x40 visible viewport.

Some trickery with the ClockDomainsRenamer was necessary to keep the register facing side of the text/attr memory. The "sys" domain gets renamed to "hdmi" typically, so we put the write side of the text/attr memory in the "csr" domain and rename that to "sys" at the same time the "sys" domain is renamed:

vt = ClockDomainsRenamer({ "sys": clock_domain, "csr": "sys" })(vt)

Thanks a lot @swetland, really interesting. Do you eventually have have some C code that could be used to test this on hardware? I'd like to be able to test it easily and maybe try to see if we should directly integrate this in the VideoTerminal and just add a mode parameter to the Video Terminal (to either receive/interpret characters from a UART or from CSR registers as you did).

I have a simple test I can expand -- is there a place in the litex tree / build system for software tests? I see soc/software/demo but don't see that stuff ending up in the build/.. for the boards I build for.

I originally thought about making this a feature of VideoTerminal but couldn't figure out how to do it cleanly (new to Migen, not very comfortable with python), so went for the least-invasive approach.

Another possibility that I couldn't figure out how to make work, which maybe would be simpler, would be to just expose the char/attr memory as (write only?) SRAM and just let software poke it directly.

My goal here is to allow multiple software threads directly interact with different regions of the text display as a way of demonstrating/debugging a simple OS.

Thanks, can you share a simple test for now? Just to allow me to quickly do some tests with the core? This will also probably allow me to rework the integration and try to just make it a mode of VideoTerminal.

vtg-test.elf - linked at 0x40000000 vtg-test.bin - raw binary for serial download to ULX3S or similar vtg-test.lst - disassembly start.S & vtg-test.c - source code

Assumptions: 32MB ram at 0x40000000 VideoTextGrid at 0xF0003000 sysclk 50MHz (for spin delays)

This test draws a checkerboard background and a red rectangle around the visible display. It draws a green rectangle around the edges of the textgrid that extend past the visible display and some informational text. After a one second delay it scrolls the viewport (wrapping around) vertically and then horizontally. It then repeats.

vtg-test.zip

Just for info, I've been able to do a first test and get it running. I'll try to have a closer look at the integration very soon.