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>