Also I hope you guys will not have to deal directly with the Win32 API in straight, unmanaged C/C++. Kinda forgot about that, been years I haven't touched it, but I remember it was kinda weird. At least, it made .NET look like a walk in the park.
Win32 rofl. But don't give Microsoft more reasons to push UWP down our throats D:
My take on this is somewhat atypical because I once tried to port back NetBSD to it, so I did not care about all the insane Sony proprietary bits. Turns out the CPU is one of the most insane things about it : from what I can recall, it's a MIPS-III with most MIPS-IV instructions, a couple of MIPS-V instructions, 128 bits registers, 64 bits virtual addresses like MIPS64, 32 bits physical addresses like MIPS32, FPU units almost but not quite IEEE 754-compliant and a 64 byte cache line.
It's technically a MIPS CPU, but that's the weirdest MIPS ever made by far. It's like they've decided to make a hybrid of five different MIPS ISA because they could and piled on more insanity on top of it...
I haven't even talked about things a general-purpose UNIX-like OS does not care about, but the heterogeneous computing with the PS1 CPU bolted-on (or the PowerPC core on later models) on the bus would've yielded even more insanity to exploit.
Ah, interesting. I've heard a lot of talk about the GS processor on the PS2 but not a hell lot about the CPU. I guess most people assumed it was just a boring old MIPS cpu. I mean in theory it should be possible to tell GCC to target some of the CPU's features right ? (or even create a new target but i think you guys went with the safe route C:)
HP Prime G1
It's not hard because of the hardware (it's fairly standard), but the firmware' OS is quite odd from what I've heard (early versions actually relied on the RAM mirroring to boot, which screams sloppy programming to me), the flashing protocol is proprietary and the utilities are Windows-only, the calculator will be bricked if the beginning of the NAND gets corrupted or overwritten and the touch chip is proprietary. That makes for a very, very frustrating platform to work on for homebrews.
Hopefully the G2 will not be such a pain in the ass to work with
Isn't the G2 going to be more locked down though ? It's a shame that neither the Linux or NetBSD ports went anywhere.But touchscreen isn't that important on a calculator one could argue.
I saw some articles about Fushia but it's as early stages as Haiku OS it seems. At least they got rid of Java it seems.I don't really care for the microkernel design but as long as it is POSIX compliant and performs decently, it's all good.But then again, it might end up like Tizen and stay on smartwatches and all. (which kind of died because the license was not truly open source among other things)
Also, i think i should add the Philips CD-i to my list as well... Seriously, it's terrible to work with and the whole design is flawed.
The good thing is that it does support lots of colors on screen compared to other platforms at the time (like the SNES or Megadrive).
The bad things is that you must go through the OS's calls to do your work.
I mean, when you play a sound effect, do you expect it to be delayed by 4 seconds the next time you play it ?
It's not even consistent, it's completely random.
Philips came up with "libraries" (like Balboa) to somehow help developers... except said libraries is unnecessarily even complex than just using the OS's calls !
Also, everything has to be software rendered. The advantage is that it does make it more flexible, kind of like DOS PCs at the time.The bad thing is the CD-i's main CPU is too slow to deal with the load, forcing devs to rely on compiled sprites.
But it does have a CLUT 128 colors mode in which you can have 2 planes, which is used by most games.
Overall though, it honestly looks like my ports to it are going to be challenging... I still have yet to find a fix for the sound effect issue.