Misc. questions

[Shazuli]

Hi

1. I noticed Micropython was available along with Lua, would be cool if we could use languages like RISC-V Assembly or perhaps C.
2. If we are not going to have access to GCC, do you think it would be possible with some sort of toolchain where we can compile on our own machine and then transfer to the game? I did find this repo that could do that, but I don't have any experience with RISC-V and couldn't get it working on my machine, so I don't know if it would work.
3. Are there going to be familiar stuff re-added? Would be nice if we had external screens and graphics cards that can control them like before. Projectors are amazing! Having screens would be more convenient though, and could use less power to run. And Drones were really useful for simple tasks. Would be cool with a "re-imagined" take on Drones, but holding to the core aspect of them being lightweight computers with limited hardware but be more movement-oriented and quick compared to Robots. And finally Tablets, nothing really to say about them, just very useful.
4. Are there going to be any sort of package manager? Would be pretty neat if you could set up repositories where you can install binaries and libraries other people have made. A magical "Internet Card" that allows fourth-wall-breaking that gives access to the real internet while if no such card is installed will only have access to servers on a connected network that has a configured repo with packages.

Edit

Sounds like it's completely possible to build binaries on a different machine and then export to the game (going to follow that link when I get home). Perhaps an external tool that can export a file to a disk in game without having to select it with import.lua?

[Ekain06]

Regarding the first point, you can install the riscv64-linux-musl-cross toolchain to cross-compile binaries for oc2 computers (they run buildroot in a riscv virtual machine). For C it's OK, but you're going to have a hard time trying to run a more "modern" language because of the space limitations (libstdc++, for example, takes 16.8MB)

[lxhom]

btw, the link you wrote is broken. you need to write http[s]:// in front of the domain or github interpretes it as a relative path. your link currently redirects to https://github.com/fnuecke/oc2/discussions/musl.cc instead of https://musl.cc lol

[lxhom]

regarding point 1, the VMs are literally just regular VMs running linux, you can run anything on there if you can compile it to RISC-V. and for compiling to it, you just need to cross-compile to RISC-V. you can even run Rust programs on there, but its harder to use compiled languages because you need to crosscompile every time, so thats why micropython and lua is used.

[Shazuli]

I guess it would be possible to create an external VM and try stuff on that before you export it to the game? I've seen a bunch of OC emulators with varying success. So compared to OC1 creating a RISC-V VM could be a lot easier to do (no idea though) than having to emulate OC's computers with its operating system.

[atirut-w]

you can run anything on there if you can compile it to RISC-V.

Correction: any Linux program

The EEPROM currently uses an embedded Linux kernel to boot into an existing Linux OS installation(in this case, Sedna) on a hard drive so anything non-Linux is impossible at the moment. Would love to see a more generalized EEPROM for custom OSes.

[spike11302000]

its a bit to setup but you can compile c. the toolchain i used is riscv64-linux-musl-cross and download riscv64-linux-musl-cross.tgz

[Shazuli]

Ok, cool, going to try and set up that when I get home. How would you compare running a binary file regarding speed and efficiency compared to a Lua or Python script?

[spike11302000]

depending on the program it will most of the time be a lot faster then lua or python because they are interpreted programming languages so the execution time will be slower then a compiled binary

[Shazuli]

Looks like I got it working, although I have noticed some glitches that were not present before:
Any kind of input from the user will prevent the previous printf from showing up, and will only print out after the user has pressed enter. This can be worked around by having it go to a new line (ln), but you can't have so it look like this:

Write a number: 123

Occasionally it will crash and say "Segmentation fault", something that didn't happen before and only when I was developing it.

Have you noticed any other odd behavior when you run a binary?

[fnuecke]

FWIW, the segfaults may be related to segfaults I've been seeing when using tcc to compile certain things, and the investigation of which has been sapping most of my energy for this project recently (hence little happening recently).

I'm still not sure if it's related to my VirtIO device implementation or a more fundamental issue somewhere else. E.g. they don't trigger when running things purely in /tmp, which is a ramfs. It's a right pain to debug...

[spike11302000]

Have you noticed any other odd behavior when you run a binary?

I do notice some oddities but they are rare, I would get seg faults but restarting the computer seems to fix it most of the time

[Shazuli]

5. I'm guessing other GNU binaries are going to be added later on. But is it possible to smuggle in stuff like make or other Linux binaries such as adduser? I guess it's fine logging in as root, but it would be nice to have an automated way of creating new users on a system for example.

[atirut-w]

Import a zip containing the programs you want and their dependencies? Never tried that so idk if it would work.