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.
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.
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.
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.
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.
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.
LSS10999wrote on 2026-10-09, 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.
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.
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.
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.
- 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.
- 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.
- 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.
LATE EDIT: It seems this FATAL (not really panic) is still relevant on my AMD system where the issue originated. On my X99 system I did not reproduce the issue.
Maybe has something to do with the UEFI/GOP stuffs...
Last edited by LSS10999 on 2026-10-11, 06:04. Edited 4 times in total.
@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)
@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.
I know that at that speed, at UniPCemu's default 3 MIPS with 1kHz timer, the OS only has 2999 instructions to return from the interrupt handler, which let it execute only 1 instruction outside of the interrupt handler each millisecond, but RetroOS seems to take longer somehow? Also beware that memory stalls like video cards can take multiple instruction times, for example full accelerator buffers.
Last edited by superfury on 2026-10-10, 08:53. Edited 1 time in total.
It starts looking promising. I think @Solutor also had a system that didn't boot maybe that one starts working as well on this version.
@LSS: I added mount table to RETROOS.INI that you can update. It allows you to assign drives and setup a filesystem as you want it. I also added some extra support for SATA PCI, I hope that will fix the missing drive detection (no guarantees).
I will try to add USB storage support and TCP/IP support. At that point I might go do 1.0.0 release, as the system would become usable for people who want to bring a retro experience to modern machines.
@LSS: I added mount table to RETROOS.INI that you can update. It allows you to assign drives and setup a filesystem as you want it. I also added some extra support for SATA PCI, I hope that will fix the missing drive detection (no guarantees).
I noticed you now provide a BOOT.INI for mounting management, and a RETROOS.INI superseding the CONFIG.SYS.
But is there a way to edit those files from inside RetroOS? Right now it seems I can no longer just modify RETROOS.INI via DN's editor like I used to do with CONFIG.SYS.
And is there a guide on how I can use floppy and CD? The showcase files provided a few test images in the C:\FLOPPY folder and they get picked by RetroOS for mounting in the F12 menu. How to provide CD images for mounting and, does it only support ISO format or that BIN/CUE format (usually with soundtracks) are supported as well? Can RetroOS handle physical CD drives?
And (as I edited my previous post), it seems AstroFire/TerraFire (and the other game whose executable name is DUCK) can still lead to FATAL (not really kernel panic) in some cases, particularly on my AMD X570 system (UEFI boot).
For AstroFire/TerraFire it seems after reconfiguring the sound card the FATAL issue went away... though I cannot rule out it can still be reproduced under certain circumstances.
I did not reproduce this when testing on other environments (e.g. X99). Those other systems boot RetroOS via CSM.
For DUCK it seems to expose something more -- "Unhandled page fault in kernel."
Though the stack trace no longer points to any known symbol.
When I tested it on my X99 system, the game hangs after intro with black screen but I can kill it with F12 menu.
It works fine with native DOS, so I'm considering this an edge case for now and not really a high priority of getting it working.
On my X570 system, DN/2 Windows version still has the garbled bottom line issue while DN/2 OS/2 version don't.
Since they appear to be environment specific I'm not really sure anymore.
Right now I mainly use DNOSP and optionally launch NDN (DPMI32/WIN/OS2) if needed, so DN/2 may not be tested extensively as a high priority case at the moment...
As for BioMenace (patched), it seems I'm getting some info when the game abruptly exits.
1BMENACE1: 2DOS: CPU exception 6 at CS:EIP=0001:0x10a1 ss:sp=2ed0:00000006 psp=05d1 (vm86=true) bytes=[ff, ff, ff, 00, c8, 16, 00, 16] stack=5934 6e61 2064 3000 202b 202d last_irq=vec08 target=0027:00000510 from cs:ip=1e4c:000012b5 ss:sp=2ed0:0000fff0
1BMENACE2: 2DOS: CPU exception 6 at CS:EIP=0001:0x10a1 ss:sp=2edc:00000006 psp=05d1 (vm86=true) bytes=[ff, ff, ff, 00, c8, 16, 00, 16] stack=5212 6e61 2064 2b43 202b 202d last_irq=vec09 target=0027:00000512 from cs:ip=1e7a:00001298 ss:sp=2edc:0000fff0
I think I've narrowed down the cause. If I kill an enemy with gun fire I can 100% crash the game. Killing an enemy with grenade doesn't seem to trigger the crash.
And regarding installation... since there's a lot of changes to the file layout I did a reinstall but noticed these things.
- install.sh does not appear to understand --copy-showcase argument. Not a really big deal as I can always unpack the showcase.tar manually to the backing partition.
- In the showcase.tar, while folders have 755 permissions, files appear to have only 555 permissions (read-only but executable) so I have to do a chmod -R 755 to ensure they are writable. With the new release files are correctly writable with 644/755 permissions.
- Files don't appear to have any timestamps, appearing as 2000-1-1.
As for the timestamp issue, I wonder if RetroOS actually passes the actual system time to the game, as I noticed something that seems to suggest an issue with time related APIs.
Titus the Fox, if played in the present day (probably more than a decade since its release in 1992), would show a message greeting you saying "You're still playing Moktar* in <year>". However, with RetroOS I'm not seeing this greeting (the game started right away), implying the time and date passed to the game may not be the actual RTC time.
* Moktar is the name of the French version of the game.
And I'm curious about the possibility of supporting UTC and Timezone on top of local time, as on my X570 system I mainly use Linux and configured Windows to use UTC as well.
I'm using local time on my other, more DOS/Windows focused systems (B75, H97 and X99), though.
EDIT: Did a quick test on my B75 system where it had issues with detecting SATA disks (in IDE mode).
It appears RetroOS can detect the controllers and disks, but the information was incorrect. All SATA disks were seen as LBA28 PIO and reported as 128GiB by ATA, but they were actually much bigger and no partitions were detected and listed.
I noticed you now provide a BOOT.INI for mounting management, and a RETROOS.INI superseding the CONFIG.SYS.
But is there a way to edit those files from inside RetroOS? Right now it seems I can no longer just modify RETROOS.INI via DN's editor like I used to do with CONFIG.SYS.
Editing should still work, as long as retroos run with persistent disk and its normal disk installation (the ini file lives on /home/retroos/RETROOS/RETROOS.INI). In usb/iso boot it's ram backed.
And is there a guide on how I can use floppy and CD? The showcase files provided a few test images in the C:\FLOPPY folder and they get picked by RetroOS for mounting in the F12 menu. How to provide CD images for mounting and, does it only support ISO format or that BIN/CUE format (usually with soundtracks) are supported as well? Can RetroOS handle physical CD drives?
Just copy images iso or bin/cue in the C:\CD directory and then you can load/eject them in the OSD menu
LSS10999wrote on 2026-10-11, 07:02:And (as I edited my previous post), it seems AstroFire/TerraFire (and the other game whose executable name is DUCK) can still le […] Show full quote
And (as I edited my previous post), it seems AstroFire/TerraFire (and the other game whose executable name is DUCK) can still lead to FATAL (not really kernel panic) in some cases, particularly on my AMD X570 system (UEFI boot).
For AstroFire/TerraFire it seems after reconfiguring the sound card the FATAL issue went away... though I cannot rule out it can still be reproduced under certain circumstances.
I did not reproduce this when testing on other environments (e.g. X99). Those other systems boot RetroOS via CSM.
For DUCK it seems to expose something more -- "Unhandled page fault in kernel."
Though the stack trace no longer points to any known symbol.
When I tested it on my X99 system, the game hangs after intro with black screen but I can kill it with F12 menu.
It works fine with native DOS, so I'm considering this an edge case for now and not really a high priority of getting it working.
I dont have these games, would like to fix them.
LSS10999wrote on 2026-10-11, 07:02:On my X570 system, DN/2 Windows version still has the garbled bottom line issue while DN/2 OS/2 version don't.
Since they appear […] Show full quote
On my X570 system, DN/2 Windows version still has the garbled bottom line issue while DN/2 OS/2 version don't.
Since they appear to be environment specific I'm not really sure anymore.
Right now I mainly use DNOSP and optionally launch NDN (DPMI32/WIN/OS2) if needed, so DN/2 may not be tested extensively as a high priority case at the moment...
As for BioMenace (patched), it seems I'm getting some info when the game abruptly exits.
1BMENACE1: 2DOS: CPU exception 6 at CS:EIP=0001:0x10a1 ss:sp=2ed0:00000006 psp=05d1 (vm86=true) bytes=[ff, ff, ff, 00, c8, 16, 00, 16] stack=5934 6e61 2064 3000 202b 202d last_irq=vec08 target=0027:00000510 from cs:ip=1e4c:000012b5 ss:sp=2ed0:0000fff0
1BMENACE2: 2DOS: CPU exception 6 at CS:EIP=0001:0x10a1 ss:sp=2edc:00000006 psp=05d1 (vm86=true) bytes=[ff, ff, ff, 00, c8, 16, 00, 16] stack=5212 6e61 2064 2b43 202b 202d last_irq=vec09 target=0027:00000512 from cs:ip=1e7a:00001298 ss:sp=2edc:0000fff0
I think I've narrowed down the cause. If I kill an enemy with gun fire I can 100% crash the game. Killing an enemy with grenade doesn't seem to trigger the crash.
I found Biomenace .. and passing Stacks options in config.sys explaining some bug in the sound code in bio menace causing crashes. So it's a known bug in bio menace, maybe I can see if there is a fix within retroos
LSS10999wrote on 2026-10-11, 07:02:And regarding installation... since there's a lot of changes to the file layout I did a reinstall but noticed these things.
- in […] Show full quote
And regarding installation... since there's a lot of changes to the file layout I did a reinstall but noticed these things.
- install.sh does not appear to understand --copy-showcase argument. Not a really big deal as I can always unpack the showcase.tar manually to the backing partition.
- In the showcase.tar, while folders have 755 permissions, files appear to have only 555 permissions (read-only but executable) so I have to do a chmod -R 755 to ensure they are writable. With the new release files are correctly writable with 644/755 permissions.
- Files don't appear to have any timestamps, appearing as 2000-1-1.
I believe the latest installations should support copy-showcase, have the right permissions. I'm using bazel to build packages, which is strictly hermetic (ie running twice produced byte identical output) so it has fixed timestamp for tars, it uses that date.
LSS10999wrote on 2026-10-11, 07:02:As for the timestamp issue, I wonder if RetroOS actually passes the actual system time to the game, as I noticed something that […] Show full quote
As for the timestamp issue, I wonder if RetroOS actually passes the actual system time to the game, as I noticed something that seems to suggest an issue with time related APIs.
Titus the Fox, if played in the present day (probably more than a decade since its release in 1992), would show a message greeting you saying "You're still playing Moktar* in <year>". However, with RetroOS I'm not seeing this greeting (the game started right away), implying the time and date passed to the game may not be the actual RTC time.
* Moktar is the name of the French version of the game.
And I'm curious about the possibility of supporting UTC and Timezone on top of local time, as on my X570 system I mainly use Linux and configured Windows to use UTC as well.
I'm using local time on my other, more DOS/Windows focused systems (B75, H97 and X99), though.
EDIT: Did a quick test on my B75 system where it had issues with detecting SATA disks (in IDE mode).
It appears RetroOS can detect the controllers and disks, but the information was incorrect. All SATA disks were seen as LBA28 PIO and reported as 128GiB by ATA, but they were actually much bigger and no partitions were detected and listed.
I implemented a missing dos RTC api so maybe titus behaves as expected now. I added a
[clock]
rtc=utc
utc_offset=+01:00
section in the RETROOS.INI that you can use if RTC is in utc
I will work on supporting LBA48 necessary for the big disks.
EDIT: I added lba48 support, not sure if it helps with detecting partitions.
Editing should still work, as long as retroos run with persistent disk and its normal disk installation (the ini file lives on /home/retroos/RETROOS/RETROOS.INI). In usb/iso boot it's ram backed.
I kind of figured out how this works now. The BOOT.INI and RETROOS.INI installed to the boot partition (usually where GRUB is) are redirected to C:\RETROOS in RAM.
So changes made to the RETROOS.INI from inside RetroOS won't persist in this kind of scenario even in persistent disk mode, as the files are in the boot partition, not the backing partition.
Currently, installation via machine install script works similar to the USB stick, with most of the core stuffs reside in "retroos-base.img" in the boot partition, and now the INIs are there as well.
I found Biomenace .. and passing Stacks options in config.sys explaining some bug in the sound code in bio menace causing crashes. So it's a known bug in bio menace, maybe I can see if there is a fix within retroos
I've already patched the game executable using the patches from the k1n9_duk3 site.
The issue is well known. Without patching the game would simply hang the system after firing the gun when playing in native DOS (music still plays, however).
The game works fine (no longer hangs) after patching on native DOS, but in here it's crashing.
I believe the latest installations should support copy-showcase, have the right permissions. I'm using bazel to build packages, which is strictly hermetic (ie running twice produced byte identical output) so it has fixed timestamp for tars, it uses that date.
Will retest it when installing the new version on another system.
The install script as of the e8a6cb5 simply throws error if I pass the "--copy-showcase" argument, saying it wasn't supported.
So I copied the stuffs manually to the backing partition.
gsoswrote on 2026-10-11, 13:55:I implemented a missing dos RTC api so maybe titus behaves as expected now. I added a […] Show full quote
I implemented a missing dos RTC api so maybe titus behaves as expected now. I added a
[clock]
rtc=utc
utc_offset=+01:00
section in the RETROOS.INI that you can use if RTC is in utc
Both local and UTC+offset time are working as expected.
DOS Navigator is showing the correct time on my systems in both local and UTC+offset scenarios.
Still need some inspection on how the timestamp of files would appear in a native UTC environment (e.g. Linux desktop).
Titus the Fox also works as expected now. The greeting message is now shown, telling me I'm still playing it in 2026.
I will work on supporting LBA48 necessary for the big disks.
EDIT: I added lba48 support, not sure if it helps with detecting partitions.
With LBA48 support my IDE SATA disks (and the partitions in them) are correctly detected.
Haven't checked the performance side of things yet (like whether UDMA works).
It seems you are using --module which is used for usb/iso boot (that retroos still can't read themselves and uses grub to provide the necessary files as a grub module ram disk). For a disk based install use
EDIT:
I still figuring out what is convenient way of installing this. Personally I developped it by just copying kernel.elf to /boot on my linux and adding grub. I still think that leeching on a linux ext4 or windows fat is easiest, I dont want to construct a fresh fs etc... Now supporting btrfs is likely the best next. I added fat now as the same target as ext4, which means you can use that if you use fat partition as the target for C: .
Last edited by gsos on 2026-10-12, 03:30. Edited 1 time in total.