textfiles/messages/ALANWESTON/1994/DLPH02_11.txt

85574 11-FEB 00:17 General Information
     LHA Port to OSK
     From: JES68K       To: MIKEHAALAND (NR)

Mike,
      Is there work in progress on LHA 2.13 to OSK?  One of our users
on ACS BBS is interested in a version to run under OS9000 ... he just
finished an AR Port to OS9000.  If no one is working on the 2.13 version,
would you know if/where the source for this would be available?

       === Jesse ===

-*-

85575 11-FEB 04:48 OSK Applications
     RE: g-windows (Re: Msg 85562)
     From: EDELMAR      To: ROYBUR (NR)

 Roy

 > ...  i.e., g-windows for the SysIV that would cooperate with k-windows for
 > the SysIV?

 Interesting question.  Don't know.  I'll have to see how K-Windows is
 implemented on the SYSTEM IV.  Don't even know who is doing it, whether
 they've started, etc.  Unless the programmer doing the port isn't concerned
 with co-existance, I'd think he'd contact me to discuss what could be done.
 Then there is the question of how many people will want it and how much work
 will be required.  It would be interesting if K-Windows was also implemented
 to run under G-WINDOWS (not sure that's practical).  Then it wouldn't be
 restricted to SYSTEM IVs; could run on any machine running G-WINDOWS.

 Price of G-WINDOWS is $249 and includes a mouse and new mouse cable for the
 serial port.  Developer's Pack is $299.  Order both for $499.  Add $10.00
 for S/H.

 My upgrade policy is simple.  Free upgrades for 1 year after purchase.  In
 fact, I distributed 2 updates free to all my customers regardless of when
 they purchased G-WINDOWS from me.  The first, Edition 45 went out May last
 year and I finished shipping Edition 50 last month.  All my customers have
 Version 2.5, Edition 50 of G-WINDOWS; the latest official release.

 Until I know more about how K-Windows is to be implemented, I can't anticipate
 what the upgrade/pricing policy will be.

 Ed Gresick - DELMAR CO

-*-

85576 11-FEB 06:10 Programmers Den
     RE: OSK and Graphics (Re: Msg 85532)
     From: EDELMAR      To: THETAURUS

 Chris,

 To answer your questions requires an understanding of the flexibility of
 OS-9 and the manner in which MW markets it.

 With a couple of exceptions, MW does not offer OS-9 to the end user.  OS-9
 is sold to the hardware manufacturer (OEM).  Depending on the licensing
 agreement, this will include the kernel, some or all of the file managers,
 the utilities, assembler, linker, C-Compiler, etc.  It does not include
 drivers or descriptors although MW does provide _unsupported_ sample drivers
 and descriptors for some of the more popular I/O chips.  It is up to the OEM
 to write his own drivers and descriptors.  This approach was taken by MW to
 permit each OEM to optimize his hardware for his market.  (MW will write
 drivers for OEMs under a separate contract.)  Thus, the capabilities of a
 specific hardware package from an OEM are determined primarily by and are
 the responsibility of the OEM.  (The exceptions I mentioned above are OS-9000
 for the 386/486 and several Motorola VME boards.)

 I don't have any actual figures but I believe that the bulk of OS-9 sales
 are for rommed, diskless applications.  If they include any I/O it will
 be for data collection, processing and control; they will not include any
 human user interface.  The next level might by something like CD-I.  The
 OS is contained in a ROM and it reads and controls a optical disk.  Output
 is to a TV set and other input limited to a few commands.  The systems
 you and most people on the forum are familar with are disk based.  The bootrom
 contains only enough info to find the bootfile on the disk, load it and switch
 operation to OS-9.  (The CoCo version uses software instead of a bootrom.)

 Up to a few years ago, OS-9 systems which required user interface used
 text terminals.  These were mostly development platforms although some were
 used for business applications.  Of course, there were always a few hobbyists.
 The only hardware available offering graphics was the CoCo.  While MW did
 write much of the code, this was done under contract to Tandy and Tandy owns
 the rights.

 More recently, we've seen customers who want graphics capabilities.  Several
 of the OEMs providing VME equipment wrote drivers capable of driving graphics
 terminals.  Others have designed graphics boards for their equipment.  Each
 OEM has selected the graphics chip he felt best suited his market's needs.
 Since the graphics chips are different, each driver is substantially different.

 And each OEM has written his own equivalent of CGFX.l libraries and calls.

 The nearest thing to a GFX standard is MW's RAVE.  Currently, RAVE supports
 the Vigra MMI-100, MMI-250 and Matrox VIP-640 graphics processors.  So far,
 RAVE seems to be accepted only for a few dedicated apps.  But, RAVE has been
 selected for Bell Atlantic's VOD system.  Then, there are the various window-
 ing packages; X-WINDOWS, G-WINDOWS, K-WINDOWS and MGR.  X-WINDOWS is not
 practical for the 'lesser' microprocessors.  MW recommends that a 68040 be
 used.  G-WINDOWS has probably received the greatest acceptance by OEMs and
 users.  K-WINDOWS, so far, is limited to one hardware platform and MGR's use
 seems to be limited to a few European companies.

 For the SYSTEM's IV and V Computers, we've settled on video cards using the
 TSENG LABS ET4000/ET4000w32i graphics chips.  (TSENG LABS is also designing
 the Vigra chip.)  Our driver for these boards supports text modes from 40 x
 25 to 132 x 44 and graphics modes up to 1024 x 768 x 256.  A graphics C
 library is available which is a sub-set of Microsoft's Quick C.  While we
 sell and support G-WINDOWS, G-WINDOWS is not necessary for gfx on either
 computer.  Several people have written gfx programs.  There is Bob Hollman's
 port of TETRIS.  Very nice gfx and action.  Dave Proctor has written an
 excellent 'flic' viewer.  Several others have written specific programs using
 the SYSTEMs IV & V gfx capabilities.

 I hope the above answers why OS-9 has no gfx standard.

 To answer a couple of your specific questions -

 > ...  With Dos, you may or may not get Windows with the system, but even
 > if you don't you can still write graphics based programs.

 Yes and No.  So long as you stay within the modes defined by IBM (0 through
 10 and 13 through 19) your code should run on any VGA gfx card.  But this
 will limit you to 640 x 480 x 16.  There is no standard for the super VGA
 modes.  So if you write code for IBM's 8514 display adapter card (PS-2),
 in the 800 x 600 or 1024 x 768 modes, it probably won't run on other cards.
 Recognizing this, most vga card suppliers include drivers for various soft-
 ware packages.  Conversely, many software providers include drivers for
 various cards.

 > ...  I know there is or will be BGFX again for Basic, ...

 MW has no plans for a GFX package for Basic.  There may be plans for such
 a package from Blackhawk or third-parties but it will be hardware specific.
 (The CoCo GFX package is hardware specific.)

 So, you can see the way things stand now, even if you get a machine that
 supports gfx, software you write probably won't be portable to other hardware.
 Of course, if you're doing this for your own amusement, who cares?

 Gfx compatibility across hardware platforms is one of the reasons for the
 various windowing systems being offered.  Gfx written under a given windowing
 system will (or should) run on any hardware supporting that windowing package.

 Ed Gresick - DELMAR CO

-*-

85577 11-FEB 22:52 System Modules (6809)
     RE:         Disto/Ken-Ton Clash (Re: Msg 85233)
     From: MODEL299     To: COCOKIWI

Been a while since I logged on to reply to your last message.  If I have good
information on the ken-ton addresses iti can be FF74 or FF70.  I believe
those are the selectable addresses.   Mark

-*-

85579 11-FEB 23:27 System Modules (6809)
     RE:         Disto/Ken-Ton Clash (Re: Msg 85577)
     From: COCOKIWI     To: MODEL299 (NR)

yeah....FF74 is the problem..it clashed with the Sector Buffer location for
the SC-II....The NO halt part.....It can be recified easy by either moving
ken-tons address..or the SC-II FF74 location....
which ever is easier!<grin>
Dennis

-*-

End of Thread.

-*-

85578 11-FEB 23:04 Programmers Den
     'nother C problem
     From: WDTV5        To: ALL

   I've got a real puzzler in some code for the next edition of PrintForm
   thats about to make me take up origami or ??

   Example: argv[i] = "/wp"; /* the output side of my WP-RS amber screen */
   -------
     if(!out_flag)
     {
       if(argv[i][0] == '/')  /* its prob a device */
       {
         if(outpath=fopen(argv[i],"w")
           out_flag = TRUE;
       }
       else if(outpath = fopen(argv[i],"a+") /* its likely a file */
         out_flag = TRUE;
       if(out_flag) etc;
     }
     else
     {
       printf a bunch of error msgs and exit(1);
     }
   -------
   printf's scattered thru that indicate a path was opened to /wp, outpath
   number is always #396. "proc" doesn't see that path, "paths" does! As
   path #3 in the list of 6 or so that pf may have open at any one time.
   And the data going down that "path" is apparently straight into the "bit
   bucket" as it never shows anyplace.

   If I sub "/wn" for one of the other windows which has not been opened,
   then it is removed from the available list and clicking on the icon to
   open another shell skips that descriptor number. And if its a regular
   window, not the WP-RS, and a shell has already been started on it, the
   window disappears for the duration of the above programs execution time.
   It can't be "cleared" to as the clear key skips over it.

   Disk files are ok, being created, written (or appended to) and closed
   correctly, but a device window (or the WP-RS) doesn't work. Other devices
   such as "/lp", my normal printer descriptor work as usual.  The WP-RS can
 still be cleared to and used normally while a path is supposedly in use
   to it however.

   I'm running Nitros9, v1.16 here. Anybody got any ideas whats going on?

                                  -=Gene=-

-*-

85580 11-FEB 23:43 General Information
     RE: Wish list (latest) (Re: Msg 85549)
     From: SCWEGERT     To: MROWEN01 (NR)

 > I read your note regarding the Internet COCO list server. You described
 > how to be added to the list, bit what do you do to remove yourself from
 > the list? I'm interested in chyecking it out, but I don't want to keep it
 > if it over- loads my mail queue. (I'm wanting to use my work internet
 > address).


Good question!

To remove yourself from the CoCo LIST a message to the same address,
listserv@pucc.princeton.edu, containing the single line:

 UNSUBSCRIBE COCO

 should do the trick.

Alternately, you could drop a mail message to me at steve@wuarchive.wustl.edu
and I can zap you manually.

I doubt the LIST volume will overload your mail box. We see about 12-15
messages on a busy day. If you have access to newsgroups, the mailing list
is echoed to bit.listserv.coco. That should give you a feeling for the
number a messages per day.

Give a shout if I can help!


*- Steve -*


-*-

85581 12-FEB 00:19 General Information
     The Future
     From: REVWCP       To: ALL

Dear Friends:
While visiting with RICKULAND of Conect fame, we were discussing
what was now the minimum requirement for a COCO OS9 system.  For
example, at CSJW we have:
     1. A 2meg COCO 3 with a 6309, 5-1/4 and 3-1/2 drives, 20 meg
        harddrive, SC 2 with 4-in-1.
     2. A 512k COCO 3 with 6309, 2 5-1/4 drives in a Tandy 2000
        Case with an st252n with Disto SC-2 and 4-in-1.
     3. A 512k COCO 3 with 6809, 3 Tandy 5-1/4 80 track dsdd,
        Mulitpak, a Disto MEB with HardDisk Controller, two
        10 meg Bernoulli Drives, and soon a Tallgrass Tape Backup
        Unit.
     4. A Northern Telcom DisplayPhone being used as a terminal
        on the COCO/2000 box.
     5. EARS, the Voice and various esoteric hardware.
I think it is clear that the 6309 is now basic operating
standard.  512k minimum with 2 megs desirable.  We have both
Powerboost and Nitros9.  Obviously, RS232 packs, etc. are also
required equipement.  I would like to know what hardware you are
running.  This is for several reasons:
     1.  What is being used so that programmers could write for
         this hardware.
     2.  So that the hardware vendors would know what hardware is
         still needed.

     3.  What software you would like to see.  Obviously there
         are many of us in the 6809/os9 world who still want to
         see the Level 2 upgrade released.  This is a mandatory
         project for the Users Group to undertake.
     4.  The SBF module from Microware.  It was written for 6809,
         but never released.  We should negotiate with with
         MicroWare to get any unreleased 6809 specific modules.
     5.  Certain RSDOS progras to be ported to 6809/OS9.
Of course it should be noted that 6809 and 6309 should be
considered interchangable as far as need.  While OSK is the
future, OS9 (6809,6309) is still a present reality and should not
be abandoned.  To do so would leave little reason for the 6809ers
to support the User Group.  Please take a few moments to respond
to the questions raised in this posting, and feel free to post it
where-ever you wish.  If you would like, a postcard to:
     Brother Jeremy, CSJW
     Box 1903
     Racine, WI 53401
with you opinions would be very helpful.  The views expressed in
this posting are not neccessarily those of the User Group, and I
take full responsibility for them.  Please respond.  We need a
large amount of replies if we are to get any meaningful guidance.

With all best wishes,
Brother Jeremy, CSJW
OS9 User Group Treasurer




-*-

85582 12-FEB 00:22 General Information
     RE: Microware in the WSJ (Re: Msg 85547)
     From: THETAURUS    To: PAGAN (NR)

        >>Maybe if two types of operation were considered "default" -
   dual floppy and hard drive - it might work.

        My thoughts also. I have gotten several programs that worked in a
   similar way. _Data Windows_ might be one of them, plus Bob Van Der
   Poel's stuff I think. It had install programs for both floppy and hard
   disk users. Now all we would need is to include in the procedure, is
   the menu asking if the user wishes to place the files in different
   directories or maybe even better have a command line option so that
   the novice users who couldn't care less can go on with the default
   operation, while the more experienced users who know how to deal with
   commmand lines can go into more detail and move the files where they
   want them<with the install program obviously making it easy for them.
   There would be no point for it otherwise<Grin>. Boy I'm tired, I
   better stop here. Although I do agree pretty much with the rest of
   your message.

        See Ya
        >Chris<

-*-


FORUM>Reply, Add, Read, "?" or Exit>