atirut-w
commented
8 months ago If you're opening discussion threads, consider checking out the discussions tab. There's also an open discussion for this, if you'd like: https://github.com/fnuecke/oc2/discussions/262
As for your suggestions, the first two would require the ability to flash custom firmwares as the mod currently only includes the Linux kernel as a firmware. They would probably naturally come as people starts messing around with writing firmwares or adapting existing ones.
For the third one, it would require adapting OC2 itself to be architecture-agnostic as far as actual architectures goes. That means components would probably have to define their registers and architectures define their system busses, etc.
VadimP22
TGJek
I am writing an actual effortpost here for a major suggestion to make OC2 a bit more... usable. Right now, there is currently only one option for an OS to load onto a computer, and that is a Linux + BusyBox build. While it does work and gives users an actual, genuine OS to use... it's waaay too heavy. It requires that players craft all the highest tier components in order to make it run, which makes all the lower tier components useless. It also makes a multiplayer server environment, with multiple computers running at once, incredibly resource intensive.
Therefore, I'd like to suggest some alternative operating system choices that bring back the component scaling of the original OpenComputers.
SUGGESTION 1: A monitor No, I do not mean a monitor block! In this sense, a monitor is a very simplistic firmware with a very simplistic text UI that allows a user to inspect and modify memory directly, as well as load data to memory and execute it. These can be really tiny; WOZMON from the Apple 1 fits in less that 256 bytes! This will be a very useful debugging tool for developing custom software that can be run with OC2. However, nobody seems to have made such a thing for RISC-V (probably because everyone uses stuff like emulation nowadays?) so something would have to be written from scratch, which is kind of sucky. I've tried looking at RISC-V assembly, and uh, no thanks.
SUGGETION 2: An RTOS These are small, robust operating systems generally made for embedded purposes. Since one of the current uses of RISC-V is embedded stuff, there's a handful of RTOS solutions to get started with. A notable one is FreeRTOS, which has native RISC-V support and can require as little as 9kB of RAM! Since the lowest tier of memory in OC2 is 2MB, it should be able to fit comfortably. The only downside is that there doesn't seem to be a fully fleshed-out UI; I THINK there is a CLI demo somewhere? But you'd have to write all the core utils for it.
SUGGESTION 3: FUZIX Fuzix is a tiny UNIX-like system made for running on older CPUs, like the Z80. It has a complete userland and is incredibly frugal with memory. There is a Work-In-Progress RISC-V version that has a minimum requirement of 128kB RAM, but there are still issues with getting it built. This seems like the best possible choice to look into, however they will need some help getting RISC-V support properly finished.
So my overall suggestion is that at least one of these is provided alongside the existing Linux system. That way, people don't have to grind like crazy to get to what should be endgame-tier items just to start using OC2, while also providing Linux to those that do go out of their way to max out their builds.