Not directly related to the course, but, should anybody want to see what programming on the PS1 would look like using only modern tools (latest GCC, CMake, no third party libraries), I've written a few bare metal C examples that explain in depth how the console's hardware works [1]. Currently only graphics and input are covered, but I'm planning to add examples showing how to handle interrupts, play audio and access the CD-ROM next.
There are homebrew tools that can be installed on a PS1 memory card [1] and allow for executables to be loaded from a host machine into RAM through the serial port on the back of the console, in a similar way to what Sony's official Net Yaroze loader did back in the day. These tools can also use undocumented CD-ROM drive commands to disable region checks without the need for a modchip, provide semihosting (host filesystem access) and so on.
On the PS2 it's slightly more complicated, as there is no way to launch the "native" PS1 backwards compatibility mode other than to use a modchip (or firmware mod on some models) and burn the executable onto a disc; the serial port is not exposed either, making debugging much harder. It can still be done, but it's much easier to just use an actual PS1.
The author's Learn 3D Graphics Programming is one of those extremely rare courses that takes you from the basics and peels back the curtain to show you the Wizard.
One of the best courses I've ever taken. (Thanks Gustavo!)
By the way Gustavo, with your talent for explanation, graphics and Maths, maybe you should do some courses on Machine Learning!
(You'll make a lot of money ;-)
If you're taking requests, I'd love a good linear-algebra refresher course. I recently ran into the term "eigenvector" in a professional setting and that's a word I hadn't heard since my freshman year of college, which is over 2 decades at this point.
Since you mentioned math: If you can unravel the 4D being that is a quaternion and explain it to mortals, I would shower you with all the money I have on hand.
Also, it's probably premature but I would love some Rust courses in the context of game programming. I think that's something I'll need to pick up one day.
More C stuff, I really enjoy learning these fundamentals using C. I did your game physics course in C and really enjoyed it. I'll be taking this course to learn more about 3D graphics and C together.
I'd love to see a real-time multi-threaded & SIMD raytracer in C/C++/Rust. Plenty of math in there, but an opportunity to discuss thread & data parallelism, PBR, data structures for large scenes, profiling and optimization, and so on. It's like the next step after your existing 3D programming course.
I agree. As a low-level dev myself I really enjoy his courses. I did originally have issues with his game engine course where he was implementing the software in a rather inefficient fashion, but he rewrote most (if not all?) of the course from scratch and it's much better now. This is an instant buy from me
To note that PS1 was the first games console on the home market[0] to fully embrace C on its SDK, until then it was Assembly all the way, hence why so many studios were happy to jump into it.
[0] - The arcades adopted it much earlier, and there were UNIX and VAX/VMS devkits with cross-compiling capabilities for them.
I'm reverse-engineering a PlayStation video game that is rather unoptimized and I'm amazed that the game managed to do so much with such horrible game code. That SDK really was fairly forgiving for its time to new, inexperienced developers.
Yet to squeeze out performance out of the in-order, single-issue 33 MHz MIPS CPU you had to be very mindful of low-level details. The 4 KiB instruction cache hates code bloat, the lack of data cache means spilling registers anywhere but onto the 1 KiB of scratchpad memory is costly, yet the god-awful C compilers of the era liked to do both of these things. That's just for the CPU, the rest of the system also has plenty of details you need to pay attention to for performance.
I haven't actually programmed for the console, but the achievements done by talented developers such as Naughty Dogs on this dirt-cheap system are truly impressive. The console might be easy to develop for, but to make it really fly still takes a lot of skill.
Yes, for Crash Bandicoot we had to entirely skip the C SDK for everything performance-critical; pushing arguments onto the stack and the SDK popping them off for each function call used more cycles than the underlying operation in many of these SDK calls.
Sony explicitly forbade this, presumably because they envisioned the API established by the C SDK as a way to ensure future backward-compatibility. We just ignored the rules and hoped the superior performance we could achieve would overcome any bureaucratic obstacles.
We also had to reverse engineer some of the PS1’s really nice capabilities. I only learned the hardware supported vector pipelining for strip rendering by noticing the coordinate values move from one register set to the next in the debugger.
Seeing that was a revelation: when rendering a polygonal mesh, you naively have to project three coordinates for each triangle. But if you convert your mesh into sequences of polygonal strips where each triangle shares an edge with the next triangle in the mesh, you only need to project a single additional vertex for each additional polygon in the strip. Observing the behavior in the debugger, it was obvious to me that the Sony hardware had in fact been optimized for this approach. But not only were we not given any documentation on this, we were instead told to use the C SDK, which didn’t expose this capability at all.
The PS1 also had 2KB of “scratchpad” that was slower than registers but much faster than RAM. Hearsay was this was a way for the CPU designers to make use of the physical space on the die meant for floating point instructions which the MIPS CPU in the PS1 didn’t have.
I used the scratchpad to store projected 2D “stamps” of the 3D world (stored in an octree) and Crash: a kind of low-res Crash Flatland. I could then check for X/Y collisions between Crash and the world very rapidly by inspecting the flatland bitmap stored in the 2K scratchpad. This was Mark Cerny’s idea; he was our producer on the Crash games and has also been responsible for PS2 through PS5 hardware.
Hey I just wanted to chime in and say that I spent a lot of time in my infancy/youth playing crash bandicoot, thank you very much.
Also, i’ve seen many videos on YouTube about all the crazy things you had to do to make stuff work. And every time i get to read some additional detail it’s always super intriguing…
Have you considered doing something like a documentary? Like, a series of long form videos on the topic? With interviews to people involved etc?
Hopefully you’ve read the Polygon article and seen the videos with Andy Gavin talking about the underlying tech. I was going to do part two of the video series but COVID killed it. Maybe we’ll revive that; it would be fun.
Not only do you only have 4KB of instruction cache, but it's direct mapped.
So if the linker just so happens to place the function you are calling at some address that's some multiple of 4KB away from your current hot loop, then the code for your hot loop, and the function you call will get continually evicted and reloaded for each loop iteration.
A small change to a random function could have large impacts on the alignment of all other functions in your game, and could result in large performance impact. The simple solution is to just inline everything your hot loops call. That avoids the chance of the pathological cases (and has the bonus of avoiding function call overhead), but at the cost of increasing code bloat in general (which the cache hates).
I've been vaguely considering making linker that's aware of direct mapped caches, and uses the call graph to guide the placement of functions (and data too, for machines with direct mapped data caches). Not only would it be useful for retro consoles with direct mapped caches like the ps1 and n64 (and probably help for the PS2 too, which is only 2-way set associative) but it would be useful for modern microcontrollers that do XIP execution of code from flash. They often have simplistic direct mapped caches too.
Have you published anything? There are a few games that I would love to be able to round trip between the original disc contents and a build with a few tweaks or experimental features. I know there is a Wipeout decompile/source leak, but having more examples is always wonderful.
Something like the Mario 64 reverse engineering project has made the game playable effectively everywhere with the ability to take advantage of modern hardware (16:9 displays). It would be great to see efforts like that for any console.
I'm documenting my progress on my personal blog (https://boricj.net). Currently I'm in the process of porting data from a leftover SYM file onto a closely matching EXE, the next article should be out by the end of the week-end.
Be warned, I'm going about this with a very different approach than most decompilation projects out there. I want to delink these executables back into working, reusable object files. The plan is to make a native Linux MIPS port on the cheap using PsyCross, then to rewrite each piece Ship-of-Theseus style until I have a complete, portable set of source code for the game.
It's Tenchu: Stealth Assassins. More specifically, the updated Japanese re-release version, which has goodies like a level editor we didn't have in the West until Tenchu 2: Birth of the Stealth Assassins.
I do not expect to finish it anytime soon, although finding debugging symbols in a leftover file inside a proprietary archive format has been a very lucky find. Most of the past two years have actually been spent on the tooling to delink executables back into object files, which should prove extremely useful if this crazy approach of mine works out.
> We'll also learn how to use the official Sony Psy-Q libraries
Is there not a cleanroom SDK for the PS1? I doubt Sony cares too much at this point, but selling a course which relies on leaked proprietary tools still feels a bit dicey.
The Portal N64 demake got shut down because it used the leaked N64 SDK rather than cleanroom tools.
That was interesting because the author didn't receive a legal takedown notice, and the request came from Valve instead of Nintendo. It's possible nintendo didn't care, and likely that sony cares less than nintendo.
I think Nintendo cares a lot. In fact I think Nintendo gives so much fucks about its IP (of any kind, not only games/stories/characters, but also SDKs/APIs/console design/etc) that Valve fears any kind of association with potentially illegal or at least dubious origin software related to Nintendo.
Remember Valve is a company that normally celebrates and promotes the modding community, even when using their IP directly (i.e. Black Mesa). Valve's decision was totally and exclusively because it included BOTH their and Nintendo's IPs in the equation.
I believe what happened is that Valve said something along the lines of: "We are a little concerned that Nintendo might object, you can only continue if you get an official notice from Nintendo saying they don't object."
It's entirely possible that Nintendo don't care, but the chance of Nintendo agreeing to go on the record about such things is basically zero.
PSn00bSDK maintainer here. Unfortunately the project cannot really be considered clean room; the original versions of most libraries contained code that was either lifted straight from Psy-Q disassemblies or heavily inspired by them. I have since rewritten pretty much all of it (with the exception of the GTE library which still has some Sony code) using only Psy-Q API documentation as a reference, but the "ship of Theseus" nature of the rewrite makes it hard to argue that it is a clean and legally safe project.
On the flip side, there are plenty of other open source PS1 SDK options that have been written from scratch, do not reimplement the same API as Psy-Q and can thus be considered clean for the most part. Here's a few of them:
> using only Psy-Q API documentation as a reference
Doesn't that mean it's not clean room? Since even having those docs in the first place would not be legal?
I've seen others claim that clean room can only be an option if development was done without any input from anyone who has even read their docs, not just whether you have yourself or not.
For example in the N64 world some might say development is forever tainted because it's almost impossible to get information that wasn't sourced somehow ultimately from the oman dump.
Hi, what prompted you to create a 25 hour course about programming the original PlayStation? Don't get me wrong, it's very cool that such a resource exists, but it is a rather peculiar topic for a course.
Hey. Good question! People think I'm crazy, but I promise you I'm very sober about my approach to my courses.
I teach CS & mathematics at a university here in London. Empirically, I've noticed that students can find ways to be productive but they are seriously lacking the fundamentals.
To be fair, it is nothing short of overwhelming to try and grok the fundamentals of computing using modern machines, modern OSs, and a modern dev toolchain.
So what I try to do with the courses is to go back in time and limit myself with a closed hardware box that is still small and simple (compared to what we have today).
Instead of using a fake instruction set, I can have students learn the basics of MIPS, use a very simple assembler, output binary code, and execute those instructions on a hardware that exists (or existed once). That allows me to explain about CPU architecture with real examples, talk about DMA, endianness, interrupts, and so many other concepts that students can read online but they don't really grok until they get their hands dirty with grease.
Weirdly enough, so far it's been proven to be a good idea. It's definitely not for everyone, but if someone is at a stage of their career where they think it's fun to learn about RISC pipeline, fixed-point math, game physics, 3D graphics, compressing assets, computer architecture, etc., then I still think this type of course is valid!
I'm positive that in 25 hours learning how to program the original PlayStation they'll learn a lot more about computer science than taking an expensive class to read about 'Digital Transformation' or something like that.
Hey, the website isn’t loading for me right now (i’ll try again later) so i wanted to ask: does the course include examples on how to run the code on a playstation, real or emulated?
All the examples from the lectures we execute using an emulator. The final big project is the only one that I actually burn a CD ISO and run on the real PlayStation. You don't need to do it, but I still show how it's done for those who want to know.
That really makes a lot of sense. Given the constraints, the PlayStation is indeed a good fit (if you want to be sadistic, I can't think of a worse fit than the Atari Jaguar with its numerous pipeline hazards inside its proprietary RISC processors).
I do think using a modern SDK would streamline the experience without compromising on the authenticity, it might be a good idea to at least mention this option since the original Sony SDK is technically leaked tooling.
That's why I take your courses. I work in embedded so the low-level always interests me. There's too many devs who just throw javascript or python at a problem and need an i9 just to run their calculator app.
Why ESP32 over any other microcontroller? ARM and MIPS are much more widely used in industry.
Nostalgia is obviously a big factor in why people get excited for these courses, so PSX is a good choice. Although I do agree that using a non-proprietary SDK would've been a smarter decision.
There definitely is one [1], albeit perhaps not as large and active as the homebrew communities for 8/16 bit consoles (which benefit from low-code tools such as GB Studio and the ability to sell physical game cartridges that do not require modchips) or more modern ones (which tend to have a much lower barrier to entry, given the better specs and availability of SDL ports and whatnot). It is definitely growing though, as I'm seeing more and more people get interested in developing for the PS1.
I started collecting obscure retro consoles almost a decade ago when Net Yarozes could be found for prices that weren’t completely outlandish. Now it’s common to see them on popular marketplaces for $700 or more.
Their aesthetic is amazing. The PS1 holds up, imho, as one of the best looking Sony products and consoles of all time and the dark gray color way is a hint of what the next three consoles would look like.
With modern quality emulators like DuckStation, there's really no reason to use real hardware anymore as the primary target. Besides, you'd probably just have a standard PlayStation console with a modchip on hand and iterating with CD-Rs would be very slow and wasteful.
I took this dudes Atari 2600 Course on Udemy cause it was only $13 bucks. It is awesome/great. Made the whole thing super simple to learn. Very idiot proof. It's too the point (which I find helpful).
Course looks really cool, just wish it wasn't $100 but I know that's unrealistic to expect. It seems most people who want to get into video game programming are poor.
Many modern game engines are free and less frustrating than SDKs for old consoles (e.g. a lot of common tasks are often built-in with new game engines, such as physics). For people who want to get into making games, I would recommend one of those game engines rather than paying $100.
That said, I am not sure this course is targeting new game developers.
Agreed. Godot, Unity, Unreal, etc. all are better options for beginners. Gamemaker Studio even lets you program for free...you have to pay to make an executable though.
You won't have as intimate knowledge of PS1 hardware as OP's course, but I think thats a better starting point than paying first and then stopping because you didn't already know programming and it turned out more involved than you thought it would be.
Now I DO think that there is a place for a paid course like this. I can see the appeal of getting hyperfixated on extremely specific hardware such as this, and making some cool stuff for it. For that type of person, the 100$ is worth it.
> Agreed. Godot, Unity, Unreal, etc. all are better options for beginners.
Am I just lost or are a game engine and a game development course not very obviously different things? Paid tutorials exist for everything you've listed, because they are in fact tech and not teachers.
I have had some experience with Godot and Net Yaroze (PS1). It was significantly easier to make a game with Godot.
Godot comes with an IDE that build/edit/run games all in one integrated experience, and the user manual comes with a tutorial. I was able to make a game in less than a day, and the edit-test iteration cycle was practically instantaneous. I am familiar with Python, but I suspect it would have been possible to make some games without any programming experience.
Net Yaroze came with two printed manuals and a serial cable. There was no tutorial. Memory was limited and I had to lay out all the sprites in the video memory myself. The edit-test iteration cycle was slow since it involves uploading your compiled binary over the serial cable to the console on each run. If I wasn't already familiar with C, I don't think the PlayStation was the best place to start learning it.
Everything definitely got better in the past few decades given all the tools that became available, but ultimately we are comparing a purpose-built tool for making games versus a development kit plus lots of hardware constraints. There is a different type joy to be gained in developing for a console, but for beginners who just want to get some game up and running, a modern game engine is going to be an easier path.
Im saying that it is better for beginners to start with a modern engine than try to make something for an older console. Newbies will see a course like this, think "oh I loved the playstation! This course will help me learn how to make a game for it? I will buy." When in reality, they will just waste their money because development is hard, especially for the PS1.
What I was saying is "If you are dead-set on making a game for PS1 for your first game" use a free course instead of buying something like this. Newbs don't realize how complicated learning CPU architecture and assembly is. What they want to know is how to get started making games, so I linked a free course while discouraging new developers from even trying to develop for the PS1, but to go for a more modern engine.
To put this into perspective, my graduation project was porting a particle systems engine from NeXT/Objective-C into Windows/C++ using OpenGL, and using it for visualization techniques like marching cubes.
Nowadays on a modern engine, a particle engine is one item from a huge list of engine features.
If they want to get into video game programming, this is not the course. There's a ton of resources for Unity and Godot. This is for people who are interested more in the low-level implementation, game engines, and general history of the technology
Also, $100 is really not expensive for a course. I think Udemy and youtube has ruined people's expectations
I like the idea, and other courses seem solid in overview too. However, I'm put off by not being able to download the course. I understand it's my old-man mentality kicking in, but I just have this bug in my mind "what if it goes down", "I wanna watch this offline", "what if dude disappears"..). I also understand why there's no option for that.
I don't know, anyone else have feelings like these in general? I'd have no issue if it was way cheaper, and I'd have no problem if it was somewhat more expensive if I could download. It's a weird feeling like that that ultimately did affect me not purchasing it.
edit: I realized I wouldn't mind it if it was on a big platform like I don't know what would support it, steam? appstore? I know those won't go away and I have stuff there.
Hi! Creator of the course here. This is a really good point, and I honestly did not consider someone's fear of a platform "disappearing" as a potential friction to buy before I read your comment. It makes total sense.
I have been doing this for a while, so disappearing was not even in my thoughts. :)
But I'll need to think about that and how to make it clear for everyone that visits the school.
I also am in the camp of people who want to be able to download (although I know that increases the risk of people pirating the videos)
Partially because the video player doesn't work very well on tablets, and partially because after you changed the game engine course, I still wanted to refer to the original version
Thanks for consideration. Maybe easiest path would be to go through one of the bigger platforms but maybe more expensive and also offer same but cheaper on your own.
I've read through your FAQ, but one more thing to consider is to offer a bundle discount, like for buy all or similar.
> It's also possible you may go offline for reasons outside of your control.
I see. I've just discussed about this with other people at the school. I guess if something like that ever happens, the course content will probably be made available in full to all students.
One thing is that I am personally always updating the course and adding new examples and lectures to it. If students simply download the content once there will be different versions of it. This was one of the reasons I've decided to record lectures instead of simply writing a book, for example.
> I don't know, anyone else have feelings like these in general? I'd have no issue if it was way cheaper, and I'd have no problem if it was somewhat more expensive if I could download. It's a weird feeling like that that ultimately did affect me not purchasing it.
Yeah, I'm the same. These courses sound and look right up my alley, but I try to only support DRM-Free material where I can for the reasons your described. The Pragmatic Studio [1] is a good example of an online school that offers DRM-Free downloads for customers.
I have one of those yaroze things. I had all sorts of plans for it. Until I realized that the memory on the thing was identical to the size of the normal in store ones and getting at the CD for extra storage was basically broken at the SDK level. That made debugging 'interesting'. Even splurged for the codewarrior dev kit. It was a decent step down in tooling and memory that I could get on other platforms. Kind of fun for a bit.
Same. As far as I know, though, the black PS1 didn't actually do anything special to enable development, it just allowed Sony to arbitrarily make the devkit incompatible with retail PS1 consoles. It still required a special memory card dongle and boot disc in addition to the special console model for some reason. I seem to recall that someone cracked the boot disc to run on retail consoles without the dongle, and the serial link just needed a level shifter like a MAX232 (though these days you'd probably use a USB UART like CP2102 or FT231).
I too remember being mesmerized by the image of the black PS1 “developer” kit.
It truly captured my imagination and alongside the movie Hackers from 1995 is probably one of the reasons I ended up wanting to be associated with computers in my future as a child.
I just looked they are going from 800 to 10k. The 10k ones are the collectors ones where it is new in box (or at least complete in box). As long as you have the cables, console, and dev card you probably could get in at around 1-2k.
[1]: https://github.com/spicyjpeg/ps1-bare-metal