On Sat, Nov 4, 2017 at 5:17 PM, <userbeit...@abwesend.de> wrote:
> On 2017-11-04 20:50, dmccunney wrote:
>> On Sat, Nov 4, 2017 at 3:32 PM, <userbeit...@abwesend.de> wrote:
>>> I tried to find ZANSI.SYS but found that it is nowerdays really hard to
>>> get... Finally I found it there:
>> Another source is here:
> Thanks! I also would have prefered a ZIP, but on Linux there is ARC
> available, e.g. on Debian via "apt install arc".
I could get the capability here, too, but it's been years since I've
needed it. By preference, I use 7-zip as my standard archive utility.
That can create Zip files as well as 7z files, and can extract an
assortment of things including RAR files. (The 7-zip compression
engine has been ported to Linux, as well.)
>> The other common ANSI.SYS replacement was NNANSI.SYS, from Tom Almy,
>> available from http://almy.us/dospage.html
>> NNANSI was implemented as a TSR COM file instead of being a driver.
>> This is useful if you use things like DOSbox, which doesn't support
>> drivers loaded from CONFIG.SYS.
>> (I use DOSbox to run some old DOS apps on an Android tablet, with
>> NNANSI loaded as a TSR.)
> Okay, I will try NNANSI as well. Hope I remember it until then. I'll save it
> now and hopefully use what I have, so NNANSI might be it.
It's worth looking at. Almy started with NANSI code, and optimized
for even further speed. If you have a compatible assembler, you can
build his source as a SYS file. I found the TSR adequate.
>> I load NNANSI as a TSR high here, so the difference in size isn't a big
>> Another plus for NNANSI is support for the VT-100 Add Line and Delete
>> Line sequences that are missing in ANSI and NANSI.
> I'm not sure if I need that. The sole purpose for ANSI on my system used to
> be accelleration of output speed. I remember that on my original hardware,
> something like a 25 MHz 386SX, dir used to be really slow at the bottom of
> the screen, once it had to shift the line up. I do remember that after using
> ZANSI.SYS this was considerably faster - not slightly, but very much so.
I have a couple of things that originated in Unix and use ANSI
sequences for rendering. The addition of AL and DL sequences is
Generally speaking, most PC compatible DOS systems did not use the
BIOS for screen display. The write directly to video memory. So you
only loaded ANSI.SYS or the like if something specifically needed it.
I never saw things like a DIR speedup because I had an ANSI driver loaded.
I used ANSI to do things like fancy DOS prompts. My standard prompt
implemented an inverse video status bar at the top of the screen with
things like the current drive and directory that stayed at the top of
the screen, while the C:\> prompt moved down. (I used ANSI get and
set cursor position routines. Save the current cursor position, home
the cursor to the top left, erase the top line, turn on inverse video,
write the status line, turn off inverse video, and restore the cursor
to the saved position.) When I used 4DOS as the command processor, I
could embed 4DOS variable functions in the status line as well for
more information like RAM usage..
>>> So IF FreeDOS was ment not only for modern systems but also for real
>>> retro hardware, I think it may be of interest to also include the option to
>>> choose ZANSI over NANSI.
>> FreeDOS was intended to be DOS compatible and used in place of MSDOS,
>> so it can run on retro hardware.
> I know. I just wished FreeDOS included ZANSI.SYS as an option, a replacement
> for NANSI.SYS.
It's easy enough to find it even if it isn't.
> Although I don't know if parts of ZANSI were included in later NANSI
I don't believe so. Dan Kegel's site should be considered
authoritative on what went into NANSI.
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Freedos-user mailing list