I fixed Tyrian, it uses a obscure detection path that wasnt properly implemented. The hang is IF=0 caused by non-dpmi spec use of cli/popf, I added "TYRIAN.EXE repair" to loadfix config to indicate that retroos learns how to repair it.
I fixed Tyrian, it uses a obscure detection path that wasnt properly implemented. The hang is IF=0 caused by non-dpmi spec use of cli/popf, I added "TYRIAN.EXE repair" to loadfix config to indicate that retroos learns how to repair it.
Can confirm the hanging issue when entering a level has been fixed.
Additionally, emulated SB via HDA now works with Tyrian.
The version I tried yesterday still doesn't boot on UniPCemu. The last it logs to E9 and screen is a few CPUID indexes being unsupported. After that I just see 0x20 interrupts from the (A)PIC, probably IRQ0.
I'm not able to get unipcemu running on my side. It just doesn't get into booting bios. I threw an AI at it, it found
It's not able to emulate more 85k instructions per second, so maybe its not hanging but just taking hours to emulate bios post. Due to a call to SDL_GetPowerInfo every APM tick (I dont understand why emulator needs that) which apparently on my macine is really slow. After down clocking the frequency of that call, it reaches 13m instructions per second which is much more reasonable.
Has anyone checked the spin-offs of the original DOS Navigator?
So far I've been able to get DOS Navigator OSP 6.4.0 (Real Mode) working.
Can be found here: https://dnosp.su/e_index.php
I'm also able to make this the default in CONFIG.SYS (START directive) to make RetroOS use this on startup.
No success with newer (DPMI32) versions of NDN at the moment, including the 3.0 builds by Muxe (Archive link, original site dead).
I haven't tested the DPMI version of DNOSP but I'm considering that optional since the real-mode version already worked.
And neither Windows nor OS/2 versions of the DN/2 from DNOSP worked, complaining about "Bad command or file name 'DN.EXE'" when launched.
DN/2 also has a DPMI32 version but I'm afraid it would be the same as the DPMI32 versions of NDN.
can use the MC/NC style menus instead of the hideous DN ones.
+ It's now possible to use included (Dos Navigator-like menu style [ndn.mnu] files) and Norton Commander-like menu style [nc.mnu] files
To use included "ndn.mnu" : insert line - {menufile="ndn.mnu"}
To use included "nc.mnu" : insert line - {ncmenufile="nc.mnu"}
Such files seem not included in the last downloadable version (2.11 beta 8 )
I'm not able to get unipcemu running on my side. It just doesn't get into booting bios. I threw an AI at it, it found
It's not able to emulate more 85k instructions per second, so maybe its not hanging but just taking hours to emulate bios post. Due to a call to SDL_GetPowerInfo every APM tick (I dont understand why emulator needs that) which apparently on my macine is really slow. After down clocking the frequency of that call, it reaches 13m instructions per second which is much more reasonable.
The screenshot below is what i see
Those functions are called at a 32kHz timer (Intel 82347) that tries to implement a power supply on the motherboard, with it being implemented as the i430fx/i440fx chip on the PCS (also handling the emulator poweroff (termination) by BIOS APM, which is performed as observed from the APM outputs to it's I/O ports. Not 100% sure what chip is really there though (it's not documented anywhere)).
The Solutorwrote on Yesterday, 07:15:I was more interested in the Version 2.10 Beta 2 that, according to what I read here
https://ndn.sourceforge.net/new.htm […] Show full quote
can use the MC/NC style menus instead of the hideous DN ones.
+ It's now possible to use included (Dos Navigator-like menu style [ndn.mnu] files) and Norton Commander-like menu style [nc.mnu] files
To use included "ndn.mnu" : insert line - {menufile="ndn.mnu"}
To use included "nc.mnu" : insert line - {ncmenufile="nc.mnu"}
Such files seem not included in the last downloadable version (2.11 beta 8 )
I'm not able to get unipcemu running on my side. It just doesn't get into booting bios. I threw an AI at it, it found
It's not able to emulate more 85k instructions per second, so maybe its not hanging but just taking hours to emulate bios post. Due to a call to SDL_GetPowerInfo every APM tick (I dont understand why emulator needs that) which apparently on my macine is really slow. After down clocking the frequency of that call, it reaches 13m instructions per second which is much more reasonable.
The screenshot below is what i see
Those functions are called at a 32kHz timer (Intel 82347) that tries to implement a power supply on the motherboard, with it being implemented as the i430fx/i440fx chip on the PCS (also handling the emulator poweroff (termination) by BIOS APM, which is performed as observed from the APM outputs to it's I/O ports. Not 100% sure what chip is really there though (it's not documented anywhere)).
What I dont understand why the emulated power supply needs to call the host powerinfo functions (SDL_PowerInfo). It's the later call that is just excruciating slow on my machine.
I fixed NDN for dpmi32, I added the missing features for win32 version (needs threading) and will work on the os2 version later. This is a great app to test. I see the necromaniac^H^H^Hcer has added dpmi64!! Ha excellent, I'll add dmpi64 support as well. I wanted to be able to compile rust to 64bit dos-apps at some point.
I fixed NDN for dpmi32, I added the missing features for win32 version (needs threading) and will work on the os2 version later. This is a great app to test. I see the necromaniac^H^H^Hcer has added dpmi64!! Ha excellent, I'll add dmpi64 support as well. I wanted to be able to compile rust to 64bit dos-apps at some point.
Tested:
- Muxe NDN v3.00.0010u (DPMI32) works.
- DNOSP DN/2 2.14 Beta (DPMI32) version works.
(Other DPMI32 versions of DOS Navigator spin-offs should also work at this point)
They work fine, though taking a bit longer to start compared to Real-mode versions.
Windows version of DN/2 doesn't seem to work with RetroOS at the moment, complaining about requiring "Win32", so the Windows personality is not there yet...
DN/2 OS/2 version still reports "Bad command or file name 'DN.EXE'".
did you run the bat file? the exe file works for me, the bat file indeed gives that error. I will investigate, I just released an OS2 version as well, somethings are wrong with the keyboard it seems but it works mostly.
DN/2 OS/2 version still reports "Bad command or file name 'DN.EXE'".
This is a scenario I've seen in various situations, testing VC/MC and other clones/variations, it's like they are unaware of paths and / or environment variables.
Say MC doesn't obey to LANG=XX set in config.sys, and attempting to do that on running OS ends in "bad command or filename"
P.S. The log file is still saved in Unix like format, something tat DN manages, but older SW doesn't. Not a drama but proper CRLF end lines would be more appropriate for a DOS like system
did you run the bat file? the exe file works for me, the bat file indeed gives that error. I will investigate, I just released an OS2 version as well, somethings are wrong with the keyboard it seems but it works mostly.
With your most recent release:
DN/2:
- Windows version: Using BAT leads to the message that looked like "This program needs to be run under Win32". Running DN.EXE directly results in the "Bad command or file name" error.
- OS/2 version: "Bad command or file name" error when running DN.EXE.
NDN:
- Windows version: Same as DN/2.
- OS/2 version: Works, though it seems ENTER doesn't work in NDN OS/2. I need to press SPACE to select the option in the F10 menu.
FYI: Maybe we haven't implemented some proper OS info APIs, as NDN reports "Unknown OS (0.0) detected". This doesn't seem to affect NDN in terms of functionality.
Games normally don't care about DOS version but there were some DOS system utilities that do, and will block launch if the DOS (or MS-DOS) version is not what they wanted.
(e.g. "Incorrect DOS version" error message)
Turned out there's an archive of NDN 3.00.0012 builds (the last known release) for all platforms in "old-dos [dot] ru", about 35.5MB in size.
(Will not put the direct link here due to the nature of the site and the forum rules. Search for "old-dos necromancer's dos navigator" in DuckDuckGo).
Internet Archive only managed to capture some links after the site was gone so nothing actual about 3.00.0012 was archived. I wonder if NDN is still in development somewhere.
BTW: A few posts back I suggested using user ID instead of group ID for write identity with ext4 backing partitions.
When doing tests above I did make sure to "chmod -R 777" every time I put new stuffs into the backing partition, as in Linux, write permissions for group and others are not carried over when copying (only owner's write permission gets carried).
But this certainly feels inconvenient that I think I should eventually consider putting the commands into a script file that I'd run every time I copied new files into it.
Anyway, in its current state there's always the possibility that I might forget to fix at least the group write permissions, leading to issues that were otherwise invalid.
Last edited by LSS10999 on 2026-10-07, 03:21. Edited 3 times in total.
It's very confusing for me to track all problems. Feel free to add issues/features here https://github.com/gerben-stavenga/RetroOS/issues and if possible add the klog of the particular execution that fails.
I think before getting serious about issues on github, you have to absolutely fix a couple of things
First: a proper command line. Having to deal with MC/NDN/VC/Whatever bugs using DN (or viceversa) is really complicate, w/o adding more confusion.
Second even a semidecent versioning of the released images, with a minimum of change log on each one, w/o it, again, confusion will add to confusion.
How we can tell the feature "feature XXX regressed in build Y.ZZ" if there isn't a Y.ZZ value to use as a reference?
Consider that ATM we are just 3 users that are actively reporting bugs and feature requests, what if suddenly the interest raises and instead of 3 you have to deal with 15 or 150 users?
IMHO For everything else, there is all time of the world, Rome wasn't built all in a day, RetroOS wouldn't be any different. It's a hobby, not a job, after all... 😉
I'm not able to get unipcemu running on my side. It just doesn't get into booting bios. I threw an AI at it, it found
It's not able to emulate more 85k instructions per second, so maybe its not hanging but just taking hours to emulate bios post. Due to a call to SDL_GetPowerInfo every APM tick (I dont understand why emulator needs that) which apparently on my macine is really slow. After down clocking the frequency of that call, it reaches 13m instructions per second which is much more reasonable.
The screenshot below is what i see
Those functions are called at a 32kHz timer (Intel 82347) that tries to implement a power supply on the motherboard, with it being implemented as the i430fx/i440fx chip on the PCS (also handling the emulator poweroff (termination) by BIOS APM, which is performed as observed from the APM outputs to it's I/O ports. Not 100% sure what chip is really there though (it's not documented anywhere)).
What I dont understand why the emulated power supply needs to call the host powerinfo functions (SDL_PowerInfo). It's the later call that is just excruciating slow on my machine.
It uses it to poll the host's battery to let the client OS (like RetroOS, Windows etc.) implement it's battery status (full, almost empty etc. in this case) and allows the client OS to respond as needed. It also controls actual shutdown of the emulator itself through it's shutdown support (if you make it terminate the power supply), acting like the window close (or RALT-F4) of the emulator (saving the settings and terminating the UniPCemu app). Right now it's emulating said chip (found on Bochs' ports.lst), but I don't actually know what the BIOS expects there to actually be on said 4 I/O ports on the i430fx/i440fx/i450gx chipset PIIX Programmable Chip Select, other than what I've observed in the APM poweroff call (which just writes FFh to said base I/O port after mapping it to some address), which is done in SMM installed by the BIOS (handling the APM for power supply poweroff). If anyone knows what's really connected to that PCS, I will be glad to implement it though.
Also, is it really reaching 13 MIPS speed? I barely get a realtime speed of over 500 KIPS on my Ryzen 7 7700 running Windows 11 (actually about 18% (26% during a large REP STOSD of 200MB+ of memory) of 3 MIPS, so only 540 KIPS, which is 540K instructions per second (or 780 KIPS). Of course that's in it's IPS clocking mode, which has a lot of instruction fetch overhead (filling the PIQ with up to being filled to 12 bytes each instruction).
Last edited by superfury on 2026-10-07, 10:48. Edited 3 times in total.
It's very confusing for me to track all problems. Feel free to add issues/features here https://github.com/gerben-stavenga/RetroOS/issues and if possible add the klog of the particular execution that fails.
Well, my KLOG is full of sound underrun spams even though audio has been working mostly fine...
Anyway, looks like there really are hints on what might be failing in the klog.
Turned out there's an archive of NDN 3.00.0012 builds (the last known release) for all platforms in "old-dos [dot] ru", about 35.5MB in size.
(Will not put the direct link here due to the nature of the site and the forum rules. Search for "old-dos necromancer's dos navigator" in DuckDuckGo).
Internet Archive only managed to capture some links after the site was gone so nothing actual about 3.00.0012 was archived. I wonder if NDN is still in development somewhere.
From the thread in BTTR Software, here's a Google Drive link containing all NDN stuffs.
However, for some reasons Google has flagged something in the archive (NDN-v3.00.0012.7Z) as virus so it cannot be downloaded from the Drive anymore 🙁
PS: The U32 version of NDN (which I think means DPMI32 with Unicode enabled) feels a bit sluggish, taking a few seconds to show the panel upon launch as well as when returning from a program.
The D32 version of NDN seems fine.