I'd like to see more useful screenshots as well as prebuilt release binaries/images in the future. Currently I'm looking at how to set up a proper build environment to experiment with it.
My targets would be mostly baremetal hardware, preferably installed on hard disk though I'd be doing initial tests using bootable USB sticks. Regarding emulated (not natively present) functionalities (video, sound, etc.) I wonder where I should look at in order to configure them?
And regarding the license, it's not recognized by GitHub (showing it as just "License"), but it appears to be WTFPL with the "NO WARRANTY" disclaimer taken from MIT added under it.
Yes I should invest some time into setting up a convenient flow. Building should be easy, the ./run.sh script should work basically out of the box (downloading bazelisk automatic). bazel-out/kernel.elf is the kernel, but you need a ext4 filesystem present.
The way I have it, I have linux running on my laptop. I build kernel.elf and copy it into /boot/retroos and add grub menu for it and /home/retroos is prepared to have BOOT/... (command.com, dn, config.sys) ULTRASND/ for midi patches, CD/ and FLOPPY/ contain any images (iso,cue, img) and then my games, borlandc etc..
So /home/retroos
1drwxrwsr-x 3 priv-gerben retroos 4096 Aug 19 21:09 BOOT 2lrwxrwxrwx 1 priv-gerben retroos 59 Aug 19 21:09 BORLANDC -> /home/priv-gerben/project/RetroOS/apps-proprietary/BORLANDC 3lrwxrwxrwx 1 priv-gerben retroos 53 Aug 19 21:09 BP -> /home/priv-gerben/project/RetroOS/apps-proprietary/BP 4lrwxrwxrwx 1 priv-gerben retroos 53 Aug 14 20:01 CD -> /home/priv-gerben/project/RetroOS/apps-proprietary/CD 5lrwxrwxrwx 1 priv-gerben retroos 57 Aug 14 20:01 FLOPPY -> /home/priv-gerben/project/RetroOS/apps-proprietary/FLOPPY 6drwxrwsr-x 2 priv-gerben retroos 4096 Aug 19 21:09 GAMES 7drwxrwsr-x 4 priv-gerben retroos 4096 Aug 19 21:04 OS2 8lrwxrwxrwx 1 priv-gerben retroos 47 Aug 19 21:09 ULTRASND -> /home/priv-gerben/project/RetroOS/apps/ultrasnd 9drwxrwsr-x 4 priv-gerben retroos 4096 Aug 19 21:56 WINDOWS
I added initial OS2/WINDOWS support last evening, that's why those directories are there.
Then /home/retroos/BOOT
1drwxrwsr-x 3 priv-gerben retroos 4096 Aug 19 21:09 . 2drwxrwsr-x 8 priv-gerben retroos 4096 Aug 19 21:56 .. 3-r-xrwxr-x 1 priv-gerben retroos 24144 Aug 19 21:09 COMMAND.COM 4drwxrwsr-x 2 priv-gerben retroos 4096 Aug 19 21:09 DN 5-r-xrwxr-x 1 priv-gerben retroos 437024 Aug 19 21:09 KERNEL.SYM 6-r-xrwxr-x 1 priv-gerben retroos 2861 Aug 19 21:09 LOADFIX.CFG 7-r-xrwxr-x 1 priv-gerben retroos 3428 Aug 19 21:09 SHELL.ELF
My /etc/grub.d/40_custom
1cat /etc/grub.d/40_custom 2#!/bin/sh 3exec tail -n +3 $0 4# This file provides an easy way to add custom menu entries. Simply type the 5# menu entries you want to add after this comment. Be careful not to change 6# the 'exec tail' line above. 7menuentry "RetroOS (protected disk)" { 8 insmod part_gpt 9 insmod ext2 10 insmod multiboot 11 insmod efi_gop 12 set gfxmode=auto 13 set gfxpayload=keep 14 search --no-floppy --file /boot/retroos/kernel.elf --set=root 15 multiboot /boot/retroos/kernel.elf ram-overlay 16 boot 17} 18 19menuentry "RetroOS (writeable disk)" { 20 insmod part_gpt 21 insmod ext2 22 insmod multiboot 23 insmod efi_gop 24 set gfxmode=auto 25 set gfxpayload=keep 26 search --no-floppy --file /boot/retroos/kernel.elf --set=root 27 multiboot /boot/retroos/kernel.elf 28 boot 29}
I recommend to start with the ram-overlay which causes disk writes to only affect the ram-overlay and not modify the hard disk. Maybe @inagy can tell in detail his setup, but he is booting from his raspberry pi.
Tried building but not successful. I'm using the commands you mentioned in the "Build" section of README.md instead of the run.sh which I suppose is more for running compiled targets...
My host is Arch Linux based. Currently I'm using rustup and bazelisk packages from pacman.
Here's the build output with "--verbose_failures" added to bazelisk arguments regarding the error.
BTW: Before this error I had another set of errors including this following one, which went away after adding "--repo_env=BAZEL_CONLYOPTS="-std=gnu17"" into bazelisk args according to this comment. Perhaps toolchains from Arch Linux is too new for the purpose requiring some additional efforts to make workflows compatible.
1goption.c:169:14: error: two or more data types in declaration specifiers 2 169 | gboolean bool; 3 | ^~~~ 4goption.c:169:18: warning: declaration does not declare anything 5 169 | gboolean bool; 6 | ^ 7goption.c: In function 'free_changes_list': 8goption.c:1603:60: error: expected identifier before 'bool' 9 1603 | *(gboolean *)change->arg_data = change->prev.bool;
Hmm thanks for the report, maybe try "bazelisk build //:image --host_linkopt=-latomic " .
Thanks. Build process went through. However, it seems there's something not right with the finalization part, ending with errors.
Regarding the error, it tried to run "tools/dosrt/interp_tcc.sh" which involves building a COMMAND.COM with... "TCC.EXE", using "retroos-host" which I think is compiled in the previous steps.
And the process was aborted (core dumped). The "run.log" (which I cannot find a physical copy of) printed on the console says:
---- run.log ----
Storage: ata0 (1312 MB)
Block devices initialized
Platform: host=Interp vga_passthrough=false firmware=Substit […] Show full quote
---- run.log ----
Storage: ata0 (1312 MB)
Block devices initialized
Platform: host=Interp vga_passthrough=false firmware=Substitute audio=EmulatedSilent hostfs=true debug=HostStdout
Disk writes: PERSISTENT — pass `ram-overlay` to protect the disk
Threading initialized
ext4 root (1280 MB)
thread 'main' (10) panicked at kernel/src/kernel/startup.rs:359:23:
ext4 mount failed: ext4_mount failed
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Does this step of the build process require root privileges (sudo)? I'm currently running the command as normal user... though I'm afraid I need to be privileged to be able to mount or umount.
Hmm maybe your new version of ext4 tools use new features, the dormant lwext4 lib i use not support. I pushed a branch claude/ext4-mkfs-feature-pinning , that has some updates around not using newer features
Hmm maybe your new version of ext4 tools use new features, the dormant lwext4 lib i use not support. I pushed a branch claude/ext4-mkfs-feature-pinning , that has some updates around not using newer features
I'm not sure about the details. I checked the lwext4 library and it seems the repo on GitHub is at least 4 years old (with the official release being at least 10 years old).
So it's entirely possible that newer Linux kernels and extfs tools have enabled certain features by default, that were not supported by lwext4.
@LSS10999 i removed lwext4 its unmaintained and i had my own fork with bug fixes anyway. So I moved to a new ext4 implementation which should work with the new features.
@LSS10999 i removed lwext4 its unmaintained and i had my own fork with bug fixes anyway. So I moved to a new ext4 implementation which should work with the new features.
After pulling current changes from master I'm able to finish building. Not sure if I should do a clean build but at least I get an "image.bin" artifact.
Should I flash this file as-is to a USB stick so I could boot it on actual system?
And can this be mounted directly with QEMU to boot? I'm using virt-manager (libvirt) for managing QEMU VMs, though.
yes is you can build image you can boot the image with qemu, use "./run.sh qemu x64 --firmware (uefi/bios) --sound (hda/ac97/sb) (--kvm) " to boot inside qemu.
I haven't build a usb storage driver, so it can't mount usb fs. This should definitely be my next feature.
I use my linux ext4 system, ie. copy the kernel to "/boot/retroos" (tools/install_kernel.sh) add a grub entry. And make a "/home/retroos" that is interrpreted as C: .
Make sure you use "protected disk" which ensures no writes go to ext4 by adding a ram-overlay over a readonly ext4 partition,
gsoswrote on Today, 15:58:yes is you can build image you can boot the image with qemu, use "./run.sh qemu x64 --firmware (uefi/bios) --sound (hda/ac97/sb) […] Show full quote
yes is you can build image you can boot the image with qemu, use "./run.sh qemu x64 --firmware (uefi/bios) --sound (hda/ac97/sb) (--kvm) " to boot inside qemu.
I haven't build a usb storage driver, so it can't mount usb fs. This should definitely be my next feature.
I use my linux ext4 system, ie. copy the kernel to "/boot/retroos" (tools/install_kernel.sh) add a grub entry. And make a "/home/retroos" that is interrpreted as C: .
Make sure you use "protected disk" which ensures no writes go to ext4 by adding a ram-overlay over a readonly ext4 partition,
Yes, it should just be master branch on the repo. I'm currently not very good in keeping master healthy at all times, but it should work.
For hardware the model is, if it exist natively, (s)vga or sb/adlib/mpu-401, then use the hardware natively, ie. the ports are open/pass through and the games talk to hardware directly. For sb, it still traps some ports for recording so we can perfectly save and restore its state. The only thing we don't use natively is DMA as that is privileged and the paging can't guarantee contiguous and <16mb memory, so we have a virtualized DMA the games talk to that correctly re-pages the games virtual address ranges into actual contiguous low mem physical ranges.
If the hardware does not exist natively (for instance pure uefi GOP without VGA support or AC97/HDA soundcard) we fully emulate those and games don't know. For super vga modes, we do wrap the native BIOS so that we only support modes that we can fully emulate, this allows seamless switching dos-apps and presenting OSD monitor on top of playing games.