PlayStation Architecture (opens in new tab)

They hold up pretty well when you play them as they were originally supposed to: on a CRT if you can or using emulators' CRT filters if you can't. Trying to play them at very high resolutions on crisp LCD displays is the worst way to go IMO.

> PS1 games do not hold up so good

Eeh ... speak for yourself. PS1 did mark the dawn of the 3D era for home consoles. There are lots of people who are into the low poly 3D models with the characteristic PS1 "wobble".

Sure a lot of it may be nostalgia but it does have its charm and I can say it's grown a lot on me over time. Especially once I learned about the PS1's unique hardware limitations. If my social media feed is anything to go by "PS1 graphics" are having a bit of a revival with lots of people trying to recreate that look.

It is quite amazing to me to see the specs and what developers managed to squeeze out of that!

Graphically, either play on a CRT (or with CRT filters) or use an emulator that has PGXP geometry correction to eliminate vertex jittering at higher rendering resolutions.

As for gameplay, that console has a massive library, with thousands of commercially released games (and a lot of hidden gems). I'd be surprised if any gamer wouldn't find at least one to their taste in that catalog.

The 2D ones (e.g. Symphony of the Night) do.

This is also how the memory card bootloader works.

There is a faulty array iterator in the BIOS code that can copy arbitrary data to locations higher up in the memory map than the base pointer. Normally that wouldn't let you overwrite any executable code because the base pointer is very high up (might be a stack pointer?). But because of the memory aliasing, if you set the right value the write "wraps around" and lets you clobber the BIOS.

This means you can boot a custom BIOS, effectively, by just going into the memory card screen. From there you can execute a PSX.EXE without going through the mechacon checks, bypassing copy protection

---

I wouldn't mind learning more about the MGS port. Do you remember much about it?

It uses TCL for most of the scripting, IIRC. In fact I think MGS 1-4 use the same lineage of scripting languages.

MGS2 source code was leaked recently, but my guess would be that was a complete rewrite and shared very little from the PSX codebase.

Usually, that kind of stunt nowadays is done by using the lowest significant bits and masking them off when dereferencing the pointer, trading off for a higher alignment (so 4 bits gives you 16-byte alignment).

The PS1 also happens to have RAM aliasing, because there's not enough RAM to cover the entire decoding window for the RAM. I don't know the details, but I've seen PS1 executables setting their stack pointer to the end of the devkit's 8 MiB of RAM and yet they work on retail units, because it ends up at the end of the retail's 2 MiB of RAM. So theoretically, you could stuff bits in there too (and without messing with different memory regions with different cache behaviors).

Interesting! Trying to find that particular code in the decompiled code is proving challenging. I wonder if they haven't yet discovered and documented that yet!

https://github.com/FoxdieTeam/mgs_reversing/blob/master/sour...

Nowadays this stuff is standardized by hardware extensions.

Arm Top Byte Ignore (TBI), Intel Linear-Address Masking (LAM) and its fixed version Linear Address Space Separation (LASS), AMD Upper Address Ignore (UAI) still unsecure from SLAM exploits. Then you have security extensions build on top of this like ARM Memory Tagging Extension (MTE).

Early Macs used the upper byte of 32-bit pointers for other data:

https://en.wikipedia.org/wiki/Classic_Mac_OS_memory_manageme...

...and resulted in some models having a backwards-compatibility mode not too dissimilar to the PC's A20 gate, although for only a short period of time.

Copetti enjoyers should also checkout everything Fabien Sanglard has done, including the Wolfenstein and Doom Black Books, the Another World port analyses, and the other dozens of code reviews he's posted. https://fabiensanglard.net/

1994 always gets me too. It feels like they are more a late 90s thing.

It’s been updated many times since then!

So? That was 5-7 years ago. I haven't seen this before, so I appreciate it being posted :)

Another weird corner case is that COP2 (GTE) instructions actually start executing one instruction early with respect to where the program counter is. As a result when an exception happens the kernel interrupt handler checks to see if the next instruction is COP2 and has to add 4 to the program counter in order to not execute it twice.

Also COP2 instructions were not allowed in branch delay slots (presumably for similar reasons), however some games (from memory Tekken3) do actually do this. I always wondered if it was a sneaky anti-emulation thing :) (because many emulators had issues with this, or needed special handling).

It does. The SPU only handles decoding and playback of ADPCM samples from its own memory and receives all CD audio from an I2S bus; the CD-ROM sector decoder chip handles XA-ADPCM decoding and resampling to 44.1 KHz internally, then sends the audio over I2S as if it were CD-DA. This is also why the SPU's ADPCM format is slightly different from XA-ADPCM (no interleaving and 5 filter coefficient presets rather than just the 4 used by XA-ADPCM and the older ADPCM format used on the SNES).