I worked on the Metal Gear Solid port from PSX to PC, and Konami programmers chose a wild trick to store how the "C4" bomb was planted - either on the wall, or on the ground.
Essentially the pointer pointed to the same physical memory address, but if it was planted on the wall (or on the ground, I forgot) - then it was OR-ing it with 80000000h or was A0000000h - or maybe something else - lol was long time ago.
It was fun porting this on PC, and right now I don't even remember what I did exactly - hahaha
jbreckmckye 11 days ago [-]
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.
boricj 11 days ago [-]
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).
whizzter 11 days ago [-]
You can see this on many consoles, iirc it basically just boils down to some address pins not being connected anywhere, so whatever the pins are set to doesn't matter as they're just out in the air so to say.
kalleboo 11 days ago [-]
This was also done on the original Macintosh. The Motorola 68000 was a 32-bit CPU but only supported a 24-bit address bus, so the top bits were used by the OS as flags.
Then they released a new Mac with a 68020 that supported a 32-bit address bus and there was a multi-year process of making the OS and all the software "32-bit clean" to take advantage of it. There were 68020 Macs where the ROM in the machine itself wasn't even 32-bit clean and needed a software patch on boot.
corysama 11 days ago [-]
Then there’s the opposite situation. I knew the guys who ported NBA Jam: TE from arcade to PC (by hand-translating assembly!). Apparently the arcade CPU had bitwise addressing. And, because pretty much all of the data was aligned to bytes, the arcade programmers liked to stuff 3 bits of extra parameter data into the low bits of pointers.
knome 11 days ago [-]
it's not uncommon for runtimes to use always-zero bits from aligned pointers or bits above 48 (unused in most current 64bit CPUs) to store flags today. you don't need special 'bit-addressing' to do it. byte addressing works just fine.
spicyjpeg 11 days ago [-]
On the PS1 it's actually slightly more complex than that. The CPU does support up to 16 MB of main RAM (development kits and PS1-based arcade systems did come fitted with more than 2 MB) and has a register to configure its geometry, with the CPU automatically generating an exception when attempting to access unmapped memory. However, Sony's BIOS made the mistake of initializing said register to 8 MB (the configuration used by dev boards) even on retail hardware, resulting in the 2 MB region being mirrored four times. Development builds of games typically assumed 8 MB and put the stack at 0x80800000, so the accidental mirroring made that setup work on retail hardware too (at least as long as the stack did not collide with the heap) even if the developer forgot to move the stack down in the final build.
The PSX BIOS code sounds like a disaster. Everything I read about the software part of the stack, makes me amazed the console even boots
The faulty malloc. A bunch of random qsort implementations. Reiji Asakura wrote an account of how the BIOS and kernel were developed, and it sounds so amateurish
Then there's the way the JP console checks for faulty ECCs on sectors 0..15, not as a clever anti piracy check, but because the CDU-920 broke CD-XA authoring...
The commentary section starts with "The retail PlayStation BIOS code is a constellation of bugs and bad design." and it gets worse after that. There are hidden gems inside the source code comments of that simili-reconstruction.
boricj 11 days ago [-]
You could do that on PC too, if you mmap() one given block of memory at multiple locations. I think that's how PS1 emulators handle mirroring (it's been a long time since I took a peek at the innards of DuckStation).
malkia 11 days ago [-]
ha! I wish I knew this back then, but now I do remember - I think what we did was simply clearing the bit before access, and it was in just dozen or so places. Slap a macro and you are done!
foldor 10 days ago [-]
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!
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).
userbinator 11 days ago [-]
Early Macs used the upper byte of 32-bit pointers for other data:
...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.
So? That was 5-7 years ago. I haven't seen this before, so I appreciate it being posted :)
MrDOS 11 days ago [-]
Yep! Just that the post title should have a (2019) in it. Or maybe (2021) or (2025), given the most recent revision dates.
kthartic 11 days ago [-]
Fair enough!
giancarlostoro 11 days ago [-]
Not only that, for a device from 1995... It's still amazing to learn about this, its not as if most people will read this once, and remember everything on the page in one go.
mrandish 11 days ago [-]
Check out the rest of Copetti's site. He's got similar posts on almost all the other consoles. So much gold.
Forgeties79 12 days ago [-]
Love Copetti. Even as someone who is not particularly knowledgeable of everything he’s talking about, I I really enjoy thumbing through his writing and diagrams. There’s just something really fun about trying to understand what is going on under the hood with these machines, especially fifth and sixth generation consoles
rideontime 11 days ago [-]
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/
dnnddidiej 12 days ago [-]
1994 always gets me too. It feels like they are more a late 90s thing.
tapoxi 12 days ago [-]
They didn't launch outside of Japan until late 1995, so most people got one in '96.
kaycebasques 12 days ago [-]
Which means that we're really talking about hardware from 91-93, right? I.e. if launch was 94 then they were designing in 91-93ish.
doubled112 12 days ago [-]
PS2 didn't come out until 2000. Most of the games I remember are from later too.
lowbloodsugar 11 days ago [-]
Executing the instruction after the jump seemed mental, but after a few days it was second nature. N64 had related issue: had to find an instruction to put between two multiplies. If the first multiple multiplied by zero or otherwise finished in two cycles, the CPU would freeze if the next instruction was also a multiply.
joe91 11 days ago [-]
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).
adamddev1 11 days ago [-]
What a beautifully designed website. Everything is thoughtfully set-up and well placed. A great example of a well curated digital garden. It feels well kept and very human crafted.
Scroll_Swe 12 days ago [-]
These articles are always excellent.
PS1 games do not hold up so good, but PS2 games uprezzed to 1440p-4k are basically perfect imo.
Narishma 11 days ago [-]
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.
hmry 11 days ago [-]
It's interesting how different it is from the N64, which was seemingly designed to produce perfectly correct pixels even though no player would own displays that could really show the difference. I guess that's what you get when you let SGI design the GPU.
whizzter 11 days ago [-]
It probably had to do more with the evolution of chipset manufacturing and transistor counts (and costs).
The ps1 was released 1.5 years before the N64, the 3dfx voodoo chip is as capable as the n64 (maybe more so considering memory available), but I guess both Nintendo and Sony did opt for a bit more cost-efficient designs to make a profit on their consoles.
Looking at the release dates, the progression of capability is quite matched.
1994 dec 3 ps1
1995 nov 6 3dfx voodoo
1996 jun 23 n64
1998 nov 27 dc
2000 mar 4 ps2
patmorgan23 11 days ago [-]
Yeah, any 8/16-bit pixel are t wasn't made to be viewed on a screen with that high a resolution. CRTs smoosh/blur the image a bit so you don't see all the hardlines.
whizzter 11 days ago [-]
The PS1 didn't even have perpsective corrected texture mapping, some titles handled that manually to make it look less shit but not all titles did so.
The evolution of graphics was brutal in the 90s and early 00s, but somewhere around the PS3's appearance it slowed down since lighting models were becoming "good enough" on the PS3 for not being annoyingly bad and asset creation costs became the limiting factor rather than hardware.
HerbManic 11 days ago [-]
John Carmack once said something like, if you cannot get your game out with the vision you want on a PS3/360 then you are doing something wrong.
That isnt to say that technology hasn't improved (duh!) Just that at that point there was enough grunt and memory that you could approximate what you want without massive compromise.
I still think this is true. But we will take the extra capabilities while we are here.
aidenn0 11 days ago [-]
I own a CRT and several playstation games. Many (most?) of the 3D games don't hold up that well. The aliasing artifacts are still quite visible and many games have occlusion bugs that TFA alludes to.
stuxnet79 11 days ago [-]
> 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
On the emulator side I would definitely recommend Duckstation. It's performant, has great UI / UX and also has a CRT filter available by default that more or less recreates the original look, even slightly warping the image to make you feel like you are staring into a TV tube.
babypuncher 11 days ago [-]
What I find truly ironic is how CRT shaders work best on a 4k display with good HDR performance.
4k lets you scale the image and insert scanlines without scaling artifacts and with enough extra pixels to make the scanlines feel properly soft.
HDR lets the shader compensate for the brightness lost to the CRT filter without desaturating the color.
mrandish 11 days ago [-]
Fully reproducing the motion clarity of a CRT on a modern display also requires 480hz.
While HDR is used to reproduce micro-patterns in brightness in such a configuration, I think CRTs would have been capable of HDR with appropriate control electronics since HDR requirements are basically: pixels can individually be set to very close to black and also to "pretty bright".
mrandish 11 days ago [-]
> I think CRTs would have been capable of HDR
Very likely. CRT technology from phosphors to screen masks to deflection yokes were highly-evolved but there was still a lot of headroom for more performance and new innovation. Some CRT tubes where capable of driving much higher brightness than their controllers ever allowed.
It's unfortunate that CRT manufacturing wound down entirely after ~2010. While the size, weight and huge glass volumes where impractical for mass-market consumer media devices, CRTs also had unique capabilities modern display tech still can't match. With all the current interest in retro CRTs, I actually looked into what it would take to do small runs of ultra high-end HD CRTs for collectors, almost on an artisanal boutique basis. Unfortunately, it looks like the upstream manufacturing chain of many component elements also collapsed because there were no other applications for them. So, the start-up costs to make the first one would be pretty huge.
babypuncher 10 days ago [-]
I would buy a brand new CRT from a boutique manufacturer, even for a pretty absurd price. Whether enough people would is a tough question to answer though.
pezezin 11 days ago [-]
Nah, I was there a million years ago, and I always thought the PSX looked like crap compared to PC games of the era with their wobbly polygons and warping textures. And that is assuming that you were using SCART with a clean RGB signal, composite was even worse.
stuxnet79 11 days ago [-]
> 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.
Dwedit 11 days ago [-]
I had the N64. It did not wobble. Seeing a Playstation in action with its wobble was so weird.
RiverCrochet 11 days ago [-]
N64 didn't have the wobble, but it definitely had the blur.
ahartmetz 11 days ago [-]
Reportedly, the only location to store textures for quick GPU read access was a whole 4 KB in size. What an, apparently, dumb mistake. The blur was bad.
HerbManic 11 days ago [-]
Yeah that 4KB also had to hold the MIP maps as well, effectively halving that down to 2KB for the full size and then 2KB for all the down scaled pieces.
Ps1 also only had a 4KB cache but it could also dynamically manage it for larger textures but that came with a large performance penalty.
The blur on N64 was a combination of that and small cartridge size. It graphics setup did have some advantages, look at Mario 64 for example. The hills in the distance are usually just a few polygons with some low resolution textures stretched over them. The filtering and perspective correction means it is a very consistent image, you would not be able to do that on PS1 without it becoming a visual mess.
PS1 affine rendering was fast but limited, which for the release window was good enough.
Scroll_Swe 10 days ago [-]
I'm 35, I know, I was there.
>o by "PS1 graphics" are having a bit of a revival with lots of people trying to recreate that look.
Yea I like it too I'm not saying it is bad :)
Also I do hate these cringe zoomers.
thenthenthen 11 days ago [-]
It is quite amazing to me to see the specs and what developers managed to squeeze out of that!
stuxnet79 11 days ago [-]
Yes an entire generation of games running on a mere 2MB of RAM and 1MB of VRAM.
The crazy thing too was how much a step up PS2 was compared to PS1 in terms of available compute and sheer horsepower. But even that wasn't enough for a sandbox game like GTA 3 to run without a lot of clever tricks [1]
Interesting video, we also made a PS2 game with streaming and fragmentation was definetly the worst part (as we also used Renderware) and funnily enough iirc the release version also had a built-in defragmentation system to move memory around (an annoying thing to do in C++ projects that weren't prepared for that from the start).
Scroll_Swe 10 days ago [-]
And now all devs know is UE5, slap on DLSS and done.
I see 0 difference in graphics 2016-2026
boricj 11 days ago [-]
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.
a-french-anon 11 days ago [-]
The 2D ones (e.g. Symphony of the Night) do.
matheusmoreira 11 days ago [-]
Love the 2D games of the PS1 era. I still replay Mega Man X4/5/6 every once in a while.
gregsadetsky 11 days ago [-]
Hey all, I posted this as I'm currently working on a PS1-related project that I hope to release soon.
Does anyone have recommendations for a PS1 web/js/wasm emulator? PCSX-Redux [0] has been great on desktop, and DuckStation [1] as well.
I found a few js/emscripten efforts, but if anyone has a rec, I'd appreciate it. Thanks!
Did read this years ago and read it today again. Just so happy that there are people producing such quality work. Even if I personally don't know much about any of it, I still find myself being totally sucked in while reading.
suprjami 11 days ago [-]
The architecture which made me fall in love with RISC (or "load-store" if you prefer) and see the error of my ways with x86 (insert your derogatory term here).
busfahrer 11 days ago [-]
The PS1 architecture is fascinating - it will also reveal why PS1 games have such a unique, recognizable style that games are trying to recreate nowadays.
aidenn0 11 days ago [-]
Why did I think the XA decompression happened in the CD-ROM unit rather than the SPU?
spicyjpeg 11 days ago [-]
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).
0x1ceb00da 11 days ago [-]
They should start teaching about plash speed routers in schools.
helf 12 days ago [-]
I love his work. I bought one of his books recently :)
I worked on the Metal Gear Solid port from PSX to PC, and Konami programmers chose a wild trick to store how the "C4" bomb was planted - either on the wall, or on the ground.
Essentially the pointer pointed to the same physical memory address, but if it was planted on the wall (or on the ground, I forgot) - then it was OR-ing it with 80000000h or was A0000000h - or maybe something else - lol was long time ago.
It was fun porting this on PC, and right now I don't even remember what I did exactly - hahaha
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.
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).
Then they released a new Mac with a 68020 that supported a 32-bit address bus and there was a multi-year process of making the OS and all the software "32-bit clean" to take advantage of it. There were 68020 Macs where the ROM in the machine itself wasn't even 32-bit clean and needed a software patch on boot.
[1] https://psx-spx.consoledev.net/memorycontrol/#1f801060h-ram_...
The faulty malloc. A bunch of random qsort implementations. Reiji Asakura wrote an account of how the BIOS and kernel were developed, and it sounds so amateurish
Then there's the way the JP console checks for faulty ECCs on sectors 0..15, not as a clever anti piracy check, but because the CDU-920 broke CD-XA authoring...
The commentary section starts with "The retail PlayStation BIOS code is a constellation of bugs and bad design." and it gets worse after that. There are hidden gems inside the source code comments of that simili-reconstruction.
https://github.com/FoxdieTeam/mgs_reversing/blob/master/sour...
Look here - https://github.com/search?q=repo%3AFoxdieTeam%2Fmgs_reversin...
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).
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.
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).
PS1 games do not hold up so good, but PS2 games uprezzed to 1440p-4k are basically perfect imo.
The ps1 was released 1.5 years before the N64, the 3dfx voodoo chip is as capable as the n64 (maybe more so considering memory available), but I guess both Nintendo and Sony did opt for a bit more cost-efficient designs to make a profit on their consoles.
Looking at the release dates, the progression of capability is quite matched.
1994 dec 3 ps1 1995 nov 6 3dfx voodoo 1996 jun 23 n64 1998 nov 27 dc 2000 mar 4 ps2
The evolution of graphics was brutal in the 90s and early 00s, but somewhere around the PS3's appearance it slowed down since lighting models were becoming "good enough" on the PS3 for not being annoyingly bad and asset creation costs became the limiting factor rather than hardware.
That isnt to say that technology hasn't improved (duh!) Just that at that point there was enough grunt and memory that you could approximate what you want without massive compromise.
I still think this is true. But we will take the extra capabilities while we are here.
On the emulator side I would definitely recommend Duckstation. It's performant, has great UI / UX and also has a CRT filter available by default that more or less recreates the original look, even slightly warping the image to make you feel like you are staring into a TV tube.
4k lets you scale the image and insert scanlines without scaling artifacts and with enough extra pixels to make the scanlines feel properly soft.
HDR lets the shader compensate for the brightness lost to the CRT filter without desaturating the color.
(https://blurbusters.com/crt-simulation-in-a-gpu-shader-looks...)
Very likely. CRT technology from phosphors to screen masks to deflection yokes were highly-evolved but there was still a lot of headroom for more performance and new innovation. Some CRT tubes where capable of driving much higher brightness than their controllers ever allowed.
It's unfortunate that CRT manufacturing wound down entirely after ~2010. While the size, weight and huge glass volumes where impractical for mass-market consumer media devices, CRTs also had unique capabilities modern display tech still can't match. With all the current interest in retro CRTs, I actually looked into what it would take to do small runs of ultra high-end HD CRTs for collectors, almost on an artisanal boutique basis. Unfortunately, it looks like the upstream manufacturing chain of many component elements also collapsed because there were no other applications for them. So, the start-up costs to make the first one would be pretty huge.
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.
Ps1 also only had a 4KB cache but it could also dynamically manage it for larger textures but that came with a large performance penalty.
The blur on N64 was a combination of that and small cartridge size. It graphics setup did have some advantages, look at Mario 64 for example. The hills in the distance are usually just a few polygons with some low resolution textures stretched over them. The filtering and perspective correction means it is a very consistent image, you would not be able to do that on PS1 without it becoming a visual mess.
PS1 affine rendering was fast but limited, which for the release window was good enough.
>o by "PS1 graphics" are having a bit of a revival with lots of people trying to recreate that look.
Yea I like it too I'm not saying it is bad :)
Also I do hate these cringe zoomers.
The crazy thing too was how much a step up PS2 was compared to PS1 in terms of available compute and sheer horsepower. But even that wasn't enough for a sandbox game like GTA 3 to run without a lot of clever tricks [1]
[1] https://youtu.be/cIbCxbrBCys?si=cLMr4-7ubGD4fNWi
I see 0 difference in graphics 2016-2026
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.
Does anyone have recommendations for a PS1 web/js/wasm emulator? PCSX-Redux [0] has been great on desktop, and DuckStation [1] as well.
I found a few js/emscripten efforts, but if anyone has a rec, I'd appreciate it. Thanks!
[0] https://github.com/grumpycoders/pcsx-redux/
[1] https://duckstation.org/