superfury wrote on 2026-09-28, 16:15:

Rn you'd need an OS to setup the partition and the boot loader on the disk from what I can see? There aren't any tools included that can do this without an OS already installed (afaik that's Linux). Hence why you'd need included software to partition the hard drive (to FAT or Linux filesystem) and at least copy the boot configuration over (install GRUB or something compatible from what I've read here). Without any of those, the elf is unusable. If you don't have Linux (or a flavour of it) already installed, you can't even use the elf to boot (due to missing GRUB and no partitions configured for use).

You need that in case you want to setup a permanent install, and IMO is not yet time to do that.

But even if you wanted to do that, Linux is available in live setup since two decades, bootable windows like hiren's boot CD are available as well, so still no need of an already installed OS.

Then is matter of personal need's/preferences and skill level, as usual.

All you need is a FAT32 partition to store settings, and additional SW. But that's optional, you can use RetroOS and play Doom/Quake/whatever is included in a machine with no HDD

LSS10999 wrote on 2026-09-28, 11:51:

I just tested RetroOS on an older AMD based system (ASUS KGPE-D16) and it booted as well.
Not sure if the issue really was the HPET. But right now all my success cases are AMD ones and none of my Intel systems are booting.

Albeit really old (end of XP / beginning of Vista era), my Acer-5104 (Turion X2 / ATI Xpress 1100) shows a black screen after a really short moment when moment I can read the logs (likely the black screen comes when DN tries to start), so we have at least one AMD machine that doesn't work as expected. 😉

The Solutor wrote on 2026-09-28, 11:08:

For now, given the noumerous problems faced b LSS, I decided to test what happens on my Homeserver/HTPC which is based on a N100 […]
Show full quote

For now, given the noumerous problems faced b LSS, I decided to test what happens on my Homeserver/HTPC which is based on a N100 CPU

This to be precise

https://www.asus.com/motherboards-components/ … ime-n100i-d-d4/

And nothing, it boots and what I got is a 2cm white stripe on the top of the screen, and nothing else. (tested only in UEFI mode given I don't have CSMWrap installed there)

In short, this project seems one of the rare cases where AMD got more love than Intel, not that I don't like that (the N100 is the second Intel CPU that enters my home in 4 decades).

But still, I guess gsos needs some Intel HW to do some tests in person and enlarge the audience of the project.

The white stripe is shown when RetroOS rejects the GOP framebuffer provided and it cannot render boot log text.

What is the mode grub gives RetroOS on your machine? On that machine, pressing c at the GRUB menu and running videoinfo would show the modes GRUB sees (if you could provide a picture of available modes that might help). The decisive evidence is the mode actually passed to RetroOS, width, height, pitch, bits per pixel, and RGB masks

The Solutor wrote on 2026-09-28, 16:30:

LSS10999 wrote on 2026-09-28, 11:51:

I just tested RetroOS on an older AMD based system (ASUS KGPE-D16) and it booted as well.
Not sure if the issue really was the HPET. But right now all my success cases are AMD ones and none of my Intel systems are booting.

Albeit really old (end of XP / beginning of Vista era), my Acer-5104 (Turion X2 / ATI Xpress 1100) shows a black screen after a really short moment when moment I can read the logs (likely the black screen comes when DN tries to start), so we have at least one AMD machine that doesn't work as expected. 😉

What mode is this? Can you try "Boot diagnostic + native bios" mode (protected disk), that one stops before DN so you can take a pic of the log on the screen.

gsos wrote on 2026-09-28, 16:34:

The white stripe is shown when RetroOS rejects the GOP framebuffer provided and it cannot render boot log text.

What is the mode grub gives RetroOS on your machine? On that machine, pressing c at the GRUB menu and running videoinfo would show the modes GRUB sees (if you could provide a picture of available modes that might help). The decisive evidence is the mode actually passed to RetroOS, width, height, pitch, bits per pixel, and RGB masks

I'm going to test when I can shutdown the machine but IIRC is more or less the same list seen by Arandr under Linux

The only bit strange one is 1360x768 thing (learned very recently that the origin of this is 1360x760x8bpp fits in 1MB while 1366x760x8bpp does not)

I updated the white bar with a pattern that indicates what is wrong with the frame buffer

gsos wrote on 2026-09-28, 03:56:

@LSS10999: I added better hpet ahci detection perhaps that is the problem for your system.

Tested. Sadly this doesn't fix boot on my X99. Hangs the same place except I see the new line mentioning the HPET.
My B75 and H97 systems aren't booting, either. Same symptom.

1HPET: ACPI base 0xfed00000 (Multiboot2 ACPI tag)

This is the only difference compared to the previous build.
NOTE: If I'm booting a locally deployed kernel.elf with GRUB4DOS (via "kernel" directive), the HPET line reads (firmware memory scan) instead of (Multiboot2 ACPI tag), but no real difference (ACPI base is the same).

Anyway, I'd like to see the issue with multiple storage controllers resolved so I can further test it on my AMD systems (where RetroOS can boot) with my own stuffs.
Ideally, with adequate documentation on how one can manually deploy the kernel and base data, and set up GRUB entries.

I tried the iso from the last version I downloaded with my x86 emulator (which uses a ET4000/W32i graphics card setup). I get some text display for a bit when the OS boots, then some graphical mode, after which I get a green 1 or 2 lines on the top of the display with some weird pattern in it (which isn't regular)?

I added support for multiple disks, and a installer. It is still linux installer but on btrfs it can install the kernel.elf on your btrfs /boot and adds a grub entry.
The C: will be a fat32 or ext4 with /home/retroos directory, if multiple are possible "--c-uuid=...." and "--c-dir=..." you can select your wanted setup.

I'm afraid there is a regression.

My AMD machine wont boot anymore (black screen)

The intel server went from a white stripe to this (Top-Left corner of the screen)

Perhaps I think it's about time to do some versioning in file names, now that builds are piling up, taking track of releases starts to be complicate.

gsos wrote on 2026-09-29, 15:37:

I added support for multiple disks, and a installer. It is still linux installer but on btrfs it can install the kernel.elf on your btrfs /boot and adds a grub entry.
The C: will be a fat32 or ext4 with /home/retroos directory, if multiple are possible "--c-uuid=...." and "--c-dir=..." you can select your wanted setup.

I've succeeded in setting up a locally deployed environment on my main X570 system, and it successfully picked up the partition I used to store my own games and data for RetroOS use.
So multiple disks support is working in my case.

However, I noticed games would complain about unable to read or write files, and it doesn't matter whether I use Protected Disk or Persistent Disk.
Not sure why, but considering I'm using ext4 for the backing partition, I wonder if I need to set permissions and ownership to something special from Linux...
I recall something about "retroos" group was mentioned in the docs. However, right now the partition's ownership (user:group) are set to my main Linux user so I don't need to be root to manage stuffs there.

As I'm booting via UEFI, the GOP framebuffer looks a bit better now, but text mode rendering is still not 100% perfect.

Despite the issues with file reading (mostly affects setup programs that manages configuration files), some games can be actually run at this point:
- Bio Menace
- Jazz Jackrabbit
- Rampart
- Skunny 32-bit
- Nova 9
- Arya Vaiv

I do have a few games that currently cannot run due to the aforementioned file access issue, which needs to be resolved before I can validate them.

I don't have anything to further validate OS/2 or Windows personalities yet. Not sure if it can eventually reach the point of running things like Program Manager.

BTW: How do I make changes to some default configuration values? Put my own CONFIG.SYS (e.g. /home/retroos/CONFIG/CONFIG.SYS) in my backing partition?
The issue right now is that, I need to set the mixer volume to 100% and output to "Jack" instead of "Headphone" for proper audio playback.

Does RetroOS support early SVGA adapters, like Tseng (ET3000AX, ET4000AX, W32(i)) or the like? They have extended registers (past the VGA standard) and also a segment select register for mapping VRAM into user address space (sort of like EMS does).
My implementation has a SVGA DAC (up to 24-bit color), but it's unusable if the VRAM isn't properly addressed using the 3CDh register for accessing the whole megabyte or more of VRAM (anything past 256KB of VGA VRAM).

@The Solutor: Those 4 stripes mean grub is giving a resolution that's too low 640x400 or so. Maybe you can instruct grub to give a higher resolution framebuffer. I made a number of stripes instead of a single white bar to indicate why the GOP framebuffer is rejected

@Superfure: I'm unable to get unipcemu working, i dont have good roms it seems. Where do i get them. Ps you can dm me with your setup so i can make it work with unipcemu

I use SVGA through BIOS. Whatever modes the bios exposes RetroOS re-exposes to DOS apps as opaque modes. DOS can only interact with them through BIOS calls (that are forwarded to the actual bios) and not through any ports.

for the failing intel machines, maybe someone can run retroos with qemu/kvm (run.sh qemu --arch x64 --kvm --sound hda --firmware uefi), this will execute retroos on intel hardware using virtualization.

A question about MIDI support. Is it powered by soundfont? If so, how can I specify a soundfont that I'd like to use?

I didn't see any soundfont in the RetroOS base data but I did see some GUS patches in the ULTRASND folder...

LSS10999 wrote on 2026-09-30, 04:58:

A question about MIDI support. Is it powered by soundfont? If so, how can I specify a soundfont that I'd like to use?

I didn't see any soundfont in the RetroOS base data but I did see some GUS patches in the ULTRASND folder...

Right now it uses ultramid patches for midi, having a separate soundfont is a todo

LSS10999 wrote on 2026-09-29, 18:18:

I've succeeded in setting up a locally deployed environment on my main X570 system, and it successfully picked up the partition […]
Show full quote

gsos wrote on 2026-09-29, 15:37:

I added support for multiple disks, and a installer. It is still linux installer but on btrfs it can install the kernel.elf on your btrfs /boot and adds a grub entry.
The C: will be a fat32 or ext4 with /home/retroos directory, if multiple are possible "--c-uuid=...." and "--c-dir=..." you can select your wanted setup.

I've succeeded in setting up a locally deployed environment on my main X570 system, and it successfully picked up the partition I used to store my own games and data for RetroOS use.
So multiple disks support is working in my case.

However, I noticed games would complain about unable to read or write files, and it doesn't matter whether I use Protected Disk or Persistent Disk.
Not sure why, but considering I'm using ext4 for the backing partition, I wonder if I need to set permissions and ownership to something special from Linux...
I recall something about "retroos" group was mentioned in the docs. However, right now the partition's ownership (user:group) are set to my main Linux user so I don't need to be root to manage stuffs there.

As I'm booting via UEFI, the GOP framebuffer looks a bit better now, but text mode rendering is still not 100% perfect.

Despite the issues with file reading (mostly affects setup programs that manages configuration files), some games can be actually run at this point:
- Bio Menace
- Jazz Jackrabbit
- Rampart
- Skunny 32-bit
- Nova 9
- Arya Vaiv

I do have a few games that currently cannot run due to the aforementioned file access issue, which needs to be resolved before I can validate them.

I don't have anything to further validate OS/2 or Windows personalities yet. Not sure if it can eventually reach the point of running things like Program Manager.

BTW: How do I make changes to some default configuration values? Put my own CONFIG.SYS (e.g. /home/retroos/CONFIG/CONFIG.SYS) in my backing partition?
The issue right now is that, I need to set the mixer volume to 100% and output to "Jack" instead of "Headphone" for proper audio playback.

And about my current test results. Is there any requirement on the ownership/permissions in the ext4 backing partition?

Right now games complain about being unable to read or write files, regardless of Protected or Persistent disk modes.

My ext4 backing partition is currently owned by my main Linux user so I don't have to be root to manage files in Linux. What permission does RetroOS require for proper read/write access by games and such?

RetroOS takes its write identity from the group ID of the selected C: directory (/home/retroos by default). To write an existing file, that file must have the same group ID and the group-write bit. Creating a file requires those conditions on its parent directory. This applies in both Protected and Persistent modes (I want to prevent accidental modification of the ext4 system outside of the dos designated directory.

AI:
On Linux, after mounting that partition, check the actual C: directory and a failing game file:

stat -c '%n owner=%U group=%G mode=%a' /path/to/home/retroos /path/to/home/retroos/GAMES /path/to/home/retroos/
GAMES/FILE

For a dedicated RetroOS C: directory, this grants its current group access throughout:

C=/path/to/home/retroos
sudo chgrp -R "$(stat -c %g "$C")" "$C"
sudo chmod -R g+rwX "$C"
sudo find "$C" -type d -exec chmod g+s {} +

gsos wrote on 2026-09-30, 00:54:

@The Solutor: Those 4 stripes mean grub is giving a resolution that's too low 640x400 or so. Maybe you can instruct grub to give a higher resolution framebuffer. I made a number of stripes instead of a single white bar to indicate why the GOP framebuffer is rejected

I wish it was that simple, the fact is your strange layout on the pendrive prevents from doing test easily

fdisk still isn't happy

1welcome to fdisk (util-linux 2.41.3).
2Changes will remain in memory only, until you decide to write them.
3Be careful before using the write command.
4
5GPT PMBR size mismatch (115191 != 30233587) will be corrected by write.
6The device contains 'iso9660' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.

And if I save anything fdisk corrects the partition table screwing the system

HPFS is a problem because to mount it RW I need more space, to get more space I need to use fdisk, so I'm in a closed loop.

Perhaps Isn't clear to me where the actual manu.lst (or whatever else configuration file) is actually located.

Windows, like I already wrote, don't like that partition table at all.

And no, I can't try to install the system on my N100 machine, it's a server, it's meant to stay up h24, so I can do quick tests when I can, but I can't risk to screw up things, if something goes wrong.

Perhaps, for some reason my current grub installed there lacks any videoinfo/vbeinfo commands, so I need to check those info using a bootable linux distro, something that I will do when I can, which means not ASAP.

A more standard layout with a fat32 boot partition, and a ext4/fat32 main partition and a fixed partition table would be very helpful to bisect problems

gsos wrote on 2026-09-30, 07:53:

RetroOS takes its write identity from the group ID of the selected C: directory (/home/retroos by default). To write an existing […]
Show full quote

RetroOS takes its write identity from the group ID of the selected C: directory (/home/retroos by default). To write an existing file, that file must have the same group ID and the group-write bit. Creating a file requires those conditions on its parent directory. This applies in both Protected and Persistent modes (I want to prevent accidental modification of the ext4 system outside of the dos designated directory.

AI:
On Linux, after mounting that partition, check the actual C: directory and a failing game file:

stat -c '%n owner=%U group=%G mode=%a' /path/to/home/retroos /path/to/home/retroos/GAMES /path/to/home/retroos/
GAMES/FILE

For a dedicated RetroOS C: directory, this grants its current group access throughout:

C=/path/to/home/retroos
sudo chgrp -R "$(stat -c %g "$C")" "$C"
sudo chmod -R g+rwX "$C"
sudo find "$C" -type d -exec chmod g+s {} +

Well it seems the most straightforward way is to simply "sudo chmod -R 777" everything inside "/home/retroos" on the backing partition. After that games stopped complaining about file access.
However, it is very dangerous to casually "chmod -R 777" on modern day Linux because many security-sensitive software would explicitly refuse to access certain files if they are "world-writable" (or in any other permission setting than the one it expects), so you may accidentally break the system this way. Not sure if using just "chmod -R 775" (granting write only to owner and group) is enough.

PS: It seems for some reasons RetroOS would not update the timestamps of files upon modification, according to DN output, so I cannot immediately tell whether a file has been successfully modified. Files can be correctly modified if permissions are set correctly.

And I just found out that for some reasons RetroOS' boot entry only overlaid the RETROOS folder itself, not other stuffs in the base image, so I had to manually copy other folders than RETROOS from the base image to the backing partition. CONFIG.SYS kind of worked for setting default mixer volume to 100 but still cannot fix the issue with my system's HDA where it would always default to "Headphone" and I always have to manually switch to "Jack".

I'm able to test a bit further but noted some apparent issues.
- In GOP Framebuffer, text mode fonts looks rough, and the VGA rendering has some artifacts that are very apparent with smaller texts ingame, though barely noticeable otherwise.
- Bio Menace crashes (back to DN) when killing an enemy. I'm using the patches here to resolve bugs that occur in native DOS.
- TerraFire crashes the whole system (black screen and hangs) upon exit. AstroFire exited fine, however.*
- Terminal Velocity's SETD crashes the whole system (black screen and hangs) when testing sound card. The game itself cannot start citing failing to load the sound driver.
- Skunny 32-bit gets stuck on a black screen upon exit but can be killed via F12 menu. (EDIT: It seems one of the versions is not affected by this, and exited fine.)
- Nova 9's opening cinematics would make the screen turn black (and silent). The game can proceed fine after pressing keys like ENTER to skip the cinematics in question.
- Titus the Fox cannot detect emulated Sound Blaster and would use PC Speaker instead.
- Some programs simply don't run, with DN showing something like status code 05 or something briefly in the background (not sure how to hide/show the DN window).
- Stargunner runs but no sound and no keyboard input, and needs to be killed via F12 menu.
- Only 8-bit mixing works correctly in Wacky Wheels. The distorted sound I once encountered was due to using 16-bit mixing.
- Death Rally doesn't seem to run (black screen) correctly and has to be killed via F12 menu.
- Jill of the Jungle works fine after patched.**
- Sound in Duke Nukem 2 does not work out-of-box and requires patching and replacement PCM samples.***

* ORT Software DOS games like TerraFire and AstroFire had Windows installers and were meant to be played from a Windows DOS box, as upon exit it launches something in Windows for showing ordering info (for shareware versions). I'm not sure if RetroOS' Windows personality may have done anything, but normally in a pure DOS one would simply see a message saying "This program can't be run in DOS mode."
** The patch is required for the first game to have proper Sound Blaster output, while optional for the other two. However, it seems the patch contains additional fixes needed for correct operation inside RetroOS so I'll have to patch the other two games as well. Without patching the game feels extremely sluggish.
*** So RetroOS' Sound Blaster emulation doesn't support ADPCM. IIRC not all Sound Blaster compatible sound cards implemented that.

On the other hand, SDLPAL DOS Port works if using VGA mode (DOSForceMode13h=1 + DOSLowEndOpt=1). Using OPLCore=NUKED is recommended here.
It doesn't run in default (VESA) mode. Perhaps GOP Framebuffer is only good enough for VGA at the moment.