jrdres

It may have designed as a stack to better decoding math expressions. Or they may have used stacks because Intel liked stacks at the time.

It's known that the 8087 was designed to attach to either the 8087 or Intel's 32-bit chip the 432. The contemporary rumor is it is in fact the floating point unit FROM the 432, a money-is-no-object project to make the "ultimate" 32-bit chips. The 432 itself had only stack-based registers, had all kinds of weird-length instructions, had to be split across multiple chips, and locked those registers away from programmers who were only allowed a slow high-level language to program it. Only when 432 was clearly failing was also paired to the 8086/88--a chip that itself was a crash project because of delays in the 432. Adding the very different 8087 to the 8088 was described as pairing a race car engine into a poky Volksagen bug.

Rumors mongered in 1982 by Hal Hardenburgh: http://www.easy68k.com/paulrsm/dg/dg06.htm, "Page 4" section.

On the other hand, getting floating point right in the 8087 was absolutely worth the effort. You can see the comparisons in a 1983 issue of Hal's newsletter on the Savage benchmark: http://www.easy68k.com/paulrsm/dg/dg26.htm. Go to "Timing Conclusions" and particularly "Error Conclusions" and beyond.

The code makes me smile, because it's nasty. This isn't like C4, a tiny but complete C compiler which does error checking on its subset. Instead, this is worse than Sector C, which takes every shortcut and just plain assumes everything in the source is right.

This "Python" just plain assumes for keywords: Any "f" is a "for [x] in range[y]" (exactly that, no other for's). Any "w" is a "while". Any "i" is an "if". Any "d" is a "def". Any "p" is a "print("

Nasty, nasty.

(Also nasty is that the code snippets in the article has more comments than the github copy of the "readable" version. You need the article to understand what's going on.)

This is a just a bit too simple for a "Tiny Python". If somebody is willing to allow a few more K's of bytes, I'd love to see at least lists & dicts here--Lisp can do them!

Yes, but compiling or modifying Snek from source is very challenging. I wish it was one single C file for an example base like Posix, instead of many files for many platforms plus a custom parser in Python (Lola).

Is it down? Every attempt to click the link in both Firefox and Chrome is forbidden by both browsers: "SSL received a record that exceeded the maximum permissible length."

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

I'm curious how it handled mixed entry.

https://forum.vcfed.org/index.php?threads/bought-a-al-alamia...

https://www.msx.org/wiki/Sakhr_AX-230

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.

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

Huh. Works on Android phone. Doesn't work on desktop, Adblock or no Adblock.

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.

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.

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

Thanks for the 8088 version on Github. Any chance you still have the 8080 CP/M version?

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):

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

Now seems to be the trend to bring TCP to retro machines from first principles.

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

Oh, this is DDA, not Bresenham, for lines.

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

The nice thing about 70s-80s computer magazines (and even some books) on archive.org is the relative lack of copyright concern: they're just out there without sign-on and checkout protection. Especially the ones for the 8-bit machines. You can find almost all the old magazines for those machines freely available, and no copyright concerns when people upload more. Even though it's still 50 years before they're public domain, in the computer world they're just "too old to worry about."

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.

Don Lancaster (outside of Apple) did that. In fact, he ignored the Mac and connected a LaserWriter directly to his Apple II, and programmed in straight PostScript. Used that language the rest of his life. All the PDFs on his site were hand-crafted.

I don't know enough music to tell if this is insightful, or just neat pattern-matching.

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

One of the first CP/M C's was BDS-C. It's claim to fame was that it compiled the source in-memory, so it was at least that part was nice and fast.

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.

As other commenters have said, C didn't actually generate fast programs for 8-bit processors, or even 16-bit processors for a long time. C is a poor fit for most of them, so assembly language was the only way to go.

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.