SCOUG OS/2 For You - April 1998
Watching OS/2 on TV
by Dallas E. Legan, Jerry Rash, and Paul Wirtz
This article will describe how to use a composite monitor (TV set)
with OS/2 using an inexpensive VGA to NTSC (composite or television)
converter. Some of the expensive converters claim to work right
out of the box, not needing any supporting software for full function.
Reasons someone might want for using one of these devices are numerous,
- Conserving space
- Conserving money
- Recycling or using as a backup, an old monitor that accepts
composite video input
- Video taping your sessions
- Hooking up a laptop to a hotel room TV
- Using a projection television for a monitor for classroom lectures,
business briefings or other public presentations.
- One way to hook a second monitor to a PC with predictable
- A projection TV, in 40 column by 7 line mode,
on the side of a barn, might be usefull for the
visually impared. (This is untested.)
Web TV and others hope to make a fortune converting
TVs into tools to explore the Internet, but you don't have to wait on them.
The techniques described here worked for the converter one author uses,
and represents the efforts of all the authors, but might need some
fine tuning to find specifics that work best with your particular
hardware. We will discuss two methods for using these converter boxes with
OS/2. One is a kludge that works just given the hardware. The other takes
advantage of the DOS TSR (Terminate and Stay Resident) software, that should
come with the hardware, to get what would be considered normal function from
The 'scan converters' that require software for full use generally
come with a TSR/initialization program that runs under DOS and will work
with Windows 3.1. We're not really sure the word 'driver' is correct
to descibe this software, since it only seems to set some registers,
and then allows occasional adjustment of the display
(centering, etc.) from the keyboard.
When displaying graphics, the software is apparently
not needed since converters have coped with the OS/2 desktop and windowed
command line sessions with no problem. If you never expect to
use an OS/2 full screen command line with your converter, you can stop
reading this article now, you don't have to go any further.
(But then maybe you'll learn something usefull if do read it all.)
The TSR installs and runs handily in all DOS full screen session
modes Warp 3.0 is capable of (Virtual DOS machine modes and Specific DOS)
with only one problem. The occasional error message OS/2 sends your DOS
session, such as when you forget to insert an expected floppy disk, for example,
are handled by OS/2 in full screen mode. It is only in fullscreen OS/2
sessions that the screen goes blank and something is obviously not working.
The first method we will describe, we've come to think of as the
'MODE Kludge'. It has some problems that keep it from being totally
satisfactory, but it also has some uses. One author came across it while
studying a 'VGA Graphics Array Specifications' table in Scott Mueller's
"Upgrading and Repairing PCs", 5th edition. He was trying to get the
second method we will describe to work. Noticing that even what
were described as 'Graphics Modes' had row and line specifications
for text given for them, he went back to his computer, entered an OS/2
full screen session, and entered:
(where 80 is the number of characters for the line,
and 30 the number of lines)
and was shocked to see his Commodore 1702 monitor come alive with characters.
(After puzzeling over getting it to do this for several months.)
You may notice that 30 is a very non-standard number of lines
for full screen use, 25 being more usual.
With exhaustive experimentation, it was found that 'line specifications'
between 1 and 130 there were some values that MODE rejected and
others it accepted. Of those 'line' values MODE accepted, some worked with the
VGA/video scan converter and some didn't.
This method usually has the problem that when your command line
gets to the bottom of the screen (which is still showing only 25 lines),
you lose some text off the top of the screen that MORE and TEDIT
(for examples) assume that you can see, and for some values the command
line itself drops off the bottom of the screen.
It has the obvious advantage that the little B&W monitor on the
floor, hooked up to the scan converter's VGA output for the occasional use,
was needed a lot less.
It was found that from 29-31 lines would work, so you could normally
set it to 29 to minimize the number of lost lines and it barely keeps the
command line from going off the bottom of the screen. Enter 'CLS' and
hit return a few times to make certain you have a perfectly clear view
of the command line.
With TEDIT, scroll the cursor down some and then page up to
snap the top of a file being edited into view.
You could set MODE to 80,56, and squint at the tiny letters to minimize
lost information when feeding output to the screen with MORE.
For hardcore use of this method, a replacement for MORE that allows
control of the number of lines fed to the screen could be used. There is
at least one such program in the Hobbes library, and probably one could
easily be written with ReXX. An extremely keyboard intensive,
jerky method is to use " | MORE | MORE " where you would usually
use just " | MORE " or " .... /p " to control the output of a
Throughout this ordeal, keep in
mind that UNIX was developed by people sitting at teletype machines,
and that the 'PC Revolution' started with some crude boxes with a
few LEDs on the outside for the display. You can rough it some
while doing an emergency CHKDSK of your harddrive.
Uses of this method include getting to see at least some of the
boot process with a composite monitor, and with emergency boot
diskettes (such as made with the System/System Setup/Create Utility
To use the first of these, simply execute MODE before any CALL
statements in your active CONFIG.SYS file. For example:
CALL=C:\OS2\XCOPY.EXE C:\OS2\*.INX C:\OS2\*.INY
CALL=C:\OS2\XCOPY.EXE C:\OS2\*.INI C:\OS2\*.INX
REM The above Xcopies are frequently used to back up *.INI files.
With this addition, the XCOPY commands following the
'CALL=...MODE' will be displayed on the
screen, where previously it was blank or just video hash.
For the second use, the MODE Kludge with a set of bootable utility disks,
using a VGA to NTSC converter do the following:
- Make a set of bootable utility floppies with the object in
the Warp 3.0 System Setup folder.
- Copy the following files onto floppie #2:
- Make the following changes to the CONFIG.SYS file on disk #2:
SET OS2_SHELL=CMD.EXE /KSTARTUP
(This trick was found while experimenting with this stuff, but later
found to be documented on page 457 of "The OS/2 WARP Survival Guide"
by D. Azzarito and D.W. Green. One of this articles authors thought
Azzarito and Green were describing something else, but probably absorbed
what they meant subconciously. Anyway, it enables you have a given CMD
file executed at the start of each OS/2 command line session.)
(EGA seems to have only one number of lines (25) it can show,
and this is incompatable with what the tested scan converter can
handle without more specialized software support
(29-31, and some higher ones.). For this reason, the bootable floppies
are converted to VGA.)
Add this to the end of the CONFIG.SYS file:
REM start of installation of basic vga stuff
REM end for installation of basic vga stuff
- Add this typical STARTUP.CMD, to the root directory of disk#2:
rem (Or whatever value experiment shows you should use instead
rem the '29' that works for my converter.)
Shutdown, and boot up using this set of floppies, noting carefully
the beep when the boot process is ready for floppy #1 to be replaced
with floppy #2. Insert disk #2, hit return, and wait for the command prompt
to come up on the composite monitor screen.
Before ending discussion of the MODE Kludge, probably a few things
should be said about the MODE command itself. First, this use of MODE
only works with the OS/2 command line, not with any DOS MODE.
DOS's MODE only accepts certain values for the line number
(typicly 25, 43 and 50) where as OS/2 is not limited in this way.
This DOS limit may also have limited the thinking of one author,
preventing him from trying other numbers at the OS/2 command line.
Second, "Your OS/2 Warp version 3 Consultant", second edition,
by Herb Tyson, page 281, shows how the MODE command can be used
in windowed OS/2 sessions to increase scroll back capability
by setting it to MODE 80,102 then pressing in succession (not
as usual, simultaneously) Alt then 'l' (lower case 'L').
We leave experimenting with this for homework.
The second method we will descibe is not a kludge, but works just
as you would expect with OS/2 full screen command sessions -
they simply display on the screen with no funny behaviour.
This method might be termed a 'Virtual TSR', since it emulates
the register setting initialization done when the DOS TSR is installed.
Weaknesses of this method are that it doesn't show anything at all
during boot, (including CALL statement execution (see the above example
about this)), and it seems to require installation of PMSHELL
(Presentation Manager/Workplace Shell) as the protected mode shell.
(This means there is a line early in your effective CONFIG.SYS file
This is because a setting in Presentation Manager 'Vectors'
(points) the Base Video Handler (BVHXXX) drivers to the video card
specific drivers that should come with the card, and this link is
lost if PMSHELL is not installed as PROTSHELL.
(See OS/2 Warp Unleashed Delux Edition, bye David Moskowitz and
David Kerr, et. al (C) 1995 Sams Publishing, p.540-541)
One of the authors once had a software driver, provided with one scan
converter he purchased, that worked with OS/2. This driver has been
lost so far in BackupSpace it's doubtful even Gene Aiken and the
MSR/Backmaster crew could find it. It's loss motivated this co-author
to come up with the idea that provides the kernal of the technique described
shortly. It should be pointed out that this method simply uses the
inherent capabilities of OS/2 and it's SVGA video drivers.
First, make sure that you have the SVGA drivers correctly installed.
One author tried some bogus drivers he thought would work with the
scan converter, and in the aftermath went to Recovery Choices on bootup
and reinstalled the VGA drivers. This reinstallation complicated the
process being described when it was first tried.
Typicly, correct SVGA installation would look like this:
REM THIS IS TYPICAL OF WHAT WORKS
REM THIS IS TYPICAL OF WHAT WORKS
Typicly, a wrong installation might look like this:
REM THIS IS NOT CORRECT
REM THIS IS NOT CORRECT
Note how the wrong variable VIO_VGA, instead of VIO_SVGA is assigned a value
in this wrong case.
If this happens, when leaving a full screen DOS session, the video (and only
the video) may lockup, or other odd behaviour may result. If your
desktop is simple enough, and you remember it's layout, you may be able to
maneuver through your shutdown procedure using the keyboard.
(Your milage may vary.) 'BVHVGA' is needed
along with 'BVHSVGA' in setting the value of VIO_SVGA. Elsewhere,
references to VGA should be replaced with SVGA.
Make sure the files associated with this process are installed-
VIOTBL.DCP, VSVGA.SYS, BVHVGA.DLL, BVHSVGA.DLL etc.
Next go to a fullscreen OS/2 DOS session (or just boot up DOS,
however you may do it.)
and make sure the TSR/intialization program is installed (i.e. your
composite monitor is not blank ;-) ), and the screen is adjusted
with the TSR keystrokes to your satisfaction. Remember that
screen centering set now will be what you have to live with in
OS/2 full screen sessions, unless you want to be continually
fiddeling with monitor knobs.
A Side Note.
Maybe you just got your converter and have never run it, or
don't normally have DOS support installed on your computer.
You may have to install DOS emulation temporarily
(with Desk Top/OS/2 System/System Setup/Selective Install)
to use the TSR that came with the scan converter, and latter remove it.
You can do this after this procedure is complete with the
Selective Uninstall in the OS/2 System/System Setup object.
An alternative might be to download Caldera DR DOS 7.0X (
previously known as Novell or Open DOS, and yes, it is
free for personal use) from http://www.caldera.com, and install it on
some floppies and/or other removable media, possibly in the form of bootable
disk images, to keep your machine DOS free.
This process is an example of a standard procedure with PCs,
and one legitimate use of DOS: determining whether a problem is hardware
or software by booting up DOS and using the software that works
in this simplest of operating systems to find the answer.
If you can't get a piece of hardware running in such a primitive
environment, there is no hope for more sophisticated environments
Getting back to the setup procedure, go to the directory \OS2 on whichever
drive you boot OS/2 from. Here there should be a file called SVGA.EXE.
Type 'SVGA ON DOS', and the screen will go to complete hash, either blank
or just rolling noise. This is caused by the program
SVGA probing your video card registers. The problem at this point is how
to cleanly shutdown with the screen totally out of commission.
If you are lucky, your particular video card may not have this problem
- it might return to the a simple display after an outburst of
video noise that settles down. (The authors were not with the first
setup using this method.)
not just with the composite monitor - VGA/SVGA ones may also have this happen
after executing SVGA.EXE, and exiting the DOS session to OS/2 won't restore
the screen either. This is precisely why you might want to give
consideration to doing this from DOS arrived at with either the multi-boot
tool of your choice, or from a floppy disk booted session. Then you can just
C-A-D, punch reset or turn the computer off. If your disk drive is HPFS
formatted, maybe you can copy SVGA.EXE to a floppy and work with it there, or
perhaps you have drivers to enable DOS to access HPFS. A more exotic
possibility, the practicality of which we have no idea, is to write
a series of batch files, one starting a DOS session batch file from the
OS/2 command line, where the DOS batch file installs the TSR, executes
SVGA.EXE, and exits, while the OS/2 CMD file that 'start''s the DOS session
pauses till the visual noise of the probe settles down, then after the user
hits return it initiates SHUTDOWN.EXE.
Shutdown, however appropriate, reboot, and return to the directory C:\OS2.
Now you should find a file called SVGADATA.DOS. Rename or copy it to
C:\OS2\SVGADATA.PMI. You may even want to make it read-only and back it
up eventually. It is used by the SVGA drivers to initialize the video system.
Reboot to OS/2.
You should now be able to go to a fullscreen OS/2 command line prompt
session and enjoy the pleasure of watching your session on your
composite monitor through the scan converter.
If there is any problem at this point, it may be possible to
twiddle the values of SVGADATA.PMI to get it to work, since it is
just a plain text file that can be attacked with any editor.
Other files can be generated under other
circumstances with SVGA.EXE for comparison to help in this.
It was found by comparison that only a few hexidecimal values,
labled as 'CRT Registers' were changed by the TSR. (If anyone has any
information on these feel free to inform us. We're particularly
interested in their absolute addresses, if that makes any sense.)
SVGA.EXE enables OS/2 to 'borrow' initial register values of any
video driver that may run under DOS (or any other environments
SVGA.EXE will run in). SVGA.EXE takes a snapshot of these configurations.
Then they can be put to use by OS/2, even subjected to manual
change if necessary.
The sections of the PMI file are clearly labeled for the modes
they setup. Patching in settings for oddball column settings,
like 40 or 132 may be needed to get desired screen positioning
may be neccessary.
Detective work may be needed for modes that OS/2 has
but DOS does not.
This method does not have any effect on DOS sessions under OS/2,
where you will still need the TSR.
This is apparently for the same reasons you cannot switch from
windowed to full screen OS/2 command line sessions but can for
OS/2 DOS sessions, and that no 'virtual drivers' are needed for
the OS/2 sessions - the video is handled in different ways
for OS/2 and DOS sessions under OS/2.
Neither of these techniques (nor did the manufacturer supplied OS/2 driver or
DOS TSRs) show what is going on throughout bootup on a composite monitor.
Some leave their computer on all the time, so this may be a rare occurance.
You can learn to pay attention to the beeps and LED flashes during boot,
and what constitutes a reasonable amount of time for these sounds and flashes
to occur in. One author drove his car around for about a year with a broken
speedometer cable, successfully gaging from the rest of the traffic and road
conditions what was a reasonable speed. When something goes wrong during boot,
pull the little B&W monitor out of the closet, or borrow one from another
computer, and hook it up to figure out what's happening. This can also be
done when installing major changes in hardware or software that might suggest
a need for carefully observing bootup. It may be possible to use driver
switches to turn off hanging on any problems for driver installation,
and write a script using some system analysis tool to verify that
all are operating properly after bootup.
These measures may seem extreme, but a case can be made otherwise.
All Power PCs and SUN SPARC workstations have a Forth language/RAM memory
operating system in a ROM, built in for investigating major hardware failures.
(This is in conformance with IEEE standard 1275-1994.) For the Power PC's,
when something goes wrong, a terminal is hooked up to a serial port and
appropriate keys are held down during boot. You're greeted with the Forth
'OK' prompt on the terminal attached to the serial port. This allows you to
poke and probe registers etc. investigating what went haywire. Think about
it - booting up DOS with some floppies, to snoop around the hardware,
is not a viable option for a SPARC workstation. For this reason, the ROMed
Forth system is provided to fulfill a similar purpose - close to the hardware
testing at a relatively low level of abstraction. Why should procedures for
your PC be that much different from a SUN workstation or a Power PC when
something is broke?
After working through the SVGA.EXE method, one author was looking through
"User's Guide to Using OS/2 Warp" (the manual that came with
OS/2 3.0), and found the procedure for using SVGA.EXE described
on pages 236-237. It even specificly mentions the Trident video card
his computer used. This description only lacks indication that the video
card probing may wipe out the consol view till reboot. The manual passage,
strangely, seems to warn that the file generated may be affected by TSRs,
switches and jumpers - when this may be exactly what you are trying to record
and put to use.
"Talking Points" that won't get you before a Grand Jury:
- Mode Kludge
- You can't use the Virtual TSR method.
- Temporary conditions, such as bootup.
- Emergency conditions, such as working from bootable floppies.
- VGA video mode and supporting files.
- MODE external command and supporting files.
- Logical screen size (what the computer thinks you see)
usually differs from physical screen size (the number of columns and rows
you actually see on the monitor.)
- Only works after the MODE command has been executed.
- Requires a little bit of experimentation to find usefull settings.
- Virtual TSR
- Routine full screen opeation at the OS/2 command prompt.
- You want to use column/row modes the same as those you
can routinely use in DOS.
- You can hack out the PMI file settings for oddball,
non-standard column/row modes OS/2 is capable of.
- PMSHELL.EXE installed as the Protected Mode Shell
("PROTSHELL=C:\OS2\PMSHELL.EXE" in CONFIG.SYS)
- SVGA be installed and active.
- Only works after SVGA software has been installed
and become functional.
- Column/row modes other than those you can run in DOS
will require detective work to get functional.
- The 'Virtual TSR' is in fact only virtual (suprise! :-) )
Hot keys for changing centering and such are not
available for use in OS/2 since there really is none
of the code from the TSR installed (and it might not be right
for OS/2 even if it was) - just the video register settings
as the TSR would initialize them. This means you must either make
centering adjustments for full screen operation during
set up in DOS, or do a lot of experimentation under OS/2
operation, or (possibly) diddel with the monitor settings continually.
- Inexpensive Scan Converter Models:
- Cost from $50 (occasionally) - $200
- Typicly support only 640 x 480 resolution
- Almost invariably require supporting software or
- Expensive Scan Converter Models:
- Cost from $250 - $2000+
- May claim to not require supporting software
- Will have higher resolution modes
- May have extra features such as zoom capability or
- AVerMedia Technologies
(Manufactored the model used for this article.
One model specificly claims "no software drivers required")
- Focus Enhancements, Inc.
(One model claims OS/2 supported)
(800) 990 - 7994
- Willow Peripherals
(800) 444 - 1585
- ATI Technologies Inc.
(905) 882 - 2600
- California Digital (Bargain closeouts)
Voice: (310) 217 - 0500
FAX: (310) 217 - 1951
- SIIG, Inc.
(800) 927 - 8688
- ADS Technology Int. Corp.
Voice: (800) 888 - 5244
FAX: (562) 926 - 0518
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 1998 the Southern California OS/2 User Group. ALL RIGHTS
SCOUG is a trademark of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.