Announcement

Collapse
No announcement yet.

Three monitor output possible?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Three monitor output possible?

    have a dual monitor card. When I run PowerBasic (dos) I make sure I use one monitor. I am currently writing a program that will open three text files and compare them for specific differences in birth dates or where a person was born.

    (I.e., File1 says John Doe was born Jan 2, 1900, Alabama, File2 says the same thing, but File3 says he was born in Tennessee.)
    Then I use the differences in information to help me decide who to do research on.

    Can I have Power Basic output information to two different monitors? What about three diffent monitors? How do I specify:

    {for monitor 1)
    LOCATE 1,1:PRINT "JOHN DOE"

    {for monitor 2)
    LOCATE 1,1:PRINT "JOHN DOE"

    {for monitor 3)
    LOCATE 1,1:PRINT "JOHN DOE"

    Having this ability would be very useful an helpful to me. My system will allow four monitor to be plugged in. All monitors are VGA.

    Thank you.

    Robert Carneal

    ------------------

  • #2
    i have no clue re the number of monitors, but isn't looking at three (or four) monitors the hard way to find differences in files?

    i mean, wouldn't it be a lot more efficient to extract the values from the three files and compare them programatically?

    or am i missing something?

    mcm
    ps: not for pb/dos, but here is some pb/cc code you can adapt to do these kinds of comparisons:
    http://www.powerbasic.com/support/pb...ad.php?t=22637

    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      Not with the built-in PRINT statement, sorry!

      It is possible to use a mono (Herc) card and a VGA card and use both cards from PB/DOS... they key in this instance is to POKE characters directly into the video memory of the non-current card (ie, if the VGA card is the current card, you'd POKE data to &H0B000; if the current card is the herc card, use &H0B800 to poke data to the VGA text-mode. Note that Windows NT/2000/XP virtualize the hardware and wil not permit direct hardware access, so this scheme only works on plain DOS, Windows 3.x, and 95/98 (and maybe ME).

      Note that the PB/DOS IDE natively supports this VGA+MONO dual-monitor setup... the IDE runs in one, and the run-time output screen appears on the other... see the /D option in the documentation).

      Unfortunately, there is no way to achieve this kind of functionality for for dual-head and triple-head VGA graphics cards, except possibly by controlling the hardware directly (addressable memory will only cater to the primary screen).

      However, if the manufacturer provides documentation on controlling the card in real-mode, then you might be able to write a custom solution... but I'd seriously doubt that any given solution would work with more than one specific model of card.

      Using a pair of cards (PCI+AGP, or PCI+PCI, or ISA+PCI, etc) is yet another set of scenarios... it might be possible to manipulate the second card by direct hardware access, but I've never tried it...

      But... if the PC is running 32-bit Windows then it would likely be a lot easier to write GUI applications with PB/Win and simply position each of the windows where you need them simply by adjusting the origin coordinates of each window.

      Background: In Win32, dual monitors usually means that the desktop is simply larger (either wider or taller, depending on the configuration of the graphics card). In my case (Matrox G550 dual-head), I have an effective desktop resolution of 2048x768 (1024x768 per monitor)... however, in text mode (Screen 0), the second monitor shuts down, whereas on my old G450 dual-head card, the second monitor duplicates the main monitor in SCREEN 0.

      Matrox have recently released the new "Parhelia" series of multi-head cards out now (dual and triple-head models), and they also operate an [apparently] excellent developer program... you might look there for assistance if you wish to get into direct hardware control.

      I hope this helps!

      ------------------
      Lance
      PowerBASIC Support
      mailto:[email protected][email protected]</A>
      Lance
      mailto:[email protected]

      Comment


      • #4
        Originally posted by Michael Mattias:
        I have no clue re the number of monitors, but isn't looking at three (or four) monitors the hard way to find differences in files?

        I mean, wouldn't it be a lot more efficient to extract the values from the three files and compare them programatically?

        Or am I missing something?
        Michael- you are not missing anything. I just offered a incompletely described scenario. How about if I put it this way: The information on person frequently takes up 3/4ths of the screen or more. Using multiple screens would stop my having to clear one and display the name from another file.

        LANCE- You may have given me a clue! I just went to START >> MS Dos and opened the window. Then I repeated that and ended up with TWO windows, one I dragged over to the second monitor. Having two dos windows means I could run two different PB programs, AS LONG AS both do not access the same file? Does that make sense? Does that sound "doable"?

        Thanks for the thoughts guys.

        Robert



        ------------------

        Comment


        • #5
          I've been using multiple instances of PB 3.5 for DOS in separate
          DOS-VDM windowed sessions in OS/2 for as long as PB 3.5 has been
          in my posession. The ability to do just what you are attempting
          was one of the reasons I chosd PowerBASIC long ago, for use with
          OS/2.

          Provided you use OPEN for RANDOM ACCESS SHARED file techniques,
          it it may be trivial to use simultaneous read operations on the
          same file, either by separate sessions on the same desk top or
          separate system plus separate session across a LAN. Works fine.
          The superb offering by PowerBASIC for what it can do with record
          lock and so on, also makes it possible to seed your program with
          flags which designate that a particular record is locked in the
          middle of update for such operations.

          By combining advance notice of that in a pre-written record, you
          can keep track of who may be in a position to corrupt a record
          for future write, between simultaneous reads of the same record.
          That, together with locked records and error trap catch routines
          which delay action on the record until the previous user writes
          it, can make for very sophisticated multi-session uses of
          simultaneously accessed records with PowerBASIC in DOS.

          The problem has always been to me that this sort of brute force
          operation when done in a WIN-95-98 game, completely seems to fall
          flat on its face when more than one or two such incidences are
          tried on the same WIN box. Where we've tried this multiple 'use'
          same-box game on ant least WIN-95-98, it just crawls. Where as
          with OS/2, you can operate even a dozen or so and it seems that
          the more you load it, the better the operation gets under OS/2's
          superb thread-oriented task splitting.

          Contrary to the ever-present continual comment about the demise
          of OS/2, it is VERY much still in development and support. The
          current promise for supporting exactly what I'm talking about as
          to DOS-VDM's and so on is now officially posted through December
          31, 2004. It's less formally know to be there through 2006 or
          maybe 2008. Depending wholely on how well your application can
          be postulated as to the specific task at hand to the use of these
          techniques, even Heritage applications of code still needed back
          to the '386 era and into the early 1980's are still fully usable
          and supportable under OS/2 .. and will be for many years even
          beyond those dates. Yes, USB, fire-wire, the whole nine yards.

          Specifically, under the issue of multiple screens and monitors
          from the same box, you'll find that the brand new Sci-Tech Graphics
          driver solution offically endorsed and supported by IBM for OS/2
          will, in fact, let you use the Matrox dual-head video cards to
          accomplish this task. That even with a dozen PB 3.5 applications
          simultaneously in use on the same desktop and with and spanning
          both monitors! So noted. you can split the screen for the entire
          desktop across them. Although I've never done it, the use of a
          Monchrome monitor in common use, using the split video page techniques
          suggested by Lance for memory video writes, should work beautifully.
          My industrial care single board CPU CIRRUS chipset dual flat panel
          and conventional monitor output is fully supported. That much I
          do know for fact.

          I use the old page shift video windowing techniques in all my work
          and have been doing so with PowerBASIC for all these years. There
          has never been, to date, a single instance of trouble with popping
          whole screens and chunks of them back and forth on the desktop at
          will ever for me. That's how HELP is enabled in all my programs.

          One other, I suspect, VERY important milestone on where OS/2 is
          going in the future may be of interest to you as well. Recall,
          that as a totally OBJECT oriented operating system, orchestrated
          by threads, one of OS/2's really beautifully designed functions is
          to assign even complete operating systems, such as DOS .. into a
          complete emulation within the host system of OS/2. That's partly
          how this is so beautifully orchestrated in it! WIN-3.1 is nothing
          more than an OBJECT to it, as was and is, the initial experience
          of WIN-95, some of the programs for that and early WIN-NT, of
          which run as native code in it anyway.

          By the way, if you really want extremely reliable roll forward and
          transaction processing enabled plus indexed files which have this
          same capability, Btrieve's 6.15 for DOS does this horribly well
          even with no need, on the average, for any Btrieve Server based
          instance of this for OS/2. It combines really well with OS/2
          when based upon 4K data read/write blocks were are the target for
          the HPFS file system and write through caching for it.

          And please note! Just released, through CONNECTIX and cross-licensed
          by INNOTEK in Europe for OS/2, is a complete HOST/GUEST toolset.
          The complete mission-critical OS/2 operating system may now host,
          as a secured OBJECT, any flavor of WIN or MULTIPLE flavors of it
          you may desire, as well as RED HAT LINUX 7.3 too ... under OS/2.
          What happens is that you simply create an OS/2 HPFS disk partition
          of any size. You "install", the GUEST operation under OS/2 as if
          it was on an 'invisible' system. The entire WIN-XP, or NT, or
          ME, or 95, or any version or SIMULTANEOUS comination of them then
          becomes only a DISK IMAGE to the OS/2 thread hosted host! You
          may wipe that, restore it, do whatever you like with this 'phantom'
          complete guest or guests. The HOST does not care a whit about it,
          nor can any of the pest problems of the virus or hack game or
          whatever .. pass the barrier to the HOST .. as was/is noted.

          As far as I know, it's noted that full C-2 level security does exist
          for this thing on the OS/2 side. However what you do with a GUEST
          must, I suppose, open that disucssion to what isn't posted for C2
          for OS/2 proper.

          The entire GUEST experience is nothing more than a WIDOW on your
          OS/2 Desktop; that's all. That is the same sort of thing which
          was created way back then for WIN 3.1 and DOS and so on.

          Processor and memory requirements are as follows. All you'll need
          is minimum of a 400Mhz CPU and either 128MB or perhaps 256MB for
          OS/2. It's nice to have more, but not for OS/2 at all unless for
          certain complex applications. Then on top of that, you will need
          to upgrade the CPU for whatever level is called for as minimal for
          the GUEST operating system you wish to use. Obviously, code and
          processor bloat has inflated that horribly from WIN-95 upward.
          For memory, you will need to simple add whatever de-minimus
          extra memory is needed for each of the operating guest systems
          you intend to run simultaneously!

          The CONNECTIX toolset takes care of all the rest. It handles all
          of the hardware and driver requirements, converting them to standard
          such tools as is found in the OS/2 game .. and ... handles all
          networking and LAN operations as well. The systems appear to be
          nothing more than simultaneous connections or drives on the LAN
          you have on OS/2 (And your guest as well). As noted in the demos,
          all the required translation between file systems and so on are
          handled on the fly for you by the toolset(s). Your common file
          with the date you postulated will simply be a resource across
          that internal LAN for the various things you can dream up, and
          ... if you are using OS/2 for the RANDOM SHARED ACCESS networked
          file operations, I suspect ypu'll have no trouble with that if
          WIN doesn't have trouble with that in native use with PB 3.5 either.

          You may choose to use the same SCI-TECH dual head monitor approach
          across the combined HOST-GUEST(S) operation. So noted in the
          OS/2 Usegroups, this seems to work out very well across even
          Flat Panel displays.

          Actually, you can go in the reverse and use the WIN operation as
          the HOST and then run OS/2 of any flavor under it. There are
          only certain versions of WIN which can be used to do this ... I
          didn't note that as I'm not a WIN afficienado at all. I'm not
          sure that you can use Red Hat 7.3 as the HOST yet. I didn't
          notice that.

          We live in interesting times. At, of all things, a FidoNet Net
          382 BBQ monthly meeting in Austin recently, I theorized that the
          entire IBM 64 Bit CPU internal hardware and operating system
          game ... would be simply a 64 bit extension of OS/2 as what is
          now the "Z" IBM operating sustem for it. It is already known
          that this sort of emulation and HERITAGE assurance for code work
          is postulated to work under it, whatever "it" turns out to be.

          I have no official knowledge of that, but two of the table guests
          both work in systems development at the Austin campus. There was
          this puzzled huge smile on their faces when I popped off with the
          theory ..

          Further affiant sayeth not, but if you REALLY want to do cool things
          with what you posted needed to be done, for a VERY long time in
          the future you should be able to do all you can dream of with
          OS/2 and this game.

          Thinking "Out of the box", maybe?





          ------------------
          Mike Luther
          [email protected]
          Mike Luther
          [email protected]

          Comment

          Working...
          X