[boricj]

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]

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]

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]

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]

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]

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.

[1] https://psx-spx.consoledev.net/memorycontrol/#1f801060h-ram_...

[jbreckmckye]

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

[boricj]

If you want a good horror bedtime story, you can peek at OpenBIOS within the pcsx-redux tree: https://github.com/grumpycoders/pcsx-redux/tree/main/src/mip...

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]

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]

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!