Chinese apparently was originally always written vertically top-to-bottom. (And then columns would be right-to-left.) Modern Chinese just rotates everything except the characters themselves 90 degrees to the Latin order.
I also read that a few Chinese texts only make sense in vertical order: one had a pun where the characters read one way as separated characters, but as stacked was also a single character pun for something like a "crumbly cookie".
Believe it or not, there once was an 8-bit computer with native Arabic. It was a version of the Z-80 MSX series by Al Alamiah called Sakhr. It seems it could switch between English, Arabic, or mixed. (In fact, this was mentioned in the OP.)
A forgotten point is that modern pixel fonts all assume pixels have a 1:1 ratio: height the same as width, so an 8x8 character box is perfectly square.
That's NOT true for many of the old computer displays. Most had finer resolution in the horizontal compared to vertical lines, so more pixels across than in the same distance down. 1:1 "square pixels" was an innovation of the Macintosh, and very unusual for the time. So the fonts on this page displayed on other 80's machines would not look "right". And fonts from those machines brought to modern displays also look off.
Square pixels were certainly not an innovation of the Macintosh. The earliest raster scan workstation I'm aware of is the Alto, released in 1973. It and the ones that came after it like the Star and Dorado all had square pixels. So did the early 1980s engineering workstations like Apollo and Sun, which also came out before Macintosh.
I think the Amiga is the most well-known example of what OP means. Older home computers which could be connected to TVs generally had resolutions up to 320x200 (or x240 for PAL) and square pixels. The Amiga could double that on both axes to 640x400/480, but because of the interlaced display of typical TVs/TV-based monitors, that would flicker so bad that it made productive working impossible. So the default resolution used by AmigaOS was 640x200/240, and the fonts were optimized for that.
Even in the PC world, the most common resolution in for CGA, EGA, and VGA remained 320x200 for many years. With square pixels, this would be 16:10, but the usual case was that this resolution was displayed fullscreen on a 4:3 display, so individual pixels would have an aspect ratio of 5:6.
Most DOS-era games took this into account, so e.g. if the artist wanted to draw a circle 20 pixels tall, they'd make it 24 pixels wide. Textmode followed this pattern as well, so when rendered on a modern square-pixel display without aspect correction, will look vertically squashed compared to their original appearance.
It's not that forgotten, for example int10h font collection (which probably is the biggest bitmap font resource) prominently shows aspect-ratio corrections for the fonts https://int10h.org/oldschool-pc-fonts/
Interesting. In the 70's & 80's, 8-bit microcomputers had a the same problem as old teletypes: you couldn't type in some ASCII characters even when the computer could display them. (And many couldn't.) At least some home-grown tiny-C compilers allowed a Pascal-like "BEGIN" and "END" substitute, which I'm sure would be an abomination to Kernighan. Even Pascal itself could have a problem: the very popular TRS-80 Tiny Pascal used ( and ) instead of [ ] for arrays because neither brackets nor braces could be typed.
To summarize from the article for { and }:
Modern digraphs:
<% , %>. This is only one that looks symmetric
Less-modern trigraphs:
??< , ??>
Unix v4 (in the teletype driver):
\( , \)
PDP-11 B:
*( , *)
PDP-7 B:
$( , $)
In other micro software (Advanced MuMath for the TRS-80), I have seen:
<< , >> for [ , ]
(< , >) for { , }
Back in the 80's, the joke among new learners of C and Unix is that the designers must have had a very bad keyboard where typing each character was painful, because every keyword or command was so short and cryptic. This article suggests a different reason: on their 36-bit Honeywell 6070, "four characters fit into a word", so there was incentive to fit in 1 machine word.
It also explains why they used the obscure characters {,},|, and ~ while never using the FAR more common # and @. In the Teletype driver, "#" is clear previous char, and "@" is clear current line. So unavailable for C. I will still curse the C designers to my dying day for picking * as the prefix operator for dereference pointer, when the more logical @ character was SITTING RIGHT THERE! On every keyboard! So now every newbie to C has to stop thinking "multiplication" when they see *.
> I will still curse the C designers to my dying day for picking * as the prefix operator for dereference pointer, when the more logical @ character was SITTING RIGHT THERE!
And what’s worse, many other languages copied this decision without understanding why it was made and why it’s completely nonsensical for modern languages.
I'm confused. Should I be seeing something on this site?
From the comments, there are apparently supposed to be amazing photos. But I see text, I see black backgrounds, but no photos--none at all. Neither on Firefox, nor on Chrome. Just empty boxes where say "Amber Ducky" should be.
The CBS field-sequential color system did have one application after the 1950's: it was the system used for color transmissions from the Apollo moon landings.
If you watch footage of the Apollo 17 LEM liftoff from the moon, you can see color artifacts in the burst of fragments off the platform. Their motion is too fast to stay in the same color band.
It runs, but it would be very slow on actual hardware.
I tried on a cycle-accurate emulator of a TRS-80 Model I with Omikron CP/M mapper. Most Z-80 machines of the time were 4MHz, but the TRS-80 was only 1.77 MHz.
1. Type "GUESS", get question prompt.
2. User types: "Are you an animal?", ENTER key
3. Wait 25 seconds
4. Program prints "N"
5. Wait 20 seconds
6. Program prints "O"
7. Wait 23 seconds
8. Program prints linefeed, returns to question prompt
Total time to return 2-char answer to user's question: 1 min 9 sec or so. I bet a longer answer would take proportionally longer.
"The wonder isn't that it does it well, it's a wonder it does it at all."
Though it'll still be kinda slow on a Model I, I've written an about 9 times faster Z-80 code for the network evaluation. I imagine the pull request will end up in the main depot but for now you can find it in https://github.com/gp48k/z80ai
I think I can do a little bit better; maybe 10% faster.
Well, I was pessimistic. Just pushed an update that slightly more than doubles the execution speed with a PR to the main depot pending. It is very close to 20 times faster than the original.
The version with external 5 x 64k memory is definitively in Osborne-1 disk drawer.
But Osborne does not work. It was so heavily modified that it will never work. The external memory was partially visible in memory space. And the display driver was improved to have 80 columns.
Now that I think about it, it might be possible that it could work in both configurations. The external memory was kinda bulky and not suitable for portable computer.
It would have been wasteful to keep the main memory empty. Or maybe it was reserved for compiled functions?
Wildberger has always been this way. Way back in 2007, Marc Chu-Carroll's "Good Math Bad Math" highlighted Wildberger: "This isn’t the typical wankish crackpottery, but rather a deep and interesting bit of crackpottery." In brief, Wildberger is clearly educated, but also clearly rejects axioms that mathematicians accepted a long time ago (infinite sets in this case):
I also read that a few Chinese texts only make sense in vertical order: one had a pun where the characters read one way as separated characters, but as stacked was also a single character pun for something like a "crumbly cookie".