#: 19552 S3/Languages 31-Dec-93 21:20:48 Sb: Ultra C 1.1.1 Fm: Allan 70506,1173 To: Carl Kreider 71076,76 (X) Carl I just been catching up on the messages here in the forum. I don't know if I fit what you would call a power user but I am a beta site for Ultra C. I use it to do all of my OS-9 Ports (drivers etc.) To get really small code you must use the SC libs. and I-code link the files. If you need an example makefile I can provide one. Basically you compile thru the IOPT phase to a I code modle, then ilink with the sclib.il libraries. When you run this thru the backend and final link the code should be considerably smaller or faster depending on the way you tweak the knobs. best results are with "-t=0 -i -j -n -iom" this should shrink your application considerably. BTW don't use this combination with anything other than 1.1.1. Allan R. Batteiger President Real-Time Services Inc. #: 19583 S3/Languages 12-Jan-94 19:48:23 Sb: C lib warning Fm: Carl Kreider 71076,76 To: all I found a rather nasty problem with the C V3.2 libraries. The function strtod(), which is called by atof(), which is called by scanf(), clobbers d6. Now, that is not a big problem unless you happen to be using register variables like I was. The only solutions are to not use regiter varibles or to patch the movem instructions to save d6 also. #: 19658 S3/Languages 25-Jan-94 20:40:16 Sb: Cross Compiler Fm: John VanHoozer 74160,1562 To: all I was wondering if Microware has any products to support cross-compilation for CD-i under os/2 (yes - develop on os/2 for os9)? Anyone? Thanks. #: 19660 S3/Languages 26-Jan-94 09:19:48 Sb: Linker Crash - Help !! Fm: Hannu Heikkinen 100315,1011 To: Microware Hello !! I got an internal linker error message from OS9 C cross-compiler V3.2 for MS-DOS environment. **** l68: error - jmp total > guess (1/0) in USP_trap_a referencing usp_call in nmuspsw_c **** Below you can find a listing showing the linker input. Might be caused by too many files ?? (I didn't invent this module structure, but unfortunately have to use it !!) Regards, and thanks for the tips... Hannu Copyright 1984-1991 Intersolv, Inc. All rights reserved. Today's date is 26 Jan 1994 17:03:46. l68 -z=E:\temp\lis_0000.tmp -- Contents of E:\temp\lis_0000.tmp: D:\ISA\LIB\RELS\isausp.l D:\ISA\LIB\RELS\GRUS0245.R D:\ISA\LIB\RELS\GRUS0246.R D:\ISA\LIB\RELS\GRUS0247.R D:\ISA\LIB\RELS\GRUS0248.R D:\ISA\LIB\RELS\GRUS0249.R D:\ISA\LIB\RELS\GRUS0250.R D:\ISA\LIB\RELS\GRUS0251.R D:\ISA\LIB\RELS\GRUS0252.R D:\ISA\LIB\RELS\GRUS0253.R D:\ISA\LIB\RELS\GRUS0254.R D:\ISA\LIB\RELS\NMENVUSP.R D:\ISA\LIB\RELS\ISADB.R D:\ISA\LIB\RELS\MSGPIPE.R D:\ISA\LIB\RELS\EVSYS.R D:\ISA\LIB\RELS\GLOBRAM.R D:\ISA\LIB\RELS\TRAP.R D:\ISA\LIB\RELS\GRUS0238.R D:\ISA\LIB\RELS\GRUS0239.R D:\ISA\LIB\RELS\GRUS0240.R D:\ISA\LIB\RELS\GRUS0241.R D:\ISA\LIB\RELS\GRUS0242.R D:\ISA\LIB\RELS\GRUS0243.R D:\ISA\LIB\RELS\GRUS0244.R D:\ISA\LIB\RELS\GRUS0210.R D:\ISA\LIB\RELS\MODGLOB.R D:\ISA\LIB\RELS\GRUS0100.R D:\ISA\LIB\RELS\GRUS0101.R D:\ISA\LIB\RELS\GRUS0102.R D:\ISA\LIB\RELS\GRUS0103.R D:\ISA\LIB\RELS\GRUS0104.R D:\ISA\LIB\RELS\GRUS0105.R D:\ISA\LIB\RELS\GRUS0106.R D:\ISA\LIB\RELS\GRUS0107.R D:\ISA\LIB\RELS\GRUS0108.R D:\ISA\LIB\RELS\GRUS0109.R D:\ISA\LIB\RELS\GRUS0110.R D:\ISA\LIB\RELS\GRUS0111.R D:\ISA\LIB\RELS\GRUS0202.R D:\ISA\LIB\RELS\GRUS0203.R D:\ISA\LIB\RELS\GRUS0204.R D:\ISA\LIB\RELS\GRUS0205.R D:\ISA\LIB\RELS\GRUS0206.R D:\ISA\LIB\RELS\GRUS0208.R D:\ISA\LIB\RELS\GRUS0209.R D:\ISA\LIB\RELS\GRUS0211.R D:\ISA\LIB\RELS\GRUS0212.R D:\ISA\LIB\RELS\GRUS0213.R D:\ISA\LIB\RELS\GRUS0214.R D:\ISA\LIB\RELS\GRUS0215.R D:\ISA\LIB\RELS\GRUS0216.R D:\ISA\LIB\RELS\GRUS0217.R D:\ISA\LIB\RELS\GRUS0218.R D:\ISA\LIB\RELS\GRUS0219.R D:\ISA\LIB\RELS\GRUS0220.R D:\ISA\LIB\RELS\GRUS0224.R D:\ISA\LIB\RELS\GRUS0225.R D:\ISA\LIB\RELS\GRUS0226.R D:\ISA\LIB\RELS\GRUS0227.R D:\ISA\LIB\RELS\GRUS0228.R D:\ISA\LIB\RELS\GRUS0229.R D:\ISA\LIB\RELS\GRUS0230.R D:\ISA\LIB\RELS\GRUS0231.R D:\ISA\LIB\RELS\GRUS0232.R D:\ISA\LIB\RELS\GRUS0233.R D:\ISA\LIB\RELS\GRUS0234.R D:\ISA\LIB\RELS\GRUS0235.R D:\ISA\LIB\RELS\GRUS0236.R D:\ISA\LIB\RELS\GRUS0237.R D:\ISA\LIB\RELS\USPLIB.R D:\ISA\LIB\RELS\PID.R D:\ISA\LIB\RELS\COUNTER.R D:\ISA\LIB\RELS\ISATHIF.R D:\ISA\LIB\RELS\CONV.R D:\ISA\LIB\RELS\NMUSPSW.R -l=D:\ISA\LIB\RELS\isasys.l -o=D:\ISA\LIB\RELS\isausp -l=D:\OS9C\LIB\cio.l -l=D:\OS9C\LIB\clib.l -l=D:\OS9C\LIB\sys.l #: 19664 S3/Languages 26-Jan-94 19:24:23 Sb: PASCAL refuses STRING Fm: Jim Cross 74040,3003 To: all Has anyone else had trouble getting MW's PASCAL09 to accept a variable type STRING? Is there a documented fix? #: 19669 S3/Languages 30-Jan-94 21:30:33 Sb: GNU - PLEEEEZE! Fm: John VanHoozer 74160,1562 To: Anyone Anyone know where sources for a GNU C/C++ compiler and GAS assembler for os-9 or cd-rtos might reside? PLEASE!!!!! If I can't find it I'll have to drive the Broken L.A. Highway system to work - A fate worse than being un-dead!!! #: 19670 S3/Languages 30-Jan-94 23:44:30 Sb: Linker Crash #2 Fm: Hannu Heikkinen 100315,1011 To: sysop (X) Hello again (Is there anybody out there ??!!) I got an internal linker error message from OS9 C cross-compiler V3.2 for MS-DOS environment. **** l68: error - jmp total > guess (1/0) in USP_trap_a referencing usp_call in nmuspsw_c **** Below you can find a listing showing the linker input. Might be caused by too many files ?? (I didn't invent this module structure, but unfortunately have to use it !!) Regards, and thanks for the tips... Hannu Copyright 1984-1991 Intersolv, Inc. AllD\S\B\RELS\GRUS0247.R D:\ISA\LIB\RELS\GRUS0248.R D:\ISA\LIB\RELS\GRUS0249.R D:\ISA\LIB\RELS\GRUS0250.R D:\ISA\LIB\RELS\GRUS0251.R D:\ISA\LIB\RELS\GRUS0252.R D:\ISA\LIB\RELS\GRUS0253.R D:\ISA\LIB\RELS\GRUS0254.R D:\ISA\LIB\RELS\NMENVUSP.R D:\ISA\LIB\RELS\ISADB.R D:\ISA\LIB\RELS\MSGPIPE.R D:\ISA\LIB\RELS\EVSYS.R D:\ISA\LIB\RELS\GLOBRAM.R D:\ISA\LIB\RELS\TRAP.R D:\ISA\LIB\RELS\GRUS0238.R D:\ISA\LIB\RELS\GRUS0239.R D:\ISA\LIB\RELS\GRUS0240.R D:\ISA\LIB\RELS\GRUS0241.R D:\ISA\LIB\RELS\GRUS0242.R D:\ISA\LIB\RELS\GRUS0243.R D:\ISA\LIB\RELS\GRUS0244.R D:\ISA\LIB\RELS\GRUS0210.R D:\ISA\LIB\RELS\MODGLOB.R D:\ISA\LIB\RELS\GRUS0100.R D:\ISA\LIB\RELS\GRUS0101.R D:\ISA\LIB\RELS\GRUS0102.R D:\ISA\LIB\RELS\GRUS0103.R D:\ISA\LIB\RELS\GRUS0104.R D:\ISA\LIB\RELS\GRUS0105.R D:\ISA\LIB\RELS\GRUS0106.R D:\ISA\LIB\RELS\GRUS0107.R D:\ISA\LIB\RELS\GRUS0108.R D:\ISA\LIB\RELS\GRUS0109.R D:\ISA\LIB\RELS\GRUS0110.R D:\ISA\LIB\RELS\GRUS0111.R D:\ISA\LIB\RELS\GRUS0202.R D:\ISA\LIB\RELS\GRUS0203.R D:\ISA\LK #: 19675 S3/Languages 02-Feb-94 06:39:33 Sb: #19670-Linker Crash #2 Fm: Bill Dickhaus 70325,523 To: Hannu Heikkinen 100315,1011 Hannu, There are people out here, but apparently there aren't many who have used the cross compiler. Is this a Microware product? Have you tried Microware product support? They don't frequent this forum, or CompuServe, for that matter, so they probably won't respond here. One thing that you might try, which would help narrow the problem down a little, is to merge some of those .R files together. If the problem is with too many files, this would be a workaround. Not knowing how large these .R files are, the problem could also be that one of the .R files is too large or that the combination of all the .R files is too large for the linker to keep track of. You might also check to make sure that one of the .R files didn't get corrupted somehow. -Bill- #: 19790 S3/Languages 12-Mar-94 12:42:14 Sb: #19664-PASCAL refuses STRING Fm: William Schountz 73622,1715 To: Jim Cross 74040,3003 The problem is that CoCo Pascal is the ISO standard and ISO does not use the type STRING as does Turbo Pascal or THINK Pascal. The STRING type is a addional data type instituded by some vendors. In CoCo Pascal you have to declare a new type as an ARRAY OF CHAR. Tony Schountz #: 19982 S3/Languages 22-May-94 22:55:49 Sb: #Software Tools/Pascal Fm: Paul R. Santa-Maria 71674,422 To: All In library 3 there is a file from 1986 called SWTOOL.AR which is supposed to contain the Pascal source from Kernighan & Plauger's Software Tools In Pascal book. As I use an MS-DOS machine, and have no access to OS9 decompressors, can some kind soul please e-mail me the uncompressed file, or perhaps recompress it with an MS-DOS compatible compressor and re-upload it to the library? There is 1 Reply. #: 19983 S3/Languages 23-May-94 20:21:32 Sb: #19982-#Software Tools/Pascal Fm: Ernest Withers Jr. 71545,1117 To: Paul R. Santa-Maria 71674,422 (X) Paul, I just downloaded SWTOOL.AR and converted the file to SWTOOL.ZIP. I used PKZIP 2.04g to zip the file. The CR/LF conversion has already been done. As soon as the management makes it available, it should be in Library 3. By the way, it was un-AR'ed on a '486 running OS-9000 and ZIPped on the same machine. Ernest. There is 1 Reply. #: 19984 S3/Languages 24-May-94 04:13:03 Sb: #19983-#Software Tools/Pascal Fm: Mike Ward 76703,2013 To: Ernest Withers Jr. 71545,1117 (X) Thanks for handling the repackaging Ernest! The SWTOOL.ZIP is available as I type. Mike There is 1 Reply. #: 19985 S3/Languages 24-May-94 20:51:11 Sb: #19984-Software Tools/Pascal Fm: Ernest Withers Jr. 71545,1117 To: Mike Ward 76703,2013 (X) No problem Mike. I just happened to have the right systems set up to do it easily. Ernest #: 20033 S3/Languages 15-Jun-94 07:54:37 Sb: Probl. with Ada compiler Fm: Franklin C.A. de Wi 100341,1534 To: all Has anyone of you any experience with the Ada compiler for OS/9 from Meridian ? Currently we're encountering some problems when using optimize options. Please respond to: Franklin C. de Wit tel: intl. 31-2230-53945 fax: intl. 31-2230-52945 compuserve: 100341,1534 internet: 100341.1534@compuserve.com #: 20044 S3/Languages 19-Jun-94 13:12:26 Sb: #19983-#Software Tools/Pascal Fm: Paul R. Santa-Maria 71674,422 To: Ernest Withers Jr. 71545,1117 (X) Thanks for SWTOOL.ZIP! I am converting it to Borland's Turbo Pascal 7.0 for MS-DOS. That means having to compare every line with the book since the code was adapted for Turbo Pascal 3.0 for CP/M and minor changes were made in some routines. I also have to type in all the comments and test each program. My goal is to have every routine match the book exactly except for the operating system dependent primitives described in the Appendix. Fortunately, I have a Pascal source code reformatter to handle all of the grunt work of proper indentation and capitalization. When I am done I shall upload it to the Borland Pascal forum (BPASCAL) since I doubt a third incarnation would be appropriate in OS9. I learned one lesson... don't optimize! I lost four days after I "optimized" two routines the book said should be primitives if possible. After replacing them with the book's brain-dead versions, everything worked fine. I shall finish using only the book's routines, and save optimization after the routines work. Since I never REALLY examined the code before because I did not want to type it in, I never noticed how much the code resembles C. That is not suprising, however, if you consider who the authors are. There is 1 Reply. #: 20060 S3/Languages 23-Jun-94 21:11:46 Sb: #20044-Software Tools/Pascal Fm: Ernest Withers Jr. 71545,1117 To: Paul R. Santa-Maria 71674,422 You're most welcome. I hope you are successful in converting it. Good luck. Ernest. #: 20067 S3/Languages 25-Jun-94 13:33:43 Sb: #Coco/OSK C compilers Fm: David Breeding 72330,2051 To: ALL Here's a little "feature" of the MW OSK C compiler I _BELIEVE_ I've stumbled across. It could be common knowledge, but I'd never heard of it myself. Seems that with a structure, from what I can determine, a block of characters joined by an int, float, and ???, will have a character added if the total for that blockof characters is odd. This won't hurt the program, but would cause problems in sharing files with systems that don't do this. I found this by trying to port a prog from the coco to OSK. I was looking for int's, but was surprised in the filesize incongruity with structures containing only floats & chars. It seems that the following will result; * char a1[x];char c1[y];int b1 : if a1+c1=odd, one byte added, same * if int b1 before the two. * char a1[x];int b1;char c1[y] : if EITHER a1 OR c1 = odd, one byte * added, if both odd, 2 bytes added. * sizeof() reports correctly the actual size, reflecting any * additional bytes added. If this _IS_ news, and anyone wants to * play around with it, here's a little routine for it. struct { /* Play around with the order of the elements...*/ char a1[24]; int b1; char c1; } S1; char a2; main() { printf(" Size of S1 : %d\n", sizeof(S1) ); printf(" Actual Size : %d\n\n", (int)(&a2)-(int)(&S1) ); printf(" Totals of els: %d\n", sizeof(S1.a1)+sizeof(S1.b1)+sizeof(S1.c1) ); } Another difference between the CoCo and the OSK compilers, although insignificant, I suppose, is in mktemp(). The OSK mktemp checks the directory for a unique tmpfile name, probably doing an "Open". It exits with Error #216 in "errno" - Coco doesn't. I like to end a program with "exit(errno)", which looks kinda messy. Guess I'll either have to cleanup after mktemp (and others???) or do an exit(0) . -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ There is 1 Reply. #: 20073 S3/Languages 26-Jun-94 10:25:22 Sb: #20067-#Coco/OSK C compilers Fm: Pete Lyall 76703,4230 To: David Breeding 72330,2051 (X) This isn't a bug, nor is it abnormal for compilers written for machines with larger wordsizes. The reason is that the CPU needs to make an address reference to a certain address boundary, usually on a multiple of the wordsize. Internal to the structure, they call this 'padding'. If you need to write the structure to disk in a semi-portable fashion, you'll have to write out each element individually: write(fd,struct->element1,sizeof(struct->element1); write(fd,struct->element2,sizeof(struct->element2); etc....... Pete Lyall There is 1 Reply. #: 20074 S3/Languages 26-Jun-94 13:13:47 Sb: #20073-Coco/OSK C compilers Fm: David Breeding 72330,2051 To: Pete Lyall 76703,4230 (X) > This isn't a bug, nor is it abnormal for compilers written for machines > with larger wordsizes. The reason is that the CPU needs to make an address > reference to a certain address boundary, usually on a multiple of the > wordsize. Internal to the structure, they call this 'padding'. I didn't think it was a bug as such. I've just upgraded to OSK and this was something that I didn't expect. I was aware of the diff in int-size, etc, but this took me a little while to figure out. > If you need to write the structure to disk in a semi-portable fashion, > you'll have to write out each element individually: I think the portability thing would be too much to keep up with. From my limited experimentation, it would take quite a bit of watching to keep it straight. And if you ever changed the structure, you might throw it all off again. -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ #: 20072 S3/Languages 25-Jun-94 20:49:36 Sb: #68xx XASM on DOS machine Fm: DOUG 72667,1433 To: all Hi all... Anyone out there know of an inexpensive crossassembler for 6800, 6802, 6809 that will run on a DOS (yuck) machine???? Doug There is 1 Reply. #: 20075 S3/Languages 27-Jun-94 14:06:38 Sb: #20072-#68xx XASM on DOS machine Fm: James Truesdale [JBM] 71174,3442 To: DOUG 72667,1433 (X) I used to have a file full of this information but recently tossed it out because I needed the room. Check the ads in the back of Embedded Systems, Byte, and DDJ magazines which is where I accumulated my information from. There are 2 Replies. #: 20077 S3/Languages 27-Jun-94 20:03:10 Sb: #20075-68xx XASM on DOS machine Fm: Bob van der Poel 76510,2203 To: James Truesdale [JBM] 71174,3442 (X) I think the C-User's Magazine PD library also has some cross-compilers. #: 20079 S3/Languages 28-Jun-94 21:48:35 Sb: #20075-68xx XASM on DOS machine Fm: DOUG 72667,1433 To: James Truesdale [JBM] 71174,3442 (X) Thanks Jim, will check those sources and Bob's possibility. #: 20088 S3/Languages 02-Jul-94 12:47:24 Sb: #20072-68xx XASM on DOS machine Fm: Paul R. Santa-Maria 71674,422 To: DOUG 72667,1433 There are a couple in the IBMPRO forum libraries. #: 20194 S3/Languages 09-Aug-94 03:36:09 Sb: #20072-68xx XASM on DOS machine Fm: Simon R Ashby 100111,2173 To: DOUG 72667,1433 X-asm on DOS 68xx 8-bit Try: IAR Research (swedish but with international outlets) Avocet (US) 2500AD (US) (both these also do small C compilers) MPE (UK, Southampton, Forth house but better than assembler on its own) Those are all established sources with track records. Good assembling! Simon A #: 20279 S3/Languages 02-Sep-94 18:08:34 Sb: #20194-68xx XASM on DOS machine Fm: DOUG 72667,1433 To: Simon R Ashby 100111,2173 Thanx... took the advice of previous respondees and found TASM 3.0 on IBMPRO Just registered it. It's very impressive. Doug #: 20249 S3/Languages 25-Aug-94 20:06:36 Sb: #Wanted, Pascal & C Fm: Rogelio Perea 72056,1204 To: ALL WW WW AAAA NN NN TTTTTTTT EEEEEEEE DDDDDDD WW WW AA AA NNN NN TT EE DD DD WW WW AA AA NN N NN TT EE DD DD WW W WW AA AA NN N NN TT EE DD DD WW W WW AA AA NN N NN TT EEEEEE DD DD WW W WW AAAAAAAA NN N NN TT EE DD DD WW W WW AA AA NN NNN TT EE DD DD WWWWWWW AA AA NN NN TT EEEEEEEE DDDDDDD Pascal & C Compilers for the Color Computer I am interested in programing in these two languages and would rather do it on my CoCo III than using an MSDOS system (yeah you know). For Pascal I have seen ads in old issues of The Rainbow regarding a DEFT Pascal system and also know about an OS9 version that was available (from Radio Shack?). For the C compiler I would like it to be a system already "hacked up" with the various patches available that make it a little less hostile (the hard coding that prevents a more flexible system), but if the original OS9 version is available then it would do nicely. So how about it?, anyone has something like this in their closets or basement?....... Rogelio Perea [72056,1204] -=> Givin' my CoCo a dayly work out :) TOP SHAPE!! There is 1 Reply. #: 20254 S3/Languages 26-Aug-94 20:55:47 Sb: #20249-#Wanted, Pascal & C Fm: Bill Dickhaus 70325,523 To: Rogelio Perea 72056,1204 (X) Rogelio, I have a copy of the Tandy OS9 Pascal around here somewhere that I never used much. I deleted it off of my hard drive years ago. If I can find it, its yours for shipping costs. -Bill- There is 1 Reply. #: 20266 S3/Languages 29-Aug-94 13:38:04 Sb: #20254-Wanted, Pascal & C Fm: Rogelio Perea 72056,1204 To: Bill Dickhaus 70325,523 (X) Thanks Bill!!.... I do hope you find it, and if the docs are included so much better.... but the software alno will do anyway. I'll be "hanging" around here for your reply.. again, thanks Rogelio -=> CoCoing south of the border, for 10 years now!!! #: 20317 S3/Languages 07-Sep-94 06:15:44 Sb: #GNU C compiler Fm: Bruno Nilsson 76407,600 To: Sysop (X) Does anybody know if the GNU C compiler is available for OS9 ? There is 1 Reply. #: 20318 S3/Languages 07-Sep-94 07:21:15 Sb: #20317-GNU C compiler Fm: Bill Dickhaus 70325,523 To: Bruno Nilsson 76407,600 Bruno, Yes, it is, for OS9/68000. I use GCC 1.42 on my MM/1 (OSK 2.4) all the time. A later version is also available, but with only 3M of memory, it just doesn't quite work. GCC 1.40 is here in LIB 12, along with some other GNU stuff. If you have access to the Internet, later versions can be found on chestnut.cs.wisc.edu, or if you don't, we ought to be able to find someone to upload the later versions here. -Bill- #: 20417 S3/Languages 28-Sep-94 20:41:37 Sb: #20318-GNU C compiler Fm: Bruno Nilsson 76407,600 To: Bill Dickhaus 70325,523 (X) Thank you very much for the information Bill. I will try it right away. Bruno Nilsson #: 20472 S3/Languages 16-Oct-94 16:17:19 Sb: #20317-GNU C compiler Fm: DTR 100302,3271 To: Bruno Nilsson 76407,600 YES - inquiries to fax ++49-431-86511 #: 20489 S3/Languages 23-Oct-94 10:19:21 Sb: #20472-GNU C compiler Fm: Bruno Nilsson 76407,600 To: DTR 100302,3271 Thank you very much. I will send them a FAX. Regards Bruno #: 20555 S3/Languages 15-Nov-94 11:56:37 Sb: #20318-#GNU C compiler Fm: David M. Horn 73260,242 To: Bill Dickhaus 70325,523 (X) Bill, I saw your reply to a GNU C compiler question back in September. I am trying to find some answers regarding the GNU package and thought I would toss them at you. Do you know the status of the GNU C++ compiler for OS-9? Do you know if there is source debug capability for C++, does it use the GNU source debugger or Microware's? Thanks for any help you can provide. David Horn There is 1 Reply. #: 20557 S3/Languages 15-Nov-94 22:53:09 Sb: #20555-GNU C compiler Fm: Bill Dickhaus 70325,523 To: David M. Horn 73260,242 (X) David, I haven't used the GNU c++ compiler, though I know that its been ported. I'm not sure about the GNU debugger, I don't think its been ported, but I really don't know. If I hear anything I'll let you know. -Bill- #: 20568 S3/Languages 19-Nov-94 16:08:13 Sb: #_gs_rdy() question Fm: David Breeding 72330,2051 To: all Hey, Gang, I have a question. Why doesn't the following work? I have tried this both on my OSK and CoCo, and get similar results. The program as written will continue to loop, keeping getting the "AT" and "OK", with some other gibberish. It seems to keep writing and reading the modem. If the while{} statement is not used, and The Alternate Method, commented out, here, is used, if you write something to the modem, then you keep getting a positive value returned from _gs_rdy(). If you do the for loop without writing to the modem, you keep getting a -1 returned, which is correct. But if something has been written, it looks like the pointer is not getting updated, and, in fact, it seems that it keeps getting rewritten to the serial port.. strange.. or am I overlooking something? Note: this is the coco version, but, as I said, OSK seems to act the same way. This here is just a test program.. but it still looks like it SHOULD work. I've also tried time loop delays between reads, etc, but still no luck.. I can't see why it keeps sending to the modem.. #include #include int mdm; char buf[30]; char cmd[10] = "AT\x0d"; /* try something else, too */ main() { int count, state; if ( (mdm=open("/t2",UPDATE)) == -1) exit(1); write( mdm,cmd,3); while ((state=_gs_rdy(mdm)) > 0 ) { printf("\x0a_gs_rdy()=%d Read()=%d ", state, read( mdm,buf,state ) ); fflush(stdout); write( 1,buf,state ); } /* Alternate method */ /* if you delete all the above after the open(), -1 is always returned.. if the write() is left in, it goes crazy */ for (count=1;count<10;count++ ) { printf("_gs_rdy()=%d\n",_gs_rdy(mdm) ); } /* End Alternate method */ close(mdm); } -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ There is 1 Reply. #: 20569 S3/Languages 19-Nov-94 21:22:54 Sb: #20568-#_gs_rdy() question Fm: Bob van der Poel 76510,2203 To: David Breeding 72330,2051 (X) David, A few things for talking to the modem.... 1. You have to turn off echo! Otherwise what the modem sends back is sent back to the modem. 2. You should use read() to get stuff, but writeln() to send. 3. _gs_rdy() never returns 0. It returns 1..? if there is data, -1 if there isn't. So, here is a program which works: #include #include #include int mdm; char buf[30]; char cmd[10] = "AT\n"; /* try something else, too */ struct sgbuf mpathbuff; main() { int count, state; if ( (mdm=open("/t3",S_IREAD+S_IWRITE)) == -1) exit(1); _gs_opt(mdm, &mpathbuff); /* make sure that echo if off to the */ mpathbuff.sg_echo=0; /* modem, otherwise we shoot ourselves */ _ss_opt(mdm, &mpathbuff); /* when reading... */ writeln( mdm,cmd,5); while (1) { state=_gs_rdy(mdm); if(state<0) { printf("No data at modem, state=%d\n", state); exit(1); } count=read(mdm, buf, state); printf("state=%d count=%d buf=%s\n", state, count, buf); } } Hope this helps. There is 1 Reply. #: 20570 S3/Languages 19-Nov-94 22:20:01 Sb: #20569-#_gs_rdy() question Fm: David Breeding 72330,2051 To: Bob van der Poel 76510,2203 (X) > David, A few things for talking to the modem.... > > 1. You have to turn off echo! Otherwise what the modem sends back is sent > back to the modem. Hey, I hadn't thought of that.. So that's why everything just kept going back and forth.. > 3. _gs_rdy() never returns 0. It returns 1..? if there is data, -1 if > there isn't. I think it returns the number of bytes available, if any are available. > So, here is a program which works: > Hope this helps. Thanks.. I knew someone would be here with the answer.. I think I posted this only about 3 hrs ago.. pretty fast turnaround. What I'm trying to do is write an external autodialer. As far as I know, there's no generic one available.. If I'm not mistaken, my system's comm driver does not support CD, so I'm going to have it look for result codes. There was an autodialer on Delphi, but it was for KWindows, and I got an error 208 pretty quickly . Thanks again, Bob, I'd probably have been scratching my head for quite a while on my own.. -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ There are 2 Replies. #: 20572 S3/Languages 20-Nov-94 11:33:10 Sb: #20570-#_gs_rdy() question Fm: Pete Lyall 76703,4230 To: David Breeding 72330,2051 (X) David - I wrote a generic dialer hundreds of years ago in 6809 asm... Probably of very little use if you're using OSK. C is the better way to go anyway. Pete There is 1 Reply. #: 20574 S3/Languages 20-Nov-94 22:14:51 Sb: #20572-#_gs_rdy() question Fm: David Breeding 72330,2051 To: Pete Lyall 76703,4230 (X) > I wrote a generic dialer hundreds of years ago in 6809 asm... Probably of > very little use if you're using OSK. C is the better way to go anyway. I hadn't seen it, but, as you said, it would probably be a little hard to port over. Yes, I think that "C" is the "wave of the future". I have the dialer where it will connect, now, thanks to Bob.. I was really baffled as to what was going on. I was of the impression that the .EKO in the descriptor was for echo to stdout. Learned something. I think I'll try to get the thing to auto logon, too.. I guess it's kind of an elementary project, but I've not seen one anywhere, so maybe someone will be able to use it. We have a single-line BBS here and sometimes I get a little tired of hitting "a/" so many times . -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ There is 1 Reply. #: 20578 S3/Languages 21-Nov-94 19:44:32 Sb: #20574-#_gs_rdy() question Fm: Pete Lyall 76703,4230 To: David Breeding 72330,2051 (X) David - It _does_ echo to standard out. Don't forget that /T1's standard out IS /T1 (or whatever port you're using). Pete There is 1 Reply. #: 20589 S3/Languages 26-Nov-94 12:58:19 Sb: #20578-#_gs_rdy() question Fm: David Breeding 72330,2051 To: Pete Lyall 76703,4230 (X) In reply to MSG #20574 > It _does_ echo to standard out. Don't forget that /T1's standard out IS > /T1 (or whatever port you're using). Now I AM a little confused - sorta . Since I had opened a path to the port (not having first closed stdout, that is) I would have thought the screen would still have been stdout. But, in any case, you and Bob were entirely correct. After taking Bob's advice and turning Echo off, it worked like a charm. I couldn't find any of the autodialers for OSK here - I found yours, for the CoCo, and maybe Bob's version for the CoCo, but nothing for OSK - so I went ahead and got mine up and running. Don't have autolog going yet, would like to, but I now have it to where it will get the connect. Boy, talk about something fantastic, I really love OSK and G-Windows.. rather than typing in all the stuff from Bob's example (well, really all I needed was about 3 lines), all I did was list the thing in one window, and with my original file in the editor in another window, pressed my mouse button to highlight the lines I wanted in Bob's example, move to the editor window and paste it into that file with a double mouse click.. I just wish we had enough users to make it financially appealing for those who have written all these good programs we have to go in and really put in the bells and whistles. -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ There is 1 Reply. #: 20595 S3/Languages 28-Nov-94 10:13:37 Sb: #20589-#_gs_rdy() question Fm: Pete Lyall 76703,4230 To: David Breeding 72330,2051 (X) Well, I don't know if I can remember the details well enough to be coherent, but what it amounts to is that for each SCF device, there may be an assigned 'echo' device - usually itself. So when something appears on that device's input, if the ECHO path option is set, the character will be sent to the echo device's path (again, usually the same device). This is how a modem user logging into your machine would see his typing. In your case, your 'modem user' was your MODEM, who was happily sending command echo's back to you, and was then haveing T1 echo them back out, and so the loop went. Pete There is 1 Reply. #: 20602 S3/Languages 01-Dec-94 08:20:52 Sb: #20595-_gs_rdy() question Fm: Mark Griffith 76070,41 To: Pete Lyall 76703,4230 (X) David and Pete: As Pete says, there are a number of options on the device that should be unset to get reliable communications to the modem. Basically, you null out all the SCF options and then set those that you need, like baud rate, parity, etc. If you need an example, look at the source code for Sterm 1.5 that's in the communications library. The file IO.C has the routines to do this. There are other examples around, Pete could probably mention a few, that do the same thing. Mark (Hi Petely!) #: 20573 S3/Languages 20-Nov-94 18:29:26 Sb: #20570-#_gs_rdy() question Fm: Bob van der Poel 76510,2203 To: David Breeding 72330,2051 (X) > What I'm trying to do is write an external autodialer. Besides Pete, I have written 2. One is in assembler for level II, the other is in C for OSK. I believe they are: LIB 10 phone.ar LIB 12 phone.lha Try browse LIB:ALL KEY:PHONE or KEY:DIAL and see what comes up. There are 2 Replies. #: 20575 S3/Languages 20-Nov-94 22:15:42 Sb: #20573-#_gs_rdy() question Fm: David Breeding 72330,2051 To: Bob van der Poel 76510,2203 (X) > > What I'm trying to do is write an external autodialer. > > Besides Pete, I have written 2. One is in assembler for level II, the > other is in C for OSK. I believe they are: > > LIB 10 phone.ar > LIB 12 phone.lha > > Try browse LIB:ALL KEY:PHONE or KEY:DIAL and see what comes up. Whoa! I didn't know we had one. No use trying to re-invent the wheel. I'll be sure and grab it. I did get mine to dial in, thanks to you, but, as I said, no use if it's already been done.. I have a listing of the database, but apparently overlooked it. Thanks, again for the help and info.. The knowledge about .EKO should be useful later.. I'd thought that it was only for echo to stdout.. -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ There is 1 Reply. #: 20579 S3/Languages 21-Nov-94 21:23:50 Sb: #20575-#_gs_rdy() question Fm: Bob van der Poel 76510,2203 To: David Breeding 72330,2051 (X) I'll have a look myself. If the c-version is not there, I'll upload it later this week. Don't recall if I never got around to doing so, or if there was a reason for not doing so, or if it has been deleted. Bug me if I forget again . BTW, both the asm and c versions handle a complete login sequence. There is 1 Reply. #: 20590 S3/Languages 26-Nov-94 12:59:11 Sb: #20579-#_gs_rdy() question Fm: David Breeding 72330,2051 To: Bob van der Poel 76510,2203 (X) > I'll have a look myself. If the c-version is not there, I'll upload it > later this week. Don't recall if I never got around to doing so, or if > there was a reason for not doing so, or if it has been deleted. Bug me if > I forget again . BTW, both the asm and c versions handle a complete > login sequence. That would be great. I have mine to where it will do the connect, but haven't gotten into the login yet. But if it's already available, then it would save my having to do it. How does your version handle the connect? Does it look for the modem result sequences or look for Carrier Detect? If I got my information straight, I don't think my driver supports CD, but I'm not exactly sure. -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ There is 1 Reply. #: 20592 S3/Languages 27-Nov-94 15:18:45 Sb: #20590-_gs_rdy() question Fm: Bob van der Poel 76510,2203 To: David Breeding 72330,2051 (X) I am uploading phone.lzh to lib 12 today. Have a look after the sysop gets a change to do his thing. Let me know if it works for you. > How does your version handle the connect? Just looks for the connect strings sent back from the modem. It would be nice to change the code to use multiple matches so that if it gets "CONNECT" it does one thing, "BUSY" it does something else, etc. Something like a switch() statement in C does...maybe you want a project? #: 20577 S3/Languages 20-Nov-94 22:17:12 Sb: #20573-_gs_rdy() question Fm: David Breeding 72330,2051 To: Bob van der Poel 76510,2203 (X) > Besides Pete, I have written 2. One is in assembler for level II, the > other is in C for OSK. I believe they are: > > LIB 10 phone.ar > LIB 12 phone.lha > > Try browse LIB:ALL KEY:PHONE or KEY:DIAL and see what comes up. Just went in. Tried different KEY's - phone, dial, phones, dialer, also browsed phone.*, phones.*. Found phone.ar, and Pete's stuff, but not phone.lha. It might have been put in the archives. Did this one do auto logon? I thought I'd try to add this.., it would be handy. -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ #: 20607 S3/Languages 04-Dec-94 14:04:49 Sb: #20602-_gs_rdy() question Fm: David Breeding 72330,2051 To: Mark Griffith 76070,41 (X) > As Pete says, there are a number of options on the device that should be > unset to get reliable communications to the modem. Basically, you null > out all the SCF > options and then set those that you need, like baud rate, parity, etc. > > If you need an example, look at the source code for Sterm 1.5 that's in > the communications library. The file IO.C has the routines to do this. I have the source. I saw where this was done. If you missed my original post, I had not nulled out my echo.. I had not realized that it worked the way it does. -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ #: 20606 S3/Languages 04-Dec-94 14:04:05 Sb: #20595-_gs_rdy() question Fm: David Breeding 72330,2051 To: Pete Lyall 76703,4230 (X) > coherent, but what it amounts to is that for each SCF device, there may be > an assigned 'echo' device - usually itself. So when something appears on > that device's input, if the ECHO path option is set, the character will be > sent to the echo device's path (again, usually the same device). Yeah, I see that now. I didn't realize that was the way it worked. > In your > case, your 'modem user' was your MODEM, who was happily sending command > echo's back to you, and was then haveing T1 echo them back out, and so the > loop went. Yep, that was the way it was going -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ #: 20605 S3/Languages 04-Dec-94 14:03:20 Sb: #20592-_gs_rdy() question Fm: David Breeding 72330,2051 To: Bob van der Poel 76510,2203 (X) > I am uploading phone.lzh to lib 12 today. Let me know if it works for you. I'll get it.. > > How does your version handle the connect? > > Just looks for the connect strings sent back from the modem. It would be The same way I started out. > nice to change the code to use multiple matches so that if it gets > "CONNECT" it does one thing, "BUSY" it does something else, etc. Something I had mine exit on "NO DIAL TONE". I set up a config file, to look for each BBS, with a # of attempts to try.. I let it be infinite if this # wass negative. It would keep trying as long as it saw "BUSY" or "NO CARRIER". Yes, and if "NO ANSWER", it would set the count to 1 and try once more, then exit. > like a switch() statement in C does...maybe you want a project? It might be a good idea.. Do we have a need for a fairly elaborate external autodialer? I had thought of developing mine to a pretty neat thing, but, if you have already done it, there would be no need. Ummm, about the switch() thing.. I can't think of anything to do except keep dialing on "nonfatal" responses or exit on "fatal" ones. -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^