From: david@harpegolden.net   
      
   On 24/09/2024 19:22, Paul Rubin wrote:   
   > https://www.hackster.io/news/olimex-s-one-euro-rvpc-single-boa   
   d-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/SOFTWAR   
   /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/SOFTWAR   
   /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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)