11

Would like to run "black on white" software on a DOS machine with an LCD screen, so am wondering if there are any TSR tools, or similar, for inverting the screen. I believe it is grey scale VGA, not monochrome.

It's a HP Omnibook 300, if that matters.

I had a look at Simtel (I believe) a while ago, but could not find anything that worked.

Addition: I am running DOS only, not MS Windows.

More additions: ansi.sys does not seem to work, I believe the program handles the graphics directly by itself. The program also does not have a way to change the colours. Giving the command mode mono before running the program does not make a difference to the program (but it does mess up the display of the battery level, which is something special apparently using the CP437/850 block graphics). The machine does not have any BIOS options for changing the display in any way. In fact I am not sure it even has a standard BIOS.

Improve this question

5 Answers 5

Reset to default
8

You can invert the screen on a monochrome Omnibook by holding the Fn key and pressing either of the contrast up/down buttons next to the screen.

Improve this answer
0
17

Some laptops have built-in support for inverting the screen in one form or another; Toshiba laptops for instance have a setup menu to configure gray-scale translation and inversion, as well as a pop-up TSR and a command-line tool (VCHAD on VGA systems). If your system doesn’t have anything like this, I think your options are rather limited...

As mentioned by RichF, ANSI.SYS will allow you to set the current foreground and background colours, which will work for programs which don’t reset them; in practice, that’s mostly the DOS prompt and console tools, most full-screen programs will reset the colours themselves. If you do want to explore this option, I recommend using a more capable driver such as NNANSI, along with ANSISET to set things up more easily.

Other options you could look at are the basic MODE MONO, which will switch the system to monochrome mode, and perhaps the PC Magazine TSR MONO which will replace text-mode character attributes continuously with monochrome attributes, and which you can modify to choose your own replacement colours. If you can find a copy somewhere, UltraVision should provide enough control to set things up however you want — that was the go-to utility for DOS laptop users in the nineties (this was developed by Personics, and last released as “Laptop UltraVision”).

Many DOS programs also support colour configuration of their own, some with pre-configured palettes for various types of LCD screens.

Improve this answer
0
6

Seems to me that the way to go would be to re-program the lookup table use by the digital to analog converter (DAC).

The DAC is essentially the last component in the VGA, taking 8-bit VGA colors and deciding what each of those will represent. Thus, it affects the output from essentially all other programs, even those that write directly to the hardware. The only obvious exception would be programs that themselves re-program the same lookup table--not really much you can do about that.

For programs that run in text mode and/or high-resolution graphics (640x480), you only need to worry about the first 16 entries in the LUT (because they only use 16 colors, of course). In this case, you can read the current values from the LUT, invert their order (swap 0 and 15, 1 and 14, etc.) and then write them back to the LUT. The first 16 colors are (at least normally) chosen so that inverting the color number approximately inverts the color itself (e.g., 0->black, 15->white, 1->blue, 14->yellow, etc.)

As to a pre-existing program to do this...sorry, but I don't know of one. The code to handle this really is fairly simple though. I'd be tempted to write it and post the source code, but I wouldn't be able to test it...

References:

  1. http://www.osdever.net/FreeVGA/vga/vgadac.htm
  2. https://en.wikipedia.org/wiki/Video_Graphics_Array#Color_palette
Improve this answer
7
  • Brutal, but could work. Also consider messing with the actual hardware video signal...
    – rackandboneman
    Commented Dec 12, 2017 at 21:44
  • I coded this up here, but it would really need to be a TSR because the palette is re-initialised when the mode changes (typically when exiting a full-screen program, if not before).
    – Stephen Kitt
    Commented Dec 13, 2017 at 11:17
  • @StephenKitt: Yeah, it could be a TSR or perhaps a device driver, but you're definitely right that it'd have to be re-done on a regular basis; you couldn't just do it once and leave it at that.
    – Jerry Coffin
    Commented Dec 13, 2017 at 14:33
  • @StephenKitt: I tried your program and it works fine in DOS, but the program I want to run changes it back.
    – Tomas By
    Commented Dec 13, 2017 at 22:58
  • So if I understand this correctly, it would be enough to do this once (ie no TSR), but it has to be after the program sets the mode? Hijack the mode call?
    – Tomas By
    Commented Dec 13, 2017 at 23:40
4

For programs which run within a DOS screen or window, you should be able to pre-load ANSI.SYS with CONFIG.SYS. You would then preset your desired foreground and background colors before running the program you wanted. The page ANSI Sequences seems to give pretty good guidance in using ANSI within a DOS window.

I'm not sure whether ANSI.SYS still came standard with MS-DOS 5.0. It would still work, but for some reason they removed it from the standard distribution at some point.

Improve this answer
10
  • @TomasBy sorry, I've gotten out of habit of thinking in DOS. I was editing my answer as you added your comment. ANSI.SYS works fine (and originally intended for) a full-screen environment.
    – RichF
    Commented Dec 12, 2017 at 13:24
  • 1
    I think ANSI.SYS provides a virtual terminal, so can affect only those programs that do not go straight to the hardware. In non-virtualised DOS I don't think anybody gets to tell the latter what to do.
    – Tommy
    Commented Dec 12, 2017 at 13:33
  • 1
    @TomasBy It will only affect programs which use normal text screen drivers. Games, for example, would not even know ANSI.SYS was there, and it would have no effect upon them. Plus, you can change colors on the fly in between programs.
    – RichF
    Commented Dec 12, 2017 at 13:34
  • ... or programs which read the current settings and apply them manually (console I/O under DOS has a lot of moving parts depending on the variant).
    – Stephen Kitt
    Commented Dec 12, 2017 at 13:35
  • 2
    It's not just games though, surely? Wasn't Lotus 1-2-3 one of the standard "how compatible is this IBM compatible?" test pieces because it goes straight to hardware? I can't think of any application more straight-laced than a spreadsheet.
    – Tommy
    Commented Dec 12, 2017 at 14:38
2

If all else fails, and you're up for (or know somebody who would be interested in) a fun low-level programming challenge, there's an interesting hack you could apply to this problem. This will work if:

  • the software you want to run is traditional real-mode text-mode DOS software (i.e. doesn't use DPMI or similar), and
  • you have a 386 or higher processor (which I believe you do in the machine you describe) and a bit of spare extended memory space.

The way it would work is to use the 386's Virtual X86 mode to map some extended memory into the space usually occupied by the text display; you would then map the original location somewhere else (probably outside of the lower 1MB address range) and run a periodic operation to copy the data from one to the other, flipping attributes while you did.

This isn't an easy task, but it may be easier than expected because there are open source 386 Expanded Memory Manager implementations available which already do a lot of the necessary work.

Of course, it would probably be better to solve this in just about any other way you can think of. But this way would be fun. :)

Improve this answer
3
  • Given the small amounts of memory involved, I don’t think there’s much need for remapping; in fact PC Magazine’s MONO TSR could be extended to do this relatively easily, on a 8086.
    – Stephen Kitt
    Commented Dec 13, 2017 at 10:05
  • 1
    Actually a V86 approach would be useful to virtualise the VGA I/O ports and fix the palette as values are written to the DAC.
    – Stephen Kitt
    Commented Dec 13, 2017 at 17:20
  • Good point. That would make the fixed palette approach much more likely to work.
    – Jules
    Commented Dec 13, 2017 at 19:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .