gsos wrote on 2026-10-01, 04:01:

HDA_OUTPUT=Jack in C:\CONFIG\CONFIG.SYS selects the Jack route.

This doesn't work, and IIRC the default CONFIG.SYS set it to "Speaker" which doesn't exist.

Here's an excerpt of the KLOG related to HDA. Not sure if it gives any hint on why "Headphone" is taking precedence regardless of settings.

1hda: amp pin gain=0x0 dac gain=0x57
2hda: state pinctl=0xc0 eapd=0x2 pinamp=0x0 dacamp=0x57 pinpwr=0x0 dacpwr=0x0 pinsel=0x0
3hda: selected 0e:00.4 codec=0x10ec1220 pin=nid27 dac=nid2
4hda: path len=3 score=645 nodes=1b>0c>02>00>00>00 conn=0,0,0,0,0

Terminal Velocity now works, including SVGA mode. With current kernel I don't reproduce the hang (possibly a panic) in SETD so I can set up everything with ease.
CD cinematics playback don't seem to work.

Some weird behaviors compared to native DOS:
- Planet overview (rotating stars and the planet) during the briefing moves very slowly. Enemy overview (that shows the surface) looks fine in comparison.
- When pressing ESC to return to main menu, if I don't press Y or N within about 3 seconds the game crashes (back to DN).
- The ship has a tendency to keep turning towards the direction you previously pressed so I often need to press the opposite direction to stop it.
- Projectiles (e.g. PAC) move a bit differently. Like, if you just pressed UP to look down, the projectiles move even further downwards to the ground than usual. Feels like some "constants" used to calculate projectile movement differ in this environment. In any case, I find it more difficult to hit accurately than when playing in native DOS.

Now that boot log in GOP mode is visible I suspect the "hangs" were actually panics.

When exiting AstroFire after playing it a bit, I got:

1!!! FATAL !!!
2at arch-metal/src/traps.rs:1054
3Unhandled exception in arch: int=0xd err=0x60 at 0x0008:0xc0bdccf5
4
5RetroOS kernel retroos-1-gb3bcc0b3
6Stack trace:
7   0: 0xc0bc15c4 lib::term::screen_text+0x0
8   1: 0xc0bdcc97
9   2: 0x00011202

And here's another panic I got from a vertical shooting game called Duck.
Happens before entering the main menu after the intro animations.

1RetroOS kernel retroos-1-gb3bcc0b3
2Stack trace:
3   0: 0xc0bc15c4 lib::term::screen_text+0x0
4   1: 0xc0b0b065 arch_metal::traps::arch_dispatch+0x0
5   2: 0xc0b0a238 isr_handler+0x6d8
6   3: 0xc0bdcc97
7   4: 0xc0b4b3e1 kernel::kernel::dos::dosabi::rm_ctrl_dispatch::<arch_metal::backend::Metal>+0x11a4
8   5: 0xc0b44c57 kernel::kernel::dos::handle_event::<arch_metal::backend::Metal>+0x65a
9   6: 0xc0b964e7 <kernel::kernel::thread::Personality<arch_metal::backend::Metal>>::handle_event+0x42
10   7: 0xc0b952b5 kernel::kernel::startup::dispatch::<arch_metal::backend::Metal>+0x107
11   8: 0xc0b91182 kernel::kernel::startup::event_loop::<arch_metal::backend::Metal>+0x3abc
12   9: 0xc0bbc51c kernel::kernel::startup::run_program_with_screen::<arch_metal::backend::Metal>+0x9e
13  10: 0xc0bbc907 kernel::kernel::startup::run::<arch_metal::backend::Metal>+0x3ac
14  11: 0xc0bbd13c __rustc::__rust_realloc+0x0
15  12: 0xc0bbd61b kernel::boot::prepare_boot+0x0
16  13: 0xc0bdc3aa

Not sure if these reveal any bugs or not yet implemented stuffs...

Ok.

Some news.

On my AMD machine, the black screen introduced in the latest releases is gone.
The system boots, but it doesn't go past the initial screen, with the last line saying that KLOG.TXT is saved.

Speaking of witch, it is saved with no timestamp, so I can't be sure if it related on the last boot or it's there from previous releases.

On my N100 server, finally the system booted (not sure if the intended resolution or just 800x600, but it booted), it arrives correctly to the DN screen, but then I have no keyboard working despite I actually I have 3 connected (a proper USB keyboard, cheap a wireless mini keyboard, and a MX3 remote, that acts also as a keyboard).

Perhaps, like I said earlier, on my AMD machine when older releases worked, only one of my two USB keyboard worked, so that's an area that deserves some more love.

Say is there any way to control what resolution gets passed to fbcon?
With GOP framebuffer I noticed fbcon is always using 800x600 according to the KLOG, even though I could force as high resolution as 1920x1080 in GRUB.
At 800x600 text mode fonts don't look very good and I'm trying to pass a different resolution in hope to improve it somehow...

EDIT: Disabling CSM allowed me to use higher resolutions including 4K which is my monitor's native resolution. However, when using a widescreen resolution, the DOS window maintains aspect ratio leaving the borders untouched, which is not what I'd like to see, as whatever these areas had is not cleared so the borders grow messier over time. With CSM enabled the system would either use 800x600 or 1024x768, with the text mode font look slightly better when in the latter resolution.

Regardless, the resolution fbcon can use can be unpredictable depending on the resolution initially used by the bootloaders.
Enabling CSM limits what resolution I could use. For now the only need for CSM on that system is to boot to my FreeDOS partition that I'm currently using for testing SBEMU (with VDPMI).
And through all the testing, looks like RetroOS is good enough to be a better solution eventually.

For linux is
set gfxpayload=keep

No idea if it works here

The Solutor wrote on 2026-10-01, 09:47:

For linux is
set gfxpayload=keep

No idea if it works here

I kind of figured out a bit. If I replace this portion:

1insmod all_video
2set gfxmode=auto
3set gfxpayload=auto

With what you said:

1set gfxpayload=keep

Then RetroOS uses whatever mode GRUB is in.

For now I'm using 1400x1050 which is accessible when CSM is off. Looks a bit better but still not ideal.
At present, RetroOS only occupies the entire screen when a 4:3 resolution (or 1280x1024) is specified.

On the other hand, 1920x1080 is only accessible when CSM is on for some reasons.

And here are some more test results that seem to have issues with sound.
- Tyrian 2000 runs with only FM music and no sound effects.
- Death Rally only runs with sound disabled in SETUP. Previously it hangs if sound is enabled.

LSS10999 wrote on 2026-10-01, 11:41:

Then RetroOS uses whatever mode GRUB is in.

Yes that's the idea

GRUB_GFXMODE=auto

or (say)

GRUB_GFXMODE=1024x768x32

Tels grub which resolution to use

then
GRUB_GFXPAYLOAD=keep
or
GRUB_GFXPAYLOAD_LINUX=keep

ask to proceed using whatever already configured above

P.S. the GRUB_ part and the _LINUX part may be needed or not, it's the usual mess of the *nix camp where people enjoy to change paths, switches, configuration files, just to complicate the life of users. A behavior that exist since the early days when forks and competing Unixes were dozens, and each one tried to be "the smartest guy of the classroom" 😁

Ah some progress 😁 "it's the usual mess of the *nix camp where people enjoy to change paths, switches, configuration files, just to complicate the life of users" ain't this the truth.

@Solutor I will look at the USB peripherals detection/initialization.

@LSS I'm optimizing kernel display path for old systems that struggle and in the process i removed unnecessary clearing which caused the mess on the borders (I'm aware) which should be cleared once at the appropriate transitions, which will be fixed shortly. But on the question of borders, I purposefully try to maintain the original aspect ratios and don't like the stretched look. What would you like? Just an option to stretch or just cleared borders is fine?

The main problem is that RetroOS runs code natively. It runs orders of magnitude faster. I suspect TV kinematics uses euler forward for projectile kinematics with a delta T based on fps that is pushed in limit where things get clamped and gets wrong dynamics. Also sound detection for some programs is broken due to interrupts arriving too fast or internal time calibration loops overflowing. I'm still brewing on good robust solutions for these problems.

LSS: "And through all the testing, looks like RetroOS is good enough to be a better solution eventually"
This would make me very happy, if RetroOS helps preserve retro computing experience for a few more generations.

gsos wrote on 2026-10-01, 13:52:

@LSS I'm optimizing kernel display path for old systems that struggle and in the process i removed unnecessary clearing which caused the mess on the borders (I'm aware) which should be cleared once at the appropriate transitions, which will be fixed shortly. But on the question of borders, I purposefully try to maintain the original aspect ratios and don't like the stretched look. What would you like? Just an option to stretch or just cleared borders is fine?

Personally I prefer DOS programs fill the entire screen, so an option to stretch to the entire screen would be good.

The GOP framebuffer code path looks well optimized, as games can still run smooth even at my monitor's native resolution (3840x2160, need CSM turned off to access it).
In comparison, GRUB struggles to draw and respond to keypresses when running in such high resolutions.

gsos wrote on 2026-10-01, 13:52:

@Solutor I will look at the USB peripherals detection/initialization.

Thanks but if you have an idea about why I can get past this on my machine...

(deleted the klog before trying to boot, so I'm sure the log is current)

Spoiler

VME enabled
SYSCALL enabled
[96mRetroOS Rust Kernel[0m
Paging: PAE (64-bit entries)
CPU supports Long Mode (64-bit)
Long mode tables set up
Identity mapping removed
NX (No-Execute) protection enabled
PAT: Write-Combining slot enabled (framebuffer)
Hardening kernel:
.text: 0xc0b00000-0xc0bdd000 (pages 789248-789469): R-X
.rodata: 0xc0bdd000-0xc0c06000 (pages 789469-789510): R-- NX
.data: 0xc0c06000-0xc0c84000 (pages 789510-789636): RW- NX
Kernel hardening complete
kernel_phys: 0x100000
Physical memory: 0x7c80 pages free
Memory regions: 24
Available: 0x0 - 0x8f000
Available: 0x90000 - 0xa0000
Available: 0x100000 - 0xa200000
Available: 0xa20a000 - 0xb000000
Available: 0xb020000 - 0x4968c000
Available: 0x4ac0c000 - 0x5e000000
Available: 0x100000000 - 0x35f340000
fbcon: boot LFB 1440x900 pitch=5888 bpp=32 R16/8 G8/8 B0/8 addr=0xa0000000
fbcon: format accepted, native_blit=true
HPET: no ACPI table found; using timer fallback
IRQ: PIC
Clock: stable TSC 3592560894 Hz
IRQ: PIT
xHCI: probing 01:00.0
xHCI: scratchpad buffers allocated: 31
xHCI: running (slots=127 ports=22) at 01:00.0
xHCI: no keyboard found
xHCI: no mouse found
xHCI: probing 0a:00.3
xHCI: scratchpad buffers allocated: 2
xHCI: running (slots=64 ports=8) at 0a:00.3
xHCI: port 2 speed 1 class 0 keyboard=true mouse=false
xHCI: port 3 speed 1 class 224 keyboard=false mouse=false
xHCI: keyboard ready (slot 1 port 2 ep 1 mps 😎 at 0a:00.3
xHCI: no mouse found
xHCI: probing 0a:00.4
xHCI: scratchpad buffers allocated: 2
xHCI: running (slots=64 ports=2) at 0a:00.4
xHCI: no keyboard found
xHCI: no mouse found
IRQ: keyboard
IRQ: mouse probe
IRQ: mouse unavailable
Interrupts initialized
Stack guards at 0xc0c06000 (kernel) 0xc0c7f000 (arch)

[92mHello from Rust kernel![0m
SELFTEST PIT counting=1 samples=038E 003C 00B6 01F6 02E4 03D0 022A 001E
SELFTEST PIC master IRR(seen)=00000001 IMR=11111000 IRQ0_pending=1 IRQ0_masked=0
SELFTEST APIC none (pure-PIC machine, INTR direct)
SELFTEST CPU vendor=AuthenticAMD family=15 tsc_deadline=0 x2apic_cap=0 invtsc=1
SELFTEST CPUID.15H unavailable (maxleaf=0xd)
SELFTEST CPUID.16H unavailable
Ring1 entered, paging + interrupts + syscall setup complete
Heap base: 0xc0c84000
RetroOS kernel retroos-1-gb3bcc0b3
Storage: nvme0n1 (244198 MB)
Storage: ahci0p0 (476940 MB)
Block devices initialized
hda: amp pin gain=0x0 dac gain=0x4a
hda: state pinctl=0x40 eapd=0x0 pinamp=0x0 dacamp=0x4a pinpwr=0x0 dacpwr=0x0 pinsel=0x0
hda: selected 0a:00.6 codec=0x14f15098 pin=nid31 dac=nid16
hda: path len=2 score=5016 nodes=1f>10>00>00>00>00 conn=0,0,0,0,0
Platform: host=Metal vga_passthrough=false firmware=Substitute audio=EmulatedHda hostfs=false debug=Debugcon
[91mDisk writes: PERSISTENT[0m — pass `ram-overlay` to protect the disk
Threading initialized
Filesystems: scanning partition tables...
Filesystems: 5 partition(s) found
Filesystems: probing ext4/FAT volumes...
Filesystems: 2 supported partition(s)
Multiboot ext4 (32 MB, volatile RAM) → /
FAT C: (330 MB) from disk → /home/retroos/
C: backing volume 1 (nvme0n1) directory /
boot runtime → C:\RETROOS (read-only)
C:\CONFIG: disk files before boot defaults; C:\TEMP: RAM
DOS E: → /disk1 (FAT partition, 199 MB, read-only)
DOS C: maps to /home/retroos/
Loading kernel symbols (244569 bytes)
Loaded 2765 function symbols
ISA PnP: no Sound Blaster found; trying legacy DSP discovery
Audio: EmulatedHda (SB_AUDIO=native)
Loading General MIDI bank...
midi: no ULTRASND under the C: root — General MIDI silent
General MIDI bank load complete
hda: stream RUN sdctl=0x00100002 cbl=32768 lvi=63 fmt=0x0011 lpib=0
DOS: installing substitute BIOS (vga_passthrough=false)
UMA: EMS frame at D0000, UMB 64KB free
Welcome to RetroOS! F12 opens the host monitor.
Starting home/retroos/RETROOS/DN/DN.COM...

LSS10999 wrote on 2026-10-01, 14:13:

In comparison, GRUB struggles to draw and respond to keypresses when running in such high resolutions.

Yepp sometimes grub is pretty slow in UEFI mode

Usually I workaround the problem using

GRUB_GFXMODE=text

Then (if needed) use GRUB_GFXPAYLOAD to set the resolution for what comes next.

The mileage varies wildly, depending various factors, just play with parameters until you get the best result

This is what I'm getting booting on UniPCemu (downloaded grub iso on the evening of the 29th), booting with that diagnostic mode according to the boot menu:

CPU configured for 3 MIPS (Dosbox-style instruction timing in IPS clocking mode).

The CPU itself is in HLT state with interrupt flag cleared, at C0B0B123, so it put itself into hanging mode for some reason. Perhaps due to diagnostic mode?

Btw, UniPCemu doesn't have USB emulated, only iso and hard drive (ATA/ATAPI) are supported for storage.

@The Solutor, it seems to boot to DN. DN is not coming up? Does F12 work? From the log it seems it makes it all the way to starting dn, what do you see on the screen?

gsos wrote on 2026-10-01, 23:18:

@The Solutor, it seems to boot to DN. DN is not coming up? Does F12 work? From the log it seems it makes it all the way to starting dn, what do you see on the screen?

I see the initial string with the confirm of klog written as the last line.

(perhaps I had something else than DN configured before, so I thought my customization was the problem, so I deleted first my config file, then the whole config folder from my fat32 partition, but nothing changed.

I updated the latest release with flushes on all logs, that might produce the error after the boot completed that might illucidate what happens

btw VC now works. Had to add DOS country syscall, allow manual MCB manipulation and correct dos last error syscall. Slowly converging to some finished state.

gsos wrote on 2026-10-02, 01:10:

I updated the latest release with flushes on all logs, that might produce the error after the boot completed that might illucidate what happens

btw VC now works. Had to add DOS country syscall, allow manual MCB manipulation and correct dos last error syscall. Slowly converging to some finished state.

Hi still no system up and running, the klog is a bit longer now

But it still has no timestamp

The boot screen looks like this (no change since the last time)

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

Regarding file permissions. IMO it may be better to just use the owner ID as write identity instead of group ID, as it would be the least troublesome to manage this way.

Normally in Linux a file owned by a user has write permission only for the user itself while read-only for group and others. That is, 644 for normal files and 755 for directories and executables.
When performing "cp" in Linux, write permission for group and others will not be carried over. "mv "on the other hand retains everything as in Linux moving and renaming are not distinguished.

Requiring all files to be group-writable is overkill and there are some security-sensitive Linux programs don't like a file being writable by other ones than the owner (including group-writable).

Regardless, executable permission is not required for RetroOS with ext4 backing partition so EXE/COM/BAT can be run regardless of executable permission.

PS: Not something of high priority but maybe you should consider tidying up certain log messages at some point.
Special symbols like "→" cannot be printed properly in text-mode and will appear as a bunch of gibberish characters, as shown in the photo on the post above.

Perhaps I tried the latest USB image on vmware (in UEFI mode, obviously).

It boot correctly but games aren't shown albeit the compressed image is accessible under the drive E:, and this is something that (I guess) you can test easily in first person.

Last thing: I posted a message in the RustDOS thread which is valid also here

Re: Rust-DOS, a new DOS emulator

The Solutor wrote on 2026-10-02, 11:47:

Perhaps I tried the latest USB image on vmware (in UEFI mode, obviously). […]
Show full quote

Perhaps I tried the latest USB image on vmware (in UEFI mode, obviously).

It boot correctly but games aren't shown albeit the compressed image is accessible under the drive E:, and this is something that (I guess) you can test easily in first person.

Last thing: I posted a message in the RustDOS thread which is valid also here

Re: Rust-DOS, a new DOS emulator

I just tested FDAPM and Laaca's ACPITOOL.
Neither worked with RetroOS for performing shutdown or restart.
Not sure if it's because I'm booting in UEFI mode.

These tools do work with FreeDOS on my X570 system.
Though on my Intel PCs (B75, H97, X99) only ACPITOOL works.

Apparently there's no ISO image anymore on the releases to use? I only see USB stuff there and raw files?

@The Solutor. This is very strange you don't see DN, the log shows DN started and output the lines. I bet something is wrong with the timer interrupts/wake up or so. Does F12 work and bring up OSD?

I added new diagnostic logs in the new release bundle.