Newsgroups: comp.sys.apple2 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!unlinfo.unl.edu!hoss!greg From: greg@hoss.unl.edu (Life...) Subject: Re: Lets sum up! (was: Apple II BBS discussion) Message-ID: <1991Jun8.194653.18316@unlinfo.unl.edu> Sender: news@unlinfo.unl.edu Nntp-Posting-Host: hoss.unl.edu Organization: GBBS/ACOS Sysop Support References: <1991Jun8.035310.7362@clark.edu> Date: Sat, 8 Jun 1991 19:46:53 GMT Lines: 237 apollo@pro-hindugods.cts.com (Amrit Chauhan) writes: >greg@hoss.unl.edu (Greg ????) writes: >>apollo@pro-hindugods.cts.com (Amrit Chauhan) writes: >>So we have come to the law of opinions. What one runs is what is best for >>that person. No-one is suggesting anyone should change. We're just >>appraising the differences between the systems, so that a person so >>informed would be able to make the choice that is right for them when >>buying a new system. >I think that it's pretty inevitable that people will take things to heart >here. Yeah, we have our opinions, but it's human nature to REALLY stick by >them and a little opinion like that doesn't hurt. We all know that we're >only defending aspects of each system. A little interjecting opinion is ok. >>However AppleSoft becomes very cumbersome and difficult to navigate as the >>program's size increases. Numbers become numbers, instead of pointers to >>important routines. >AppleSoft is not the BEST programming module on the market. It's got its >difficult points, but it doesn't have ANY bugs. I must say here that even Apple has admitted that there are some bugs in AppleSoft. One of them I believe is the handling of the ON NOCAR GOTO and RESUME commands. They are documented. I believe they are repeated for compatibility reasons. >ACOS does have bugs. That's >a bit of a setback for it. Yes, ACOS makes adding MOD's easy and fixing >programs much easier than in AppleSoft BASIC. If ACOS gets out its bugs >(like in future updates) it will be a very capable program editor. Every large program has its bugs. It is just whether or not you can find them. Some bugs are completely dormant, because due to changes in the code they are no-longer in the instruction chain. Arcade games sometimes have bugs, simply because the programmer couldn't get to the levels where the bugs manifest themselves. Too bad Lance needs the remote sysop to track down a bug so that it is reproducable before he'll try to fix it. He won't bother trying to duplicate the system on another. >However, >although MD-BASIC can be run only on an Apple //gs, let's not forget how >powerful it is. If, in fact, you have an Apple //gs, and you want to >seriously rework ProLine, then buying MD-BASIC would not be a horrible idea. >You don't have to use for ProLine ONLY mods...there are those that buy it for >their own programming needs. Yes. From what I've been able to get out of the manual, it is a rather good programming language. As it is now, I might as well have a //e, since I don't have a good setup to look at the language as it runs. >Have we done any comparisons between MD-BASIC >and ACOS yet? Put aside the fact that it can only be run on an Apple //gs, >and let's look at both program editors. We're all aware that it can only run >on an Apple //gs. That's unfortunate, but all the same, a reality. Which is why I recommend to Morgan to work on a ProDOS 8 version of MD-BASIC. Why should the IIgs users have all the fun? :-) >One other thing. NO program in ProLine needs to be rewritten. Unfortunately I find the need to get it to run under 2 800K volumes (one /RAM5). That involves a rewrite of some routines. >If you wanted >to write your own additions to ProLine, ok. If you wanted to add a little >MOD to this little program, then that's great too. But no one ever, EVER has >rewritten a program from scratch. There's no need to. Certainly not. My system isn't a complete rewrite of GBBS "Pro". It is a large amount of modifications and enhancements. However through the course of time the amount of unedited GBBS "Pro" code has reduced. It is possible that eventually it could vanish. This does take time. >>Already have [MD-BASIC]. However it does add to the cost. A time delay >>doesn't decrease the cost. >It doesn't >have to add to the cost of ProLine. MD-BASIC is not a ProLine only program >editor. You can buy it for other programming needs as well. True, MD-BASIC stands well on its own. However ProLine stands much better with MD-BASIC. >>>If you want to make a few MOD's, >>>then just use AppleSoft. >>MODs, or additions? There is a difference. >Both. Looking back, "a few" mods would be possible. Would splitting the root directory fit that? Perhaps the word "minor" would be appropriate in there somewhere. We'll leave file xfer out of the discussion. Thinking about it more carefully, the stock systems may be about equal in this regard. >>>GBBS's message base really >>>SUCKS. ... >>> ProLine has an EXCELLENT message base...GBBS doesn't even have a >>>competitive one. IT REALLY SUCKS for messages. >>Give some reasons. >Ok..I'm being a bit obnoxious here. Sorry. 1) ProLine has GREAT networking >capabilities (regardless of if you WANT them or not). 2) Both GBBS and >ProLine can have message bases in separate partitions. 3) ProLine message >bases can also be put into an 800K disk. 4) GBBS has bugs in the message >base, to my understanding. The only bit I can disagree with is the last point. The "bug" I am familiar with is if a message base is configured with the wrong capacity for the number of messages. For n messages, one needs to tell it to create a file capable of storing (4*n)K. The CONFIG program doesn't properly default to that, and so when the K limit is reached, messages get trashed depending on their proximity to the storage bitmap. >I, PERSONALLY, don't like ANSI, or >animation unless I'm playing an on-line game. Then, I'm prepared for the >slow screen updates, and I don't mind because if the game is good, I'm having >fun. As far as message bases go, I agree that graphics don't belong there. >Games, as you stated, are a GREAT place for color graphics. ProLine does NOT >have this option. Here we are in agreement, more or less. However, a graphics "movie theatre" is a nice place for those who are creative enough to make nice movies to put them, so as to prevent emulation crosstalk when reading messages (since the graphics have been relocated). (Real fun when you receive a PSE ^N for normal text when in a VT-100 emulation, where it will put you into a graphics mode, where lowercase letters are redefined.) I use extensions on the subject lines to indicate graphic messages, and if the extention does not match the emulation, a warning message is printed with the ability to skip the message. However I have not fully implemented this due to the allergic reaction an older version of ACOS had to some 8th-bit ASCII, causing random holes to be created in .S and .G files. I had to salvage what I could and reconfigure. I'm still hesitant to attempt it again, even with the new ACOS. It felt like when I discovered my drive was nuking key blocks on my disks, like block 2. Required total interior replacement. Anyway, I'm digressing... >>>Can GBBS do something useful >>>with special effects?...like maybe a full screen text editor? >>Definitely. Such a thing already exists. However I don't use it. I have >>other modifications that are more important to me right now. >The full-screen text editor available on ProLine is a GREAT option. It makes >things easier to edit, and I'm using it right now to add this message. It >has it's SMALL downturns but it works well. I like it. The reason I don't use the ACOS full-screen editor is that it isn't just a text editor, but also a graphics editor. Since it is designed for ProTERM Special Emulation, it will allow inclusion of graphics where others couldn't, due to their generic nature. This make them more useful for more users, but limits what unique things each user could do, if it was designed specifically for them. This is both an advantage and a disadvantage for both. It depends on the sysop's feelings on the subject whether or not it is desireable. For myself, it gives me less control on filtering out emulations for those who don't have them. >>What happened to your manual? >For the Ampersand commands...I don't have the manual. Ah, I understand. (THAT'S what that 4th registration card was for! Thanks for jogging my memory.) >>>2) have about 4 to 5 times as many network bridges >>>than GBBS. >>Networking is not the sole reason to run a BBS. If every BBS was >>networked, you'd effectively have only one BBS. >Fine. We understand that networking is not the only reason to run a BBS. >But, like you said, we're only offering comparisions between the two systems. >ProLine has a better networking system than GBBS and just because you don't >want to network doesn't invalidate that point. If you want to network, then >ProLine is better than GBBS in this aspect. Agreed. >Now, what can ACOS do that MD-BASIC can't and >vise-versa? It can be used online. You can load up a segment, edit it, save it, then run it. It is automatically compiled and run at that time. You can code AppleSoft online with ProLine, but you can't with MD-BASIC. Shell scripts are a nice compromise, but still not full coding ability. Vice-versa, MD-BASIC is a good tool for creating programs. You can create programs which can execute by themselves, without the need of an underlying system like ACOS. Plus, you can use your favorite BASIC -> ML compiler on the resulting code to make it run even faster. No such tools exist to make ACOS files into ML files... at least, none that I know of. Then again, ACOS was designed to be used as a language for communications -- it is part of the name. MD-BASIC was just applied to that field, not designed for it. That is the root of the conflict. They were designed for different purposes. Even if I never run ProLine, I would still use MD-BASIC (as soon as I get at least a second 3.5" drive :-). >God...it's tough to include your signature :) How are the attributes this >time? I think I got it. Signatures are usually edited down to just what is needed. For mine, you'd only include the last line, since that is the only important information in it. However one only includes the previous poster's signature, not any of those previous. The reduction is shown in the editing I made of yours: >Amrit >ProLine:apollo@pro-hindugods | Internet:apollo@pro-hindugods.cts.com | >UUCP: crash!pro-hindugods!apollo | ARPA: crash!pro-hindugods!apollo@nosc.mil | But, one can do without the previous poster's signature altogether. I include only the alternate email paths available. The best way to think of inclusion is the taking of the message being replied to, adding a > at the beginning of every [non-blank] line, adding an attributation at the beginning in standard form, and then editing. Everything else is up to the human in the editor, and whether the system is configured to add a signature at the end. -- /// ____ \\\ "The major problem--one of the major problems, for there are | |/ / \ \| | several--one of the many major problems with governing \\_|\____/|_// people is of whom you get to do it, or more to the greg \_\\\/ hoss.unl.edu point, who gets people to let them do it to them."