Redkey

Could someone expand a little on this statement, or point me toward an applicable resource? How do "real" (modern?) CPUs prevent unwanted recursion? As in, not the compiler or the OS, but the CPU itself? I've been searching for a while now but I haven't found anything that clears this up for me.

TL;DR: The clock oscillator for the sound chip (separate from the main CPU clock, which does not have this issue) appears to be speeding up over time as it ages. Games from that era use video signal synchronization to regulate their overall speed, so this will not affect game times. It may cause audio glitches or crashes, but it won't make games run faster. However, it has the potential to cause (and probably has caused) desynchronization issues with tool-assisted speedruns on original hardware.

(I looked into this a bit for another post of this same article.)

AFAIK the overall execution speed of the old consoles was always intimately tied to the video refresh rate, not audio. I don't have much experience programming the SNES specifically, but from what I do know about it and my experience with other retro consoles, I don't imagine that the sound processor running ever so slightly faster will change the speed of the game overall. Not even to the degree of "less than one second over an entire playthrough" as suggested by the article.

If the oscillator goes far enough out of spec, it may lead to audio glitches and possibly even complete crashes, but I doubt that many games -- frankly, any games at all -- are busy-waiting on the sound processor as their main way of keeping time.

...

OK, I just took a short break. I've done a little reading about the potential issue from first sources, and brushed up on the SNES hardware. To reiterate, I still don't believe that any game will run even one frame faster due to this issue. However, what does seem to be at stake is tool-assisted spreedruns on original hardware. If this oscillator speeds up just a little, but not enough to cause software issues, there's a chance that controller inputs may be read slightly earlier than otherwise expected (due to the slightly faster audio system finishing earlier), potentially causing a desynchronization with sub-frame accurate hardware input tools, meaning that a TAS may run correctly on one console but not another.

While this is an important issue in the TAS community, I don't see how this could result in an otherwise "correct" run finishing even one frame faster, as the inputs will still only be read by the game once (or however many times the game normally reads them) per field ("frame"), and the game will still be using the video vertical blank for main timing.

Seconding Markor for Android. I originally installed it because I was sick of all the note-taking apps that store your notes away in hidden directories and proprietary formats. I've been using it for years and it's not let me down yet.

A great stealth/adventure game. It's a pity that only one of the three was localized into English.

Icons that are based on English puns and wordplay are easily understood by speakers of other languages.

This reminded me of one of those Top Gear "drive across a foreign country in weird vehicles" specials where Jeremy Clarkson needed to borrow a cable to jump-start his car, and laboriously mimed out jumping for "jump", and walking a dog for "lead", to a perplexed local. Richard Hammond was cracking up but finally managed to point out what a fool Clarkson was being.

Geolocation is an accurate way to predict the user’s language.

And as an addendum to this, in 2025 nobody should be using Windows' "Non-latin/-unicode character set" setting to guess the user's preferred language. That's a pre-WinXP kludge. I'm specifically looking at you, Intel integrated graphics software writers, but you have plenty of company, don't worry.

Why be like that? Whether you think their position is silly or not, this person obviously gets called out on this a lot. And rather than pitch a fit over being needled about it for the umpteenth time, they responded with links that ought to satisfy any genuine curiosity. Considering the times I've seen an empty "Go educate yourself!" as a response from petulant children, I'd say buddy did us a solid. They don't owe us a personalized response.

Some of my favourite slow-burn adventures that no one's mentioned yet:

• Project Zero/Fatal Frame (1, 2, and 3)
• Shadow of Memories/Shadow of Destiny
• Echo Night: Beyond
• Zettai Zetsumei Toshi 1 and 2 (a.k.a. S.O.S. The Final Escape/Disaster Report, and Raw Danger)
• Killer7
• Siren (1 and 2)
• Chulip

And some action-adventure-RPGs that have a place in my heart but aren't generally considered to be anything special:

• EverGrace (there's also a sequel which I haven't played yet)
• Eternal Ring

Yep, surveillance_records.person_id is the same as surveillance_records.id, which is incorrect. I looked at the Github repo and there's already a report for it.

What I don't understand (and apparently this is my problem, not a bug) is how we're supposed to narrow the list down to three suspects in the next-to-last step, as the "Case Solved" text describes (Yeah, I cheated). The interviews with the two witnesses give a partial hotel name and a check-in date, but that returns dozens of results. The ending messsge congratulates us for reducing that list by using the surveillance records in some way, but I can't see how. The only other detail I have is "The guy looked nervous", which doesn't seem to have any connection with the surveillance records.

Sure, but as far as I'm aware, no other large group of LISP users exists. My contention isn't that most AI researchers use LISP now, but that most LISP programmers are (were?) AI researchers.

I've been trying to learn about early AI work, and I'm finding that to get any practical details you're almost guaranteed to have to wade through LISP code, although at least it's usually pretty well commented.

LISP: You are an AI researcher and a nerd.

Very similar variants of the same CPU and VDU were used in the Colecovision, the MSX, and Sega's early systems, among others.

I've also read that there were several ports from the ZX Spectrum to the MSX, due to them sharing essentially the same CPU at the same clock speed, and the MSX VDU having a video mode that could operate similarly to the Spectrum's display.