Hi, > On Jul 31, 2022, at 3:49 AM, TK Chia <u1049321...@caramail.com> wrote: > > Hello Jerome, > >>> Generally, I would not include an attachment. However, this is a >>> tiny zip and includes the test source, build scripts and the compiled >>> version. > > Well... I found that your ansitest.com still works with the FreeDOS 1.3 > kernel + nansi.sys 4.0d. (I.e. there was no regression between FreeDOS > 1.0 and 1.3.) > > I took a FreeDOS 1.3 "floppy edition" boot disk image, and doctored it > so that it loads nansi.sys on startup and does not start the installer, > then ran it under QEMU. ansitest.com says "ANSI supported". > > (I will try to enclose a floppy disk image once I manage to pare it down > to a small enough size...) > > Are you using devload.com to load the nansi.sys driver? If so, this > might explain the failure. I found that if I use devload.com --- rather > than load the driver through fdconfig.sys --- then for some reason > nansi.sys's input handling routines are not triggered, and there is no > ESC [ y ; x R response. This would mean there is an issue in devload.com.
I did not see your message until now. However, it did not take long to narrow down. I did some testing under VirtualBox and it didn’t take long to when the issue occurs. I saw almost immediately that when booting with NANSI.SYS in the config file the test passes successfully. However, post boot loading using DEVLOAD (high or low) would cause the test to fail detection. This is occurs even when nothing other than the SHELL= is in the config with an empty autoexec. So, my test results match yours and it is easy to replicate. Finding the actually issue may be a little more complicated. I’m suspecting the issue may not be NANSI itself. :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel