Installed in vmware 20H1 and worked w/o problems at the first try

I didn't expect it had even Glide support. So if the good day is seen from the morning... 😉

LSS10999 wrote on Yesterday, 07:33:

I just noticed you've updated the artifacts in the Release. […]
Show full quote

I just noticed you've updated the artifacts in the Release.

I'm a bit confused. The "machine" package seems to suggest I need to run this from... an existing Linux install with ext4?

Originally I considered putting kernel.elf on the same boot partition (FAT32) that I used for everything from DOS to Windows just I wasn't able to boot it using GRUB4DOS' "chainloader". Will consider trying booting it using "kernel" directive again but what do I need to put in the folder that would be "C:\RETROOS".

I'm currently assuming "C:\RETROOS" would be the exact folder on my DOS boot partition (FAT32), but some docs seem to suggest this folder be virtual and read-only so I'm not sure...

I kind of understood the details after reading the BOOTING.md.

I tried to actually boot the kernel via GRUB4DOS after extracting machine_boot.tar to my target machine's main boot partition (FAT32), using "kernel" directive with "ram-overlay". It launched but alas it failed to boot.

1!!! FATAL !!!
2at arch-metal/src/traps.rs:1054
3Unhandled exception in arch: int=0x6 err=0x6 at 0x0008:0xc0ba3a60
4
5RetroOS kernel master-pre-ff-20260807-224-g48643746*
6Stack trace:
7   0: 0xc0ba4427
8   1: 0xc0bbea97
9   2: 0xc0b9ee42
10   3: 0xc0bbe1aa

(Written down manually after taking the photo of the error message on the screen.)

Not sure if this error message contains any possible hint. I'm testing this on my X99 system and the SATA disks are AHCI.

I uploaded new kernel. Unfortunately I compiled with panic=immediate which prevented rust panics to give information, the new kernel has panic enabled so these rust "ud2" aborts come with info. The most likely cause is the number of scratchpad buffers (I used a fixed number) for xHCI USB. I made that dynamic so maybe it would work now, otherwise there is likely an informative panic message.

Yes, voodoo is supported, the whole OS is becoming quite complete for DOS. Going forward, I would love to add internet support (and things like null-modem over internet), multi-core support, a real GUI composting framework and more complete OS2, Windows and linux personalities. One can dream.

@gsos

One minor thing that drives me crazy is the commander style file manager, why F10 brings up the menu instead of exit, while F9 does nothing instead of calling the menu?

Not sure about what NC did, but I assume that the ubiquitous Midnight Commander cloned the F functions as they were.

gsos wrote on Today, 02:44:

I uploaded new kernel. Unfortunately I compiled with panic=immediate which prevented rust panics to give information, the new kernel has panic enabled so these rust "ud2" aborts come with info. The most likely cause is the number of scratchpad buffers (I used a fixed number) for xHCI USB. I made that dynamic so maybe it would work now, otherwise there is likely an informative panic message.

Yes, voodoo is supported, the whole OS is becoming quite complete for DOS. Going forward, I would love to add internet support (and things like null-modem over internet), multi-core support, a real GUI composting framework and more complete OS2, Windows and linux personalities. One can dream.

The updated kernel booted, but hangs right after the hello message. Keyboard (like pressing CAPS LOCK) doesn't seem to respond at this point.

1RetroOS Rust Kernel
2kernel_phys: 0x100000
3Physical memory: 0xfcba pages free
4Memory regions: 18
5  Available: 0x0 - 0x9e800
6  Available: 0x100000 - 0x5ab2b000
7  Available: 0x5b88d000 - 0x5bb0e000
8  Available: 0x5cf9e000 - 0x5cf9f000
9  Available: 0x5d025000 - 0x5d288000
10  Available: 0x5dff9000 - 0x5e000000
11  Available: 0x100000000 - 0x20a0000000
12Interrupts initialized
13Stack guards at 0xc0bef000 (kernel) 0xc0c6f000 (arch)
14
15Hello from Rust Kernel!

The cursor blinks at the beginning of the "Stack guards" line. Not sure what might be causing the hang. I'm booting this off my main boot partition (that would be C: from DOS), and necessary files are present in the RETROOS folder in its root (so it would be C:\RETROOS).

Should point out that my X99 system currently has 128GB memory installed, and the system memory layout is a bit sophisticated and only about 1.4GB is available below 4GB boundary.

BTW: I also tried booting without "ram-overlay" argument. Still hangs, no difference.

Is that ELF a 64-bit or a 32-bit kernel?

@Solutor I agree—the NC key bindings are what I grew up with too. I initially
used Norton Commander, but it isn’t free to redistribute. DOS Navigator is,
and it’s a nice file manager in its own right. Exiting it currently just
restarts it anyway.

I’ve added a START=C:\AWESOME\FILEMAN.EXE setting in C:\CONFIG\CONFIG.SYS, so
you can point it at your own copy of NC or any other file manager. DN isn’t
RetroOS itself; I just think those old-school orthodox file managers suit it
well as a UI.

By the way, how are you finding it? RetroOS is meant to run on bare metal and
let our favourite old games run directly on the hardware. Feedback and
suggestions are very welcome!

@superfury it's 32bit, with a tiny bit of 64bit code to handle entry from 64bit apps.

@LSS10999
It seems it hangs at the pit programming. Very weird. That was the final boot log line?

gsos wrote on Today, 14:03:

@Solutor I agree—the NC key bindings are what I grew up with too. I initially
used Norton Commander, but it isn’t free to redistribute. DOS Navigator is,
and it’s a nice file manager in its own right.

I see, I wasn't aware it was an external, existing, program. I thought was part of your work

Exiting it currently just
restarts it anyway.

Sure, but F10 isn't normally just to close the whole program, it also works to exit the editor and/or the viewer

P.S. I tested the image on baremetal and the system hangs with with garbled screen.

Not that I had much hope, given that machine (HP elitedesk 705) is complicate on it's own, It has a buggy CSM (so I use CSMwrap), it has only xhci usb ports, and it's Ryzen 1AMD machine, which usually means a bit of additional complications over contemporary Intel machines.

@Solutor try to boot without CSM/CSMWrap. My laptop is a razer amd without csm so i boot in pure uefi.

gsos wrote on Today, 14:38:

@Solutor try to boot without CSM/CSMWrap. My laptop is a razer amd without csm so i boot in pure uefi.

Not that I had much time to dedicate to the matter, but the image, as is, won't boot in UEFI mode, in bare metal and in VMware, likely I have to spend more time reading your github pages.

BTW In the meantime I see you uploaded a new release, I'll try it ASAP.

gsos wrote on Today, 14:03:

@LSS10999
It seems it hangs at the pit programming. Very weird. That was the final boot log line?

Yes. That was everything.

The cursor blinks on the "Stack guards" line and did not proceed any further from there. Keyboard no longer responds.

But 64-bit code won't run on the legacy 32-bit (80386,486,Pentiums) machines? So the ELF will crash on that if it tries to run 64-bit code? Or is it simply unused code in that case (some unused 64-bit to 32-bit glue)?

@superfury indeed, the kernel itself is 32-bit. If it detects a 64-bit capable cpu it allows executing 64-bit user space code, with the kernel running in 32-bit compat mode, only the interrupt/syscall entry code has a 64-bit variant which is just not used for 32-bit cpu's. Because the PAE and LM page tables are practically identical, the kernel internally switches between regular protected mode with PAE and long-mode in 32-bit compat mode using the same page tables (just PML4 is substituted for PDPT and vice versa, leaving the linear address space identical). This way it can still support VM86 real mode apps together with 64-bit apps.