Msg 86064) From: KSCALES To: COLORSYSTEMS Hi, Zack - > Boisy, save me some research time. I was looking at my /tn modules to > see about increasing the buffer sizes for them, but moded does not > indicate a field identfied as a buffer size. Which field is it? Can I > change this with moded? If I need to change it with dEd, what is the > offset and field size? Check page D-3 of the OSTerm 68K manual for a description of using 'moded' to increase the buffer sizes. It also includes information for setting hardware handshaking in the descriptor. (Of course, since you are still awaiting hardcopy, and the info is in an appendix, it was probably safely hidden ;-( ). But as Paul J has mentioned, you will need the updated version of the 'moded.fields' file, which was included in the MM/1 upgrade files. (I think it is under "./SCF/SYS/moded.fields" in the upgrade versions posted online. It should be copied to "/DD/SYS/moded.fields".) Good luck... / Ken -------------------------------------------------------------------------- Ken Scales Delphi:KSCALES Internet:kscales@delphi.com CIS:74646,2237 -*- 86079 6-MAR 23:01 General Information RE: MM/1A Screen Problems (Re: Msg 86067) From: RANDYKWILSON To: COLORSYSTEMS Zack, I used moded to make the buffer (and other) changes to /t0 and /t5 on my mm/1a. But, in order to do this, I had to add a proper section in moded.fields. Take your favorite text editor and run through moded.fields. Find the section for sc68681, block copy it (making a dup section), then go through the copy and change all 68681's to 68340's. The 68681 and 68340 chips and drivers are not the same, but close enough for this to work. Randy -*- 86085 7-MAR 02:35 General Information RE: MM/1A Screen Problems (Re: Msg 86079) From: JOSEFL To: RANDYKWILSON Frome a purist systems standpoint, you should only *Add* to the 'moded.fields' file as it is supposed to know about evertything. But hey! I'm not a purist. Wanna make it work faster1 (said the hacker!) Take out every reference that isn't a descriptor on YOUR system. It loads in a fraction of the time. (Make a backup first!) Josef L. P.S. Then again, how often do you use it? -*- 86086 7-MAR 06:32 General Information RE: MM/1A Screen Problems (Re: Msg 86051) From: SCWEGERT To: BOISY > I found the problem with dots and missing bits appearing on the screen > when scrolling while connected at 38400 baud. I set my input and ouput > buffers on the /t3 device descriptor to 256 bytes each. This fixed the > problem. You reduced the size of the buffers to 256 bytes? Hmmm ... seems counter- intuative to me. Any idea why a smaller buffer would be better in this case? *- Steve -* -*- 86090 7-MAR 20:15 General Information RE: MM/1A Screen Problems (Re: Msg 86086) From: BOISY To: SCWEGERT (NR) The buffers were $14 and $50 respectively BEFORE I changed them. They were increased in value, not decreased. -*- 86097 7-MAR 22:11 General Information RE: MM/1A Screen Problems (Re: Msg 86063) From: DIETER To: BOISY (NR) > I *increasd* them. Actually the input buffer was 20 characters and the > output buffer was 80. For good measure, I kicked both buffers up to > 1024 characters. No problems have occurred since. > Where and how do You increse the buffer in /T3 ? Dieter -*- End of Thread. -*- 86068 6-MAR 16:20 Programmers Den pf TNG From: WDTV5 To: ALL I'm making some progress in the re-write of printform to handle the escP2 EPSON stuffs. The general outline is to make the config file go up from 432 bytes to 2048 by allowing the use of any character that will get past the "isprint()" function, minus of course the ones already defined in the current version. That leaves a few holes in the array that can be used for the escP2 specialty stuff. I have in mind 2 methods of doing it. Method 1 will be an absolute size command achieved via an added '.' command. This would tend to limit it to whole lines. Method 2 will if the escP2 implementation allows it, cause a 1 step up or one step down in size. This incremental method will be integrated into the line position tally being kept such that we can still do the proper line wraps etc. This method could be expanded to allow absolute sizes too, but I need to see the manual pages for a printer that does do "escP2" things before I tackle such a project in ernest. This is going to need a basic list of char widths obtained from your manuals under the "proportional" heading. They'll be entered into the file you feed to print_mod, and I'll have to assume they are in the printers basic "dot" width values. And I'll have to figgur out how to integrate that LONG list into the config file, or attach it to the end thereby expanding it beyond the 2k mark by about 114 bytes. Why am I telling you'all this? Easy, I need somebody to mail me the down and dingy details of how this works since my printer doesn't. Can somebody drop me an envelope full of a copy of those pages from a manual? Don't send the real manual, just copy those pages. Send to: Gene Heskett 291 Garton Ave. Weston WV 26452 Thanks! WDTV5@delphi.com -*- 86069 6-MAR 18:44 Games & Graphics RE: new user hard drive (Re: Msg 85990) From: DSRTFOX To: COCOKIWI Dennis, how does Hyper I/O work with the Disto? I have a Disto SCII and SCSI HD system, but use the 512 byte sector format from Northern Xposure on the drive. I doubt Hyper I/O will work with that... -*- 86076 6-MAR 21:10 Games & Graphics RE: new user hard drive (Re: Msg 86020) From: DBREEDING To: THETAURUS > SOME of those games. Also I think they require the vdgint > descriptor/driver which might still be in your bootlist. > since I am in the process of trying to do the same thing, I would > advise you to make up a seperate bootfile for games since the VDGint > Module takes up a good deal of memory, plus FTDD and some of the > others which are specific to the some of the games. The only need for having a separate bootdisk is if your bootfile is so big that you run out of system memory. I have both WindInt and VDGInt in my bootfile, as well as FTDD, etc, and apparently both 'Int's can coexist. In addition, I use the ftdd/nil, etc stuff from "vrn.ar", which replace the fs2, KQ3 drivers & descriptors. -- David Breeding -- *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ -*- 86078 6-MAR 22:20 Games & Graphics RE: new user hard drive (Re: Msg 86069) From: COCOKIWI To: DSRTFOX (NR) I don,t know about that,did,nt B&B come out with a 512 byte driver? Dennis -*- 86100 7-MAR 23:07 Games & Graphics RE: new user hard drive (Re: Msg 86078) From: THETAURUS To: COCOKIWI (NR) Yeah they did come out with their own driver dennis. I haven't heard much about it, but have seen it mentioned. >Chris< -*- End of Thread. -*- 86070 6-MAR 18:52 OSK Applications system command From: VAXELF To: ALL In the os-9 C manual for V2.4, it states that systerm() returns the exit status of the created shell. If I say: if ( system("dir") EQUATE NUMBER ) what would I use to tell that the system command failed to execute the dir command. Would I be looking for a "== 0" or "< 0", or ect??? Is it dependent on the program that "system()" calls?? The manual is somewhat vague on this. It does say that if I send a NULL POINTER it will return a non-zero value, if the shell is available. John D. -*- 86072 6-MAR 20:01 OSK Applications RE: system command (Re: Msg 86070) From: MITHELEN To: VAXELF (NR) Under OS-9, programs normally return 0 onm exit if they exit normally. -*- 86099 7-MAR 22:42 OSK Applications RE: system command (Re: Msg 86070) From: PAGAN To: VAXELF (NR) >If I say: > > if ( system("dir") EQUATE NUMBER ) > >What would I use to tell that the system command failed to execute the dir >command. Would I be looking for a "== 0" or "< 0", or ect??? 'Normal' exit status under OS9 is zero so, usually, you want to look for a zero. Try something like the followng to check it for yourself: #include main(argc,argv) int argc; char *argv[]; { char *process; int status; process=argv[1]; status=system(process); printf("status=%d\n",status); } BTW, I would advice against using system() to fork a child process except during testing. os9exec() is easy to use and provides much more flexibility. Stephen (PAGAN) -*- End of Thread. -*- 86071 6-MAR 19:06 General Information RE: Unix System V problem (Re: Msg 86046) From: DSRTFOX To: ALWAGNER (NR) Hmmm..... try shutting the system down after everyone gets off for the evening... I mean shutting all processes down, but not resetting. It sounds very much like there is some stray process left running with nothing to do- the input device is gone and possibly the output is off-line also. So shut all but the absolutely necessary processes doen before leaving work. Might even get your boss to allow you to change your work schedule... come in an hour later, leave an hour later. Would skipp most of the traffic that way anyhow! But do try this and see if it solves your problems. -*- 86073 6-MAR 21:07 General Information RE: DISTO Products running Low. (Re: Msg 85589) From: DBREEDING To: DISTO (NR) Tony, I have the 4in1 board - love it, but I have been wondering about getting it (or another one) modified to recognize RTS/CTS flow control in order to use data compression and error correction on my modem. I own a multipak and RS232 Deluxe pak, but would hate to go back to using the multipak. -- David Breeding -- *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ -*- 86074 6-MAR 21:08 General Information Hello All... From: DBREEDING To: ALL Hello everyone... I finally got around to signing up on Delphi. Been putting it off for a long time but finally jumped in. Several of you have already had the misfortune of meeting me, either personally or via telecom but you may have to out up with me here for a while. Everyone had been telling me that the SIG here was pretty active.. from what I have seen so far, it is. Started to dload the entire msg base. Got about the first 600, had a Segment list full error, saw I only had about a month of msgs & said "Uh-Oh", then went back and grabbed the LAST 600. Lotta reading It seems that navigation here is a little different than CIS, but maybe I can learn it. My biggest problem is that I have "IX" and it's so easy, that I may not get in there and work to learn as fast . Well, think I'll go blunder around some more. Talk to y'all later.... -- David Breeding -- *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ -*- 86084 7-MAR 02:00 General Information RE: Hello All... (Re: Msg 86074) From: REVWCP To: DBREEDING (NR) Hello David: One of the things that I did with the forum messages was a read ns (for non- stop) subject: (whatever) You could also use a dir ns subject: It is really easy to search. Glad to have you here. With all best wishes, Brother Jeremy, CSJW OS9 User's Group Treasurer -*- End of Thread. -*- 86075 6-MAR 21:09 Telecom (6809) RE: SandV BBS (Re: Msg 85861) From: DBREEDING To: ZOGSTER Hey, Jim, How ya doin'? Thought I'd butt in on this thread to ask something I've been wondering about, I suppose it's related enuff. Really, anyone may be able to answer... I wonder if a CoCo can benefit from a modem's data compression. My modem is capable of MNP and v.32bis etc. However I'm using a Disto 4in1 and it doesn't support RTS/CTS handshaking. I've heard that it can be modified or I also have a Multi-Pak and RS232-Deluxe, but hate to put it back in. However, I wonder if there is any benefit. Also, there is a passage in my Modem manual about "the computer-to-modem speed should be several times faster than that of the DCE line speed." Does that mean that I could have my computer set at something above 2400 baud? The modem is 2400... Just wondering... -- David Breeding -- *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ -*- 86081 7-MAR 00:12 Telecom (6809) RE: 9600 on a CoCo... (Re: Msg 85942) From: DIETER To: CBJ > Unfortunately the CoCo can not handle bidirectional transfer of data at > 9600 baud. Especially if wea re talking about large files. I have the > proof of that. > Carl > Well, I have the StG login package, and my brother has the same package, and we use this setup to send very large files bidirectional at 9600 baud all the time, from Lethbridge to Edmonton! And have no problem whatever! The highest CPS we got was 790... We use the 63C09 CPU running NitOS9 1.16... G'Day! Dieter -*- 86082 7-MAR 00:12 Telecom (6809) RE: SandV BBS (Re: Msg 85944) From: DIETER To: CBJ > You must realize that Jim is talking about a bidirectional transfer of > data here. He is running StG, just like me. TTYL, > I use StG BBS and have NO problems using 9600 baud transfers with PhotoNet, also a StG Node! Dieter -*- 86083 7-MAR 00:12 Telecom (6809) RE: SandV BBS (Re: Msg 85945) From: DIETER To: CBJ > 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 > Sure! I have one TANDY Deluxe RS-232 pack already converted, and it works great on my CoCo 3 with SARDIS No-halt controller and the B&B hard drive sub-system, my CoCo 3 has the Disto 1meg memory board, and the 63C09 CPU running NitrOS-9. I also use a 512 K memory board as RAM Disk R0... I also have a disto setup with 80meg hard drive space! Tryed to setup the BBS on that one a while back and had the same problem You are having now! Never could get it going at 9600 baud, but the obove B&B system works just great... If You want me to upgrade the RS-232 pack, send me Your pack plus $20 bucks US and I will upgrade it, plus include all the the SACIA patches for it... G,Day! Dieter -*- 86092 7-MAR 21:04 Telecom (6809) RE: 9600 on a CoCo... (Re: Msg 86081) From: CBJ To: DIETER Ah but Dieter, you have modified your serial port. I am talking about an unmodi unmodified pak and running NO patches such as powerboost or Nitros. Carl -*- 86093 7-MAR 21:05 Telecom (6809) RE: SandV BBS (Re: Msg 86082) From: CBJ To: DIETER Dieter, Are you running a stock serial port and stock OS-9 with stock modules? I think not. Carl -*- 86094 7-MAR 21:07 Telecom (6809) RE: SandV BBS (Re: Msg 86083) From: CBJ To: DIETER I should have all the SACIA patches now. Carl -*- 86101 8-MAR 00:06 Telecom (6809) RE: SandV BBS (Re: Msg 86093) From: MITHELEN To: DIETER (NR) Welp... Just talked with Scott G. again tonight, and got some good news... He now has the base low level protocal working for StG V4 "stgxfr" and, on a 9600 baud link between his MM/1 and Sun 3/160, was able to get over 1300 CPS on a bi direction test transfer, on un refined code. The MM/1 side showed no errors, while the Sun side had only 7 retries (don't know how big the test file was) -- Paul -*- End of Thread. -*- 86077 6-MAR 21:10 OSK Applications RE: Finally figured it out (Re: Msg 85934) From: DBREEDING To: JEJONES > Thanks to Bob van der Poel for writing VPRINT, and to Gerry McCleary > Opinions herein are those of their author, and not necessarily those Hey, I picked up VED/VPRINT (CoCo) in Atlanta, and, although I don't do a lot of text composition, I was really impressed. Of course you can see changes that could be made in anything, but VPRINT is fantastic. The setup procedure may be a little involved, but this thing can really put out some professional-looking text. I'd have to see something really stupendous to not get the combo when/if I get an OSK machine. Yeah, great job... -- David Breeding -- *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ -*- 86080 6-MAR 23:05 Programmers Den C's stack From: WDTV5 To: ALL I would like to know if others have found a similar effect to the one I just found while working on yet another edition of pf. The effect in question is that the compiler apparently does NOT add the stack requirements to the data size value in the module header! At least not for arrays declared inside the opening { of a module, which should put the declared array on the stack. It does ask for the correct amount via a call to stkcheck, but its instant whole system crash to exec the stkcheck code if the request is much larger than the datasize currently defined in the modules header. As in 3x the available memory in this case. And the instant whole system crash has to be in the stkcheck code as the next statement was a debugging printf call to show where the array was numerically. It never got to the printf statement, ever! I kept changing the array size, but found that it had no effect on the actual datasize in the module header when changed from [27][16] to [134][16]! Moving the declaration to a point above the function declaration apparently fixed it just fine. From what I know about the compiler, that puts the data area back on a pointer from the y register. And no crash.... Is this the reason we've had to nearly always declare extra memory on the CC invoke line via the "-m=xk" for all these years? Cheers, Gene Heskett, WDTV5@delphi.com -*- 86096 7-MAR 22:10 Programmers Den RE: C's stack (Re: Msg 86080) From: BANANAMAN To: WDTV5 (NR) I certainly sounds like a compiler problem to me. I've run into that data size problem on almost every program I've wrote, too. It could be time to disassemble stkcheck()? --Andy -*- End of Thread. -*- 86087 7-MAR 08:46 General Information internet mail From: DONALDS To: ALL How can I send a internet mail file to Matt Thompson? I have his address but when I type it in I get '@vicuna.ocunix.on.ca' is not valid. I have a message made up in my work space that I want to send to him. I tried to send it from E-MAIL. Don -*- 86089 7-MAR 18:42 General Information RE: internet mail (Re: Msg 86087) From: ILLUSIONIST To: DONALDS (NR) try this.. MAIL> send name_of_file_to_send To: in%"matt's address" that should work... -*- End of Thread. -*- 86088 7-MAR 08:51 System Modules (6809) SMALL VDGINT From: DONALDS To: ALL I read somewhere that Alan Dekok had made new VDGINT files that would work with the Disto 2meg upgrade; Does anyone know where he has uploaded these files to? I have the ones he first made but need the new ones to work with my upgrade. Don -*- 86095 7-MAR 22:08 System Modules (6809) RE: SMALL VDGINT (Re: Msg 86088) From: KSCALES To: DONALDS (NR) > I read somewhere that Alan Dekok had made new VDGINT files that would > work with the Disto 2meg upgrade; Does anyone know where he has uploaded > these files to? I have the ones he first made but need the new ones to > work with my upgrade. Don, Alan has produced a new version of the small VDGInt, but he hasn't uploaded it anywhere. He only has 512K, so he cannot test it himself to make sure that it works. He gave it to me to email to another user to test it. I haven't yet heard back whether it works or not. I will not post the file to the database until I get confirmation that it actually works. Regards... / Ken -------------------------------------------------------------------------- Ken Scales Delphi:KSCALES Internet:kscales@delphi.com CIS:74646,2237 -*- End of Thread. -*- 86091 7-MAR 20:16 General Information MM/1A Mouse Mysteries Revealed?? From: BOISY To: ALL Hi All, Deciding I couldn't live without a mouse for my new MM/1A any longer, I went out and bought two different mice. The first one was a Logitech Trackman which claimed 100% compatiblity with Microsoft mode or your money back. This mouse retailed for $67. The other mouse was an Identity Systems el cheapo $9.95 mouse. Both have three buttons. On the Identity Systems mouse, there is a switch which indicates either Mouse Systems mode or Microsoft Mode. At this point, only the el cheapo mouse works, and then only in "Mouse Systems Mode." I thought that the MM/1A handled Microsoft mice ok. The Logitech Trackman does not work. Given the fact that my prior assumption of Microsoft mice working on the MM/1A has been blown away, just what are "the facts?" As I see it, there are three modes: Microsoft (doesn't work on the MM/1A) Mouse Systems (works on the MM/1A) Logitech (doesn't work on the MM/1A) Does the MM/1 070 mouse driver work with the MM/1A? I noticed that there was an 'ms' descriptor on the 070 bootmods disk. Why isn't this used in the MM/1A? Can someone give me the history of mice on the MM/1 and put things into perspective? Thanks -*- 86098 7-MAR 22:26 General Information RE: MM/1A Mouse Mysteries Revealed?? (Re: Msg 86091) From: MRGOOD To: BOISY (NR) I don't have an MM1A, but I do have a regular MM1. From what I remember reading, both Microsoft and Mouse SYstems mice are supported. However, the preferred mouse was Mouse Systems due to its support for three buttons. (Left button is for menus and such, middle button is cut and paste, right button is cycle through windows). Download Mike Sweet's (DODGECOLT) kwindows reference document from the databases here, it should be helpful to you. From the document, it appears that 2-button microsoft mice are controlled by msdrv.070.ms or msdrv.901.ms. The latter /t2 and the former for /t0. Hugo -*- End of Thread. -*- FORUM>Reply, Add, Read, "?" or Exit>