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 2026-09-21, 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 Yesterday, 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 Yesterday, 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 Yesterday, 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 Yesterday, 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.

@Solutor and @LSS I’ve updated the release with a USB image that supports both BIOS and native UEFI:

https://github.com/gerben-stavenga/RetroOS/re … ses/tag/retroos

Download retroos_grub_module.iso and write it directly to a USB stick using an
image writer (choose DD/raw mode if prompted). The older image.bin.zip is BIOS-only.

On your HP, select the UEFI USB entry in the firmware boot menu, without CSM/
CSMWrap. Start with the default Protected disk option. UEFI uses the GOP
framebuffer; BIOS boot also offers native VGA or a VBE framebuffer.

If your HD is fat then it becomes C: (if protected is chosen it has a ram-overlay)
If your HD is ext4 then /home/retroos becomes C:

gsos wrote on Yesterday, 20:50:

@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.

So how much memory can the kernel handle in theory? Is it same for both 32-bit and 64-bit?

From my experience with other OSes, practical (working) uses of PAE seem to cap at 64GB (36-bit).

Some later CPUs supported 128GB (37-bit) PAE, but not everything (e.g. device drivers) worked that way.

Right now it's limited artificially, but the kernel can theoretically handle whatever the cpu it is running on can handle. Legacy protected mode 4GB (of which 1GB is kernel address space), PAE protected mode same 4GB address space where sum total of all address spaces of concurrent processes can be total mem available on the box. For long mode the 64-bit user apps can access in principle the whole memory and 32-bit user apps can access a (3+1 GB) slice of it.

I have run some simple 64-bit linux apps from the linux distro on my machine (ls, cd, ...), but the 64 bit side is under developed.

gsos wrote on Today, 01:58:

@Solutor and @LSS I’ve updated the release with a USB image that supports both BIOS and native UEFI: […]
Show full quote

@Solutor and @LSS I’ve updated the release with a USB image that supports both BIOS and native UEFI:

https://github.com/gerben-stavenga/RetroOS/re … ses/tag/retroos

Download retroos_grub_module.iso and write it directly to a USB stick using an
image writer (choose DD/raw mode if prompted).

Ok thanks.

The older image.bin.zip is BIOS-only.

Speaking of which, it must have a not standard partition scheme, you likely used Linux, but on windows the FAT32 partition 1, is not accessible and not even formattable in fat32, (likely it's too small to be considered valid by Windows)

The partition 2 is ext4 so, normally, not accessible as well, which is not that practical for windows users.

If you really have to use a Linux FS, BTRFS could be a better choice, firstly because it has compression and other advanced features, secondly because the BTRFS driver for windows is mature, robust and easy to install, way more solid than any ext4 solution for windows I tried.

P.S. You should really choose better names for your downloads, who could figure at first sight that

retroos_grub_module = UEFI bootable ISO Image ? 😉

P.S2. most UEFI system can boot from a MBR partitioned HDD/Pendrive providing a fat32 partition is present and the correct EFI files are there, which means that if you make that partition active, and install the traditional bootloader, you can have a single image that boots either on UEFI and BIOS machines. A bit of more work required initially, but way simpler life after.

@gsos

For the record I tested the UEFI image on baremetal, no screen corruption, correct resolution.

BUT

As I feared no xHCI USB controller, hence no mouse, no keyboard, nothing else I can do.

Maybe your kernel just lacks the correct VID/PID

Just in case they are

PCI\VEN_1022&DEV_15E0&CC_0C03
PCI\VEN_1022&DEV_43BB&CC_0C03
PCI\VEN_1022&DEV_15E1&CC_0C03

for the controller

and

USB\ROOT_HUB30&VID1022&PID43BB
USB\ROOT_HUB30&VID1022&PID15E0
USB\ROOT_HUB30&VID1022&PID15E1

for the usb root.

The Solutor wrote on Today, 03:47:

The partition 2 is ext4 so, normally, not accessible as well, which is not that practical for windows users.

If you really have to use a Linux FS, BTRFS could be a better choice, firstly because it has compression and other advanced features, secondly because the BTRFS driver for windows is mature, robust and easy to install, way more solid than any ext4 solution for windows I tried.

FAT is supported. I'm currently deploying it on my main FAT32 boot partition that would be used as a starting point for booting all stuffs including old and new Windows.

Though I do agree with supporting Btrfs because my current Linux use cases mostly use Btrfs for "/home" partition while using ext4 for system.
Since RetroOS bases itself on "/home/retroos" in case of a Linux side-by-side scenario, I don't think I can easily set up this way.

I need to keep at least the "/boot" part as ext4 in a BIOS scenario, as that's what GRUB4DOS could handle when multibooting.

gsos wrote on Today, 01:58:

@Solutor and @LSS I’ve updated the release with a USB image that supports both BIOS and native UEFI: […]
Show full quote

@Solutor and @LSS I’ve updated the release with a USB image that supports both BIOS and native UEFI:

https://github.com/gerben-stavenga/RetroOS/re … ses/tag/retroos

Download retroos_grub_module.iso and write it directly to a USB stick using an
image writer (choose DD/raw mode if prompted). The older image.bin.zip is BIOS-only.

On your HP, select the UEFI USB entry in the firmware boot menu, without CSM/
CSMWrap. Start with the default Protected disk option. UEFI uses the GOP
framebuffer; BIOS boot also offers native VGA or a VBE framebuffer.

If your HD is fat then it becomes C: (if protected is chosen it has a ram-overlay)
If your HD is ext4 then /home/retroos becomes C:

I just tested on my system but no difference. Still hangs. Some further contexts:

I've a fully working dISAppointment v0.2 setup on that system, with a Sound Blaster 16 PnP (CT2950) behind it. The card is not accessible by default. I need to set up proper I/O forwarding to the LPC bus to make the card accessible and configurable via UNISOUND. As such, the boot process usually involves booting to DOS (Win98SE's MS-DOS 7.10 is sufficient) with no device drivers, run the programs that I use to set up the necessary registers, run UNISOUND to initialize the card, and finally launch GRUB4DOS to boot the RetroOS kernel. As such, the boot environment may be a bit dirty but most OSes (including WinNT family) that I'd like to use the ISA sound card with are tolerant enough not to encounter any issue. Additionally, if initialized via UNISOUND beforehand, a PnP Sound Blaster compatible card can then use non-PnP Sound Blaster drivers.

I don't know if RetroOS kernel can do the following customizations through a config file during initialization:
- Configure certain PCI configuration register values.
- Write to I/O ports. (DMA registers need to be cleared for LPC/ISA DMA to work correctly on most supported boards.)
- Initialize PnP Sound Blaster compatible cards similar to UNISOUND.

On my board I've disabled its onboard HDA because it explicitly wanted IRQ7 which I'm using it for the Sound Blaster 16 card.
I cannot use IRQ5 on that system because almost all onboard devices wanted it. Disabling the HDA allowed IRQ7 to be free as other onboard devices don't seem to prefer it.
So on that system the only way to enable sound for now is through the Sound Blaster card which I need to initialize before I could use.

I'm not sure if in the future additional sound card support can be added. I'm currently using a PCIe Sound Blaster clone that appears to the system as an Audigy (SB0090) on that system.
EMU10Kx family is well supported across many OSes (Windows, Linux, Haiku/BSD, etc.). The Sound Blaster clone actually works on Win98SE using Audigy VxD drivers.

Anyway, I'm going to try this on my other systems as this one isn't going anywhere for now...

BTW: Can RetroOS load DOS TSRs? Actually, on one system I need to use EGAFIX and NEWAX to patch crippled VGA and VESA functionalities of my nVidia video card. Otherwise games may not work correctly. If not, perhaps I need to assess the performance of the software VBE/GOP framebuffer...