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.

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.

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.

You’re kind of arguing against yourself, here. If the point is to impose limitations in order to reduce choice exhaustion and foster creativity, then portable software like PICO-8 can do that just as well as a physical device, and creators will have a much larger potential audience.

I’ve often daydreamed (I’m sure I’m not alone) of making various kinds of electronic entertainment devices with very low specs as a challenge/creativity booster to myself and other creators. But I always come back to the realization that it makes much more sense, in a world where almost everyone has a powerful computing device with plenty of storage and a responsive colour display in their pocket, and constant Internet access, to implement them as software rather than hardware.

A handful of people may be excited enough by the physicality of a device like this that they’ll buy it, but many more people will pass it by. Look at the proliferation of games for software-based formats like PICO-8, Bitsy, Inform, and Twine, compared to development on purely physical “low spec” devices like the PlayDate. Even real vintage systems are starting to become software-based formats; new games developed for them these days will often include an “emulator-friendly” version if they do anything particularly tricky with the original hardware.

One of my favorites. I’m so glad that I played it without any guides, so I could find all the little touches on my own.

Also, if you’ve got the time (or a cheat device), it’s mildly amusing to grind to the maximum level so you can virtually one-shot the final god-like boss after all its posturing.

I did jump through the hoops necessary play this, years ago, although I can’t remember why. It was probably due to reading an article much like this one.

Honestly, while I think it’s important to make a note that this game existed, I also think some people overreach a bit on just how influential it was. I wouldn’t say that anyone needs to play it these days unless they really want to. Just look up a few screenshots; it plays almost exactly how it looks like it plays.

deleted by creator

We’d better keep an eye out for them in the future.

What ShinkanTrain said. The last a read about it, the PS2 only switches into PS1 mode on a trigger from the optical drive subsystem, and then most of the memory and other hardware used to run homebrew is deactivated. AFAIK no-one’s yet found a way to trigger the change in software and keep the connection to wherever you’re loading your game from.

I believe that on certain revisions of the console, MechaPwn can overcome the protection, but you still need a “Playstation 1” CD in the drive to actually run something, as ShinkanTrain wrote.

Probably because it’s pretty slow, and the custom drive format used by the PS2 isn’t very flexible; game images have to be in one continuous block, and blocks can’t be moved. You can overwrite one game with another, but only if it’s the same size or smaller. So if you delete games off in the reverse of the order you put them on you’re fine, but otherwise you’re going to leave empty “holes” of wasted space.

Having tried both a USB3 drive adapter and downloading over Ethernet, I’ll say that Ethernet was way slower for me.

The average copy time on the adapter was about 30 minutes, but over Ethernet it took 3-4 times as long.

I have a 2TB SATA HDD in my PS2 fat. AFAIK that’s still the maximum storage size possible with the FMCB/wLaunchELF software. I believe that an unmodded original network adapter should be able to take up to a 512MB IDE drive, but I’d have to double-check that.

I used to use a third-party “network adapter” (they usually don’t have Ethernet, just an HDD connector) with SATA support, which still works fine (it seems like most brands stopped working properly after a certain homebrew software version), but later I bought an official adapter (IDE/PATA) and a SATA conversion kit (a kit specific to the PS2 network adapter, not a standard IDE-SATA converter, which sometimes work with the PS2 and sometimes don’t) so I could try network stuff.

I don’t think it was worth it, but these days it’s probably the way to go since there no longer seems to be any way of telling the non-working aftermarket adaptors from the working ones; the companies making the bad ones just started putting the brand name of the one still working adapter on their products.

If you have a relatively powerful computer or phone, and your library only contains games from the console’s top 100 or so, you’re probably right.

You can run games directly over Ethernet, which I believe can run at close to full speed. Some people have made dedicated little server devices for this out of cheap single-board computers like a Raspberry Pi; I think one guy may even have been selling a finished product like this for a while.

And to be really picky, the first version of the slim actually has IDE HDD support onboard like the original network adapter, just no physical connector (you have to solder one on yourself).