Do you have any plans (maybe in the far future) to re-implement the Photon microGUI system?
Just asking because for me, that's half of what made QNX so great back in the day. Even today I keep raving about that 1.44MB demo floppy, about how polished, performant and efficient Photon was.
Well.. who knows. My interests are not exactly in the area of GUIs, but I do agree that Photon was great. When the main system stabilizes; when it runs RT tests (such as the audio test I'm planning) under heavy load for e.g. one week -- AND when all important "syscall-like" APIs are implemented and proven to be correct -- I might return to this.
Question to you: on which hardware platform would you like to have Photon running?
Currently, the only system I got is SiFive Unmatched with NVidia GK-208 card. Re-using Nouveau in QSOE should be possible, but it's a big pile of work.
Low-spec/embedded/vintage devices. Mainly RISC-V, or old x86 hardware like a Pentium III with a Matrox Millennium AGP card or something.
For context: I'm sick and tired of modern hardware, modern GUIs and modern Internet... all of which keeps getting more and more complex, commercialised, controlled and demanding.
I miss the old days, when hardware resources were paltry, when you could mostly understand what went on in your hardware and OS, when developers coded in native languages, didn't rely on bloated toolkits and infinite dependencies and didn't take a user's system resources for granted and were able to make really cool programs in mere kilobytes, when the OS didn't impose arbitrary restrictions on you in the name of "security" and you were free to do whatever you wanted with it, and when the Internet wasn't controlled by mega corporations and there was no Javascript and browsers didn't need gigabytes of RAM and the web wasn't the bloated mess that it is today.... I really, really miss those days.
My dream is to either have a RISC-V box or a vintage PC, hook it up to a LoRa network like Meshcore or something, run an efficient 90s-style OS like QNX/Haiku/SerenityOS/KolibriOS, and run some old-school networking apps similar to IRC, BBS or even Web 1.0, all over LoRa... and rediscover the joy and magic of computers again, relive the spirit of the 90s whilst being able to communicate with others freely without corporations and governments getting in your way... that's my dream.
Sorry if I went off on a tangent, I just saw "QNX" in the headline and it got me all nostalgic and emotional.
Fully support your dream -- and out of similar reason/sentiments I created GateMate PC (google for it) and GateMate S/359. I will return to these systems in autumn; it's a pure joy to work with them.
As for the video controller -- if during the next couple of days I have zero success with GK-208 initialization in U-Boot, I have a plan B. I will throw away that card completely and will buy DragonBoard (Xilinx Artix 7). I already have a video controller implementation for it.
Own video-controller + own OS + own bootloader on RISC-V. What could be better! :D
Raspberry Pi was a shot in that direction. But it's still a complex beast with 3D GPU, some embedded RTOS to get everything started, etc.
Personally I think software size should reflect the complexity of the task. And yes, a modern GUI does subpixel rendering of scalable fonts, decoding complex video codecs etc etc. But the bulk of today's massive software size is just pointless abstractions, inefficient 'frameworks' or eyecandy.
For QNX/Blackberry it would make sense to opensource Photon since they are not using it anymore. Porting it to the modern QNX and other systems would be great.
Depending how recent the card is, you might need to implement UEFI & GOP instead. Might be better approach to read any open source driver code on Linux or BSD to find out how to get basic framebuffer
Do you have any plans (maybe in the far future) to re-implement the Photon microGUI system?
Just asking because for me, that's half of what made QNX so great back in the day. Even today I keep raving about that 1.44MB demo floppy, about how polished, performant and efficient Photon was.
Well.. who knows. My interests are not exactly in the area of GUIs, but I do agree that Photon was great. When the main system stabilizes; when it runs RT tests (such as the audio test I'm planning) under heavy load for e.g. one week -- AND when all important "syscall-like" APIs are implemented and proven to be correct -- I might return to this.
Question to you: on which hardware platform would you like to have Photon running?
Currently, the only system I got is SiFive Unmatched with NVidia GK-208 card. Re-using Nouveau in QSOE should be possible, but it's a big pile of work.
Low-spec/embedded/vintage devices. Mainly RISC-V, or old x86 hardware like a Pentium III with a Matrox Millennium AGP card or something.
For context: I'm sick and tired of modern hardware, modern GUIs and modern Internet... all of which keeps getting more and more complex, commercialised, controlled and demanding.
I miss the old days, when hardware resources were paltry, when you could mostly understand what went on in your hardware and OS, when developers coded in native languages, didn't rely on bloated toolkits and infinite dependencies and didn't take a user's system resources for granted and were able to make really cool programs in mere kilobytes, when the OS didn't impose arbitrary restrictions on you in the name of "security" and you were free to do whatever you wanted with it, and when the Internet wasn't controlled by mega corporations and there was no Javascript and browsers didn't need gigabytes of RAM and the web wasn't the bloated mess that it is today.... I really, really miss those days.
My dream is to either have a RISC-V box or a vintage PC, hook it up to a LoRa network like Meshcore or something, run an efficient 90s-style OS like QNX/Haiku/SerenityOS/KolibriOS, and run some old-school networking apps similar to IRC, BBS or even Web 1.0, all over LoRa... and rediscover the joy and magic of computers again, relive the spirit of the 90s whilst being able to communicate with others freely without corporations and governments getting in your way... that's my dream.
Sorry if I went off on a tangent, I just saw "QNX" in the headline and it got me all nostalgic and emotional.
Fully support your dream -- and out of similar reason/sentiments I created GateMate PC (google for it) and GateMate S/359. I will return to these systems in autumn; it's a pure joy to work with them.
As for the video controller -- if during the next couple of days I have zero success with GK-208 initialization in U-Boot, I have a plan B. I will throw away that card completely and will buy DragonBoard (Xilinx Artix 7). I already have a video controller implementation for it.
Own video-controller + own OS + own bootloader on RISC-V. What could be better! :D
I share that dream, and surely it's not just us.
Raspberry Pi was a shot in that direction. But it's still a complex beast with 3D GPU, some embedded RTOS to get everything started, etc.
Personally I think software size should reflect the complexity of the task. And yes, a modern GUI does subpixel rendering of scalable fonts, decoding complex video codecs etc etc. But the bulk of today's massive software size is just pointless abstractions, inefficient 'frameworks' or eyecandy.
Right.
That's why I love good text mode interfaces so much.
For QNX/Blackberry it would make sense to opensource Photon since they are not using it anymore. Porting it to the modern QNX and other systems would be great.
To all experts in video cards reading this:
Do you know, how to initialize a NVidia card in the RISC-V system (such as Unmatched or Polarfire) to the basic VGA mode 3 (text mode, 80x25)? :)
I really wanted to get the Real Console for QSOE, but so far all my efforts to run video BIOS (via U-Boot's bios_emulator) are not successful...
Depending how recent the card is, you might need to implement UEFI & GOP instead. Might be better approach to read any open source driver code on Linux or BSD to find out how to get basic framebuffer
will this work with liteX? fascinating project
Is it a micro-kernel based? Because writing kernel drivers is not the most convenient approach.