read new nonstop follow 90936 10-DEC 17:13 New Uploads RE: PowerBasic for OS9/68000 ships! (Re: Msg 90935) From: FHOGG To: ALL I need some feedback from you guys. Mike and I have been talking about a demo version of PowerBasic that would be restricted in some way but would allow compiling. Our discussion ranged from limiting the size of a source file to eliminating some functions. After playing with PowerBasic to write the date program I uploaded today I can see how having a demo version would enhance interest and sales. The concern about having a demo that was 100% but restricted the size of a source program is the fear that some clever bloke would figure out how to 'fix' the demo so it would work like the regular PowerBasic. This fear makes a restricted demo (with some features totally removed) attractive. The question then becomes which features can be removed that would allow a useful demo while not stealing sales by being too useful? If we decide to go the restricted route we could include a group of demos in source form plus compiled versions of the demos that will not compile on the restricted compiler. What do you think. Frank -*- 90937 10-DEC 18:14 Programmers Den RE: _gs_rdy() Question (Re: Msg 90878) From: DBREEDING To: JEJONES PAGAN said: > > > From now on, just about everything I post will be compiled with UCC. > > > I'm porting most of my G-Windows stuff for recompilation to OS9000. > > Sounds like a good testimonial. Might just see if I can go with it. > Well...for what it's worth, here's an additional piece of data. > Remember gifshow for the MM/1? Long ago, when I first got my MM/1, with > Mike Haaland's permission I did some work to speed it up. I did about > all I could short of rewriting in assembly language. > About a week ago, when I finally got around to installing Ultra C on > my MM/1 (blush...I'm a fairly serious procrastinator), I recompiled > gifshow with no particular knobs twisted to speed it up. The resulting > program runs about 22% faster. It would appear that UCC is definitely the way to go if one one wants to get something besides 3.2. I had thought that the GNU package was the way most were going, but from the posts here, if one is writing code for distribution, there might be too many strings attached. -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ -*- 90939 10-DEC 20:04 Programmers Den RE: _gs_rdy() Question (Re: Msg 90892) From: DBREEDING To: EDELMAR > > ... Are there any restrictions on distributing software compiled under > > GCC, or 3.2, for that matter? ... > > There are no restrictions distributing and/or selling code compiled with > and using the libraries provided with either 3.2 or Ultra-C. Indeed, MW > gives permission to distribute, at no charge, 'csl', the replacement for > 'cio' and the math module with the code if it is compiled with Ultra-C. > To the best of my knowledge, this type of policy is universal regardless > of what software house sells you their compiler. Hmm.. It was my understanding that some of the compilers for the PC's did have licensing requirements.. I was unclear on that, maybe for some that required run-time packages? This understanding or misunderstanding was what prompted me to write the letter referred to below. > To the best of my > knowledge, there are no restrictions on code distribution for code > compiled with the GNU compiler if you _don't_ use their libraries. Well, it still sounds complicated with them > > I contacted Tandy regarding the CoCo compiler, and they sent me a > letter > stating that all that code could be considered PD in regard to > distributing > compiled code. > > Can you clarify that? Are you saying programmers cannot charge for > software if they use the CoCo C-Compiler and libraries? (PD would imply > that.) I guess I mis-phrased that statement. No, I just looked up the letter and they DID use the word "pd", but said you could sell the code.. Here is the direct quote from the letter. "Please be assured that both the library files and the "root.a" module in the Tandy C COMPILER are considered to be public domain and as such can be included in code to be distributed for sale or release." Maybe they misused the term "pd", but at any rate, from the letter, you're free to do with the compiled code whatever you will. -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ -*- End of Thread. -*- 90938 10-DEC 20:02 General Information RE: 2nd Hard Drive (Re: Msg 90931) From: DBREEDING To: CHARLESAM > and I believe my Ids are straightened out but there is also a jumper to > the left of the control cable and I'm not sure about the placement of > that. Also, I substituted my new drive for the existing drive as H0, but > os9 refuses to recognize it. I get Unit not ready ERROR. I believe now > that there is some problem with the drive. I'll keep working on it. One note: Have you tried removing the extra jumper? This might be the PARITY jumper. I went through a hair-pulling fit when installing my ST-1096N on my system. Seagate DID have a BBS where you could d/l technical specs for any of their drives. It was some time ago, but here is the # as it was then. You might give it a shot.. The file for my drive contained a schematic for the pinouts in IBM graphics. You can either "type" it on a PC, or list it to a printer having IBM emulation. SEAGATE TECHNOLOGY, INC. Technical Support Bulletin Board 408/438-8771 [300-9600 HST, MNP 3/5, N-8-1] (C)opyright 1990 -- David Breeding -- CompuServe : 72330,2051 Delphi : DBREEDING *** Sent via CoCo-InfoXpress V1.01 *** ^^^^ ^^^^^^^^^^ -*- 90942 10-DEC 23:37 General Information RE: 2nd Hard Drive (Re: Msg 90931) From: WA2EGP To: CHARLESAM The id must be different in the software and the hardware. If you have one drive and you set the software for an ID of 1, the jumpers on the drive better be set for 1 or the drive will think it is something else and will not recognize stuff sent to it. Almost as bad as having two drives trying to read the same stuff (grin). -*- 90945 11-DEC 12:45 General Information RE: 2nd Hard Drive (Re: Msg 90938) From: CHARLESAM To: DBREEDING Thanx Dave, I'll check it out(Seagate). -*- 90946 11-DEC 12:48 General Information RE: 2nd Hard Drive (Re: Msg 90942) From: CHARLESAM To: WA2EGP As I stated, I made the new(2nd) drive H0 just to see if it would be recognized,that is I removed my existing drive and substituded the new drive. Alas, Os9 came back with "DRIVE NOT READY". Go figure. Thanx Charlie -*- 90955 12-DEC 00:28 General Information RE: 2nd Hard Drive (Re: Msg 90945) From: AJMLFCO To: CHARLESAM (NR) Here is a little lesson I learned the hard way concerning Seagate 3.5" N-series hard drives: The universal installation handbook incorrectly labels the SCSI jumper positions in figure 4. It should be P NC 1 2 4 Rather than P NC 4 2 1 as shown in the figure. You probably should have no jumper in the P (parity position). Most likely your host or host adapter card is SCSI ID=0. Your first drive could be set to SCSI ID=1. You can set the second drive to SCSI ID=2. Be sure that your device descriptor is set correctly. I haven't had time to follow this entire thread, so I hope I am addressing at least part of your question. I have used the scsi47.ar drivers on my CoCo with two Seagate 157N's. It's been a few years since I have played with them, but I recall a little "strangeness" in the addressing in the device descriptors. If you are using these drivers on a CoCo, you may be able to get some help from Ken Scales, the author, or I could fire up the old CoCo and check my settings. I have also run two SCSI drives on the Kix\30. That system was provided with the necessary descriptors so I did not need to patch one to make the second on like I did on the CoCo. One other thing I have learned is that the SCSI bus really likes to have the terminators installed on the drive furtherst from the host. Some resistor packs have a pin #1 dot on them. These dots line up with corresponding dots screened onto the printed circuit board. I am not sure if resistor packs installed backwards really "terminate". This could lead to erratic performance. hope this helps, Allen Morgan -*- 90956 12-DEC 00:32 General Information RE: 2nd Hard Drive (Re: Msg 90946) From: WA2EGP To: CHARLESAM (NR) OK. I assume you had the jumper set right (or none at all). Was it formatted? Or should I ask, did a previous owner low level format it? I have picked up SCSI drives who had that done and if LSN 0 gets formatted, all the info about the drive is gone. The hardware looks there to determine how large it is. If it ain't there, there is nothing you can do except get it "fixed". They put that info back on LSN 0. Outside of putting the cable on upside-down (which is darn near impossible), I can't think of anything else. I hope you get your problem solved. Let me know how it works out. -*- End of Thread. -*- 90940 10-DEC 22:24 System Modules (6809) RE: CC3IO Patches (Re: Msg 90922) From: MIKE_GUZZI To: GREGL Good messages like that I always save! -*- 90941 10-DEC 22:29 Applications (6809) Need program From: MIKE_GUZZI To: ALL Who Sells the basic09 decompiler? or is that company out of business? I have a need for it and need to get a copy of it. -*- 90943 10-DEC 23:53 General Information RE: Install program (Re: Msg 90933) From: WA2EGP To: TEDJAEGER Well, a couple of thoughts I had.... Will it install programs to their own directories and use "standard" directories like SYS? I tend to like to put a cmds subdirectory in a directory so all my word processor stuff including utilies in under WORDPROCESSOR (as an example). I like the idea of source drive/target drive. I can your point in assuming that all the parts of a program are in the same directory on the installation disk. Some one might put SYS stuff in a SYS directory on it. Almost sounds like your working on what I would call a directed version of dsave. It sort of dsaves but sends it where you want it to go. Best of luck on the project. It's something that I think is needed. -*- 90960 12-DEC 19:35 General Information RE: Install program (Re: Msg 90933) From: NIMITZ To: TEDJAEGER Ted, I suggest you have the program query the user for his desired installation directory, and then use information obtained from the programmer to interactively generate a script file. If you use dsave after creating the users directory, you should have no problem. Your program would simply create the initial directory, and then execute dsave -e from the appropriate drive and directory. -*- 90966 13-DEC 21:21 General Information RE: Install program (Re: Msg 90934) From: TEDJAEGER To: JOHNREED (NR) > Have you considered using the `oddjob' program? You can do things > that the fancy UNIX shells do, and everyone with an MM/1 should have > it.. Absolutely forgot about it! I'll take a look. Thanks for reminding me.. > Warning. I have found (on my MM1/a) that files copied to a named > pipe, then back to a disk file have a few characters tacked on to them > at the end - mostly on larger (over 15k ) files. Yup, Joel mentioned that in his article. Another headache with the pipe method. Bests ---TedJaeger -*- 90967 13-DEC 21:21 General Information RE: Install program (Re: Msg 90943) From: TEDJAEGER To: WA2EGP > Will it install programs to their own directories and use "standard" > directories like SYS? I tend to like to put a cmds subdirectory in a > directory > so all my word processor stuff including utilies in under WORDPROCESSOR > (as an example). Yes, but at the discretion of the script that the programmer has to provide. My program is a graphical front end to the script which collects from the user the source and target drives as well as the name of the script it is to run. So if the script includes: makdir /dd/WORDPROCESSOR copy neatprogram /dd/wordprocessor/neatprogram it will install to WORDPROCESSOR directory. Here you see the reason for my ambivalence: the programer still has the work of writing the install script and the user can still get into the script and change it to muck. > that all the parts of a program are in the same directory on the > installation disk. Some one might put SYS stuff in a SYS directory on it. Yes, exactly. I invision DeskTamer being distributed that way. > Almost sounds like your working on what I would call a directed version > of dsave. It sort of Thanks, for that insight! I may be able to pass the variables for source and target drives and program name to dsave and have the install program run the dsave procedure file. That may be the best way to do the whole thing. It would save the programmer having to write an installation script as dsave would do that for them. Interesting....... Bests ---TedJaeger -*- 90970 14-DEC 01:18 General Information RE: Install program (Re: Msg 90967) From: WA2EGP To: TEDJAEGER (NR) I hope it works out. Would be nice to have some type of install program. BTW, would it have some sort of default values in case the user is a newbie and really doesn't know where to put things (like we have standards on that type of thing - like UNIX). Obviously, there would have to be some kind of standard "place" to put things beyond SYS and command stuff. I have gotten programs which dumped a whole mess of stuff in root...very ugly. Anyway, this would be a plus for those of us out there who have trouble changing directories. I guess that is the hardest thing to do....write something that a person new to the OS can use without frustration and a more experienced user can "play" with it a bit to get what they want. -*- End of Thread. -*- 90944 11-DEC 11:25 General Information palm22.lzh? From: JEJONES To: ALL Has anyone had any luck downloading palm via the gopher section of this SIG? It seems to think that "palm22.lzh" on chestnut is a subdirectory rather than a file. Opinions herein are solely those of their respective authors. Clipper Chip: Big Brother Inside -*- 90947 11-DEC 13:35 General Information RE: palm22.lzh? (Re: Msg 90944) From: MITHELEN To: JEJONES Why not just download it from the Telcom Database here at Delphi? -- Paul -*- 90949 11-DEC 18:26 General Information RE: palm22.lzh? (Re: Msg 90947) From: JEJONES To: MITHELEN > Why not just download it from the Telcom Database here at Delphi? I went looking for it one evening; guess I didn't use the right keywords to search. In any case, the menu entry for palm22.lzh under chestnut/osk/telecom really should be corrected. Opinions herein are solely those of their respective authors. Clipper Chip: Big Brother Inside -*- 90951 11-DEC 21:28 General Information RE: palm22.lzh? (Re: Msg 90949) From: MRGOOD To: JEJONES James, Palm 2.2 is in the Coco database, not OSK. Hugo -*- End of Thread. -*- 90948 11-DEC 16:27 Programmers Den powerbasic vs. Ultra C From: PAGAN To: ALL Out of curiosity I downloaded the benchmark programs that Frank Hogg offered for his new PowerBasic compiler. I converted these programs to "C" and compiled with Ultra C. I used no optimization (-o=0) and used the "csl" trap library (-i). In each case, I tried to faithfully duplicate the function of Frank's original code rather than use any slick tricks to speed things up. Where C doesn't have an equivalent function, I used the nearest I could think of. For example in "bench6" below, Basic has the "str$" function for which I substututed the C "sprintf()". The codes sizes for UCC listed below do not include the 47K overhead of the "csl" trap library and the execution times should be considered for information only; The test programs are do nothing loops that, in my experience, don't reflect the real world performance of a complex application. Also, benchmarks don't account for development and maintenance time nor for "intangibles" like personal preference. Test were done on a Delmar System IV with G-windows and screen saver deactivated by putting the mouse cursor in the lower right corner. Execution Time Code Size (in seconds) (in bytes) PB UCC PB UCC -- --- ---- ---- bench2 10 6 1362 1766 bench2m 8 -- 1350 ---- bench3 14 8 1380 1758 bench4 24 3 1462 1744 bench5 20 6 1404 1774 bench6 34 95 1432 1796 bench7 40 18 1534 1842 bench8 15 8 1384 1780 bench9 11 4 1346 1760 bench10 75 5 1352 1768 bench11 24 4 1446 1762 bench12 12 6 1370 1772 I am uploading the C source and makefile for the comparisons to the databases for anyone who is interested. Stephen (PAGAN) -*- 90950 11-DEC 18:26 Programmers Den RE: powerbasic vs. Ultra C (Re: Msg 90948) From: JEJONES To: PAGAN > Out of curiosity I downloaded the benchmark programs that Frank Hogg > offered for his new PowerBasic compiler. I converted these programs to > "C" and compiled with Ultra C. I used no optimization (-o=0) and used the > "csl" trap library (-i). If you had used the default options, the intermediate code optimizer would probably have nearly eliminated the code on most of those programs. These days one has to be pretty determined to keep optimizers from noticing code that doesn't really make any difference to the result and deleting it, or even just transforming it into something that is completely different from what you *think* you're testing. > The test programs are do nothing loops that, in my > experience, don't reflect the real world performance of a complex > application. That's true of many benchmarks. IMHO everyone should read the chapter on benchmarks in Hennessy and Patterson's book on computer architecture. Opinions herein are solely those of their respective authors. Clipper Chip: Big Brother Inside -*- 90952 11-DEC 21:39 Programmers Den RE: powerbasic vs. Ultra C (Re: Msg 90950) From: PAGAN To: JEJONES > If you had used the default options, the intermediate code >optimizer would probably have nearly eliminated the code on most of >those programs. These days one has to be pretty determined to keep >optimizers from noticing code that doesn't really make any >difference to the result and deleting it, or even just transforming >it into something that is completely different from what you *think* >you're testing. Don't I know it. At first look I could see several places UCC would take liberties if given the opportunity. I just rewrote the code as faithfully as I could but I know that the values are the more the result of the difference in compilers rather than any difference in the languages. For example, bench10.b assigns a constant to a variable in a loop: dim a:byte dim i:integer Start shell "date -j" for i=1 to 10000000 a=100 next i shell "date -j" In C this becomes: #include #include main() { char a; int i; printf("%d\n",time(0)); for(i=0;i<1000000;i++) a=100; printf("%d\n",time(0)); } Though they may seem equivalent, the complier/optimizer can play some games with this. Compiled with -o=0 (no optimization) the loop in assembler looks like: bra _$l4be _$l4bb move.b #0x64,-6(%a5) assign value move.l %d0,-8(%a5) put into storage addq.l #1,-4(%a5) increment counter _$l4be cmpi.l #0xf4240,-4(%a5) check it blt _$l4bb branch back if not done But, compiled with -o=7 the loop looks like: _$l4ba addq.l #1,%d0 cmp.l #0xf4240,%d0 blt _$l4ba Are you wondering where the assignment went to? Well, the UCC compliler is "smart" enough to figure out that the variable is not used anywhere in the program so, given the chance, it ignores it! Some of the other benchmarks Frank uploaded would suffer similar changes if compiled with UCC. In bench4, there s a simple integer calculation repeated each time thru the loop. UCC will recognize that, if forced to use it, the value only needs to be calculated once and never changes. So the compiler will precalculate it and store it with the program constants. Stephen (PAGAN) -*- 90961 12-DEC 23:18 Programmers Den RE: powerbasic vs. Ultra C (Re: Msg 90948) From: FHOGG To: PAGAN Stephen (PAGAN), While you did state that you were curious how CDL Basic (formally PowerBasic) compared to UUC you are missing the point and perhaps moving this discussion in the wrong direction. I admit I was surprised at first that a C guy would bother about Basic but then I realized that it was indeed just curiosity on your part. I welcome the comparison you have made especially the syntax comparison that showed more clearly than I, how much easier Basic is to read than C. Perhaps I should state our goals or rather Mike Smiths goals for CBL Basic. First some brief history. MW Basic for OSK came out about 10 years ago and has not changed much in the past decade. It appears that MW is commited to C while the rest of the world goes in different directions. I recently talked to a former OSK user whose company has switched to Visual Basic because it is easier to work with. I think that a good argument could be made that MW missed the boat in not continuing the development of their Basic. Proof of my point is the lack of applications for OSK. We have been limited to C and assembler for 10 years of development. That has limited us to developers who were willing or wanted to work with the tools that were available. I am not about to get into the relative merits of any language. I am just stating the obvious. If C and assembler were good enough then we would have seen more applications for OSK. They don't exist, point proven. For whatever their reasons, many developers do not want to work with C. Many would rather work with Basic and because MW Basic is slow it has been a yoke around the neck of OSK development. Now that has changed. CDL Basic is lots faster than MW Basic because it is a compiler. The benchmarks were carefully crafted to do things exactly as MW Basic does them so users could see for themselves the speed advantage compared to MW Basic. The goal was simply to impress upon MW Basic users the speed advantage of CDL Basic. We did that with the expectation that the availability of a fast Basic compiler would attract developers for OSK who would not do so with C. After all if speed alone was the criteria then we would all use assembler, which is faster than any compiler. Who wants to do serious applications in that? I hope that you do not take this as a criticism of you, it is not. As a matter of fact I regularly enjoy your Blackjack game. I really want to address issues that this thread might wander into and try to keep everyone on track about CBL Basic. Lets not throw the baby out with the bathwater by bashing CBL Basic solely based on it being somewhat slower than UUC. Microware has been developing their many versions of C for 15 years or so with a crew of programmers. Mike started CBL Basic a year ago and we are at version 1. Newer versions developed over the coming years will have more features, be faster and most importantly of all will support a continuing pool of developers creating more applications for OSK. Applications that would not have been developed in C. Speaking strictly for myself I am very very happy with CBL Basic. Programs I've written in it are by far much faster than any program I've ever written in C. (none) I feel that I already know how to program in it without having to take a college course or study any of the five books I bought over the years on C. Don't get me wrong. I would like to 'know' C. I just don't want to go to the work to 'learn' it. In the few weeks I have had CDL Basic I have written a handful of neat little utilities just for the fun of it. Let me restate that. Just for the FUN of it. I'm having FUN programming again. I have plans to do some serious applications for G- Windows using CDL Basic. Things I would not consider doing under any circumstances with C. You are probably thinking that if I just took the time to learn C I would like it etc etc. Why bother? I LIKE Basic, I don't like C. CDL Basic is fast enough to do serious applications with and it's fun to work with. Again I don't mean to jump on you for this and I'm sorry to be so long winded but let me just finish with this... In my mind comparing C to Basic is like comparing a helicopter to a airliner. It makes no sense so why do it? They are tools that serve different masters. CDL Basic is a tool that will encourage development of software for OSK and that is something we all want. Thanks again for Blackjack. BTW I would love solitaire if you feel so inclined. Frank -*- 90963 13-DEC 02:37 Programmers Den RE: powerbasic vs. Ultra C (Re: Msg 90961) From: PAGAN To: FHOGG Frank, I fully support your effort to bring a good compiled Basic to OSK. I wasn't trying to say that UCC is better or worse than CBL Basic and I won't get argument down in an argument over which is "best". I explained in a later post that the differences in execution time are the results of the optimizations available with UCC. I can agree that, for certain things, Basic would be preferable to C. Not, IMO, most things but certain things. I also agree that MW may have flubbed it by not continuing to develop Basic09. It had a lot of capability and, and you've pointed out, is easier to learn than C. I do not agree that Basic is nearly as powerful a language as C but for many applications this would not be a problem. Since OSK applications are still at the single developer or small team stage the choice of a language is influenced more by familiarity than anything else. Regarding the syntax differences, I usually find C to be easier to read than Basic. Since I'm intimately familiar with both languages I attribute this to personal preference. Now for some questions. Since I work in G-Wndows a lot, I've had to develop techniques for handling it's event driven environment. So to see if it could work well for me does CBL Basic: 1. support pointers to functions? 2. allow pointers to be passed between modules? 3. support dynamic memory allocation/reallocation? 4. support pointers to structures? 5. Will it be compatible with G-View created windows? Re solitare: It's on the list of things to do. I've just completed upgrading and porting Blackjack to Ultra-C (now testing for OS9000) and have a new game called "CyberWar" which should be ready soon for both OSK and OS9000 with G-Windows. Stephen (PAGAN) -*- 90964 13-DEC 03:10 Programmers Den RE: powerbasic vs. Ultra C (Re: Msg 90961) From: JOELHEGBERG To: FHOGG Frank, I felt the need to reply to your recent message. Let me say I'm always pleased to see new, powerful software development tools (such as CDL Basic) arrive for OS-9. I wish you and Mike the best with the project. > First some brief history. MW Basic for OSK > came out about 10 years ago and has not changed much in the > past decade. It appears that MW is commited to C while the > rest of the world goes in different directions. I do not understand how you can say this. If the world is moving in another direction other than C it may be to C++. While I agree, there has been a recent resurgence of BASIC amateur programmers with the arrival of Visual Basic, VB is used mostly by novice programmers whose main career usually isn't programming. From my understanding, VB is used in corporations and small businesses to handle simple programming needs. No large commercial applications are written in VB, to my knowledge. > I think that > a good argument could be made that MW missed the boat in not > continuing the development of their Basic. Proof of my point > is the lack of applications for OSK. We have been limited to > C and assembler for 10 years of development. That has > limited us to developers who were willing or wanted to work > with the tools that were available. I am not about to get > into the relative merits of any language. I am just stating > the obvious. If C and assembler were good enough then we > would have seen more applications for OSK. They don't exist, > point proven. That is a tremendous leap to a highly speculative conclusion. I very much doubt the lack of a good Basic compiler has thwarted OS-9's application base. For a long time now, many people in OS-9 have declared reasons why we have a lack of applications. Some have blamed it on Microware, some have blamed it on the lack of development tools, some have blamed it on a lack of skilled programmers, some have blamed it on the lack of support for our programmers, some on lack of marketing, some on the fact that OS-9's major base is industrial, etc. You cannot flippantly state 'point proven' just because applications don't exist. That condition makes everyone else's 'point proven' as well, so which point really has been proven? I would imagine it's a combination of many factors. > We did that > with the expectation that the availability of a fast Basic > compiler would attract developers for OSK who would not do > so with C. I'm hopeful you are right. Again, I'm always excited to see more development opportunities become available for OS-9. > Don't get me wrong. I would like to 'know' > C. I just don't want to go to the work to 'learn' it. I would suggest to you that the people who "don't want to go to the work to learn" C are not the programmers who will be writing the types of application programs needed to bring OS-9 out of the shadows. > Again I don't mean to jump on you for this and I'm sorry to > be so long winded but let me just finish with this... In my > mind comparing C to Basic is like comparing a helicopter to > a airliner. It makes no sense so why do it? I'm amused by your comparison, Frank! It occurs to me that a helicopter can go many places that an airliner could not possibly go. But you are correct... you really cannot compare the two. > CDL Basic is a tool that will encourage development of > software for OSK and that is something we all want. I whole-heartedly agree, and please extend my congratulations to Mike for his work! I certainly hope it becomes a best-seller. -- Joel Mathew Hegberg PS: I can't help myself... my curiosity gets the better of me. May I ask what language Mike wrote the CDL Basic compiler in? ;) -*- 90968 14-DEC 00:43 Programmers Den RE: powerbasic vs. Ultra C (Re: Msg 90963) From: FHOGG To: PAGAN Steven I do not disagree nor have many arguments with most of your comments except... > I do not agree that Basic is nearly as powerful a language as C but > for many applications this would not be a problem. CDL Basic is powerful enough to write a Basic compiler. In this case CDL Basic itself is written in CDL Basic! Does that count as 'powerful enough'? > Regarding the syntax differences, I usually find C to be easier to > read than Basic. Since I'm intimately familiar with both languages > I attribute this to personal preference. I would also attribute that to your knowledge of C. Only if you knew C could you have a preference about it. And in order to know it you had to learn it. > Now for some questions. Since I work in G-Wndows a lot, I've had to > develop techniques for handling it's event driven environment. So to > see if it could work well for me does CDL Basic: > 1. support pointers to functions? This is not fully defined as yet but it probably will. I should have the details by this weekend. > 2. allow pointers to be passed between modules? Yes > 3. support dynamic memory allocation/reallocation? YES > 4. support pointers to structures? YES and to structure sub-elements as well > 5. Will it be compatible with G-View created windows? I am not aware of any differences from standard G-Windows windows. We are perhaps making a wild assumption here but we 'assumed' that having the C library interface which allows calling all of the G-Windows C library calls would also allow the compatibility you ask about. Is this a valid assumption? Are G-View created windows different that standard G-Windows windows? > have a new game called "CyberWar" which should be ready soon for both > OSK and OS9000 with G-Windows. GREAT! I'm looking forward to it. Thanks for your help. Frank -*- 90969 14-DEC 00:45 Programmers Den RE: powerbasic vs. Ultra C (Re: Msg 90964) From: FHOGG To: JOELHEGBERG Joel >Visual Basic, VB is used mostly by novice programmers whose >main career usually isn't programming. From my understanding, VB is >used in corporations and small businesses to handle simple programming >needs. The fellow I talked to is the chief engineer at a company that makes large commercial washing machines for hospitals etc. The computer controls a whole bunch of robot carriers that shuttle the linen from washer to dryer etc. Very impressive operation. Programming in this case is probably not full time but my impression of his job was to integrate all this odd hardware and write support software modifications to their main overall application. Maintaining this for all their different customers is probably their main reason for going to something simpler like Visual Basic. When they were still using OSK they were looking for software help with C. MW lost them as a customer because of the difficulty they had working with MW C. This is not the first time I've heard this sort of thing. It was knowledge on my part of people like this that made me encourage Mike with CDL Basic. >No large commercial applications are written in VB, to my >knowledge. You could be right. But CDL Basic is intended to be able to write large applications easier than in C. >I would suggest to you that the people who "don't want to go to the >work to learn" C are not the programmers who will be writing the types >of application programs needed to bring OS-9 out of the shadows. Ah but this infers that C is the only solution. An old axiom goes something like... "It is a poor craftsman who blames his tools" means that it is the craftsman not the tools that will create the applications. If said craftsman chooses CDL Basic then that choice should not condemn the job that is done. Hey computers are supposed to make life easier, shouldn't computer languages do this too? >PS: I can't help myself... my curiosity gets the better of me. May I >ask what language Mike wrote the CDL Basic compiler in? ;) Here is where I get to prove the point of my last paragraph. CDL Basic is written in CDL Basic! A crude bootstrap version was first written in MW Basic. Then CDL Basic was used to enhance itself. It is written entirely in Basic BTW. Although it has assembler support built in it was not used in the main coding of CDL Basic. The reason is that we are looking toward doing a OS9000 version. But back to the point. CDL Basic is powerful enough to write itself. The only other two languages I am aware of that do this are C and assembler. There is no reason it cannot be as powerful or even more powerful than C. Thanks for the response. Frank -*- 90971 14-DEC 02:17 Programmers Den RE: powerbasic vs. Ultra C (Re: Msg 90969) From: JOELHEGBERG To: FHOGG (NR) Frank, > >I would suggest to you that the people who "don't want to go to the > >work to learn" C are not the programmers who will be writing the types > >of application programs needed to bring OS-9 out of the shadows. > > Ah but this infers that C is the only solution. An old axiom goes > something like... "It is a poor craftsman who blames his tools" means > that it is the craftsman not the tools that will create the > applications. If said craftsman chooses CDL Basic then that choice > should not condemn the job that is done. Hey computers are supposed > to make life easier, shouldn't computer languages do this too? Oops, maybe that didn't come out right. I meant to imply that a true programmer in the ever-evolving field of computer science can never become completely satisfied... s/he must always continue to expand his/her horizons and learn new ideas, techniques, etc. If a professional programmer says, "I don't want to go to the work to learn..." [anything] then I don't believe that programmer will be the one to write any breakthrough software. You are right, though... choices in computer languages are very important which is why I'm so excited about the availability of CDL Basic for OS-9. > >PS: I can't help myself... my curiosity gets the better of me. May I > >ask what language Mike wrote the CDL Basic compiler in? ;) > > Here is where I get to prove the point of my last paragraph. CDL Basic > is written in CDL Basic! Very impressive, Frank! I'm glad I asked... very interesting to know. -- Joel Mathew Hegberg. -*- 90973 14-DEC 04:29 Programmers Den RE: powerbasic vs. Ultra C (Re: Msg 90968) From: PAGAN To: FHOGG (NR) Frank, >CDL Basic is powerful enough to write a Basic compiler. In this case >CDL Basic itself is written in CDL Basic! Does that count as >'powerful enough'? Beats me, I have no idea what's involved in writing a compiler. They're just magic boxes to me :-) >> 1. support pointers to functions? >This is not fully defined as yet but it probably will. I should have >the details by this weekend. Pointers to functions like: void (*DoThis)() which can be changed on the fly depending on user generated events may not be absolutely positively necessary but make the event handling in a complex program _much_ easier to track and debug. >> 5. Will it be compatible with G-View created windows? >I am not aware of any differences from standard G-Windows windows. >We are perhaps making a wild assumption here but we 'assumed' that >having the C library interface which allows calling all of the >G-Windows C library calls would also allow the compatibility you ask >about. Is this a valid assumption? Are G-View created windows >different that standard G-Windows windows? Gview handles windows via the same calls as a "regular" program but making the calls is not what I'm concerned about. I'm concerned about the event reporting and handling. G-Windows provides three different ways to report a window or mosue event to a program. First is to define a signal to be sent when a particular event occurs. I'm assuming that CDL Basic can handle asynchronous events so this shouldn't be a problem. Second is to define an esacpe sequence - like a printf() format string - that wfm will put in stdin so the program can read it via the normal _os_readln() call. The most flexible method and the only one avilable from Gview is to define a callback function to be put in the event packet which is created whenever a defined event occurs. GView takes care of setting up these up for you with the Window_Set() function. The call might look something like this: Window_Set(path,0, W_Event,0,MEV_LB_up,0,0,MouseClick,0, W_Event,WEV_BlockRedraw,0,0,0,RedrawScreen,0, W_EventSignal,WEV_SIG, 0); "MouseClick" is the name of a function that wfm will store in the event packet when ever the left mouse button is released inside the window. Similarly, "RedrawScreen" is a function that will be stored whenever a part of the screen is exposed. Will CDL recognize that MouseClick and RedrawScreen are function names and inform the linker appropiately? If not, Gview and CDL Basic will not work together. Gadgets also require that callback functions be defined and the names are passed when the gadget is initialized. For example (from my gadget library): GADGET_ID *SetupButton(path,text,fontid,press_func,down_func,up_func) int path; /* path to window */ char *text; /* text to draw in button */ int fontid; /* font to draw text in */ int (*press_func)(); /* callback functions - */ int (*down_func)(); /* set to 0 if not required */ int (*up_func)(); Here again, GView takes care of this automagically but the process is the same. I hope you can understand just how important function pointers are in G-Windows and why I'm conerned with them. Frankly, without them, I would consider CDL as useless for anything but the most trivial G-Windows programs. Stephen (PAGAN) -*- 90974 14-DEC 07:28 Programmers Den RE: powerbasic vs. Ultra C (Re: Msg 90968) From: JEJONES To: FHOGG (NR) > > I do not agree that Basic is nearly as powerful a language as C but > > for many applications this would not be a problem. > > CDL Basic is powerful enough to write a Basic compiler. In this case > CDL Basic itself is written in CDL Basic! Does that count as > 'powerful enough'? Strictly speaking, if you can write a Turing machine simulator in it, you can do anything, so in that sense practically every programming language is "equally powerful" (some spreadsheets might even manage). OTOH, that's sort of like the Popeil ads--"you could even cut a tin can with it, but you wouldn't want to." The real question is how easy is it to do what you want. (Does CDL BASIC support recursion?) > > Regarding the syntax differences, I usually find C to be easier to > > read than Basic. Since I'm intimately familiar with both languages > > I attribute this to personal preference. > > I would also attribute that to your knowledge of C. Only if you knew C > could you have a preference about it. And in order to know it you had > to learn it. I'm not sure what the point of that is--your preference is probably due to your knowledge of BASIC. What difference does that make? As far as ease of learning--if natural languages are any indication, I doubt that one can classify languages as "easy" or "hard," save maybe relative to what you learned first. Surviving songs of Roman soldiers would get an A from a high school Latin teacher--all the cases, number, tenses, etc. are right. Why do we have to beat our heads against the wall to learn Latin? The advantages of Color BASIC and other BASICs of the sort that Kemeny and Kurtz, BASIC's inventors, called "gutter BASIC," are that with the exception of FOR/NEXT, it's purely line-oriented, and you can get by without any declarations for the most part. That makes it easy to get started... but also makes life far more obnoxious when it comes time to write a nontrivial program, or to maintain or modify a program. I'm no worshipper of C; I agree with many of the criticisms of it that have been made over the years. But I know people who have yet to, and probably never will, make the transition from Color BASIC to BASIC09, despite BASIC09's advantages. It's not clear to me that learning the extensions of CDL BASIC are that much easier than learning C. Opinions herein are solely those of their respective authors. Clipper Chip: Big Brother Inside -*- End of Thread. -*- 90953 11-DEC 23:33 OSK Applications CDL Basic for OS9/68000 From: FHOGG To: ALL PowerBasic for OS9/68000 has a new name. CDL Basic for OS9/68000 It was brought to our attention that the name PowerBasic was in use in the PC world and this confused many people. In order to avoid confusion (and avoid spending far too much time with lawyers) we decided to change the name. Hope this doesn't confuse too many people. Frank PS CDL Basic comes from 'Computer Design Labs', the creators of the compiler. -*- 90954 11-DEC 23:34 OSK Applications PowerBasic files in da new From: FHOGG To: MISAL (NR) Please delete all the files in da new that refer to PowerBasic. I will upload new files with the new name CDL Basic. Sorry for the trouble. Thanks Frank -*- 90957 12-DEC 02:18 Games & Graphics CD-i titles... From: MITHELEN To: ALL Welp, pick up two new CD-i titles today. Mutant Rampage: Bodyslam, and Dragons lair II: Timewarp. Both are excellent. Mutant Rampage is a fast paced, knock 'em, sock 'em, beat the heck outa the Mutant bad guys game... It has 4 levels, the first 3 have 3 different scenes (citys), the last just one (New York, the roughest/tuffest place in the world). This is a real action game! and quite challengeing. The graphics are supurb, along with the background music and sound effects. This is by far my favorate game so far, really gets the heart pumping! Dragons Lair II, is, of course the sequeal to the famous Dragons Lair game. I haven't played it in depth yet, but it definately starts out much harder then the original. Once again the graphics/sound and action are great. I noticed several more new titles in the local Best Buy(s) this weekend. They must have finally got their XMas releases in... Hall of Fame Football, Earth Control (or something like that) and one other game struck my interest but I didn't want to drop too much $$$ all at once... And I saw Dances With Wolves there too, which I definately will get next time I have a chance and some extra $$$... Looks like there will be lots of good stocking stuffers for poeple with CD-i players! -- Paul Jerkatis - SandV BBS (708)352-0948: OS-9 Support UUCP: amiserv.xnet.com!vpnet!sandv!mithelen ...or... mithelen@sandv.chi.il.us Internet: MITHELEN@Delphi.com -*- 90958 12-DEC 10:57 General Information Downed Hard Drive! :-( From: 01GEN40 To: ALL Hello All, and Happy Holidays! Quite unfortunately, my CoCos hard drive crashed yesterday 12/11. What a bummer. I do not know how long it will be before I am back on-line with my Trusty Little CoCo. I still have on-line access with the 486 non-Intel PC at work so I can read the forum just before I have to start slaving. I would like to know some tid-bits of info from anyone who has logged on with a PC. I am using a program that emmulates ProComm, it came with a modem I had bought for my CoCo. If anyone is familiar with the OS-9 program, TelStar, it works similar. I have these wierd characters that precede dis- plays such as these forum messages. There is a total of 10. I do not know how to replicate a "right arrow" so I will use this <-. These are the char- acters: <-[1;1H<-[2H I have gone into "Using Delphi" and cannot find any- thing that would help me there. The only thing that I can think of is term- inal emmulation. I cannot figure out how to change it in this program. Any help will be most appreciated. See ya. LONG LIVE OS-9! ** In whatever form it is in! -= 01GEN40 =- -*- 90959 12-DEC 18:05 General Information RE: Downed Hard Drive! :-( (Re: Msg 90958) From: MIKE_GUZZI To: 01GEN40 (NR) those weird characters are ansi escape codes, telstar doesn't understand them you have to go to your profile settings and disable ansi -*- End of Thread. -*- 90962 13-DEC 00:12 General Information OS-9 Late Night Schedual From: THETAURUS To: ALL OS-9 Late Night Conference Schedual For December AND January Date Time(EST) Topic ------------------------------------------------------------- December 5, 1994 10:00 PM Open Forum December 12, 1994 10:00 PM Open Forum December 19, 1994 10:00 PM OS-9: The Year in Review What exactly was accomplished in '94 and what can we improve on? With CD-I hitting the mainstream with good success and Personal OS-9 Software starting to come of age, it gives us plenty to talk about! December 26, 1994 10:00 PM Open Forum January 2, 1994 10:00 PM OS-9 in '95! What lies ahead for OS-9 and the OS-9 User's Group in the Coming year? January 9, 1994 10:00 PM Open Forum January 16, 1994 10:00 PM Countdown to Chicago! Come join members of the Glennside Color Computer Club as we discuss the upcoming Chicago Cocofest, which takes place on April 29,30 1994! January 23, 1994 10:00 PM Open Forum January 30, 1994 10:00 PM Open Forum >Chris< -*- 90965 13-DEC 17:07 General Information RE: RiBBS/FidoNet Message Formats (Re: Msg 90932) From: GREGL To: DGANTZ (NR) That number could be a checksum of sorts, but it appears to have been aded y e mailer and may not be required. As I stated previously, if the header line isn't documented, it is either optional and has been added by the mailer or you need better (more up-to-date) documentation. As a guess, I'd say that line is probably optional so you can probably ignore it. In fact, I'd say everything following the subject up to the body of the message is optional and is probably treated by the board as part of the body. One question, though. Are you using RiBBS or Fido documentation? -- Greg -*- 90972 14-DEC 03:34 Tutorials & Education Termcap Programming From: JOELHEGBERG To: ALL In my 68'Micros column for the next couple months, I'll be tackling Termcap programming in detail and giving some routines to make life with Termcap a bit easier. A few people mentioned a live online conference would be beneficial, and help complement the columns. So, on Tuesday, December 20th at 10pm Eastern, I will be giving the live, online version of my column for those interested. I love the live online format since it offers great feedback through questions and the participants seem to learn a lot from live conferences. Looking forward to seeing all those interested! Sincerely, Joel Mathew Hegberg -*- FORUM>Reply, Add, Read, "?" or Exit>