Inspired by some recent reverse-engineering, here are some things I find wild by the original PlayStation GPU:

• VRAM is a flat 1024x512 16-bit image (555 + 1 bit alpha). You want more than just a framebuffer? Figure out yourself what goes where.
• Yes, that means you'll need to allocate two framebuffers and double-buffer everything yourself.
• Quads are common. No “triangles only” business here.
• Vertex coordinates are screen-space x/y integers. No floats or fixed-point. (I'm ignoring the GTE here, plus higher-level libraries.)
• Wait, where's z? There's no z. So there's no perspective correction. (This one is pretty famous)
• OK, so how do you give in subpixel coordinates? You don't. There's no AA after all.
• Texture coordinates (u/v) are uint8_t. There's no texture filtering either; everything is nearest-neighbor only.
• OK, so that means you can't have textures larger than 256x256 (pretty common in that era), but how do you give in the handle to the texture?
• You don't, it points directly to the 1024x512 VRAM. You manage yourself what goes where, remember?
• So can you an only have textures in the top-left 256x256? Hah, no, we give you a bit-packed “texture page” system that offsets all your u/v coordinates.
• Most textures are paletted to save VRAM (so instead of 555+1, your pixels now mean something like “two palette indexes”). Where does the palette live?
• Well, duh, that's a 256x1 (or 16x1, or whatever) area of VRAM too. The GPU does not care, you can use another texture's pixels as a palette if you feel like it.
• OK, so you said there's no z, how do you do z-buffering? You have a z-buffer, right… right?
• Yeah, sure, we're not cavemen. We have an “ordering table” that is your Z-buffer, drawn back-to-front. If you want 256 levels of Z, you just allocate an array of 256 linked-list pointers, and then you put your polygon into the one corresponding to the correct right Z.
• But, eh, what if my polygon is not completely flat in Z-space?
• Hello?
• Hello…?