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.

To summarize from the article for { and }:

Modern digraphs:

   <%  ,  %>. This is only one that looks symmetric

  ??<  ,  ??>

   \(  ,  \)

   *(  ,  *)

   $(  ,  $)

   <<  ,  >>    for [ , ]

   (<  ,  >)    for { , }

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 *.

Comments URL: https://news.ycombinator.com/item?id=48165944

Points: 124

# Comments: 90

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.

https://en.wikipedia.org/wiki/Apollo_TV_camera#Westinghouse_...

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.

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."

Comments URL: https://news.ycombinator.com/item?id=46429944

Points: 3

# Comments: 0

"Dirty Rotten Infinite Sets and the Foundations of Math" http://www.goodmath.org/blog/2007/10/15/dirty-rotten-infinit...

Wildberger also wrote a book on geometry with nothing allowed but rationals. (Or something like that.)

8088 PC's already have M Brutman's "mTCP" driver. And DogCow (D. Finnigan) has been working on and off on the "Sabina" networking suite for the original 128K Macintosh on the MacGUI site: https://macgui.com/sabina/ https://macgui.com/news/article.php?t=550

Though it's a been slow going, apparently because of a day job. (Also note that the MacGUI site now requires an account to read progress posts.)

An interesting point about Bresenham's algorithm is made by David Schmenk (dschmenk) on his "Bresen-Span" page:

"Take note that the algorithm can be viewed as the long division of delta-major/delta-minor. The error term is really the running remainder, and every step results in a pixel along the major axis until the division completes with a remainder. The division restarts by moving along the minor axis and adding the dividend back in to the running remainder (error term). This is a bit of a simplification, but the concept is that the long division will only result in two integral spans of pixels, depending on the value of the running remainder (error term). We will take this in to account to write a routine that outputs spans based on the two span lengths: a short-span and a long-span."

In other code, dschmenk does use DDA for anti-aliased lines.

https://github.com/dschmenk/Bresen-Span

With one exception: there are absolutely no old issues of the Apple II magazine "Call A.P.P.L.E" (Apple PugetSound Program Library Exchange) anywhere online. The reason why is the group decided to keep the business going. The only place you can get those old issues is from the official callapple.org website for the price of subscription. Too bad, because there are old issues I'd love to read.

A few months ago, mathematician John Baez had a series on the mathematics of various temperament and keys. Of course he knows his math, but also music thanks to being a member of rather famous musical family. (More math in the second link.)

https://johncarlosbaez.wordpress.com/2024/01/11/well-tempera...

https://johncarlosbaez.wordpress.com/2023/10/07/pythagorean-...

Certainly compared to Whitesmiths C for CP/M, and not just for the $700 price vs $150 for BDS-C. Whitesmiths was real, official C, direct from P. J. Plauger and V6 Unix. But each compile went through many, many, many passes on the poor floppy (including pseudo-assembly "A-Natural" for the 8080 that then translated to real assembly). Everybody complained that while very professional, it just took too long to go through the cycle.

Contemporary BYTE recommendation was to develop & iterate on BDS-C, then at the end re-compile on Whitesmiths to squeeze the best performance.

A contemporary source is the opinionated "DTACK-Grounded" newsletter from 1981-1985. http://www.easy68k.com/paulrsm/dg/ Hal Hardenbergh raved about the fast 68000 chip and it's wonderfully easy assembly, but lamented that everyone switched to "portable" Pascal and C to write 16-bit programs so they seemed even slower than 8-bit ones. His favorite example was a direct comparison: Lotus 1-2-3, written in 8088 assembly, vs Context MBA with the same features but written in Pascal for portability. 1-2-3 was MUCH faster than Context on the PC, and no one remembers Context today. Or the $16,000 Unix-based AT&T workstation whose floating-point benchmarks are beaten by a $69 VIC-20. (Obviously due to the C-written runtime, which even followed the C standard of promoting all single precision calculations to double so single was no faster!)

His opinion of C was "slightly-disguised PDP/11 assembly". Not too bad for the 68000, but a terrible fit for the 8088 or Z80.