Blog

After spending some time messing around trying to port existing GUIs I decided to just write a new one, one advantage of this approach is that I can easily make builds for SDL2 as well as for testing on the new kernel in an emulator. Right now these only demonstrate simple mouse pointer operation, but the internal code for rendering this example is the same on either backend.

(NOTE: These examples are filmed on Ubuntu, so both should just look like a mouse pointer demonstration running in a window on another desktop for now! More advanced screenshots with my own window management code etc. will come later.)

Mouse pointer movement is smooth after initial test code was improved slightly. Looks like the system will have no trouble running a desktop and probably won’t need any advanced optimisations except for gaming & other multimedia intensive apps.

An initial version of my GUI API is now complete but not yet ready for detailed screenshots. I may upload some initial output from my new guitest program later.

This kernel-level API is reasonably well designed and should be flexible enough for future extension, but for now only covers the most basic operations of blitting to a screen and receiving associated mouse/touch input (with keyboard input half connected but unfinished for now, i.e. without keymap support).

Further experimentation particularly focused on performance & reliability will determine whether to expand the kernel-level API into a full GUI system or whether to leave it as basic drivers and use a portable graphics server such as Nano-X (the kernel-level interface is designed for both possibilities but windowing is not yet fully implemented in the kernel).

The choice was specifically made to offer a simple and easy to document interface rather than to require opening multiple different devices or configure modes from the program’s end for basic operations, the system is tuned for simple “framebuffer and mouse pointer” operations.

In summary this should be one of the better implementations of a graphics API as far as programmers are concerned, and is very easy to operate & extend with a minimum of fuss required at the program’s end to push pixels to a graphics output and receive events associated with the same screen (whether a physical screen or, later, a windowed abstraction).

Just a sneak preview of in-development code. This API is designed for 64-bit platforms, and may have to be de-optimised a bit if I do any 32-bit ports in the fucture.

SDL etc. usually use a plain struct (like my guirect struct) for passing rectangles, but for kernel system calls it can be better to avoid using too many pointers as long as this method (encoding rectangles as long values) is sufficient.

I’ve already posted some demos at the start of the year but these were much too simplistic to attract any attention so I’m starting to plan a proper launch now with some more capabilities.

Looking at about 3 weeks for basic GUI support becoming stable unless I face any major hurdles (pretty unlikely in an emulator environment), an additional 1 month or so to get some more interesting demo apps working (maybe some games, AI tools etc.), then a further 3 months on refining & advancing the current stack before it starts becoming more useful as a near-general-purpose OS.

So in other words, 4 to 6 months until I can start moving onto my new platform as my main development environment and then updates should start getting a bit more frequent.

This will probably include some very basic web functionality and other things people would expect from a general purpose OS but won’t be competitive with Linux etc. for at least a year or so (when emulators/virtualisation will be more convenient to run “real” apps). The system already has some container type functionality internally but this isn’t fully exposed yet, and other things like drivers and networking will still need more improvement after they start to stabilise, so most advanced “enterprise” & hardware features will be deferred until after an initial commercially-supportable release.

Stay tuned!

I don’t know if I can do anything to improve this situation, but if a professional hacker can’t get access to doctors and job networks here I can only imagine how difficult it must be for more vulnerable members of the community.

Something needs to change around here.

I probably won’t be able to focus on embedded development without setting up a more serious office, my server rack setup is a bit of a mess right now so I’m working from a laptop.

I’d like to do some book publishing in the future though once I’m done setting up my computer gear a bit better, especially making historical documents more accessible, so the business name was partly chosen with that option in mind and my software can be retargeted towards that as well.

So it will probably be a few weeks at least until I have better demos (GUI etc.) as I have some other things to worry about, but I have some excellent plans that will hopefully start coming to fruition this year.

That’s what it seems like, they are just on autopilot trying to start wars that don’t benefit their own populations.

Australia’s government does not even have the resources to defend itself from underfed bogans.

Who lit the fires that burnt Cobargo, who bought up all the local resorts after the locals were made broke, and were these two events connected or just a startling coincidence? Can ASIO answer these questions or shall I?

“Back in my day” you had to write a whole kernel yourself to have your own operating system!

Having had a look at a few modern “operating systems” including checking out the manual of Origin Quantum’s new OS for quantum computing, it looks like the accepted norm is now to just develop an operating system as a high level app running on Linux.

Origin Quantum’s new OS (Origin Pilot, these terms presumably trademarks of Origin Quantum) appears to run as a web app on top of Linux, serving requests to run algorithms on quantum hardware over plain HTTP. I assume this will be somewhat the norm on quantum platforms.

I certainly won’t be discontinuing my own kernel work any time soon but I probably will be making some components portable so my systems can easily integrate with these kinds of solutions. As for quantum computing I do hope to implement a kernel-level API but I will of course wait until there’s a bit more research and public feedback about current/next generation quantum systems so that typical use cases can be planned for.