6 ms·

I'm tinkering with a PlayStation homebrew (voxel space renderer) and development for fifth generation consoles has never been easier. Modern toolchains, progra

by boricj 2mo ago

I'm tinkering with a PlayStation homebrew (voxel space renderer) and development for fifth generation consoles has never been easier. Modern toolchains, programming languages, dev cartridges and libraries from the community makes all the difference. Outside of some niceties like ICE (gotta write that GDB stub for target hardware at some point), it's not that different from what you'd experience with modern embedded work.

dottjt 2mo ago
How did they do it back in the day? Was basically everything from the tooling etc. just created inhouse from scratch?
- RugnirViking 2mo ago
  https://www.retroreversing.com/playstation-2-development-hardware https://www.retroreversing.com/playstation-2-development-har...
- inigyou 2mo ago
  They had stuff, but it was all proprietary. The N64 was a stripped-down implementation of the technology used on (high-end) SGI graphics workstations of the time. SGI certainly had all the required tools.
  - inigyou 2mo ago
    The N64 SDK docs, if not the SDK itself, leaked at one point. I would expect that by now the whole thing has leaked long ago. Come to think of it, it must have, because the bit-perfect recompilation projects are using the exact compilers from the SDK.
    - monocasa 2mo ago
      Yeah, the full SDK leaked decades ago when the system was still economically relevant to Nintendo.
    - skelpmargyar 2mo ago
      You can buy CDs of the SGI SDK on ebay. Recompilation projects aren't bit perfect, only decomps. They use a recompiled version of the compilers for Linux so that they don't need to emulated with QEMU like they used to, though.
- doublerabbit 2mo ago
  Yeah, pretty much. They provide the devkit hardware, the specification technical documentation and the tool chain to compile the binary.
- Bad_CRC 2mo ago
  The Dreamcast dev kits came with CodeWarrior as an IDE iirc.
  - pjmlp 2mo ago
    Visual Studio surely, as they had a collaboration with Microsoft using Windows CE for the Dreamcast. https://jacobfilipp.com/MSJ/directx.html https://jacobfilipp.com/MSJ/directx.html "What happened to Windows CE on the SEGA Dreamcast?" https://www.youtube.com/watch?v=QKHSlBi5qok https://www.youtube.com/watch?v=QKHSlBi5qok "Making Dreams Come True - Sega's Katana!" https://www.youtube.com/watch?v=EIr9YnMgExA https://www.youtube.com/watch?v=EIr9YnMgExA Maybe it was for the Saturn and previous consoles?
- spicyjpeg 2mo ago
  The same way it's done now with current generation consoles: the manufacturer would provide you with SDKs and development hardware once you paid them a decent chunk of money and signed an NDA. Prior to the fifth generation it was common for the SDK to be just an assembler, debugger and register-level hardware documentation, leaving the implementation of a kernel and game engine up to the game developer. Sony however decided to provide a full C toolchain based on GCC as well as a set of very high level libraries that abstracted away basically all aspects of the PS1 [1], all the way up to implementing a ready-to-go 3D engine and MIDI sequencer. This was an unpopular move as the libraries were slow, inefficient and most game developers were used to having full control over the hardware, but it also allowed inexperienced devs to get started quickly (as proven by the thousands of low budget PS1 titles that used the high level APIs) and eventually contributed to the popularity of the console over its peers with worse tooling. Sony would eventually go on to release some slightly lower level documentation for certain aspects of the console as well as APIs that better mapped to how the hardware actually worked under the hood. It wasn't however until years later that the hardware would be fully reverse engineered at the register level [2], and it took even longer for most homebrew to move away from the official SDK (which only really started happening a few years ago as accurate emulators and homebrew SDKs started popping up). [1] https://psx.schnappy.xyz/sdk/Psy-Q/DOCS/LibOver47.pdf https://psx.schnappy.xyz/sdk/Psy-Q/DOCS/LibOver47.pdf [2] https://psx-spx.consoledev.net/ https://psx-spx.consoledev.net/
  - actionfromafar 2mo ago
    Crazy then that the Bleem and Bleemcast emulator were so early!
    - inigyou 2mo ago
      It may actually be helpful to emulation. There's a technique called High-Level Emulation, where instead of emulating the hardware registers that are twiddled by the SDK function, you recognize the call to the SDK function itself and emulate the whole function in one go. This can provide a massive speedup over low-level emulation, but relies on the game primarily using the SDK. This was also used to emulate the N64 on Windows 95.
shoobiedoo 2mo ago
There is something so charming about the N64/PS1 era. They were so unique in their own right and you could tell at a passing glance which system was displaying on the screen even if you didn't know what game it was. Two radically different systems at the dawning of 3D console games. I bought a MiSTer for me and my son and we played the heck out of Mario Kart 64 and Mario Golf. I think he picked up my "gaming is dead now" outlook since he doesn't really have any interest in new systems or games anymore
- kevinminehart 2mo ago
  I love that. My wife and I are hopefully having kids soon and that's one thing I really want to encourage. Not to say that modern games aren't any good, but there's an increasing lack of respect for the player's time and wallet. The goal is shifting to maximizing value because they're getting more expensive to produce, but increasing the game price itself is a cardinal sin. Not to mention that live service games just out-earn non-service ones. I hope it works out. I can see it working in the reverse: I play n64/ps1/ps2/gamecube games with my kid, they go to school and their friends are playing fortnight or valorant, and then you become the bad guy for trying to be an obstacle in that.
  - inigyou 2mo ago
    Let your kid go over to their friend's house to play Fortnite or Valorant. And let your kid's friend come over to yours to play Mario Kart. I think as adults we get locked into a few things. I remember as a kid I would play anything I had access to and liked. Now it's more of one or two games at a time.
  - operation_moose 2mo ago
    One thing that's absolutely shocking is how "hard" it is to actually play games these days. Sit down with anything modern and between software updates, EULAs, load times, network congestion, etc. it can easily be 15-20 minutes before you actually do something; especially if you're an infrequent player. Pop in a game on N64/Gamecube and you're controlling the character within 10 seconds every time. The modern upgrades for those generations really make them great - the 8BitDo kit to make an N64 controller wireless, N64 Summercarts, replacing the optical drive in Gamecubes with a memory card reader...
spicyjpeg 2mo ago
I am still amazed my own minimalist PS1 tutorial series [1] became as popular as it did, given that prior to it basically all learning material on the internet was written around the decent-for-the-time-but-horrible-now Sony SDK and often based on 30-year-old example code full of 30-year-old C practices (in particular the complete disregard for aliasing and concurrency, which resulted in plenty of headaches once people started using those ancient libraries and example code with modern GCC). We even have bleeding-edge C++ SDK options [2] complete with an STL and coroutine support, so if anybody here wants to try their hand at PS1 homebrew development I would highly encourage checking out the modern tooling we have now. [1] https://github.com/spicyjpeg/ps1-bare-metal https://github.com/spicyjpeg/ps1-bare-metal [2] https://github.com/grumpycoders/pcsx-redux/tree/main/src/mips/psyqo https://github.com/grumpycoders/pcsx-redux/tree/main/src/mip...
- pjmlp 2mo ago
  To put this into perspective for youngsters, that horrible Sony SDK was considered a wonder for its time, and what kickstarted the movement away from Assembly into C for home console development, as main language. Until then, only arcades had already made the switch. On PS2, PS2Linux, Dreamcast there was already C++ support, by the way.
  - kridsdale1 2mo ago
    I’ve started to adapt my historic accounting of gaming away from hardware centric (console generations) and toward languages and compilers, and the force-multiplication they provided to developers which is tangibly evident in the products. Though these do correlate strongly with orders of magnitude of RAM being made available. - Physical logic gate era of gaming. - Assembly era - C era - OOP era - Interpreted languages and game logic living in scripts on top of c++ engines - Fully Gen-AI era?
    - ifjeicjwidj 2mo ago
      > Fully Gen-AI era? Yeah, no. Your historic accounting is not to be trusted by any means if “gen-AI era” is something that you really believe is happening.
yellowapple 2mo ago
I've been on-and-off writing a Zig library for writing N64 games and it's indeed pretty wild how getting working code was as simple as telling the compiler to use LLVM's MIPS III target. Of course, getting working code that actually does anything useful is a much different story (it's taking multiple days just to write the wrappers for RDP commands, for example; lots of cross-referencing between N64Brew wiki pages v. official SGI docs v. libdragon source code v. Peter Lemon's assembly code to figure out what all the different bitpacked fields really mean and how to best represent them), but it still feels magical that I can just use an ordinary toolchain and not some ancient proprietary monstrosity.

by boricj 2mo ago

dottjt 2mo ago

How did they do it back in the day? Was basically everything from the tooling etc. just created inhouse from scratch?

RugnirViking 2mo ago
https://www.retroreversing.com/playstation-2-development-hardware https://www.retroreversing.com/playstation-2-development-har...
inigyou 2mo ago
They had stuff, but it was all proprietary. The N64 was a stripped-down implementation of the technology used on (high-end) SGI graphics workstations of the time. SGI certainly had all the required tools.
- inigyou 2mo ago
  The N64 SDK docs, if not the SDK itself, leaked at one point. I would expect that by now the whole thing has leaked long ago. Come to think of it, it must have, because the bit-perfect recompilation projects are using the exact compilers from the SDK.
  - monocasa 2mo ago
    Yeah, the full SDK leaked decades ago when the system was still economically relevant to Nintendo.
  - skelpmargyar 2mo ago
    You can buy CDs of the SGI SDK on ebay. Recompilation projects aren't bit perfect, only decomps. They use a recompiled version of the compilers for Linux so that they don't need to emulated with QEMU like they used to, though.
doublerabbit 2mo ago
Yeah, pretty much. They provide the devkit hardware, the specification technical documentation and the tool chain to compile the binary.
Bad_CRC 2mo ago
The Dreamcast dev kits came with CodeWarrior as an IDE iirc.
- pjmlp 2mo ago
  Visual Studio surely, as they had a collaboration with Microsoft using Windows CE for the Dreamcast. https://jacobfilipp.com/MSJ/directx.html https://jacobfilipp.com/MSJ/directx.html "What happened to Windows CE on the SEGA Dreamcast?" https://www.youtube.com/watch?v=QKHSlBi5qok https://www.youtube.com/watch?v=QKHSlBi5qok "Making Dreams Come True - Sega's Katana!" https://www.youtube.com/watch?v=EIr9YnMgExA https://www.youtube.com/watch?v=EIr9YnMgExA Maybe it was for the Saturn and previous consoles?
spicyjpeg 2mo ago
The same way it's done now with current generation consoles: the manufacturer would provide you with SDKs and development hardware once you paid them a decent chunk of money and signed an NDA. Prior to the fifth generation it was common for the SDK to be just an assembler, debugger and register-level hardware documentation, leaving the implementation of a kernel and game engine up to the game developer. Sony however decided to provide a full C toolchain based on GCC as well as a set of very high level libraries that abstracted away basically all aspects of the PS1 [1], all the way up to implementing a ready-to-go 3D engine and MIDI sequencer. This was an unpopular move as the libraries were slow, inefficient and most game developers were used to having full control over the hardware, but it also allowed inexperienced devs to get started quickly (as proven by the thousands of low budget PS1 titles that used the high level APIs) and eventually contributed to the popularity of the console over its peers with worse tooling. Sony would eventually go on to release some slightly lower level documentation for certain aspects of the console as well as APIs that better mapped to how the hardware actually worked under the hood. It wasn't however until years later that the hardware would be fully reverse engineered at the register level [2], and it took even longer for most homebrew to move away from the official SDK (which only really started happening a few years ago as accurate emulators and homebrew SDKs started popping up). [1] https://psx.schnappy.xyz/sdk/Psy-Q/DOCS/LibOver47.pdf https://psx.schnappy.xyz/sdk/Psy-Q/DOCS/LibOver47.pdf [2] https://psx-spx.consoledev.net/ https://psx-spx.consoledev.net/
- actionfromafar 2mo ago
  Crazy then that the Bleem and Bleemcast emulator were so early!
  - inigyou 2mo ago
    It may actually be helpful to emulation. There's a technique called High-Level Emulation, where instead of emulating the hardware registers that are twiddled by the SDK function, you recognize the call to the SDK function itself and emulate the whole function in one go. This can provide a massive speedup over low-level emulation, but relies on the game primarily using the SDK. This was also used to emulate the N64 on Windows 95.

shoobiedoo 2mo ago

There is something so charming about the N64/PS1 era. They were so unique in their own right and you could tell at a passing glance which system was displaying on the screen even if you didn't know what game it was. Two radically different systems at the dawning of 3D console games. I bought a MiSTer for me and my son and we played the heck out of Mario Kart 64 and Mario Golf. I think he picked up my "gaming is dead now" outlook since he doesn't really have any interest in new systems or games anymore

kevinminehart 2mo ago
I love that. My wife and I are hopefully having kids soon and that's one thing I really want to encourage. Not to say that modern games aren't any good, but there's an increasing lack of respect for the player's time and wallet. The goal is shifting to maximizing value because they're getting more expensive to produce, but increasing the game price itself is a cardinal sin. Not to mention that live service games just out-earn non-service ones. I hope it works out. I can see it working in the reverse: I play n64/ps1/ps2/gamecube games with my kid, they go to school and their friends are playing fortnight or valorant, and then you become the bad guy for trying to be an obstacle in that.
- inigyou 2mo ago
  Let your kid go over to their friend's house to play Fortnite or Valorant. And let your kid's friend come over to yours to play Mario Kart. I think as adults we get locked into a few things. I remember as a kid I would play anything I had access to and liked. Now it's more of one or two games at a time.
- operation_moose 2mo ago
  One thing that's absolutely shocking is how "hard" it is to actually play games these days. Sit down with anything modern and between software updates, EULAs, load times, network congestion, etc. it can easily be 15-20 minutes before you actually do something; especially if you're an infrequent player. Pop in a game on N64/Gamecube and you're controlling the character within 10 seconds every time. The modern upgrades for those generations really make them great - the 8BitDo kit to make an N64 controller wireless, N64 Summercarts, replacing the optical drive in Gamecubes with a memory card reader...

spicyjpeg 2mo ago

I am still amazed my own minimalist PS1 tutorial series [1] became as popular as it did, given that prior to it basically all learning material on the internet was written around the decent-for-the-time-but-horrible-now Sony SDK and often based on 30-year-old example code full of 30-year-old C practices (in particular the complete disregard for aliasing and concurrency, which resulted in plenty of headaches once people started using those ancient libraries and example code with modern GCC). We even have bleeding-edge C++ SDK options [2] complete with an STL and coroutine support, so if anybody here wants to try their hand at PS1 homebrew development I would highly encourage checking out the modern tooling we have now. [1] https://github.com/spicyjpeg/ps1-bare-metal https://github.com/spicyjpeg/ps1-bare-metal [2] https://github.com/grumpycoders/pcsx-redux/tree/main/src/mips/psyqo https://github.com/grumpycoders/pcsx-redux/tree/main/src/mip...

pjmlp 2mo ago
To put this into perspective for youngsters, that horrible Sony SDK was considered a wonder for its time, and what kickstarted the movement away from Assembly into C for home console development, as main language. Until then, only arcades had already made the switch. On PS2, PS2Linux, Dreamcast there was already C++ support, by the way.
- kridsdale1 2mo ago
  I’ve started to adapt my historic accounting of gaming away from hardware centric (console generations) and toward languages and compilers, and the force-multiplication they provided to developers which is tangibly evident in the products. Though these do correlate strongly with orders of magnitude of RAM being made available. - Physical logic gate era of gaming. - Assembly era - C era - OOP era - Interpreted languages and game logic living in scripts on top of c++ engines - Fully Gen-AI era?
  - ifjeicjwidj 2mo ago
    > Fully Gen-AI era? Yeah, no. Your historic accounting is not to be trusted by any means if “gen-AI era” is something that you really believe is happening.

yellowapple 2mo ago

I've been on-and-off writing a Zig library for writing N64 games and it's indeed pretty wild how getting working code was as simple as telling the compiler to use LLVM's MIPS III target. Of course, getting working code that actually does anything useful is a much different story (it's taking multiple days just to write the wrappers for RDP commands, for example; lots of cross-referencing between N64Brew wiki pages v. official SGI docs v. libdragon source code v. Peter Lemon's assembly code to figure out what all the different bitpacked fields really mean and how to best represent them), but it still feels magical that I can just use an ordinary toolchain and not some ancient proprietary monstrosity.