The Infinite Loop That Wasn't (2020) | Hacker News Reader

The Infinite Loop That Wasn't (2020)

mgba.io

136 pointstosh14 comments

Hyrum's law[0] seems appropriate here:

  With a sufficient number of users of an API,
  it does not matter what you promise in the contract:
  all observable behaviors of your system
  will be depended on by somebody.

Except the API here is the behaviour of the hardware.

[0] https://www.hyrumslaw.com/

Relevant xkcd: https://xkcd.com/1172/

Googling the xkcd also led me to this: https://github.com/dwmkerr/hacker-laws/

No discussion of infinite loops that aren't would be complete without a mention of The Story of Mel: http://www.catb.org/jargon/html/story-of-mel.html

Thank you! I've been hunting for this story for years.

The story was featured on the YouTube channel "Computerphile".

https://youtu.be/XS3UBuZ7D34

This is an amazing read. I too was looking for this for a while.

I read it when I was a kid (11/12)... along with Real Programmers Don't Use Pascal. I was chiefly impressed by both, for quite some time I thought both of the them were real and represented real(!) values. To this day I can quote quite a bit of both.

> both of the them were real …

Well, Mel's story is definitely real!

"The manual for the LGP-30 refers to “Mel Kaye of Royal McBee who did the bulk of the programming...” "

Indeed, Mel is (was?) real and we have a photo of him! If we go to Wikipedia for the LGP-30[0], it links to a wiki article on "The Story of Mel"[1] which names the titular "Mel" as "Melvin Kaye" with a citation, linking to a PDF scan[3] of an issue of "The Librazette" where on the first page, the photo on the left, in the very back and named last of all the people in the photo, is [sic]"Royal-McBee Applications Engineer Mel Kaye" standing and smiling in an all-white shirt.

[0] - https://en.wikipedia.org/wiki/LGP-30

[1] - https://en.wikipedia.org/wiki/The_Story_of_Mel

[2] - https://en.wikipedia.org/wiki/The_Story_of_Mel#cite_note-Lib...

[3] - https://www.librascopememories.com/Librascope_Memories/1950_...

The Commodore 64 has a similar "feature". It has a separate 4-bit per address * 1k "nibble" ram chip for the screen color attributes. The processor and data bus are 8 bits wide. When the processor reads from color ram the low 4 bits come from the color ram chip but the hi 4 bits are disconnected. The returned results look a bit random but are actually whatever data was put on the bus the previous clock cycle.

Well, the OSDev Wiki’s discussion of RAM detection on x86[1] still mentions the issue of bus capacitance in its discussion of memory probing (while exhorting you not to attempt memory probing). The text is likely old, but probably not C64 old. Pentium-era old maybe?

[1] https://wiki.osdev.org/Detecting_Memory_(x86)#Practical_obst... and https://wiki.osdev.org/Detecting_Memory_(x86)#Manual_Probing...

Discussed at the time:

The Infinite Loop That Wasn't - https://news.ycombinator.com/item?id=22151036 - Jan 2020 (35 comments)

tl;dr: DMA + bus float. I'm undecided whether this was a deliberate anti-emulation technique, or a clever trick to sync CPU execution with the DMA position. I remember seeing a similar type of thing in the protection of a very old PC game.

Reply on news.ycombinator.com