Path: ...!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David De La Harpe Golden Newsgroups: comp.lang.forth Subject: Re: 1 euro Olimex RISC-V mini-PC: this needs Forth ;) Date: Wed, 25 Sep 2024 16:20:24 +0100 Organization: A noiseless patient Spider Lines: 55 Message-ID: References: <87frpoewse.fsf@nightsong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 25 Sep 2024 17:20:26 +0200 (CEST) Injection-Info: dont-email.me; posting-host="97de2f3304373ca738feb00824a03d3e"; logging-data="3926889"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19NcXCfiH6msskTIIFkdXowzDdfLNX9UbaW2VcIp2oIng==" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:PXPyWnmODo5p4ciFcvcwjUea4Lk= Content-Language: en-US In-Reply-To: <87frpoewse.fsf@nightsong.com> Bytes: 3770 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.