PS1 Programming Course with MIPS Assembly and C
pikuma.com
pikuma.com
PS: thank you for all the good help on the PSX Discord, as always.
Buy one with FMCB preloaded from AliExpress, and take it from there
https://consolemods.org/wiki/PS2:FMCB
And also check out for example MX4SIO as well
You can buy one of those from AliExpress as well, but only certain versions of FMCB are compatible with MX4SIO out of the box
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.
[1]: https://github.com/JonathanDotCel/unirom8_bootdisc_and_firmw...
https://pikuma.com/courses/learn-3d-computer-graphics-progra...
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 ;-)
I'm still deciding what to tackle next. I had a couple of ideas, but since my true background is really math I'll probably consider that.
I'm not sure there's much money in what I do, but it sure it's a fun topic. Fun always trumps everything else at the end of the day. :)
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.
Get 60fps on an RPi5 for extra challenge.
[0] - The arcades adopted it much earlier, and there were UNIX and VAX/VMS devkits with cross-compiling capabilities for them.
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.
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.
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.
As for why I'm doing it this way, I've written about it here before: https://news.ycombinator.com/item?id=37165533. I've also written about the delinking process itself here: https://news.ycombinator.com/item?id=35738758.
I’m attempting to do something similar for the Sega CD for other reasons, but a lot of the same ideas apply.
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.
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.
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?
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.
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.
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:
- https://github.com/grumpycoders/pcsx-redux/tree/main/src/mip...
- https://github.com/ChenThread/candyk-psx
- https://github.com/cuckydev/CKSDK
- https://github.com/spicyjpeg/ps1-bare-metal (shameless plug)
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.
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.
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.
wow I'm getting old
More actively maintained...
Thank you so much for sharing. :)
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.
To each, its own.
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.
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.
It seems it could have been a better approach without the possible legal issues of PS1 homebrew development.
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.
[1]: https://psx.dev/
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.
That said, I am not sure this course is targeting new game developers.
If someone is dead-set on making a game for PS1, there are free tutorials out there also: https://www.youtube.com/playlist?list=PLAQybJIBW2UtXJITyUTJi...
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.
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.
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.
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.
Nowadays on a modern engine, a particle engine is one item from a huge list of engine features.
Also, $100 is really not expensive for a course. I think Udemy and youtube has ruined people's expectations
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.
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.
Thanks!
To be frank, this is not very re-assuring. Every platform that has ever gone offline has at one point told their customers something 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've read through your FAQ, but one more thing to consider is to offer a bundle discount, like for buy all or similar.
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
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.
As an adult.. boy I wish someone made a cozy Javascript transpiler to PS1 tool.
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.