• Please review our updated Terms and Rules here

ANSI.SYS Escape Code Resolution, Mode 6 on Olivetti M24(SP)

freakedenough

Experienced Member
Joined
Jul 30, 2016
Messages
93
Location
Vienna, AT
According to the MS-DOS manual of my M24 there is an ANSI.SYS support for 640x200b/w mode when switching to mode 6h (ESC[6h).
This works for the command prompt itself, however it does not work for applications like the MS-DOS editor, which then cause only garbage on the screen.
Is there any explanation for this? Shouldn't the DOS 5.00 Editor work in graphics mode like TopView does? Or automatically switch to 80x25 mode (that's what is done on my 486)?
The outcome is the same regardless of if I use the original Olivetti DOS ANSI.SYS or the one provided by MS-DOS 4.01. Or other applications like mTCP ftpsrv.

(Pictures say x400, but it's in fact x200. I am too used to write x400 when writing something about this PC...)
 
Last edited:
For laughs I tried this with the version of ANSI.SYS included with PC-DOS 7 on my Tandy 1000 with a VGA video card plugged in. On that machine if I set a graphics mode with an ANSI code (I tried a number of different modes from 640x200 CGA up through 16 color 640x480) before entering EDIT/QBASIC (same thing) I don't get the same response; the machine resets the video mode to 80x25 text. Upon exiting, though, it seems to *try* to set the graphics mode back up the way it was, but in every case the palette/attribute set was screwed up.

Looking at the screenshot of what's displayed on your machine it looks to me like EDIT isn't detecting it's in graphics mode and, like Chuck says, it's just writing directly to the screen buffer thinking it's already in 80x25 text mode. If it wasn't a hassle (I put my CGA monitor up for now) I'd pull out the VGA card and see if the same thing happens with the built-in CGA graphics.

That said, I'm kind of puzzled *why* you'd want to use ANSI to set 640x200 graphics as your DOS prompt text mode. It's just going to be slower than the character based text mode.
 
BASIC has had its own SCREEN statement for setting video modes, before ANSI.SYS existed. I don't think I've ever seen these escape codes used anywhere, and I can't imagine what the intended use case would be... maybe vestiges of a plan for more extensive graphics support which never materialized?

EDIT: actually... one possible use-case would be allowing multi-lingual text in some programs that didn't support it out of the box. The first implementations of ANSI.SYS were done in the days of CGA, where fonts could be modified *only* in graphics mode. (DOS code page support came later, and targeted at least EGA).
If an application was "well-behaved" (i.e.: didn't set its own video modes and didn't write directly to the screen), you could use this sort of trick to force it into graphics mode, and load your own character set/language driver before launch. For example, I have here a Hebrew language TSR from IBM dated 1983, which only works in (CGA) graphics modes, so it can only be used with such "well-behaved" software.
 
Last edited:
Support for color is marginal at best with DOS.

The most pressing use for ANSI.SYS was so that preference for foreground and background screen color can be set once and the system "remembers" it.
 
Okay! What eas the purpose/use of these ANSI modes? For BASIC apps only?

ANSI color codes and cursor positioning make sense, but setting the graphics modes was just done for completeness, and it was a mistake.

Once in one of the color modes you can't draw lines or really set colors, so there it just no point to doing it. Nothing that I know if uses the ANSI escape codes to move to a graphics mode because it's just pointless.
 
Okay! What was the purpose/use of these ANSI modes? For BASIC apps only?

For CPM programs ported to DOS, for color and positioning in terminal applications, and for MS-DOS compatible programs that were not necessarily IBM PC-compatible. (In the first few years, MS-DOS ran on more systems than just the IBM PC.)

Actually there's a 4th reason: Some programs used ANSI codes for I/O because the idea was that ANSI.SYS was an "API" you could use to "write once, support many". In an ideal world, ANSI drivers could be written for anything, and/or better ones could come out at a later date and support more hardware, but the original program wouldn't have to be modified to run in such situations. In practice, this never really took off, since programs writing directly to textmode memory could run way faster than outputting ANSI codes.
 
You're also forgetting BBS culture. Quite a number of them required that you use a terminal program that supported ANSI/VT100 protocol. With ANSI.SYS, a dumb terminal program could display the stuff. Back in the day, when you wanted to create a multi-user PC system, those secondary serial consoles usually supported ANSI as the obvious choice.

I seem to remember that there were several "improved" ANSI.SYS programs over the stock one distributed with MSDOS, ZANSI and NANSI come to mind. They were also faster than the standard MS-DOS character interface based on INT 10H.

Even today, when I'm writing code that interfaces a microcontroller via USB to a PC, I use ANSI escape sequences to produce good looking displays. Linux utilities such as minicom and screen support those codes as well as several Windows terminal programs such as REALTERM. Most telnet and ssh clients also support ANSI sequences.
 
"You're also forgetting BBS culture."

Yes, true. But not in the era of the early XTs. Using ANSI in BBS was later and those terminal programs had ANSI support build in, they did not rely on ansi.sys.
 
I assure you, PC-TALK did not have ANSI built in, and we called BBSes that used ANSI codes. Just because ANSI ART wasn't a big thing in 1985 doesn't mean BBSes didn't use it for basic things like colors.
 
Gotta clarify for the OP: my reply in the previous page was strictly about those video-mode escape sequences. ANSI escape codes in general are eminently useful for lots of things (being one of those guys who used to trade BBS artwork for file access, I should know). ;)

After all these decades with an ANSI-less Windows command prompt, it was funny to see MS bringing ANSI support to cmd.exe, in a relatively recent Windows 10 update.
Still holding out for native ZMODEM transfers... 2030, perhaps?
 
It does seem exquisitely useless to include a code to switch to graphics mode if there are no codes for, I dunno, piping a bitmap of dimensions "x" into a region starting at a specified cursor location. I wonder if whoever implemented that in ANSI.SYS had a momentary fever dream of implementing something like DEC's ReGIS or Digital Research's GSX inside of it.
 
Or NAPLPS, or Teletext. :)

As mentioned, one legitimate use case of forcing 'well behaved' apps into graphics mode is for charset localization (on CGA), but somehow I doubt that was the motive.
 
It was very useful in emulating terminals, and for screen manipulation. For example it included ways to move the cursor to a given (x,y) position.
Some 3rd party versions buffered output for much faster screen writing. I may be wrong, but NANSI & FANSI come to mind. There was a "before" & "after" demo showing cursor manipulation ANSI animation, and improved screen writes. The difference was dramatic.
 
Back
Top