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 <david@harpegolden.net>
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: <vd19np$3nqr9$1@dont-email.me>
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.