Re: Rationale for aligning data on even bytes in a Unix shell file?

On 5/15/2025 2:33 AM, Lawrence D'Oliveiro wrote:

On Fri, 9 May 2025 12:50:10 -0500, BGB wrote:
 

On 5/8/2025 9:26 PM, Lawrence D'Oliveiro wrote:

>
On Thu, 8 May 2025 18:50:33 -0500, BGB wrote:
>

But, I don't bother with C1 control codes, as they are unused ...

>
Mostly true. But I think terminal emulators do interpret CSI as
equivalent to ESC followed by “[”.
>

Possibly, though generally, ESC+[ is used IME.

 Actually, several other C1 controls are also defined as equivalents to
sequences beginning with ESC.
 

Also creates uncertainty, as AFAIK the terminals traditionally operate
on raw bytes regarding ANSI commands, whereas if the terminal interface
is UTF-8, a CSI (as a 2-byte encoding) would not be equivalent to 0x9B
(if encoded as a single byte).

 Yeah, I just checked KDE Konsole, and it doesn’t interpret 0x9B (CSI) as
equivalent to 0x1B followed by “[”.
 I suppose I should check if changing the encoding makes any difference to
this ...
 

As noted, IME typically the ESC prefixes are used by software. Also avoids creating ambiguity with UTF-8, and uses the same number of bytes either way (if the CSI is UTF-8 encoded).

I was thinking here more of a GUI based editor or pseudo-word processor;
where Text + ANSI codes could, in theory, serve a similar role to the
RTF format, although more as extended text rather than a sort of markup
language (though, modern word processors typically use XML internally,
as opposed to the more unusual markup scheme that RTF had used).

 There’s an old thing called “sixel graphics”, which DEC invented back in
the day. I found out KDE Konsole supports it! I think some other terminal
emulators do, too. There is a libsixel library that allows converting
image formats. You only get 256 colours maximum, but that is still
potentially quite useful.
 

Early on in my project, I had created a scheme where ASCII escapes could be used to encode 4x4 color-cell graphics, effectively allowing using an 80x50 console as a 320x200 pixel color-cell display (though, 320x100 if in the 80x25 mode). IIRC, I was originally using 64-color (RGB222)
Not ended up used much. Sixel could be supported in theory as well.
For the consoles, I am using the traditional ANSI escapes (but had extended them with color-cell stuff), ...
In my ISA project, the text mode, 320x200, 640x400, and 800x600 color-cell modes effectively use the same block formats.
There are some bitmap modes, ended up used some as well:
   320x200 hi-color;
   640x400 256-color (issues on HW with refresh mem-bandwidth);
   800x600 256-color (basically unusable on real HW, broken mess).
In the text-mode (and 800x600 graphics mode), a commonly used block format is uses 8x8 1-bpp (64 bits), with two RGB555 color endpoints.
In the 640x400 color-cell mode, it instead uses 4x4x2 color-cells, with 4 pairs of RGB555 endpoints (at 256 bits per logical color 8x8 color cell).
Early on, the design of the graphics hardware had a font ROM, but this was dropped to save FPGA resource costs (so, instead, the text-modes are primarily handled by using 8x8 color cells).
For 1024x768, thus far, only monochrome was usable. Did experiment with a sub-mode of 1bpp with 2 8-bit colors per 8x8 cell (total of 1.25bpp, can do 1024x768 in 128K). Image quality isn't great, as color-cell makes the limits of the 256 color palette more obvious (but, technically, still better than pure monochrome). This mode would break from the previous pattern in that the pixel and color data would be stored separately, so 96K of monochrome pixel data, followed by 32K of color data.
Getting screen refresh to happen quickly in these modes (for the experimental GUI) is more difficult though, as, with a 50MHz CPU, getting an RGB555 internal framebuffer transcoded into color-cells isn't super fast (so, getting more than single-digit screen-refresh rates is difficult).
Though, 640x400 is more doable for video playback, etc, if using a color-cell codec design and bypassing the use of bitmap graphics (directly redrawing that part of the screen as color cells).
In theory, the closest "standard" option would be to feed the graphics data in as DXT1 (AKA: S3TC and BC1), though this still requires some repacking into the on-screen format. I have another (less standard) compressed texture format that is closer to what the display hardware uses.
Though for image quality, the color-cell modes are still a lot better than equivalent bitmapped modes would be:
   16-color (640x400)
     Traditional RGBI ("EGA" color palette).
   4-color (800x600)
     Eg: black/white/cyan/magenta, black/yellow/red/green, ...
     Similar to CGA graphics modes.
   2-color (1024x768)
     Though, with a selectable per-screen palette
       black/white, black/green, black/amber, ...
Screen buffer is RAM backed, but ends up limited to around 128K as, much over this, it is hard-pressed to get this streamed into the graphics hardware at 60 Hz (256K is possible, but pushing it).

Sometimes, it would also be nice if there was a sort of a standalone
graphical viewer/editor that used MediaWiki or Markdown or AsciiDoc or
similar.

      pandoc -f markdown -t pdf «infile» | okular - &

Possibility...
Wouldn't be so great for interactive WYSIWYG style editing though...
Did find a program, but it is annoyingly bulky, apparently comes with a crapton of JAR files...
Like, Java isn't really an advantage over C here, when it still ends up being platform dependent and around 1000x bigger because they ship a whole ecosystem of JAR files along with it...