Author: admin

Basic screen & mouse support is working while other devices on RVVM targets should soon be more functional, meaning the kernel should be able to start running desktop style programs very soon (but APIs & ports will take a while).

Following some early success with the port to RVVM emulator target I kept going and now have nearly enough hardware working:

• Framebuffer & RTC are now configured at boot time from the device tree blob (when available)
• The network stack (previously ported to the kernel for reading on QEMU) now appears to start correctly on RVVM but without ethernet drivers at this stage
• The OpenCores interface for I2C is partly operational/partly configured
• First contact has been made with the (virtualised) input devices over I2C, but haven’t finished drivers for those yet

In summary this means a GUI demo will soon be feasible but I haven’t figured out a plan for one yet aside from finishing the graphics & input drivers.

Disk, audio etc. could present further problems for this port but RVVM appears to be a good platform for this stage of driver development.

I’ve had a few connectivity problems with my complicated hardware test setup from last year so I’m going back to basics now with more support for emulated devices, while also continuing with support for device trees and other things useful for “real hardware”.

Improved device tree support means graphics output for RVVM is now configured dynamically at boot allowing support for different screen resolutions. Some other devices like RTC seem to be easy to work with as well (I think that will work like the one in QEMU).

I expect that full support for other devices – input, disks, networking, audio – will still take a while inbetween other updates, but this work should start becoming easier once I’ve developed a bit more infrastructure for drivers (e.g. proper interrupt management).

Update: work on other drivers for RVVM is progressing quickly, RTC seems to work and I may be able to get input working soon…

Back to work now on some features which I had already prototyped earlier but left unfinished & broken.

Booting In RVVM

RVVM is probably the fastest or most convenient RISC-V emulator for general purpose operating system work but hasn’t been a major focus of my porting efforts so far.

Booting on RVVM with just the OpenSBI firmware seems to require a slightly different setup than when using uboot on real hardware so the current build has been tailored for that setup, which allows easy testing of new kernel updates.

A fix to DTB support was required and the system is now recognised & operational to some extent.

Graphics Support

This means graphics is now working, since RVVM has an easy to use framebuffer device, but further work will be required on APIs, input drivers etc. to get a full GUI up & running.

Current graphics output is limited to some pixel tests so screenshots will come later after some font or GUI work.

Other Updates Needed

A little infrastructure like support for “hub” type devices (USB etc.) will probably be needed for more serious driver work whether in RVVM or on real hardware but there could be some easy options at least when working with emulators, I’ll see…

I’m currently having some minor “it’s not working” problems with my very complicated computer setup and am also trying to prioritise getting to a doctor and getting a better chair. I don’t think I’ve lost any recent work between malfunctions though and I aim to be back to work within a month or so.

I’ll be dropping the DOS reference in REFDOS (RD) for reasons but haven’t finalised a new name. There will also be some changes in direction along with or after the rebrand:

• Maybe looking at incorporating a custom processor architecture & using FPGAs as the main target (this could lessen the need for excessive driver work and also help spread the RISC, so to speak)
• Will do some more work on marketing & finding a niche (maybe education or maybe robotics etc.)
• Will decide what to do about a graphics subystem
• May look at open-sourcing some components (maybe the whole OS, we’ll see)

There will be more to come too in time like maybe an online package repository and easily installable versions of compilers etc.

Network Stack Appears Stable

Basic TCP/IP network functions appear to work correctly, although these functions haven’t been expanded to a full suite yet (missing DHCP etc.). Using an academic IP stack instead of a commercial one seems to have resulted in very solid foundations and I remain very happy with this codebase.

As this appears mostly stable, debugging output has now been disabled so the stack now works silently in the background instead of printing a lot of junk on every event.

HTTP Server In Progress

I ported a HTTP server early on for testing the network stack, this was originally a little problematic (in retrospect I should’ve tested with an echo server or something) but now that it’s working it seems like the HTTP server can easily be expanded for dynamic content etc.

SecureLang® RD Online Launch

This smooth but uninspiring progress means that the platform can probably be put into production early serving sections of my own website/s. This would probably involve using a mainstream (e.g. Linux/Apache) frontend and relaying requests internally to VMs running SecureLang® RD and the custom HTTP server, which would serve information like API documentation for the OS.

This will mark a significant change from the early 1.0.1 & 1.0.2 releases, going from downloadable demos which don’t do much to an interactive system people can gain some familiarity with online. It should be possible to also provide shell accounts and online SDK services eventually.

Due to rapid increases in AI capabilities, my main compiler product could be pushed before it’s “ready” just to differentiate it from what I’m sure will be a lot of vibe coded programming tools just around the corner.

This product was mostly developed a couple of years ago and was a result of a great deal of raw effort coming up with something directly comparable to other modern programming tools but also with some unique features. So for the most part it’s well designed and already works well enough, but it quite simply isn’t finished yet it’s very rough around the edges and hasn’t been optimised.

The original plan was to build up more of an ecosystem so that this product could be launched more smoothly, but because of a likely explosion in competition about to happen this year I think I will probably just package & drop it early, but probably not for a little while yet – I will still have to clean up a few things and make sure it builds reliably!

Complexity & Security

IPv4 is generally the first exposure people get to networking, when you see addresses like 192.168.0.1 and 127.0.0.1 these are IPv4 which is what we were using decades ago when Internet rolled out to many areas. This system worked, but is a little limited particularly in number of addresses. IPv6 theoretically replaces IPv4 with a more practical Internet architecture, key word being theoretically.

IPv6 has some slight security improvements, such as apparently making it easier to create internet connections through secure channels, but these improvements don’t seem to result in any meaningful difference for common configurations (and can probably be done with IPv4 or only small extensions anyway).

The showstopping problem with IPv6, however, is that you still need IPv4 to do anything in practice anyway. So with IPv4 you have a simple but limited internet style architecture, with IPv6 you have a new Internet but still effectively piggybacking off the old one.

If you’re just looking at features, this doesn’t really matter. IPv4+IPv6 gives you full featured internet architecture. But if you’re looking at security, maintenance costs, training costs … IPv4 is the clear winner, because IPv6 can’t compete with it without being twice as complicated in practice (still needing IPv4 configuration too).

Addressing

As for IPv4’s address space problem, this isn’t really an actual problem. 4 billion addresses is a lot! Certainly enough to coordinate more complex international communications and connect a bunch of smaller networks together. The problem is that the Americans basically saturated their IPv4 address space and the rest of the world kept using the same one, when we obviously should’ve done our own addressing prioritising our own servers!

So the problem with IPv4 didn’t really exist in practice for most of us, we were just limited by the American network not by the network protocol it used. Overall, IPv4 is basically fine and the solution to the biggest problem people said it has is just to deploy your own networks instead of relying on America’s!

It also seems extremely dubious to claim that IPv6’s addressing system actually solves this problem, as the addressing system is confusing enough for developers & administrators for everyone to know typical users won’t want to care about it.

Does IPv6 Solve Any Problems?

It obviously adds problems, but it doesn’t seem to really enable anything we couldn’t do before. It doesn’t seem to resolve the issue of IP addresses not really making sense on modern (mobile heavy) networks, it doesn’t allow me to connect to many devices that IPv4 won’t. So the tradeoff is not very tempting.

Is The IPv6 Internet Worth Accessing?

What has improved on the Internet since the introduction of IPv6? It may be designed to streamline access to social media sites with billions of users, but who likes these? Is it responsible to encourage this kind of usage of the internet? Shouldn’t different countries be running our own smaller sites anyway, and linking these, instead of relying on such a massive scale of connectivity for everyday communications?

Who Owns The Internet? Who Is The Police?

The standards authorities? The governments? The cloud providers?

Do those people represent my interests, my client’s interests, my community’s interests? Have those authorities really explained their own interests to the public in full?

No, I think this is our internet, and I am the Internet police. I think if we (average tech users, small businesses) don’t assert more dominance it will be taken away. So I control the Internet as far as it applies to my own business products, not them.

Summary

Obviously I’m biased, I’ve already ported an IPv4 stack to my OS and am too lazy to implement IPv6, but I think a lot of people are starting to have similar thoughts about whether IPv6 was maybe just pushed to distract us from making our own infrastructure instead of solving any real problems. After all the idea of every person on the planet being able to connect freely (the excuse for needing so many IP addresses) will never be viable on an internet controlled by Western governments.

I’ve been following these projects for years, ReactOS was just gaining steam when I was learning about computers and I remember giving my mum and the PC guy some headaches when I tried to install it on our home PC as a kid. BeOS was a particular favourite back in the day although none of us got time to really use it properly before they went under, so Haiku is also very interesting.

Awesome to see these projects still going, I hope to integrate some of my own tech with various open source operating systems in the future.

Originally a large part of my business was going to be developing & maintaining a legacy C stack, that will be balanced against whether better options for lightweight C compilers become available.

This could mean that upcoming releases (1.1) may not include the custom “compilec” builds, which will make actually producing releases easier in the short term. This won’t change anything longer term, the compiler code is still there and can be reused later.

The kernel & networking code have mostly been tuned for use with small compilers which could be a useful feature in some environments, but the compiler code remains buggy and in need of more maintenance so this is simply a cost cutting or prioritisation move.