85868 24-FEB 18:19 Music & Sound UltiMuse with NitrOS9 From: NICKJOHNSON To: ALL Is anyone running UltiMuse successfully with NitrOS9 version 1.15 or greater? I already know about the need for the timing patch, but I'm having problems getting the program to run at all. (never even gets to the play routine) Nick -*- 85879 24-FEB 21:48 Music & Sound RE: UltiMuse with NitrOS9 (Re: Msg 85868) From: WDTV5 To: NICKJOHNSON Yes, I am runnning it, to both a hardware midi interface driven from a modified rs-232 pack, and to the bit banger, both at the same time IF I like! There is a file available here describing the nuts and bolts of how I did it, from a mutliview icon yet! By now its probably in the music databse. A quick synopsys is that I've got the nv.115-6 patched VDGINT in my normal boot, the AIF.ume file names a script in the commands dir whose exec bit is set, and this script in turn launches Umuse3 for me, version 4.7.2 in this case. It should all be in the file, including the how-to's of patching you version of Um3play. Get that file & study it for hints about your actual system as what I did there should be a pretty universal way to do it altho the exact location of the byte to change might not be given correctly for the version of Um3play you might have. The approach I used for the rest of it should be usable on any system, even stockers provided the basic bug fixes commonly applied to the stock system have been applied to yours therebyy cleaning up the crashes. One comment, I suspect that a system with a know sensitivity to the BLOB might be harder to make work. Good luck Oh, PS etc, I've got those 4 vdgint descriptors in my bootfile too. Thats the v0.dw, v1.dw etc available in the database here. Again, good luck -=Gene=- -*- 85884 24-FEB 23:23 Music & Sound RE: UltiMuse with NitrOS9 (Re: Msg 85879) From: NICKJOHNSON To: WDTV5 What's the CRC and version number of your VDGINT? -*- 85906 25-FEB 23:46 Music & Sound RE: UltiMuse with NitrOS9 (Re: Msg 85884) From: WDTV5 To: NICKJOHNSON Hi Nick, an ident of the one in memory says its Edition 3, revision 3. The crc is $AFDFF4. Hope that helps. Cheers, Gene -*- 85920 26-FEB 11:38 Music & Sound RE: UltiMuse with NitrOS9 (Re: Msg 8) From: NICKJOHNSON To: WDTV5 Many thanks. Now I can test a theory -*- End of Thread. -*- 85869 24-FEB 19:39 General Information RE: Palm (Re: Msg 85851) From: JOHNBAER To: DIETER > I have LHA 2.06 for OSK and have so far NO problems, got the file from the > StG network... > > Dieter > Well all I can say is that MRGOOD, EDELMAR, and myself have found that the Palm file here on Delphi is a problem with 2.06. 2.01 DOES unarchive it thou... -- John - johnbaer@delphi.com jbaer@pacs.pha.pa.us * IX 1.01 * "If you lose your memory, forget it!" -*- 85885 25-FEB 00:00 General Information RE: Palm (Re: Msg 85788) From: DIETER To: JOHNBAER > Like I said in a previous message, this is the only file that I had > a problem with. As for me, 2.06 is darn good. I've `opened' dos, > amiga, and atari lzh/lha files with no problems. > I downloaded PALM yesterday, and also have problems extracting the fi-E 058 General Information RE: Palm (Re: Msg 85869) From: DIETER To: JOHNBAER > Well all I can say is that MRGOOD, EDELMAR, and myself have found that the > Palm file here on Delphi is a problem with 2.06. 2.01 DOES unarchive it > thou... > In the meantime I found out that I have the same problem! Where can I get LHA 2.01 from? Dieter -*- 85919 26-FEB 10:48 General Information RE: Palm (Re: Msg 85912) From: JOHNBAER To: DIETER Dieter, > In the meantime I found out that I have the same problem! Where can I get > LHA 2.01 from? > It's right here in the database. Uploaded by Mike Haaland. Check the OSK apps. first. I think thats where it's at. -- John - johnbaer@delphi.com jbaer@pacs.pha.pa.us * IX 1.01 * "Clipper Chip - Big Brother Inside !" -*- End of Thread. -*- 85870 24-FEB 19:57 Applications (6809) RE: TSEDIT? (Re: Msg 85825) From: JEJONES To: KEITHJA mport into PageMaker 4.0 on my PC to build my mag, "the world of 68' micros". -*- 85873 24-FEB 20:59 Applications (6809) RE: TSEDIT? (Re: Msg 85866) From: DSRTFOX To: ISC Being one of those third party supporters, I thank both you and Chris very much! If that attitude prevails, we'll be around to support you for quite a while!! -*- 85880 24-FEB 22:08 Applications (6809) RE: TSEDIT? (Re: Msg 85873) From: ISC To: DSRTFOX (NR) Thanks again, Frank. I know it gets lonely sometimes, but those of us who know appreciate your efforts very much. Bill -*- 85881 24-FEB 22:19 Applications (6809) RE: TSEDIT? (Re: Msg 85872) From: ISC To: DSRTFOX (NR) Frank, The only negative factor about "Simply Better" regarding Keith's original post is that he wanted to import text to "Home Publisher" which I assume he is using in OS9. So I was trying to point him to OS9 programs which produce ascii files. Then he could also use TSSpellsme of my corespondence where different fonts and/or graphics are required. I guess I would like to be able to do this from OS9, but in all other respects, the TS series has done well by me. I believe the series would do what you have spelled out as YOUR requirements. The vi patches, available here on Delphi in the OS9 sig, are mandatory if you want to run the series under OS9 lvl2. As some one else pointed out, if you are familiar with vi on UNIX, the TS series, particularly TSEDIT with the vi patches, will look very familiar. Others have brought out that support for current third party dealers rather than continuing to support the first party that has turned their back on the system has merit. I might point out that buying from the above mentioned first party and getting "free" software out of the sig database has the same effect on the third party suppliers. But, if it means getting the job done or going with out because of the buck$, then go for what you can afford. I do'special on ALL of the TS packs! So I got TSEDIT, TSWORD and TSSPELL all for less than $50! I had recently learned vi on UNIX, and I quickly realized TSEDIT was going to be VERY similar to vi. I looked at TSWORD and trashed it off the bat. I did not care for its icon interface. And at the time I did not need the functionality of TSFMT. I did like TSSPELL a lot. Later when I got just a little more involved with Word Processing, I realized I needed a text formatter. I looked around and decided on mroff, as it was more functional than TSFMT and it was free. But I still wasn't happy. I knew there had to be something better out there. Before going to OS-9, I had done a little Word Processing with Telewriter-128, written by Bob van der Poel. I noticed an ad in a new magazine I had just subscribed to, The CoCo Clipboard (I'm sure a lot of you will recognize that name!), from Bob van der Poel Software for an OS-9 editor program he had called VED (for Visual EDitor). He didn't want too much for in8 so you can load it up in your startup script in a single memory block and your editor is always ready for you. It can edit a file of any size up to ~54K, grabbing as much memory as it needs and growing in memory as the edit session demands. Plus, since it was written by Bob, it had virtually the SAME function keys as the editor for TW-128!! So the learning curve for me (since I had used TW-128) was super quick. I wrote to Bob that I was pleased with VED and now it appeared that he had merely taken the editor portion of the TW-128 code and ported it to OS-9. And now all we OS-9'ers needed was for him to port the text formatter portion of it to OS-9 as well. Less than a year later, VPrint hit the market. It is by far the most powerful text editor available for the CoCo3. It has tools I have yet to discover and use! So, yes, for many users needs, TSEDIT/TSWORD/TSSPELL are fine, but when your needs get a little more serious, the VED/VPRINT/TSSPELL configuration looks better and better! - Well, the 8450 IS pretty decent.. the older VS100s we had before this were a bit of a pain... that was TWO VS100 models linked together... had to keep 'em coordintated when bringing the system back up or taking it down. If one crashed, you could sometimes re-start without messing with the other, depending on HOW it crashed! We get occasional corrupted files and such for seemingly no reason whatsoever. We can only IPL and hope that clears it up. Recently it displayed intermittent problems, so I reset the thing, only to have on e heck of a time getting it started again. I crashed about two hours after users really started getting on! Got everyone off, then reset it again, and everything has been sweet since! But I'm about to start it back up from a reset now.... -*- 85875 24-FEB 21:09 General Information RE: Unix System V problem (Re: Msg 85841) From: DSRTFOX To: ALWAGNER Read 85874. It seems that a file or so gets corrupted occasionally on a multi-user system and causesrb (Re: Msg 85874) From: BROWN80 To: DSRTFOX (NR) I used to think that nothing could be worse than a system 36. I was wrong. We went from a lot of 36's to one AS400. Yes, while most companies are networking and spreading their processing around, we are centralizing ours. Until our new software is written and debugged, we are running 36 environments for our old software and the whole mess is tied together with a VSAT system that we share with a department store chain. Sounds kinda neat doesn't it? I have learned a lot. I can't complain about having a dull job. Our guys at the home office took a week and 30 people working all over the United States to find two cut wires at their office last month. Oh! good luck on your reset. John Brown -*- 85896 25-FEB 05:01 General Information RE: Unix System V problem (Re: Msg 85875) From: ALWAGNER To: DSRTFOX (NR) Its not a system crash in the classic sense as the only symptom so far has been the ihbe worth looking for a 'cron' job that is scheduled to run every so often. Perhaps one of these jobs is not having its I/O re-directed properly, or the program is not restoring the terminal characteristics properly when it exits. -------------------------------------------------------------------------- Ken Scales Delphi:KSCALES Internet:kscales@delphi.com CIS:74646,2237 -*- 85911 26-FEB 00:26 General Information RE: Unix System V problem (Re: Msg 85841) From: BANANAMAN To: ALWAGNER I wonder if the console would come back on-line if you unplugged the RS-232 port and plugged it back in. Might wake up the getty controlling it. --Andy -*- 85938 27-FEB 06:45 General Information RE: Unix System V problem (Re: Msg 85911) From: ALWAGNER To: BANANAMAN (NR) The Console keyboard is the one that you would have connected to a pc if it were not running UNIX. ie., it is connected directly to the motherboard via a connector. It is not running as a termit suggest fixes for a problem you can't personally observe. -*- End of Thread. -*- 85876 24-FEB 21:11 System Modules (6809) RE: SCSISYS v1.0/2.2 (Re: Msg 85837) From: DSRTFOX To: DONALDS Leave a message to COLIN MCKAY (I'm not sure if that is his user name or not, no space between names). He sales Matt's drivers (commercial version). -*- 85917 26-FEB 10:00 System Modules (6809) RE: SCSISYS v1.0/2.2 (Re: Msg 85876) From: DONALDS To: DSRTFOX (NR) Thanks for the info. I will try that. I have a 2meg upgrade and was trying to get use of most of the ram with a RAMDISK. I have patched locations '0C and 74' with different values but the best I can get reliably is 1040 sectors. OH; I did patch location 'D4' with '7F' to recognize the 2meg. Don -*- End of Thread. -*- 85877 24-FEB 21:14 OSK Applications RE: adding titles to windows (Re: Msg 85847) From: COLORSYSTEMS To: VAXELF A framed window (with cgfx.l and KWindows on an ERVED, menus }; The problem is there are NO menus. Just a plan WT_FBOX that I want to title. Can I NULL out the second and last elements and call it as _ss_wset(TermShell,WT_FBOX,WNDSCR); John D. -*- 85898 25-FEB 20:00 OSK Applications RE: adding titles to windows (Re: Msg 85847) From: ROYBUR To: VAXELF john, i don't know diddly about what you're trying to do, but is "GREY" something _you_ defined or is it something already known to CGFX.L? i ask because, while "grey" is not incorrect, another way to spell it is "gray". 8*).............roy -*- 85899 25-FEB 21:00 OSK Applications RE: adding titles to windows (Re: Msg 85898) From: VAXELF To: ROYBUR RED & GREY are the forground and background colors. It just happen that is how it was spelled in the orginal files. John D. -*- End of Thread. -*- 85883 24-FEB 23:07 General Information RE: Hard Drive Problem (Re: Msg 85858) From: RANDYKWILSON To: PAGAN r14 baud, ouer transfer never has any errors no mather how large the transfer is, and the fastest CPS was 590... I also have a TANDY RS-232 pack that I was using at 9600 baud, No problems either, but I do have the 63C09 CPU, and NitrOS-9, my brother also... Dieter -*- 85887 25-FEB 00:00 Telecom (6809) RE: 9600 on a CoCo... (Re: Msg 85805) From: DIETER To: MITHELEN > You CAN get it to work reliably, with > minimal software changes (hacked SACIA) and a cable hack, but still > It does not REALLY handle TRUE 9600 baud throughput. > Paul > You are right Paul! You dont get true 9600 baud, but the fastest transfer the CoCo 3 and OS9 is capable of, and thats wat I am after till I can either implement StG v3 or StG v4 on the MM/1a, and is not that then I will change to RCIS, that BBS software a lready runs on the MM/1. But I like StG better and will wait till then, or if I can find an StG system that is running at 9600 baud right now, and is w Dieter -*- 85892 25-FEB 02:08 Telecom (6809) RE: SandV BBS (Re: Msg 85890) From: MITHELEN To: DIETER Just talked with Scott (again) tonight, and he was working once again on "stgxfr" the V4 netxfr program... HE had to do som major rehashing of thew code, due to major problems in the read routine, and he had some problems in the CRC routine for Unix. He said he might have it comunicating by next weekend, at the low level... then he has to implement the higher level protocal to it... I'm still optimistic he will getit done by fest (i'm just too optimistic) -*- 85900 25-FEB 21:35 Telecom (6809) RE: SandV BBS (Re: Msg 85886) From: ZOGSTER To: DIETER > any errors no mather how large the transfer is, and the fastest CPS was > 590... > I also have a TANDY RS-232 pack that I was using at 9600 baud, No > problems either, but I do have the 63C09 CPU, and NitrOS-9, my brother > also... The 6309 with Nitro makes the differance between ni rsll Netting with each > other, > soon as either Horst or I can find an StG system that has and is running > is system with a high speed modem (9600 baud or better) and is willing to > be ouer parent system will will be back online... Currently all the StG systems are running at 4800 or 2400 baud. If/when I get a 6309 with Nitro and a high speed modem Narnia will be set at 9600. We will miss both of your nodes. Jim -*- 85922 26-FEB 13:49 Telecom (6809) RE: SandV BBS (Re: Msg 85902) From: DIETER To: ZOGSTER > Currently all the StG systems are running at 4800 or 2400 baud. If/when I > get a 6309 with Nitro and a high speed modem Narnia will be set at 9600. > > We will miss both of your nodes. > > Jim > Thanks Jim, let me know when and if You are running 6309/NitrOS9 with a 9600 baud modem... Till then I will stay in contact via Delphi or CIS... G'Day! Dieter -*- 85923 26-FEB 13:49 Telecom (6809) RE: SandV BBSro and the CPS drops tremendously. For now (until I get a chance to do all my hardware hacks and repackage the CoCo for the BBS) I am going to stay at 2400 baud. Carl -*- 85944 27-FEB 09:57 Telecom (6809) RE: SandV BBS (Re: Msg 85834) From: CBJ To: RICKULAND (NR) Rick, You must realize that Jim is talking about a bidirectional transfer of data here. He is running StG, just like me. TTYL, Carl -*- 85945 27-FEB 10:05 Telecom (6809) RE: SandV BBS (Re: Msg 85923) From: CBJ To: DIETER (NR) Dieter, I've never had any luck getting the hack to work properly with my CoCo. Perhaps what I need is to send you my RS-232 pak and let you do the hack and send me the pak and your SACIA settings. IF I could get ChiCoCo running at a reliable 9600 baud I'd hook the US Robotics back up to it. TTYL, Carl -*- End of Thread. -*- 85891 25-FEB 00:14 Programmers Den RE: print formatter (Re: Msg 85792) From: MDALENE To: WDTh I can't tell ya where to find a legal copy now. I think that puppy is still in the cmds dir tho. Humm, nope, wonder where it got to, its not even in my "cmdsineveruse" directory, probabaly lost in one of the st-238r sneezes here. I've got the original disks yet I'm sure. But no, I hadn't really given that any real thought yet. Maybe, uh, . . .. Cheers, Gene -*- 85910 26-FEB 00:10 Programmers Den RE: print formatter (Re: Msg 85891) From: WDTV5 To: MDALENE Humm, read it offline. Most of the info on the dot commands is hidden in the file itself. Running pf on pflister with a starting page of 100+ will leave you with a file in that dir describing the dot commands. The ^ commands are in the help files. If owrse comes to worse, grab dEd and sub a space for all the control codes, then list it. I keep forgetting there are some users who may not have had this siince day one, and have a hard time getting it "bootstrapped" and running well enough to print the listing. And I odn name of course) -*- 85904 25-FEB 23:22 System Modules (6809) SCSISYS v1.0/2.2 From: KSCALES To: DONALDS > Leave a message to COLIN MCKAY (I'm not sure if that is his user name or > not, no space between names). He sales Matt's drivers (commercial > version). Colin isn't active on Delphi, but does frequent the CoCo, OS-9, and MM1_Tech echos on Fido, as well as the Princeton CoCo list. (There are just too many active forums to keep up ;-) So Colin follows those groups, and I try to monitor this forum and the CIS OS-9 area, and we keep each other informed of the highlights. So, you can reach Colin through me, or you can contact him directly through Delphi Internet mail at IN%"cmckay@UUISIS.ISIS.ORG". ... / Ken -------------------------------------------------------------------------- Ken Scales Delphi:KSCALES Internet:kscales@delphi.com CIS:74646,2237 -*- 85916 26-FEB 09:55 System Modules (6809) RE: SCSISYS v1.0/2.2 (Re: Msg 85904) Fro now what you were saying. Sure, you can contact Colin through me, if you want to... I talk with him pretty much daily. Cheers... / Ken -------------------------------------------------------------------------- Ken Scales Delphi:KSCALES Internet:kscales@delphi.com CIS:74646,2237 -*- 85939 27-FEB 08:40 System Modules (6809) RE: SCSISYS v1.0/2.2 (Re: Msg 85937) From: DONALDS To: KSCALES Thanks ken. I didn't see what happened to my message until I had logged off. The general question I had for him was I can use both of my ST277n drives under scsisys1.0 but when I switch to scsisys2.2 I can only use the drive that was refurb'ed the other one I can do a scsifmt with scsifmt2.2 but it will not use the 2.2 driver to do a logical format. where I can do both with 1.0 driver and scsifmt. Don -*- End of Thread. -*- 85905 25-FEB 23:23 Programmers Den Ultra C 1.1.2 From: PAGAN To: ALL This is a copy of a message I posted to comp.os.os9 r I (naturally ;-) ran some "benchmark" program through it to see what happened. All of the results shown were generated on a Delmar System IV with a MC68000-16, 4 Meg RAM, G_Windows and no hardware floating point coprocessor. Each of the compiled programs was run at least three times to check that the values being produced were stable. First I tried Dhrystone 2.1. With 3.2 I compiled both with and without the register attribute set. Since Ultra C ignores register declarations I only compiled without register attribute. All three versions below were compiled with no stack checking and I used the '-t=10' switch to tell Ultra C that time is ten times as important as space. The results shown are for 10,000 iterations Dhrystone 2.1 3.2 compiler cc -xist=/r0 dhry_1.c dhry_2.c -f=dry21.knr Header for: dry21.knr Module size: $1ABC #6844 Microseconds for one run through Dhrystone: 689.1 Dhrystones per Second: n a suppressed for either compiler. Ultra C was, again, told to give precedence to time over space. Each test run consists of sieving the numbers from 0 thru 1,000,000 once. Sieve of Erastothenes 3.2 compiler cc -xit=/r0 sieve.c -dALLC Header for: sieve Module size: $F10 #3856 Elapsed Time: 18.74 seconds cc-xit=/r0 sieve.c Header for: sieve Module size: $ECE #3790 Elapsed Time: 11.82 seconds Ultra C cc -to=OSK -tp=68K -itd=/r0 -t=10 -dALLC sieve.c Header for: sieve Module size: $CEC #3308 Elapsed time: 11.04 seconds cc -to=OSK -tp=68K -itd=/r0 -t=10 sieve.c Header for: sieve Module size: $C68 #3176 Elapsed time: 13.36 seconds This trial held a real surprise. As expected, the assembly language version was faster than the all C version when compiled under 3.2. With Ultra C, howevfwe Header for: whet Module size: $138A #5002 Whetstone time for 100 passes = 461 sec This machine benchmarks at 0.216920 whetstones/second Ultra C c -to=osk -tp=68k -itd=/r0 -t=10 whetstone.c Header for: whetstone Module size: $15C2 #5570 Whetstone time for 100 passes = 243 sec This machine benchmarks at 0.411523 whetstones/second Here, even tho the Ultra C generated module is 11% larger, the performance improved by a whopping 47%. Determining how much of this is caused by the 'fpu' module and how much from compiler optimization will take some more testing. When reading this message, remember that these three "benchmark" programs are "do nothing" programs I'm using to get an idea of how the Ultra C compiler performs. The real test will come when I start using it on application programs. There are still some unanswered questions regarding Ultra C. For instance, will 57) From: COLORSYSTEMS To: JES68K > How do I get the 1.1.2 update to Ultra C? via Peripheral Technology or > MWC? Is it freebie or $$$$$? From MWC. And for BIIIIIIGGGGGGG $$$$$$. ------------------------------------ Zack C Sessions "Always in motion is the future." - Yoda -*- End of Thread. -*- 85908 25-FEB 23:59 Programmers Den pf question From: WDTV5 To: ALL First to JRUPPLE: While it might be nice for gui trained users, putting in a menuing interface is not IMHO conducive to getting the job done in a timely manner. There may be some who could pick the command line opts out with a mouse quicker than I can type them, but the time to declare and show the menu would be added too. Uh, maybe. Naahh.. As far as the fonts and the escp2 stuffs go, I suspect that could be worked in with some additional monkey business to calculate the present vertical lines per inch and keep a running total of it. I'd need to fnboth the ^up and the ^down triggers. However, thats not presently very handy due to the current usage of the top row in that data array. So maybe we add 4 more rows at the bottom. Or even (and I've given this some thought but it sure would screw up the printing of already made files you've had for years) take out the automatic toupper(c) and make the array about 2.4x bigger. Use the uppercase to do, and the lowercase to undo, and start the basic array at $30, restricting the access by the ^ triggers to just the upper/lower alpha, but have the rest of those blanks filled in for 'pf' used config data, humm, I like that. Heck, if we used the 0-9 area for a direct 'use this size' command, the preparation phase of the editing would be a bunch simpler. However if we start the triggers below '0', then print_mod is gonna require major surgery. Making the array larger isn't what I'd call major tho. How many actual sizes are there in the escp2 command set?trcan handle 16 or more intensities per color. I don't have one of them puppies tho. 2. The formats individual line length in bytes. Thats an integer(16 bit) Why? Well, here a full line in 24 pin could be an 8640 byte line buffer! 3. The formats total height in 'load up a line and print it' lines. Another integer I suspect. So thats a 5 byte header. Here I'd like to force the issue a bit and require "printer ready" graphics, eg, a file which is, if arranged on paper according to those 4 items, a direct bit image of what you want to print. Or a negative image of same. I don't want to have to attempt to translate the color info in a VEF or GIF into something that would look ok on paper. Unless of course we're talking color ribbons here. My one attempt at that was for an amiga generated image at the tv station, we wanted to show the client what his graphic would look like in print so we played around for several days, using every option we coul ar regardless of how we twiddled the drivers options. Not satisfactory at all and we never did show the client anything but video. So the next question is obviously, other than FIT, is there an existing gfx format that matches those specs, or do we have to re-invent a new 4 cornered wheel here. FIT would be nice, but to reduce one of those to printable would take more cpu time and memory (and probably a smarter programmer too!) than we've got I'm afraid. Go see your local astronomer for the real details on FIT. Its the original, and presumably still the best "scalable" image transfer format today. Bulky files tho I'm told. It boils down to 'which existing, commonly used file format would match those requirements?' Item 1 I'm sure will be the sticking point. I'm not too allergic to attempting to wrap text around it either, but I really don't want to get into the centering and/or cropping of images, so they need to be trimmed and cropped for this traly by a program that can translate the bit image into the correct line buffers worth of process red (magenta), process cyan, process yellow plus black information in the proper order to be very simply read from the file and shoved out the door to the printer. With the plethora of methods used, that translator I suspect is going to be pretty specific to the individual printer. "Process", that sounds like an ink pushers lingo, is, I've done some. In printing color to the paper, we're starting out in nearly all cases with white paper. The colors of ink used are "subtractive" in that what almost looks like red ink isn't, its magenta because it reflects both red and blue light. If you want real red on the paper, you must also overprint the magenta with yellow which reflects red and green but not blue thereby absorbing the blue that the magenta ink reflected. To get green, use cyan (no red) and yellow (no blue) which leaves green. Etc. I've had my own colorhh use organic dyes. I used to formulate my own paper developer too because the ready made stuff spoiled too fast, you could see the difference from one 8x10 print to the next! I'm in the process of clearing out a corner of the basement and planning walls for another darkroom right now. I made the sink last summer. Anybody got a Bessler 23/dichro they want to sell? Make me an offer. I suspect I'll need copies of your printers manual to pull this bit of magic off. BUT, Do not, repeat do not send me your original manual, I found out the hard way they are the closest to being made out of "unobtainium" as you could imagine. If you lose the one that comes with the printer, it will take at least $100 in phone calls to the vendor/maker to get a new one, probably 2 years later. Gee, I wrote all that? This is awful long for the forum, sorry. Educate me here folks! Cheers, Gene (WDTV5@delphi.com) -*- 85914 26-FEB 01:30 Programmers Den RE:a was thinking, file formats would be a problem.. and the CPU time could very well be a sticky point as well, although, I am more worried about the file formats. A) Finding a file format that fits those specs is probably gonna be difficult. and then B), even if you find a file format, the average file of that format cant be all that large, CoCoers arent used to real big files..now, if this were for UNIX the file could be in upwards of 500k, and no one would think twice...if the output was nice enough. As for translating gray scale from VEFs an external program could be used to translate color VEFs to gray scale files that pf could use (assuming a new format must be created), and while printing in color would be nice..that could be oopps, that could be "phase two". I mean, I bet there are more users with b/w printers than color. (I myself have an HP DeskJet 500, and a 500c) Although the 500c isnt working right now..if you want a copy of my DeskJet manuals, I will photocopy them off to you..(beca re them. I only use them in my products. K. Darling wrote them. -Tony. -*- 85924 26-FEB 16:08 Music & Sound sound From: LUCKYONE To: HAWKSOFT (NR) Hi Chris, So far I have tried ver 1.3 on term and win7 and I still get error 196. When I do a tmode on win7 pag=26, type=00, term pag=24 and type=00. When I start sound I get a blue screen with a lot of buttons toward the top of the screen and a grey window in the middle of the screen. This happens very fast and everything disappears and the error message appears at the top of the screen. I hope this can help. Howard Howard Luckey delphi LUCKYONE CIS 74746,3207 ********** By InfoXpress 1.01 of course! ********** Howard Luckey delphi LUCKYONE CIS 74746,3207 ********** By InfoXpress 1.01 of course! ********** -*- 85925 26-FEB 17:39 OSK Applications RE: gnuchess (Re: Msg 85681) From: WRHAMBLEN To: DAVGEORGE (NR) I linked the binaries I uploadecrlibrary because that version of curses was already available in the OS9 forum's databases. It uses termcap. I also linked gnuchess with Microware's unsupported curses library (also a termcap curses) in the Microware utilities set sold by Ed Gresick and got no difference in behavior on my system. I stuck with the termcap versions of curses because not everyone has terminfo. Gnuchess uses a pretty limited subset of termcap: only number of rows and colums on the screen, screen clear, and cursor movement. If you can run uMacs, you have a complete enough termcap to run gnuchess. Gnuchess misbehaves with G-Windows (as reported by Ed Gresick) and K-Windows (as reported by a number of others). I suspect a stray pointer or machine register being munged. Gnuchess does run correctly on a serial terminal (as reported by several) and runs fine on my system using either a serial terminal or the IBM keyboard plus VGA display. You do have the sources in case you want to recompile and relink with yo52-E23:54 General Information RE: MM/1A SCSI Speed (Re: Msg 85929) From: RANDYKWILSON To: BOISY Boisy, I went digging through scsi_mm1a, and found the target string at $06CE ($7571) and $06AE ($6971). I tried many passes of ddtest with all four settings. The results were not good. Every setting gave readings of around 900Kb/sec, +/- 20Kb. Funny thing is, I do not remember getting that wide of an error range before. But I am *not* going to put the 070 back in for baseline testing. :> Randy -*- End of Thread. -*- 85934 26-FEB 23:51 OSK Applications Finally figured it out From: JEJONES To: ALL Gee...it only took me a few months or so to figure out that I didn't lift stuff thoroughly enough. I've corrected a big mistake in my Epson Stylus 800 VPRINT initialization file, and with any luck (and a modicum of measuring) I hope to have stuff filled in for other proportional fonts and finally get it sent off to Bob van der Poel. Thanks to Bob van der Poel ht I didn't do a good enough job of cribbing from. Opinions herein are those of their author, and not necessarily those of any organization. I am unassociated with Bob van der Poel, save as a customer satisfied with everything but my stupid mistakes. *** posted w/InfoXpress 1.1 *** -*- 85936 27-FEB 04:15 Telecom (6809) From: BILLGRESENS To: ALL Where can I find the Zmodem send and recieve procedures that are mentioned in the SuperComm docs? thanx. -*- 85947 27-FEB 11:29 Telecom (6809) RE: (Re: Msg 85936) From: MITHELEN To: BILLGRESENS (NR) Look for rzsz 3.24 in the New Uploads or Telcom Database here on Delphi. -*- End of Thread. -*- 85940 27-FEB 08:43 General Information COCO parts From: DONALDS To: BOISY Where you looking for some programs and a 6309 I may have them. contact me in mail. Don -*- 85941 27-FEB 08:58 General Information MAIL From: DONALDS To: ALL I have a list of items I wi No more messages. FORUM>Reply, Add, Read, "?" or Exit>