Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PlayStation Architecture

copetti.org

Post reply on HN
Print view View original

41–50 of 71 posts

Re: PlayStation Architecture

#41

Post by ahartmetz »

babypuncher wrote: post #32
Narishma wrote: post #13

Earlier quoted context omitted.

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.

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.

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".

Re: PlayStation Architecture

#42

Post by ahartmetz »

RiverCrochet wrote: post #40
Dwedit wrote: post #25

Earlier quoted context omitted.

I had the N64. It did not wobble. Seeing a Playstation in action with its wobble was so weird.

N64 didn't have the wobble, but it definitely had the blur.

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.

Re: PlayStation Architecture

#43

Post by corysama »

whizzter wrote: post #34
boricj wrote: post #29

Earlier quoted context omitted.

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…

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.

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.

Re: PlayStation Architecture

#44

Post by malkia »

boricj wrote: post #37
whizzter wrote: post #34

Earlier quoted context omitted.

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.

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).

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!

Re: PlayStation Architecture

#45

Post by lowbloodsugar »

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.

Re: PlayStation Architecture

#46

Post by HerbManic »

whizzter wrote: post #35
Narishma wrote: post #13

Earlier quoted context omitted.

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.

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…

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.

Re: PlayStation Architecture

#47

Post by HerbManic »

ahartmetz wrote: post #42
RiverCrochet wrote: post #40

Earlier quoted context omitted.

N64 didn't have the wobble, but it definitely had the blur.

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 .

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.

Re: PlayStation Architecture

#48

Post by joe91 »

lowbloodsugar wrote: post #45

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.

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).

Re: PlayStation Architecture

#49

Post by zero_shift »

malkia wrote: post #27

There are memory regions that are mapped to the same physical memory - https://psx-spx.consoledev.net/memorymap/ 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)…

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.

Re: PlayStation Architecture

#50

Post by rasz »

malkia wrote: post #27

There are memory regions that are mapped to the same physical memory - https://psx-spx.consoledev.net/memorymap/ 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)…

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).

Post reply on HN