Re: 1 euro Olimex RISC-V mini-PC: this needs Forth ;)

On 24/09/2024 19:22, Paul Rubin wrote:

https://www.hackster.io/news/olimex-s-one-euro-rvpc-single-board-computer-goes-up-for-sale-next-week-1cfe4fe2c985
 

Found some code on github following the name in the article:
https://github.com/TurboVega/RVPC/blob/towers-of-hanoi-1/SOFTWARE/Demo-VGA/src/main.c#L288
(forked from Olimex's initial sample repo https://github.com/OLIMEX/RVPC/tree/main/SOFTWARE/Demo-VGA )
Haven't found an 800x600 pixel res variant (though they may be more talkingh about overall display sync/timings but with wide pixels).
However, can see their general approach - appears to be bit-banging out gpio->vga individual scanlines of a tilemap/charmap display.  So vaguely similar to a lot of 8-bit tilemap/charmap display hardware, implemented in software, on the apparently-fast-enough-to-do-that tiny cpu.
Wwe're not talking a large linear bitmapped framebuffer in the small ram area, just a smaller tile/char screen area and the current-scanline buffer in the ram area. The 1-bit bitmap glyph image data itself can then come from the flash area, much like the "character rom" of an 8-bit.
https://github.com/TurboVega/RVPC/blob/towers-of-hanoi-1/SOFTWARE/Demo-VGA/src/chardefs.h#L2663
That towers of hanoi sample code linked appears to be doing 21x18 8x8 pixel chars display, so in pixel terms that's 168x144, and the byte-per-tile/char display ram area is only 378 bytes.
I suppose adding some control bytes allowing selecting different tilesets during the display could also give a bit more versatility with not too much more overhead, as the device has 16384 bytes flash and thus can hold at least a few different tilesets while still having room for program code. a 256-character 8x8 1-bit bitmap charset/tileset is 2048 bytes obviously, just like a C64 etc.
Unclear to me ( / far too lazy to work it out) if it's actually fast enough that it could actually e.g. be pushed all the way to, say 50x38 x 16x16 tiles, but that would then cover a 800x600 pixel res (just over as obviously 600/16=37.5) and still be 1900 bytes for byte-per-tile ram area (and we need the scanline buffer, another 50 bytes), technically fitting into the 2048 bytes ram ... though really not leaving room for a whole lot else at all.
A 256 tile 16x16 1-bit bitmap tileset is 8192 bytes, half the flash.
Perhaps 40x30 16x16 -> 640x480 -> "only" 1200 bytes screen ram could be made work.
40x30 8x8 -> 320x240, perhaps doubled on output to 640x480 sync/timing-wise for better compat with vga->digital adaptors, might be a sweeter spot ....if that can be made work.