Thanks LSS, you are running another newer version that relied on new symbols, I added those it might work now. I addresses some keyboard mapping issues between OS personalities and other fixes. Also fixed executing across personalities in the different versions.

@superfure Excellent I will test more tonight.

As a hat tip to the excellent work on rust-dos by dividebysandwitch I added rat commander as the linux personality tui.

Some tests with the recent release.

Windows versions of NDN and DN/2 now works.
DN/2 OS/2 version still doesn't work.

1synth_fork_exec entry: ds=0625 dx=87DC es=0625 bx=86C6
2synth_fork_exec: filename="DN.EXE" tail.len=0 tail_first8=[]
3handle_fork_exec: "C:\\DN2O214\\DN.EXE" size=1053524 format=lx free_pages=26528
4  fork done, loading protected-mode image...
5OS/2: unresolved NLS ordinal 7
6OS/2: cannot fix up module DN.EXE
7Bad command or file name: 'DN.EXE'

Not sure if this matters for NDN OS/2 version but I noticed these OS/2 log messages in the klog when launching it.
NDN OS/2 itself works, however.

1synth_fork_exec entry: ds=0625 dx=87DA es=0625 bx=86C4
2synth_fork_exec: filename="NDN.EXE" tail.len=0 tail_first8=[]
3handle_fork_exec: "C:\\NDN-O32\\NDN.EXE" size=1459451 format=lx free_pages=26414
4  fork done, loading protected-mode image...
5  child tid=2, parent tid=1 continues without blocking
6WARNING: sound underrun #4 written_frames=4844813 consumed_frames=4845740
7OS/2: unresolved PMWIN ordinal 701
8OS/2: unresolved PMSHAPI ordinal 115
9OS/2: unresolved PMSHAPI ordinal 114
10
11Necromancer's Dos Navigator v3.00.0012v/OS/2. 
12Based on Dos Navigator by Ritlabs...
13[DEFINES/CPU86/CPU87/OS2/VIRTUALPASCAL]
14* OS/2 (v20.45 rev. 0) detected...
15* Process ID = 3 ...
16* PCRE Version 8.45 2021-06-15
17
18OS/2: unsupported Base(272) args=0x3,0x4,0x4,0x3

On the other hand, sound underrun messages still spams the log a bit (as seen in the NDN log), even though sound is working without apparent issues.
I wonder if there are options to mitigate it somehow.

Besides, it seems I cannot launch any other OS ports of NDN from the DPMI32 version of NDN, complaining about "This program must be run under xxx" (xxx being Win32 or OS/2 depending on the port type). Perhaps this is a limitation.

And by the way... I wonder if it's somehow possible to make Windows or OS/2 processes run fullscreen, as "Make window/Make fullscreen" doesn't seem to have any effect on Windows or OS/2 processes (such as NDN ports) at the moment.

EDIT: I noticed something odd with DN/2 Windows version. In the bottom line where it shows the info of the selected file (file name, size, timestamp), only the file name is being shown correctly, while the size and timestamp appear garbled.

I downloaded DN/2 and fixed the issues. garbled text was a windows locale syscall missing. It seems to work for me.

Right now os2, windows and linux are all composited. I should make a fullscreen/resize solution.

I added vga-uni unicode rendering and unicode support for linux,win,os2 and a locale in config.sys. DN/2 should display correctly in Cyrillic (this was the garbled text). Keyboards should also work for different countries.

LOCALE=nl-NL in config.sys, not all combinations are added.

Did a boot test on my H97 system.
Still hangs with cursor blinking on the very first line.
But looks like there are additional messages now, apart from memory range listing.

1Boot: framebuffer init
2Boot: framebuffer ready
3Boot: ACPI timer search
4HPET: ACPI base 0xfed00000 (Multiboot2 ACPI tag)
5Boot: IRQ init

I wonder if this means an issue with IRQ with Intel 9 series.

Testing this on my B75 system and got a kernel panic when running DN/2 OS/2 version.
Apparently, this kernel panic happens on pretty much everything that switches from native VGA to Framebuffer.
Including both Windows and OS/2 versions of DN/2 and NDN.
In fact, just by pressing F12 to open the host monitor menu is enough to trigger it (system hangs with a black screen, probably a panic whose output is not visible).
Probably a regression as I did not encounter this kind of panic before.
I'm not exactly on 0.8.0 but on your latest commit (d39a418), using build artifact from the CI workflow (retroos-<full commit hash>).
This is a panic when running Windows versions of DN/2 or NDN.

1!!! KERNEL PANIC !!!
2RetroOS kernel v0.8.0-2-gd39a4182
3at arch-metal/src/traps.rs:1017
4Arch: OOM during kernel heap demand paging
5
6RetroOS kernel v0.8.0-2-gd39a4182
7Stack trace:
8   0: 0xc0b0b267 <core::fmt::Formatter>::pad_integral+0x0
9   1: 0xc0b0d46c core::panicking::panic_nounwind_fmt+0x0
10   2: 0xc0b0d44d core::panicking::panic_display::<&str>+0x0
11   3: 0xc0b08ada arch_metal::traps::try_handle_page_fault+0x2af
12   4: 0xc0b08ea1 arch_metal::traps::isr_handler_ring1+0x4b
13   5: 0xc0b080d5 isr_handler+0x6dd
14   6: 0xc0bffdd7
15   7: 0xc0bdaade __rustc::__rust_alloc_zeroed+0x1f
16   8: 0xc0b00146 <alloc::alloc::Global>::alloc_impl+0x1b
17   9: 0xc0b0061d <alloc::raw_vec::RawVecInner>::try_allocate_in+0x42
18  10: 0xc0b0f3c7 alloc::vec::from_elem::<u8>+0x5b

I do not encounter this panic on my X570 system which is booting with UEFI (GOP Framebuffer).
Both Windows and OS/2 versions of DN/2 and NDN launched fine (from DNOSP 6.4.0 Real-mode).
Windows version of DN/2 still has the garbled info line despite the UI language is already set to English. Not sure why.
The OS/2 version of DN/2 seems to use Russian by default (probably because I'm using en-US locale so it can't render Cyrillic), switching to English and everything (including the info line) looks fine.

@LSS it looks like physical memory exhaustion allocating the buffer for compositing. The full klog would be helpful, then I can see what mode (how much mem for the framebuffer) and how much memory is available.

I'll try to shore up some mem inefficiencies. I need to refactor the allocator and page sharing some more.

I improved the memory / page allocation, it should now have access to all memory available. I added more diagnostics on booting that might shine some light on the h97 problem.

gsos wrote on 2026-10-08, 23:44:

I improved the memory / page allocation, it should now have access to all memory available. I added more diagnostics on booting that might shine some light on the h97 problem.

Some quick test results with the latest commit.

On my B75 the OOM is no longer there. However, it seems for some reasons, both Windows and OS/2 versions of DN/2 hang on launch and has to be killed via F12 menu.
The klog doesn't show much info apart from quite a few sound underrun spams.

After killing DN/2 the keyboard feels sluggish. However, I'm able to subsequently run both Windows and OS/2 versions of NDN fine, and after exiting from those versions, keyboard responsiveness restored to normal.

And as for the H97 system. This time it booted.
From the klog I'm able to see it correctly initialized the dISAppointment and performed ISA PnP.
However, it's not picking up my card (ESS1869) despite it's listed in the ISA PnP output, probably because it's not an official Creative Sound Blaster card.
I'm using hkzlab's ES1868_ISA8 card that I assembled. I'm using an ES1869F chip which also works, though with other OSes I still need to use ES1868 drivers. UNISOUND (using the /XEA option as suggested by the board author) can configure the card without any issue.

Though I'd like to know if there's a way to somehow store the active klog back to the USB stick even in Protected Disk mode.
As on some systems that I'm initially testing booting RetroOS with, there may not be any partition immediately available that I could let RetroOS use as backing partition for storing persistent klog files.

LSS10999 wrote on Yesterday, 00:49:

On my B75 the OOM is no longer there. However, it seems for some reasons, both Windows and OS/2 versions of DN/2 hang on launch and has to be killed via F12 menu.

After killing DN/2 the keyboard feels sluggish. However, I'm able to subsequently run both Windows and OS/2 versions of NDN fine, and after exiting from those versions, keyboard responsiveness restored to normal.

This used to work before right? So this is a regression? Keyboard responsiveness is very weird, I have no idea at moment, how apps could influence that.

LSS10999 wrote on Yesterday, 00:49:

And as for the H97 system. This time it booted. From the klog I'm able to see it correctly initialized the dISAppointment and pe […]
Show full quote

And as for the H97 system. This time it booted.
From the klog I'm able to see it correctly initialized the dISAppointment and performed ISA PnP.
However, it's not picking up my card (ESS1869) despite it's listed in the ISA PnP output, probably because it's not an official Creative Sound Blaster card.
I'm using hkzlab's ES1868_ISA8 card that I assembled. I'm using an ES1869F chip which also works, though with other OSes I still need to use ES1868 drivers. UNISOUND (using the /XEA option as suggested by the board author) can configure the card without any issue.

Huh?!? It now works, wow. Maybe it's the memory. I added ESS detection/initialization. Note: kernel mixing requites 16bit so only sb16, but sound blaster pro 2.0 should still allow for native use by dos apps. So if it now logs detection games should work with it.

LSS10999 wrote on Yesterday, 00:49:

Though I'd like to know if there's a way to somehow store the active klog back to the USB stick even in Protected Disk mode.
As on some systems that I'm initially testing booting RetroOS with, there may not be any partition immediately available that I could let RetroOS use as backing partition for storing persistent klog files.

Yes, I realize next important thing is to have usb storage driver added. The usb stick workflow is the most convenient for starting so I'll add this. Thank you for testing.

gsos wrote on Yesterday, 01:22:

This used to work before right? So this is a regression? Keyboard responsiveness is very weird, I have no idea at moment, how apps could influence that.

Yes this does appear as a regression, and I'm not sure what might have influenced the keyboard responsiveness.
- When launching OS/2 version I got a completely black screen but F12 can be called out to kill it.
- When launching Windows version I get a window and working mouse cursor but it seems to be stuck on loading for some reasons (a small white rectangle in the upper left) so I had to kill it.

When I went to launch Windows and OS/2 versions of NDN, however, they both started fine, and keyboard responsiveness returned to normal while inside NDN and after exit.

Maybe install fresh/delete dn.cfg or so. Maybe something wrong, i cant repro locally.

Questions:
- On your setup with SB16 (dISApointment) and HDA together, does live toggling while running a game playing on sound blaster between "kernel emulated" and native work?
- Does the new release work on your H97 with correct sb detection?
- Does the H97 boot now deterministically? Or was it a lucky boot, where some irq didn't happen in a critical section.

gsos wrote on Yesterday, 03:06:

Maybe install fresh/delete dn.cfg or so. Maybe something wrong, i cant repro locally.

Retested this on 0.8.1. It seems DN/2 OS/2 now launches. It used Russian by default but after switching to English it turned completely black that I had to kill with F12. I still get the black screen after relaunching it.
DN/2 Windows works. The language is in English and the bottom line is no longer garbled.
The klog doesn't seem to reveal anything unusual so can't really determine the cause at the moment.

gsos wrote on Yesterday, 03:06:

- On your setup with SB16 (dISApointment) and HDA together, does live toggling while running a game playing on sound blaster between "kernel emulated" and native work?

It does work as expected. However, it's not a very common use case so I doubt I'll test that extensively.
At present only on my B75 system has both SB16 and HDA present for such tests. On other systems only one of either (native SB or HDA) is available.

Tyrian 2000:
- When switching from SB to HDA, the currently playing FM note will hang on the SB side, while the music continues to be played from HDA.
- Switching back from HDA to SB will stop the hanging FM note when the next note plays. Music on the HDA side stops immediately.
- Sound effects work in both modes.

Titus the Fox:
- Switching from SB to HDA feels seamless, though exiting F12 menu will lead to the music played through HDA a bit higher pitched for a few seconds then return to normal.
- With native SB percussions in FM music can be heard. With emulated SB through HDA, however, percussions aren't audible.
- Launching while in HDA leads to some popping noise at first (detection issue?), then sound will play in PC Speaker mode.
- Turned out RetroOS now supports PC Speaker output from HDA as well. The PC Speaker music is played through HDA output instead of the actual PC Speaker.

SB mixing doesn't work at the moment. I'm only getting silence.
Will check the klog later, but back then I don't recall seeing anything unusual apart from the sound underrun spams (which seems suppressed now).
I'll probably need the SB mixing feature on my H97 and X99 systems later on, since HDA were not enabled there.

gsos wrote on Yesterday, 03:06:

- Does the new release work on your H97 with correct sb detection?

My ES1869 works as expected. However, there's no mixer control.
Perhaps ESS' mixers operate differently from Creative's, though from native DOS, UNISOUND can configure mixer values of the ES1869 just like Creative SB16.

gsos wrote on Yesterday, 03:06:

- Does the H97 boot now deterministically? Or was it a lucky boot, where some irq didn't happen in a critical section.

I think booting with 9 series is now fixed. Not only H97, my X99 system also booted.
On my X99 system, my CT2950 (SB16 PnP) behind dISAppointment is also picked up.
There're still some issues, likely due to stuffs from old builds that I put on my hard disks, that I need to clean up.

Should note that on both my H97 and X99 systems, RetroOS picked up my SATA disks (in AHCI mode).
But on my B75 system, my SATA disks (in IDE mode) were not detected so only the NVMe disk were usable.
So it appears SATA in IDE mode is not properly supported by the ATA driver I think...

By the way... I wonder if it's possible to have a config file to manage what partition to expose to RetroOS (mounting), as well as whether to allow writing to them, kind of like Linux's fstab.
Right now I'm mostly constraining activities on C: and have not touched other disks/partitions (which RetroOS mounted them read-only).
Though I do find that, on my H97 system, when booting with the argument to mount the "games" module, the GAMES folder on one of my FAT partition picked up by RetroOS took precedence.
So things can indeed end up a bit messy in some circumstances, without an option to manage mounting and permissions.
No real harm done at the moment, as I only tested the H97 and X99 systems in Protected Disk mode.

EDIT: After cleaning up old stuffs on my X99 system I installed it to my Linux /boot partition using the script from the "machine" package, as the partition happened to have plenty of spare space for the purpose.
The CT2950 works okay. Some audio issues I had with native DOS happen in RetroOS as well... so I guess it's just the sound card being a bit unreliable in some cases.

Additionally, games such as AstroFire/TerraFire no longer cause panics under circumstances I originally reported back then, so the kernel looks good enough.

gsos, how did you manage to get 13m IPS? I'm only getting some 500k IPS on Windows (SDL3/MSYS2 build).

@superfury: I think my first measurements were wrong. I redid and am getting 763k IPS (ubuntu / amd ryzen 9 3ghz) with the patch to downclock powerinfo (without that patch it is 80k IPS, but you fixed this upstream)

gsos wrote on Yesterday, 14:13:

@superfury: I think my first measurements were wrong. I redid and am getting 763k IPS (ubuntu / amd ryzen 9 3ghz) with the patch to downclock powerinfo (without that patch it is 80k IPS, but you fixed this upstream)

Also just fixed the APIC interrupts. Now instead of spamming a non-existing interrupt (which is then automatically directed to the 8259A PIC, causing a spurious interrupt (for IRQ7)) it will properly not raise the interrupt. This also fixed Windows NT 4.0 to once again boot (it was causing a IRQ7 storm, which kept executing a single instruction over and over: IRETD on Windows NT 4.0, then once the IRETD returned (with setting the interrupt flag) it would trigger this again, thus a neverending interrupt 37h handler was executing (unless a timer interrupt or the like intervened from the Local APIC)). The cause here was the new INTA-based interrupt handling, which was checking if a interrupt is available on the APIC controller, which reported it's old -1 result(no interrupt pending), which was cast to a byte (thus becoming FFh), which was interpreted as 'interrupt pending', thus firing off the CPU's INTA-cycles, which wouldn't find any interrupts on the APIC, thus giving the PIC(8259A) result instead that returned interrupt vector 37h as a spurious interrupt vector).
This might affect RetroOS as well, if it enables the Local APIC interrupts (which is where the bug occurred, the moment the local APIC is in full enabled state (not soft-disabled or fully disabled)).

Edit: Looking at the OS booting, it's setting the local APIC LVT Timer at roughly 1kHz, which is too fast for the CPU, halting it permanently because of the interrupt storm. I need to increase the emulated CPU to 40MIPS (from my sane 3MIPS speed) speed to make it skip past it while that's happening, after which the OS changes it to an even more ridiculous time (it prints something about 444000 interrupts per second though), so it's an uphill battle with too much CPU speed being required.