SCOUG OS/2 For You - April 1998

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, including:

1. Conserving space
2. Conserving money
3. Recycling or using as a backup, an old monitor that accepts composite video input
4. Video taping your sessions
5. Hooking up a laptop to a hotel room TV
6. Using a projection television for a monitor for classroom lectures, business briefings or other public presentations.
7. One way to hook a second monitor to a PC with predictable behaviour.
8. 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 converter.

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:

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 command.

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 disks icon).

To use the first of these, simply execute MODE before any CALL statements in your active CONFIG.SYS file. For example:

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:

1. Make a set of bootable utility floppies with the object in the Warp 3.0 System Setup folder.
2. Copy the following files onto floppie #2: NLS.DLL BVHVGA.DLL MODE.COM VIOTBL.DCP
3. Make the following changes to the CONFIG.SYS file on disk #2: Change SET OS2_SHELL=CMD.EXE to 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.)

   Change

   DEVINFO=SCR,EGA,VTBL850.DCP to REM DEVINFO=SCR,EGA,VTBL850.DCP (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 DEVINFO=SCR,VGA,A:\VIOTBL.DCP SET VIDEO_DEVICES=VIO_VGA SET VIO_VGA=DEVICE(BVHVGA) REM end for installation of basic vga stuff
4. Add this typical STARTUP.CMD, to the root directory of disk#2: @ECHO OFF ECHO. ECHO. ECHO. ECHO. SET PROMPT=$i[ER:$p] mode co80,29 rem (Or whatever value experiment shows you should use instead rem the '29' that works for my converter.) ECHO. ECHO. ECHO. ECHO. 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 resembling: PROTSHELL=C:\OS2\PMSHELL.EXE)

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:

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.

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 like OS/2.

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.)

This is 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

  Use when:

  1. You can't use the Virtual TSR method.
  2. Temporary conditions, such as bootup.
  3. Emergency conditions, such as working from bootable floppies.

  Requires:

  1. VGA video mode and supporting files.
  2. MODE external command and supporting files.

  Disadvantages:

  1. 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.)
  2. Only works after the MODE command has been executed.
  3. Requires a little bit of experimentation to find usefull settings.

• Virtual TSR

  Use when:

  1. Routine full screen opeation at the OS/2 command prompt.
  2. You want to use column/row modes the same as those you can routinely use in DOS.
  3. You can hack out the PMI file settings for oddball, non-standard column/row modes OS/2 is capable of.

  Requires:

  1. PMSHELL.EXE installed as the Protected Mode Shell ("PROTSHELL=C:\OS2\PMSHELL.EXE" in CONFIG.SYS)
  2. SVGA be installed and active.

  Disadvantages:

  1. Only works after SVGA software has been installed and become functional.
  2. Column/row modes other than those you can run in DOS will require detective work to get functional.
  3. 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:
  1. Cost from $50 (occasionally) - $200
  2. Typicly support only 640 x 480 resolution
  3. Almost invariably require supporting software or settings.

• Expensive Scan Converter Models:
  1. Cost from $250 - $2000+
  2. May claim to not require supporting software
  3. Will have higher resolution modes
  4. May have extra features such as zoom capability or remote control.

• Sources
  1. AVerMedia Technologies (Manufactored the model used for this article. One model specificly claims "no software drivers required")
     http://www.aver.com
  2. Focus Enhancements, Inc. (One model claims OS/2 supported)
     http://www.focusinfo.com/home.htm
     (800) 990 - 7994
  3. Willow Peripherals
     http://willow.com
     (800) 444 - 1585
  4. ATI Technologies Inc.
     http://www.atitech.ca
     marketing@atitech.ca
     (905) 882 - 2600
  5. California Digital (Bargain closeouts)
     http://www.cadigital.com
     Voice: (310) 217 - 0500
     FAX: (310) 217 - 1951
  6. SIIG, Inc.
     http://www.siig.com
     (800) 927 - 8688
  7. ADS Technology Int. Corp.
     http://www.adstech.com
     sales@adstech.com
     Voice: (800) 888 - 5244
     FAX: (562) 926 - 0518
  8. Antec http://www.antec.com

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. /