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