I think there's a sweet spot for these things. Very old consoles are very limited but also pretty simple. You could get an overview of all the basic capabilities of a GameBoy in half an hour. As such they're easier to get started, playing a sound on a GB from scratch would take you a dozen CPU instructions at most, pushing a sprite into the GPU only slightly more.
Doing that on a PlayStation 1 would be already significantly more complicated. Even if you don't bother with 3D you need to figure out how to upload the texture to the (significantly more complex) GPU, configure a bunch of stuff and then you might be lucky enough to draw something on the screen. Take for instance this code for a "virtual terminal" on the PS1 GPU, this is what the GPU init code looks like: https://github.com/simias/psx-hardware-tests/blob/a72e0ba0c8...
And keep in mind that it's a super simplistic case, for anything more serious you'll want to configure double buffering, DMA, the GTE coprocessor for the 3D transforms and probably a few other things. Even just reading data from the CD-ROM is significantly more complex than accessing the memory mapped ROM of the GB.
I expect the PS2 to be even more complicated, although I don't have a significant experience coding on it. So you end up coding on a machine that's very limited by modern standards but at the same time might be more complicated to develop for than if you used Unity or the Unreal Engine.
PS2 is already at the level where hardware only knows about 3D.
Also its programming model is closer to something like Vulkan, thanks to the Emotion Engine.
Meaning having to create command buffers and command lists, and then dispatch them via DMA to the GPU.
Or by doing GPU shaders, which on the PS2 means Vector Unit Assembly (similar to MIPS).
So even for 2D games there is quite a bit of boiler plate to write up, until something gets properly displayed on the screen.
Those lucky enough to get a Linux Kit for the PS2, could use a kind of mini-GL implementation, PS2GL, that would make it a bit easier, given that PS2 Linux did not have access to the APIs for professional game developers.
There is a copy of the web site still available, with the programming guides.
I feel like this hits the nail. In addition to the complexity, there is also the thing that ps2 is comparatively similar to basic PC development, whereas 8/16 bitters have a very distinct different feeling.
2D pixel graphics arguably have aged better than early 3d graphics, and simple pixel graphics is also far more doable for a solo dev (or a very small team) than complex 3d scenes.
> 2D pixel graphics arguably have aged better than early 3d graphics, and simple pixel graphics is also far more doable for a solo dev (or a very small team) than complex 3d scenes.
I often ask whether part of the reason for this is also that the (graphics) tooling for 2D pixel graphics is better than for 3D graphics.
Doing that on a PlayStation 1 would be already significantly more complicated. Even if you don't bother with 3D you need to figure out how to upload the texture to the (significantly more complex) GPU, configure a bunch of stuff and then you might be lucky enough to draw something on the screen. Take for instance this code for a "virtual terminal" on the PS1 GPU, this is what the GPU init code looks like: https://github.com/simias/psx-hardware-tests/blob/a72e0ba0c8...
And keep in mind that it's a super simplistic case, for anything more serious you'll want to configure double buffering, DMA, the GTE coprocessor for the 3D transforms and probably a few other things. Even just reading data from the CD-ROM is significantly more complex than accessing the memory mapped ROM of the GB.
I expect the PS2 to be even more complicated, although I don't have a significant experience coding on it. So you end up coding on a machine that's very limited by modern standards but at the same time might be more complicated to develop for than if you used Unity or the Unreal Engine.