LLUCE vs. METAL: A losing battle
Greg Boehnlein
I picked this up this morning off the FutureNet. This is directed to those of
you that sent me E-mail saying that LLUCE was going to make METAL look like
a childs toy. I'm afraid that METAL STILL has the advantage and it's so large
that it is NOT even funny. I too, have seen the LLUCE demo and I must say. I am
NOT impressed in the least bit. It isn't even a Logical next step fro ACOS!
-------------------------------------------------------------------------------
Number : 64 of 64 [ METAL Questions ]
Subject : Lluce van Pelt (sorry)
Addressed to : All
Author : The Captain at The Captain's Quarters (#1@#3)
Date Posted : Sunday, January 17th, 1993 02:47:12 EST
-------------------------------------------------------------------------------
I managed to locate a copy of the "LLUCE.DEMO" that has been on some BBS's. By
doing nothing more than reading the "LLUCE.REF" file, it looks exactly (and
reads 95%) like the orignal docs for Acos 1.3!!!! (yep, it does, word for
word... ye'ol search-and-replace coming into effect).
Things Lance has copied from the Metal concept:
EXIT to a prodos program (which Metal calls QUIT or QUIT TO)
ANSI ON/OFF lets some (not all) of the program code do Ansi output. Metal
lets you re-map ALL ptse (no matter where it comes from - program, post,
or whatever) into ANY emulation you desire (ansi, vt100, Pascal, etc)
CLS dumps a control-L. Whoopie. We've had this forever. It's called CLEAR VID
or PRINT CLEAR
DISK LOCK/UNLOCK basically kicks AppleTalk offline. Gesh! Metal LIKES
AppleTalk. It was written to be HAPPY with AppleTalk.
EXIST tells you if a file is there or not. Metal lets you use FILEINFO$ which
not only tells you if a file is there or not, but it tells you the type,
how big it is, when it was created, when it was modified, if it has a
resource fork, etc. In other words, just like a Catalog line.
FLASH some weird screen saver for the GS. Shifts colors when a clock times
out. Like I said, weird (and worthless - give us a REAL screen saver)
FMTDATE$ returns the current date in "formatted" output. Let the BBS do this
so that sysops can customize it!
GOTOXY Metal uses PRINT AT(X,Y), which is automaticly (and transparent to the
program and the user) converted to the correct emulation codes. LLUCE
looks like it only know ANSI and TTY. Bummer.
HOME Puts the cursor at the top of the screen. We do a PRINT control-X. And
again, we support all, not just Ansi.
INVERSE Ansi inverse. Why not PTSE?
LOWER$ Converts to all lower case. Metal can go lo, high, flip, and even do
a "name shift" by changing "tc wilson, the captain" to "Tc Wilson, The
Captain".
LTRIM$ removes leading spaces (flush-left). This one is a fresh one, but how
many times are you going to use this?
MIXED$ well, he ripped this one off of Metal, pure and simple. This is our
CNGCASE$ mixed-case mode.
NODE one really useless command. Just returns a constant value (this was in
Acos 1.4 beta that got floated around)
NORMAL <sigh> ansi again...
OVERLAY load an external ml program. Yes, he is allowing 8k modules. Metal
allows 24k, plus you can even "segment" your modules out to make them
larger.
RTRIM$ kills all trailing spaces. Again, how often is this needed?
UPPER$ ripped it from us again!
LLUCE finally expanded out those nasty RAM-spaces to four (4) areas of 256
bytes each. This give LLUCE 1k of ram space.
Metal has always had flexable and dynamic ram allocation from a 20k memory
chunk. This means you can have 4 or 40 areas, or one that is 20k long
(FutureVision regerually uses an 8k chunk for network routing).
LLUCE still has 20k segment limits with 20k-segmentlen for the memory.
GEEESH!
Metal has a 16MEG segment limit with 26K of variable memory that can be
shifted out to a huge 512K variable memory.
LLUCE has a 4k editor, with only a line-editor built in.
Metal's editor use whatever variable memory you have left; this means you can
have from 26k to 64K of editor space. (Consider that ProTerm has 45k of editor
space). Metal also has both a line and a full-screen editor (guess which one
gets used the most?)
LLUCE can only manipulate one MSG file at a time, and his MSG files are
limited to text only, and are prone to corruption and "super growth".
Metal can manipulate up to -four- MSG files at once, we can handle both text
and binary (even in the same message record), and are not subject to
corruption and growth.
LLUCE only knows his externals by name, and only knows of one way to call
them.
Metal supports THREE types of externals: package units, names, and shell. And
these guys know how to call each other and pass control to each other.
Metal allows aliasing shell commands to something else. For example, type
"FIG" and Metal will find out that you meant "EDIT +F 0/METAL.CONFIG", which
means "edit, using the fullscreen editor, the metal.config file"
LLUCE uses 128k and only gives you 20k of program space, 20k-programlen
variable space, 1k of ram space, 8k externals, and 4k of editor space?
GET REAL!
Metal uses 128k and gives you 16megs of program space, 26k to 512k of variable
space, 20k of ram space, 24k+ externals, and 20k to 64k of editor space.
Want more?
Okay, LLUCE uses 24-bit math, with 4-char variable names.
Gee. That sounds familar.
Metal has had 24-bit math and 4-char names and 31-char labels and multi-file
sources and procedures and long-ifs and whiles and do's and pops and pushes
and var stacking and local vars and local labels and running programs as
subroutines and irq-managed modem drivers and flashing and beeping chat pages
in the background (even during a file xfer) and... well.
You get the picture.
I'm not even going to TRY to compare FV4.0 to GBBS. Let alone 5.0 to GBBS.
It's like comparing a F-15 to a Sopwith Camel.
Both will get you there; the F15 will get you there a LOT faster, with a LOT
more style!!
Tc Wilson/The Captain \ / Wilson Wares
\/\/ / Po Box 12203
FutureNet: #1@#3 -or- #1@TCQ \/\/ Columbus, Ohio 43212
It is only people of small moral stature who have to stand on their
dignity.
-------------------------------------------------------------------------------
Steven H. Lichter
From Lance Taylor-Warren
Picked up from Ogg-Net
All I'll say about the message that was posted picking on LLUCE is this...
1) Neither Andy nor I have seen METAL (from sysops side or from a users side).
2) The only thing that 'The Captian' has done is to reopen the possibility of
a slander suit. Anyone that' have to hide behind an alias will get no
respect from me.
3) LLUCE has been over 5 years in development and it's market is NOT the end
users. It's education. The fact that there is even a version of it for
use by the general public is because of my commitment to the people that
have bought GBBS in the past.
4 Face it,LLUCE and METAL are after two different markets. I'm after
legimtimate business.
Lance
What I don't understand is why all the ACOS bashing. None of us have
done this to Metal, infact I have thought it was a pretty good program
but have found no reason to switch from what I have been using. Also
I'm one of the Ogg-Net SysOps that has been pushing for a Gateway
between the 2 networking systems, but the statement made will kill
this idea since Lance will be joining the net.
Also one of out net SysOps went to answer The Captains post on is own
board in feedback and half way through his message he got a +++ATH0,
Duncan said it must have been line noise!!!!
.
*******************************************************************************
| -=- Sysop: Apple Elite II -=- an Ogg-Net BBS |
| (909) 359-5338 12/24/96/14.4 V32/V42bis |
| Internet co...@cleveland.Freenet.Edu (Steven H. Lichter) |
*******************************************************************************
Greg Boehnlein
In article <1jidil...@usenet.INS.CWRU.Edu> you write:
>
>What I don't understand is why all the ACO bashing
I can't speak for anyone else, but my "ACOS Bashing" comes from the utter
lack of support that L& has given the product. It was plain and simple. The
language did what it was originally designed to do and that is where it ended.
It never evolved to anything that I deemed worthwhile and I none of the
Proposed features ever arose.
Bashing is, in reality, NOT that prolific on the FutureNt. In fact, we carry
two conferences dedicated to the support of ACOS. And they see a lot of action.
One is for programming, and the other is for questions. Both of which are
hosted by my site.
>None of us have done this to Metal infact I have hnought it was a pretty
>good program but have found no reason to switch from what I have been using.
LEAST 1 dimensional array support. ACOS just didn't offer me anything that I
was happp writing. Personally, I think the BBS software SEVERLY needs to be
updated.
>Also I'm one of the Ogg-Net SysOps that has been pushing for a Gateway
>between the 2 networking systems, but the statement made will kill
>this idea since Lance will be joining the net.
writing a "Networking Toolbox" that will facilitate EASY connections from
basically -ANY- network. I -WAS- working with actual code to -HANDLE- the
Team-Net. But, I got a HECK of a lot of flack from both Sysops and users.
And when I considered the fact that FutureNet has more than both Ogg net and
Team net -COMBINED-, plus the fact that I was doing this to better connect the
Apple II community, wrtning -BOTH- ACOS and METAL code, it turned out to NOT
be worth it in the long run. Cmon, I dedicate my time to a project that I feel
will benefit all and I get pissed on for it? Screw that. I that is the way
that everyone is goig to treat each other fine. But the II family is slowly
going down the tubes due to these attitudes.
Ogg-Net and Team Net sysops as WELL as FutureNet sysops ought to get off each
others backs and just think about the bigger picture.
If Ogg-Net and Team-Net were to link up with FutureNet, they would -HAVE- to
do a HECK of a lot of upgrading VERY fast. But, with that added upgrade time
would come the benefits of what the 5.0 Networking software will provide.
Mainly, full domain style addressing with OUR OWN Internet domain. Doubt me?
Give me an address, and I'll send you code to prove it.
The great thing about the new FV software is that it was DESIGNED with
expansion in mind. We -ALREADY- have the code done t d it. It's now a matter
of -WHO- wants to get involved. Our networking platform is one of the most
advancedon -ANY- Apple II networking systm and I will bank money on it.
It supports MLTIPLE networks and will INTELLIGENTLY route mail between all
of them based on the LCM (Least Cost Method). The FV 5.0 software adhers to the
ISO 7 layer standard, and as such is RIGHT there waiting to be connected to
any systems that are interested in it.
Off on a tangent for a whiea, but here is the final word.
ACOS is static and hasn't chang d.
LLUCE is fresh and hasn't been proved.
METAL is stable and has prved itself.
-BOTH- authors think their product is better than the others. -BOTH- authors
are competing with each Other. -BOTH- are strong headed.
This is good! Competition gets the blood flowing and creates a better product
for the end user.
Just look at the SonicTracker vs. ModZap debate. As a result, we have not one,
but -TWO- superior products.
Steven H. Lichter
Keep it up and let me know what is up. Lance is supporting GBBS much
better now as well as really working on LLUCE. I wish all the II
people would work together since we are the only ones that can keep
the support.
Anyone wishing communicate with Lance can contact any Ogg-Net System
and leave Net E-mail to hime on Apple Elite II or he can also be reached
on this and on the Fido Apple2 conference which he carries. He will reply
unless it is just trash or bashing which I can agree with him on that. I
have ran GBBS since 1987 and have looked at MACOS, and Metal and I think
both of them had good and bad points just as GBBS/ACOS does. Don'y
judge LLUCE on the Demo or what you have heard, it is a lot different and
ment for a multi-User system.
.
9) 359-533912/24/96/14.4 |}
ernet co...@cleveland.Freenet.Edu (Steven H. Lic |}
*************************************************************************
*************************************************************************
Sysop: Apple Elite II -=- an O|}
909) 359-533912/24/96/14.|}
nternet co...@cleveland.Freenet.Edu (Steven H. Li|}
**************************************************************************
Greg Boehnlein
>
>Anyone wishing communicate with Lance can contact any Ogg-Net System
>and leave Net E-mail to hime on Apple Elite II or he can also be reached
>on this and on the Fido Apple2 conference which he carries. He will reply
>unless it is just trash or bashing which I can agree with him on that. I
>have ran GBBS since 1987 and have looked at MACOS, and Metal and I think
>both of them had good and bad points just as GBBS/ACOS does. Don'y
>judge LLUCE on the Demo or what you have heard, it is a lot different and
>ment for a multi-User system.
As in more than one user simultaneously? Or many users using the system at
different time.
Are we to assume that Lance has figured out a way to use Two serial cards
and have TWO copies of LLUCE running at the same time on a 128K IIE? And that
he has figured out a FileSharing method for ProDos 8 based files? I don't think
so.
Be careful about what you say. Multi-User implies simultaneous use, and the
only system that -I- know of that is capable of handling something of this
nature is under GNO.
But, yes, I plan on keeping up the work. As I stated to you in E-mail, I will
be sending out, over the Net, the FutureNet RFC as soon as Josh gets me the
update. I'm calling it an RFC cause that is basically the type of information
that it contains.
Let me just say, that the ACOS based Networks can learn a lot from how the
FutureNet operates. A lot. Flame me as you must, but FutureNet is, without
any doubts, THE single most sophisticated, powerful, yet easy to use
networking platforms available on the Apple II series. Josh has done an
absolutely marvelous job with the FV 5.0 implementation of it.
I think, once I post the information files, that this will be quite apparent
to all. .
Steven H. Lichter
It is my understanding that it will be Multi-Line.
I don't want to flame anyone.
Steven H. Lichter
Apple Elite II
909-359-5338
Via CACOL PCP
Greg Berigan
> Let me just say, that the ACOS based Networks can learn a lot from how the
> FutureNet operates. A lot. Flame me as you must, but FutureNet is, without
> any doubts, THE single most sophisticated, powerful, yet easy to use
> networking platforms available on the Apple II series. Josh has done an
> absolutely marvelous job with the FV 5.0 implementation of it.
Oh great, FV 5.0. Looks like another LD call is in order. Say, has
there been a change in the code that allows users to disable hot keys
yet? I'm getting tired of recoding the whole system to use bit(57) as a
hot-key flag every time there is an upgrade.
Excuse me while I dream of a non-anonymous FTP site from which I could
grab upgrades. Customized FTP to include the owner-stamping of course.
And pardon how this message turns out. I'm still learning this thing,
while looking for a machine that has a configurable nn interface.
ber...@platte.unk.edu
joshua m. thompson
>Oh great, FV 5.0. Looks like another LD call is in order. Say, has there
>been a change in the code that allows users to disable hot keys yet? I'm
>getting tired of recoding the whole system to use bit(57) as a hot-key flag
>every time there is an upgrade.
working on it constantly for 3-4 years and it's now freeware, I would think
someone would have SOMETHING nice to say here (you don't even have to like it,
just say something nice). Ask Greg how close I am to trashing everything.
_I_ have not released an update to FV in about a year. As to what Mr. Wilson
does I can't attest since I don't do this ridculous updates.
There will be disable-able hotkeys in 5.0 if I finish it.
Greg Boehnlein
+---------------
> da...@ullman.cba.csuohio.edu (Greg Boehnlein) writes:
>
> > Let me just say, that the ACOS based Networks can learn a lot from how the
> > FutureNet operates. A lot. Flame me as you must, but FutureNet is, without
> > any doubts, THE single most sophisticated, powerful, yet easy to use
> > networking platforms available on the Apple II series. Josh has done an
> > absolutely marvelous job with the FV 5.0 implementation of it.
>
> Oh great, FV 5.0. Looks like another LD call is in order. Say, has
> there been a change in the code that allows users to disable hot keys
> yet? I'm getting tired of recoding the whole system to use bit(57) as a
> hot-key flag every time there is an upgrade.
I don't know. Haven't looked into that. I am writing the E-mail gateway for
Internet. It's a chore and a half making sure that we can parse according to
the RFC-822 standards. Lexical analysis under METAL! :) Now THAT is kinda cool
really. :) I'm adding support for folded header lines, multiple destination
addresses and everything else that I can comprehend from the RFC.
FutureNet will be 100% addressable from Internet. And, other non-futurenet
networks will be supported as well. This means that anyone that wants to take
the time to convert between our mail format and theirs can have Internet
E-mail services free of charge.
Back to your question. I'm not sure, but Josh is. Josh, can you answer this
one? :)
> Excuse me while I dream of a non-anonymous FTP site from which I could
> grab upgrades. Customized FTP to include the owner-stamping of course.
I don't think METAL will be on an FTP site, but I have thought about starting
a FutureVision FTP site that will contain the entire FV source code etc..
Also, we could have the "Upgrades" directory where we could place all of our
K00l Rad Modz man...(NOT!)
> And pardon how this message turns out. I'm still learning this thing,
> while looking for a machine that has a configurable nn interface.
Welp, I WAS waiting for Josh to get me the updated FutureNet docs, but I'm
going to go ahead and post them anyways. Next few posts...Check 'em out! :)
Roy Barrett
like hotkeys. There aren't very many Future Vision updates, except the updates
that Tc Wilson updates without informing the author of FV, Josh Thompson. The
Tc Wilson updates, FV v3.2tc, v4.0d9b, v4.0d9c, v4.0d9c tuneup, and v4.0d9d are
versions that were distributed falsely, and technically, are invalid versions.
Future Vision v5.0, if finished, will possibly, and probably be bug-free, and
not sold through the old call-TCQ-and-Download method. FV5 should be included
in a normal package, and available through the normal mail-order channels.
Future Vision 5 will sport many new features, with InterNet Mail support,
Usenet support, a new intuitive interface with many new enhanced visual
modifications, a Unix-like "expert" user shell, an enhanced transfer system
with all of Metal's protocols.
Metal v1.09.00 (9 is the major version number, so you could assume that 9.0
would be the effective version) has many more enhancements, such as new
transfer module displays, such as ProTERM 3, a new enhanced fullscreen editor,
scrollback (introduced in 1.07.00, for those who haven't seen Metal since then)
a Metal-Shell Unix-like interface (since 1.04.00) with Unix-like commands, plus
a new ROT-13 decoder, an unbinscii command, a unshar command, and many, many
more.
There are people like this Greg Berigan who do not appreciate software written
for the Apple II that has been in development since 1988 for Acos, then Macos,
and now, Metal. Josh Thompson COULD be working on software for the Mac.
and losers like this Greg Berigan could go on and push the whole II industry
into the Mac World. Don't you just wish that lots of the last-generation
Apple II supporters like Procyon and Dreamworld (Steve and Jawaid, nothing
in there is actually meant towards you.. :) went to the Mac Industry? Hell,
what about these companies like Sierra, Broderbund, Apple <grin>, Microsoft,
and thousands of other Fortune 500 companies that _used_ to create II software
that now creates Microsoft Windows, and other million-dollar making software
packages. Metal/FV is only $95 currently, and free upgrades are available.
I'm sure if enough people wanted, and everyone told Jawaid Bazyar that his
programs sucked, and if he had a Macintosh to develop on, he would probably
do so. Developers aren't in just for "fun"... they also want a LITTLE
incentive. Josh Thompson has gotten NO incentive, except for the verbal
praise he recieves from his beta-testers, and other FutureNet sysops. Josh
Thompson has brought a software package into the open channel, and has started
a 45-node network. Once (and IF) FV5 is released, people will pick FV over
ProLine, since for one, it's a lot cheaper than ProLine, and cheaper than
EBBS and ModemWorks. ProLine by Morgan Davis and EBBS by Joey Schober and
Scott Sidley are the only BBS programs at the moment that support InterNet
Mail and Usenet -- Until FV5, they will be the only ones.
Get your copy of Metal/FV now, because after 4.0d9d, FV5 may even be sold as
a seperate product. If you want your copy, rush to it.. :)
Roy Barrett
(Where's my highly warlord-able signature? Dunno! :)
Ron Dippold
>I can't see how these people (Greg Berigan) bitches about a little
>technicality like hotkeys.
Because it's a pain in the ass to recode the software every time to
support something that should be in the software to begin with? It's
a legitimate complaint - you will notice he didn't claim it was a
piece of worthless crap, rather that he took the time to make the
mentioned changes, which would seem to imply that he felt the software
was worth something.
>There are people like this Greg Berigan who do not appreciate software written
>for the Apple II that has been in development since 1988 for Acos, then Macos,
Yeah, he doesn't appreciate it so much that he takes the time to
modify it for his use. I've always thought that a lot of Apple //
shareware authors should rerelease their products as whineware.
Understand your market.
--
Q: Do Jewish people dominate the field of comedy?
A: Don't be a schmuck.
-- Albert Brooks
Roy Barrett
: ds...@okcforum.osrhe.uoknor.edu (Roy Barrett) writes:
: >I can't see how these people (Greg Berigan) bitches about a little
: >technicality like hotkeys.
:
: Because it's a pain in the ass to recode the software every time to
: support something that should be in the software to begin with? It's
: a legitimate complaint - you will notice he didn't claim it was a
: piece of worthless crap, rather that he took the time to make the
: mentioned changes, which would seem to imply that he felt the software
: was worth something.
It's only a little change, changing a "get" to an "input"... nothing big
at all... As for you, remember the people like Ian Schmidt, who had a great
program, MODZap, and because people were whining and bitching, and not even
praising years worth of work, Ian won't release MODZap, or AudioZap 2.0.
Believe me, Ian's writing great software, I've seen it, but it won't ever
be released, because people bitch about them. Instead of saying "It's a
wonderful product! But there's one thing I'd like changed..." they're
saying "What a piece of shit, it won't even do this..."
It's up to you, would you rather run a PC that costs a few grand and gets
obsolete in a year, or use your GS, which may have cost you a few grand in
1986, but it won't get obsolete for years to come? When I was getting my
GS, the Mac Plus was right up against it. If I would have got that Mac,
I tell you, I'd kill myself today. I know someone who has sold one of his
GSes and bought a 486. All he uses it for now is to dial out and call his
local Unix site. People, I can do this on my Laser 128 that I picked up for
$100. You aren't appreciative. What if someone told Jawaid Bazyar that
GNO sucked because SwitchIt and GNO are currently incompatible? (Jawaid,
aren't I using you in a lot of these "situations"? :) If everyone that
owned GNO said that it sucked, and GNO wasn't worth a cent, I'm sure that
Jawaid and Tim may even get discouraged.
Just think of it this way. If the "People" gave up on Ross Perot, would he
be our President? (Well, he's not president, but if everyone gave up on
Perot, he would probably gotten less that 1% of the vote. He quit, and lost
support, the bottom line, SUPPORT YOUR NEAREST APPLE II SUPPORTER.)
If you don't support the Apple II, why the hell do you expect for Apple to
continue supporting Apple as far as it does? Josh Thompson, author of FV,
at this moment, is out doing MACINTOSH WORK. If people like this don't get
ANY VERBAL PRAISE, they will quit. For those that think that FV sucks, it
IS A GREAT PIECE OF WORK, even if you don't like it. And if you ever see
FV5, you'll see all the effort put into it.
It was a legitimate complaint, but it seems all that Apple II users do now
days is bitch. BE THANKFUL FOR WHAT YOU HAVE GOTTEN, AND YOU MAY JUST GET
MORE.
Roy Barrett
(Excuse my language, but I'm a _little_ mad.. :)
:
:
: >There are people like this Greg Berigan who do not appreciate software written
Brian Tao
>
> It's a legitimate complaint - you will notice he didn't claim it was a
> piece of worthless crap, rather that he took the time to make the
> mentioned changes, which would seem to imply that he felt the software
> was worth something.
Interesting point... if there was really something lacking in METAL,
I would think Greg Berigan would have used that as an example. But
since he complained about a rather minor "feature", my interpretation
would be that METAL overall is an excellent system with very little to
complain about.
--
== Real name: Brian Tao (Dept. of Exobiology, University of Toronto)
== Preferred: ta...@r-node.pci.on.ca (no mail over 15K please!!!)
== Free Plug: =MuGS 2.0=, the only """"""""""""""""""""""""""
== Internet mail reader for the Apple IIGS, coming soon!
Brian Tao
>
> It's up to you, would you rather run a PC that costs a few grand and gets
> obsolete in a year, or use your GS, which may have cost you a few grand in
> 1986, but it won't get obsolete for years to come?
Most of the GS was technically obsolete a couple of months after it
came out, but obviously it isn't functionally obsolete now, six years
later. Most people forget that distinction. That's why you see people
lining up to get 486 motherboards so they can call BBS's and type up
essays and reports at 32 MIPS...
Shane M Zatezalo
>The following revelation escaped Ron Dippold's lips:
>>
>> It's a legitimate complaint - you will notice he didn't claim it was a
>> piece of worthless crap, rather that he took the time to make the
>> mentioned changes, which would seem to imply that he felt the software
>> was worth something.
>
> Interesting point... if there was really something lacking in METAL,
>I would think Greg Berigan would have used that as an example. But
>since he complained about a rather minor "feature", my interpretation
>would be that METAL overall is an excellent system with very little to
>complain about.
Actually, wasn't he complaining about Futurevision and not Metal? (there's
a big difference there)
::::::::Apple II forever!!:::::::GO BUCKS!::::::::Play Lacrosse!!::::::::::
: Shane M. Zatezalo : i-net> szat...@magnus.acs.ohio-state.edu :
: CIS Eng Ohio State : NeXTMail> sh...@kiwi.swhs.ohio-state.edu :
:GS::: call T.A.P. a Futurenet BBS 614-297-7031 16.8k DS HST 425 MEGS ::GS:
Greg Berigan
> gber...@cybernet.cse.fau.edu (Greg Berigan) writes:
>
> >Oh great, FV 5.0. Looks like another LD call is in order. Say, has there
> >been a change in the code that allows users to disable hot keys yet? I'm
> >getting tired of recoding the whole system to use bit(57) as a hot-key flag
> >every time there is an upgrade.
>
> Gee, I'm so glad everyone is so appreciative of my work. Considering I've be
> someone would have SOMETHING nice to say here (you don't even have to like it
>
> _I_ have not released an update to FV in about a year. As to what Mr. Wilson
> does I can't attest since I don't do this ridculous updates.
>
> There will be disable-able hotkeys in 5.0 if I finish it.
Damn, I hate it when I write something and I fail to gauge the
temperature. I do like FV, it is just that every time METAL gets
upgraded, there is a new version of FV out, usually with changes to net
code which as yet I don't use. (Difficult to run as a net node with one
5.25", one 3.5" (800K), and just recently a 1600K RAMdisk -- before now I
had to cut out a lot.)
Last version I saw (to memory -- no disks to check where I am now) was
4.0dsomething. Downloaded in I think November. I had posted my mod on
Tc's system, but didn't see a reply (but I call infrequently). Included
ability to chain commands if I remember right.
I have other gripes with METAL, some minor, such as "M)oniter" instead of
"M)onitor" and "Loose all text" instead of "Lose all text" hardcoded in
the system, which would seem to be simple changes. Well, maybe all my
gripes with METAL are minor.
ber...@platte.unk.edu
Greg Boehnlein
+---------------
> Damn, I hate it when I write something and I fail to gauge the
> temperature. I do like FV, it is just that every time METAL gets
> upgraded, there is a new version of FV out, usually with changes to net
> code which as yet I don't use. (Difficult to run as a net node with one
> 5.25", one 3.5" (800K), and just recently a 1600K RAMdisk -- before now I
> had to cut out a lot.)
Like Josh stated before. HE has not upgraded FV in over a year. TC's mods to
FV over the course of the past few months are not even in the FV 5.0 betas
that we are working with. The FV4.0D9c release that TC posted with METAL[A
1.08 are not officially supported by Josh.
Once the FV 5.0 release (Which is FREEWARE, Roy, it is NOT going to be
commercially marketed.) is done and stable, the only thing that should be
coming out for it are Bug Fixes and Mods.
FV 5.0 is a cool upgrade. A LOT of work has gone into it and it shows. The
majority of the work that has been done to it revolves around the networking
code to make it MUCH easier to interface with Internet.
Thet Inernet E-mailer that I have written originally started out looking like
an MDSS release, but it has evolved into something a little bit more complex.
Not as complex as Umdss for ProLine, but more suited to what METAL needs.
(Thanks Morgan and Dave for the shell scripts. It has helped us tremendously!)
It is capable of parsing and routing 100 letters (4K-20K each) in a little
over 2 minutes. This is on completely first run, non-optimized code.
> Last version I saw (to memory -- no disks to check where I am now) was
> 4.0dsomething. Downloaded in I think November. I had posted my mod on
> Tc's system, but didn't see a reply (but I call infrequently). Included
> ability to chain commands if I remember right.
Again, TC does not handle FV updates. It's fine if people want to run his
modified FV (And it's not THAT modded, just some more Maintenance Utilites)
but I believe that anything after 4.0d9 was not officially supported by Josh
as he had already begun working on the FV 5.0 code.
> I have other gripes with METAL, some minor, such as "M)oniter" instead of
> "M)onitor" and "Loose all text" instead of "Lose all text" hardcoded in
> the system, which would seem to be simple changes. Well, maybe all my
> gripes with METAL are minor.
METAL Gripes should be addressed to TC.
BTW: METAL 1.09.00 is the next major, and last major release (For a while)
of METAL. It is a MAJOR upgrade, and from the BETA that I am running of
it it kicks.
1. Completely Re-Written transfer packgs. (Y-mod G now FULLY supported)
I was able to get 3700 CPS from aUnix site when transferring my mail
2. Modified and FASTER port drivers for all systems..IIE, IIC and IIGS
3. Faster compiler with new source code options.
4. Modified and MUCH better Full Screen and Line Editors.
5. A bunch of new shell commands (Copy, UUpaff etc...)
Aww...heck..you look..
About the Metal.Obj file - PRERELEASE
-------------------------------------
Version 1.09.00: (previously referred to as 1.08.01)
----------------
Upgrades over version 1.08.00:
Metal.OBJ:
o Added code to support optional "re-directed" compiled segments.
o Corrected problem with the Metal_SetAbort external hook (Y was not being
checked for the length of the string).
o Modifed the Metal_SetAbort to also exit if a null ($00) character is in
StringBuff (thus you can set Y to 255 and term the abort string in StringBuff
with $00)
o Modifed the Shell Command Line inside of Metal to set up the abort string
with space, control-C, control-X, and escape (was previously not setting
this, so it was hard to abort from a file view!)
o Added a external hook called "Metal_ConvTime", which will convert the value
given in xay from seconds to xay as hours/minutes/seconds. The revised
transfer externals use this routine to calculate the time to transfer.
o Added the reverse of Metal_ConvTime called, natch, Metal_TimeConv. Enter with
xay as h/m/s and converts it to total seconds. Again, the new xfer uses this
to calculate - but for throughput.
o Modifed the PADDLE(x) function to more closly resemble the Basic command and
to shift the GS's speed down in a more straight-line fashion (was previously
using my own code and was shifting the speed down weirdly). This has the
results of reading the same value no matter the speed of the GS, and on the
//e and Laser 128 with Zip chips, the result will more closely resemble the
value Basic system gives.
o Modifed the Trap Handler code so that it will reset the default device back
to zero; also, errors while locally online were screwing up. (by not doing
these, if an error hit with the default device set to non-zero, data could
be lost, or if locally, the trap would go to some random location).
o Modifed Trap Checker so that it will not check the traps if the default
device is non-zero (assumes using fast-file access). Again, to prevent data
loss and wrecking of the BBS.
o Added Scriptor command PAGEBACK=<yes/no on/off> so that //e systems can turn
this off (gives the system an additional 3.75k of variable space). GS sysops
will be wasting their time playing with turning this on and off.
o I finally took the time to let Merlin 16+ generate a cross-reference of all
the labels that Metal uses, so I was able to move some routines together and
shove some things down into the dp area to improve performance overall.
o Added a TRAP XFER <link> option - this lets you trap a "**rz^m" seqence so
that you can use the auto-start ability of Zmodem to let users upload to the
system. This routine is wired into the same routine that processes the ANSI
arrow keys, remapping them into control chars. This trap action will NOT
activitate if an external is in operation (thus if you try using Zmodem to
the FSED, the FSED will sneer at you).
o Added Metal_DecOut24 to allow displaying values from 0 to 16meg (full 24
bit, positive).
o Added Metal_DecOut24F to allow displaying values from 0 to 16meg, padding
the left side to spaces (thus "0" comes out " 0" - always 10 chars)
o Modifed the routines handling the "Get Next Byte" and "Find In Cache"
routines. The effect of this is that the GNB routine is now doing a bit more
code (but is faster), since I duplicated a jsr TraceRout into it. I also
modifed GNB so that it "knows" that 512-byte blocks are being loaded, so it
only calls "Find In Cache" (FIC) half as much (at the cross of block [512]
boundary, not page [256] boundary). FIC now also handles a problem I realized
was occuring: half of the time, it would load the same part of the CIB file
twice (like blocks $C6/$C7 and then blocks $C5/$C6). The newer routines
handle this problem, resulting in more code staying in memory longer, and
faster locating of program blocks.
o The overall effect of moving stuff to zero page and the GNB/FIC mods is that
you cannot get a direct, provable, quantifiable improvement (no hard numbers
can be gotten), but there is a HUMANLY-percivable improvement in speed.
o Modifed the routine that handles opening and loading/checking .I files not
to screw around so much. A little faster, a little slower, depending on your
mood.
o Added Metal_GetVer external call. This returns the version of Metal in XAY,
with Y=??.??.yy, A=??.aa.??, and X=xx.??.??; thus 1.08.01 will be Y=1, A=8,
and X=1 (these values are in DECIMAL, so that 1.03.96 would have y=96).
o Added Metal_SaveMem external call. This will store a section of the cache
memory off either into the VMH's area set up for this, or into 9/ if the VMH
doesn't have room. You pass this XA=address to save, Y=# of pages (blocks of
256).
o Added Metal_UnSaveMem to undo the above. No entry parms.
o Added Metal_LoadAdit (Load Additional). You pass this the filename to load in
FnameBuff (use SetFilename to build it), and XA=load address. Make sure to
save the memory off before you load over top of it!
o Modified the ReadByteRange to not clear out the block of memory before it's
loaded over top of; instead, it sees if ProDOS read less than what was
requested; if so, then it zeros the "missing" part (thus doing what ProDOS
doesn't and should be doing).
o Modifed ReadCRLine so that it doesn't wreck the whole INBUFF buffer all the
time; it only clears it if reading a directory, and will now only zero the
trailing char of the read line. Thus if 1 char was read. INBUFF+0 is the
char, and +1 will be $00.
o Moved some more code around.
o Added CURBLINKRATE=<x> to the Scriptor so that you can set how fast Metal
blinks its cursor. This also affects the display of the clock and how often
it checks for a key timeout. The system defaults into 6 (which is decent),
but you can set this from 1 to 127 (anything above 50 is useless, though).
o Modifed the "fast key" delay for speedy typers and etc to check 700 times
instead of 500 times. This helps in not loosing characters from the remote
user/ascii-send program.
o Changed "RingHelp running" to "RingHelp engaged", and changed "ringy dingy"
to just plain "ring".
o EDIT$(4) is now used as the "clipboard file" for the editors to save the
line/area to clip to. This is controlled by EDIT(11). Suggested value of this
is "$/CLIPBOARD"
o EDIT(9): if this is 1, then the Editors will allow the user to Load,
Import, or Attach a file (or files) directly to the editor space. NOTE,
however, that the Editors DO NOT check file access privs!
o EDIT(10): if this is 1, then the Editors will allow the user to Save As...
the current file, overriding the current setting of EDIT$(2).
o EDIT(11): if this is 1, then the Editors will allow the user to use the
Clipboard functions. Note that if EDIT$(4) is not set up, then this value is
overriden.
o EDIT(12): allow using of inverse text for FSED
o EDIT(13): allow using of ptse text for FSED
o NOTE: EDIT(9-16) are all set to ZERO on exit, to prevent screwups like the
users loading in the remote password file, your account, etc, etc. The shell
command EDIT auto-clears these out and sets them to 1 for Staff level.
o Modifed mult/div routines to be a little faster.
o Modifed internal String Stacking routines to use a VMH call for more speed
and to allow other programs to use them.
o Modifed the Trace and Error Display to use a de-token file (Metal.OBJ1).
o Moved the token table out into a file for the Trace/ErrorDisp/DeCompiler
to use. This saves 1.25k of memory for expansion, and is actually faster than
the other way (no more searching). POKEBYTE is now displayed as POKE due to
this.
o The Scriptor now has a command called "CHECKSUM", which is used to check the
files Metal.OBJ and Metal.OBJ1 files out. It will bomb with an error if
either one is corrupted.
o Moved the start of CIB memory down 512 bytes. Yippie.
o Modified the RUNSUB/RUNRETURN to save off the For-Next stacks. I take no
responsibility if you blow the variable that is being used in the For-Next!
o Modifed the way Metal handles result codes: it now can handle ALL of the
codes from 0 to 127 (if someone points out that above 127 is used, I'll eat a
bug). So some good comes from moving the tokens out of the main.
o Modifed the ADDTORESULTMAP script command. If the baud rate string ends with
a "+", then that baud will be considered "flow-controllable". (All rates
above 2400 are, by default and usage, flow-controlable). This means that you
can set a certain value to flowable; like 2400 (or set it to 4800 so that
Metal thinks it's 2400arq... but FV won't know that).
o If the baud rate in ADDTORESULTMAP is "NO", then Metal will think that that
number is a "no carrier" value and map it back as result #3 (Hayes Standard
NO CARRIER result code).
o If the baud rate in ADDTORESULTMAP is "BUSY", then Metal will map that back
to #7 (Hayes Standard BUSY result code).
o The reason for this is that some modems are not like mine (no kidding? duh)
and that by letting Metal map the data around for us, FV doesn't have to do
so much work.
o The Scriptor, by default, sets up the Standard Hayes return codes and most of
the USR and Supra return codes. However, your results may vary, so be sure to
check them yourselves!
o A bug that's been in here for a LONG time is that the WriteOutDev internal
routine was NOT quick-shifting the currently open file; it was always
resetting the output file to the current output file for each char (in other
words, it was doing the job, but slowly).
o Rot13 is now built into the system. This can be turned on/off by using
SYSCNTRL(10). This affects almost all output, even those from externals.
It even affects PRINTing and TCOPYing to a text file.
Metal.System
------------
o Removed the "FT" text at the bottom; changed to "Dedicated..."
o It's 1993.
o Fixed a problem with the routine that kills the heartbeat tasks; it wasn't
reseting (clearing) the enabled bits in the i/o page. So if you had
UltraBlank installed, it would still be running, and blow the system.
o Modified the part that loads the .OBJ file in so that in case some IRQ comes
down the pike it won't break the system.
Compiler v3.41:
---------------
o You can tell Metal to "re-direct" where it will save the compiled segment
off to. For example, if you wish to save the runtime code as "/ram5/test",
you would put AS THE FIRST OPERATION, the following:
.SAVEAS "/ram5/test"
You can save the file as ANY filename you wish. The system will save the
current object file with this filename in it so that the Metal system can
locate the new file.
If you try to issue .SAVEAS after a command, it will complain with an error
and then ignore you.
o Expanded the lead-in commands:
\I inverse (control-O)
\M mousetext (control-P)
\P plain (control-N) (aka normal)
\Ccr repeat c for r times (or rr or rrr times)
(control-R, c, asciicode 'r')
\Gx,y goto x,y (or xx or xxx or yy or yyy)
(control-^, asciicode 'x+32', asciicode 'y+32')
o Fixed a problem with the \C and \G escapes - they were eating the character
after the value.
o Added two dot-commands to let the compiler check for system versions:
.MINVER x.y.z
will check for minimum METAL version - for example, 1.8.1 or 1.07.93
.MINCOMP x.y
will check for minimum COMPILER version - for example, 3.41 or 3.03
o Modified the code to use the new _Save/UnSaveMem and LoadAdit.
o Bug in the .SAVEAS that would link the 2nd file back on itself (whoops!!!)
o The compiler now loads part of the file Metal.OBJ1 into memory. This is the
token table, so you need both!
o I had String Expressions in here before (~0 to ~9 for the EscLead, but they
weren't used that much). I took them out and replaced them with:
o Added Constant expressions. The way this works is that you have the command
.DEFSTR ~text~ = commands
The ~text~ is the Constant to use (like ~MaxLimit~). The commands is the
string to assign the the ~text~; thus you can have ~MaxLimit~ being 50 or
have ~Version~ as v3.17 - the text is played into the compiler as if it can
from the source, so you can even reference other Constant expressions!
ex: .DEFSTR~Dice~ = 5
The space MUST come after the equals sign!!
o Use these by refereing to them as ~text~ - x=~MaxLimit~ or print
"\~Version~". As you can see, the tilda is being used as the delimiter.
Any quote marks in the Constant command will be ignored when being used
during an EscLead expression.
Package #5 (file sending/downloading) v 2.10:
---------------------------------------------
o A ton of problems had cropped up with Ymodem and Zmodem, so the entire thing
is being re-written.
o Zmodem has been totally ripped out, and attempting to use that protocol will
result in a quick abort with error #-10 (unsupported protocol). Zmodem -AND-
Kermit will be put in at a later date. Hopefully before FV5.0 comes out, but
for right now, no.
o Like the new window? I sure do - it's pretty, and it tells me how long the
network is going to take or how long the user is going to be tying my system
up. (plus Tony started whining so much I just -had- to do it!)
o Yes, the drawing of the window is slower - got a problem with that?
o The Xmodem and Ymodem protocols now display the estimated time to download
and a continuial throughput display (this tells you how quickly your system
is being leech, Tony!). They also display how many bytes were succefully sent
along with percentage, etc.
o If Ymodem-Batch is being used with more than one file being sent, it will
display "x of y" over to the right of the filename. This is not display for
Xmodem or Ymodem with a single file (silly, anyways).
o YES, it looks a lot like ProTerm 3.0's window. But PT3 looks like Qmodem,
which looks like Zterm, which looks like Pro*Term, etc, etc.
o The two bottom lines are not finished yet, nor is the "Filename" display
at the top. These will be fleshed out as time goes by.
o Ymodem-G downloading now supports both hard flow control and soft flow
control. Ymodem-G will NOT work unless a connection >2400 is made; 2400 is
always assumed to be non-arq - I STRONGLY suggest re-mapping the 4800 result
code to 2400 arq.
o Re-wrote the routine that gets the Ymodem options from the reciver to more
closely follow what is supposed to work by the industry specs on the thing.
Hopefully, ProTerm is also following specs!
o Modifed the timing routine in above Ymodem options so that the timeout is
temp lowered to 1.5 seconds, which allows a graceful exit along with working
better with non-Apple systems such as a Unix box.
o The CPS display also shows the effictive baud rate ("xx% eff"). Simply the
given cps*10/baud.
o Modifed the routine that handles errors during a transfer so that it clears
out the incoming buffer (really cleans it - keeps clearing buffer and eating
chars until it times out waiting for one). This corrects 1/2 of the problem
with the protocols recovering from a line spike/phone pickup.
o Modifed the routine that steps up the block size so that it recovers
correctly. Was previously NEVER stepping the packet size up if it could. Now
does. Corrects the other 1/2 of the problem with recovering from a line spike
o Note: I will continue to tinker with this recovery routine until it is
optimum. Right now, it's a little, well, "loose", and I'd like something a
lot better.
o Modifed the timing routines (again) so that it's more "stretched out" than
it was before. Before, the timing was expressed in 1/180ths of a second;
now it is expressed in 1/120ths, as it was before.
o Modifed the routine that handles the NAK/ACK characters from the other end.
It was never timing out correctly (if at all).
o Modified the routines to handle Ymodem-G. Before, it would not always synch
up at the start of the xfer. Now it should correctly synch, and the
super-huge delay between packets has been removed for the most part.
o Modifed the Est Time display so that it continually updates - this lets me
see how much longer you are going to be tying my system up!
o Modifed small timing problems to work better. Now the protocols work very
nicely.
Package #3: Decompiler and/or Helper (depending on version of program)
----------------------------------------------------------------------
o Too much confusion on what is what, so package #3 has been removed - all it
does now is say "Not avail" and exits.
Gs.Port and Gs.Port.DSR
-----------------------
o Don't know if I told about it, but I pulled the thing that auto-sets the
CTSDELAY value; you must now explictly set this if you have to.
o Modifed the value being written to wr11 on the SSC chip - it turns out that
a value of $50 works with all flavors of chips (this info was the direct
result of a several-month-long discussion on InterNet about the screw ups
with chip suppliers for the GS and the Mac).
VMH.8, VMH.64, VMH.GS, VMH.GSX
------------------------------
o Modifed the ZeroStringArray (which the editors call) to NOT remove the def
for the string - this lowers overhead and stops continual memory compaction.
o Added a call "_VMH:RetFreeEd" which returns the number of free bytes avail
for the editor. For VMH.8 and VMH.64, this is the same as the free space
avail; for the .GS and .GSX, this is the free space in the string section;
for .GSXL, this is the free space in the one-dimensional string section.
o Added a call "_VMH:StackRst" - resets the String Stack.
o Added "_VMH:StackStr" - stacks the current string in StringBuff & GVarData+3
o Added "_VMH:UnStackStr" - undoes the last StackStr
o Added "_VMH:LastStackLen" - returns the last stacked string's length.
VMH.GSX
-------
o Problem in the ShuffleStringArray routine. Wasn't checking the correct value
of the starting array to move.
VMH.GSXL
--------
o The Extra-Large driver for those who REALLY want to fly.
o Sucks up 512k of memory - 8 banks total.
o It splits the arrays away from other variables and splits the arrays into
two seperate sets - 1 dim and 2 dim.
o Searching is faster due to this splitting (doesn't have to skip over a whole
mess of arrays to find ASTR$), and the search code is self-modifing to not
check the array value if it's not in use (in other words, only check arrays
if in an array bank).
o The routines that handle read/writing the string's data has been improved by
a whopping 50% - this only adds 15% to the total speed improvement, though.
o The String Stacker has an entire bank dedicated to it.
o This really improves system speed (the biggest bottleneck of the system is
the VMH driver, since there is no real effective way of searching for a
four-to-seven byte "string"). Try hitting "C" from Maint 2 to see just how
much faster this sucker is!
EDIT shell command version 1.01
-------------------------------
o Checks for Staff Level 3 or better to set the EDIT(9)-EDIT(16) values.
o Sets up EDIT$(4) to "$/CLIPBOARD" if not already set.
Line/FSED Editor - Packages #1 & #2
-----------------------------------
o Removed usage of EDIT$(4) as the "saving..." prompt.
o Loading of a file now checks if there is 1k or more room; if so, lets the
file load/continue to load.
o Loading also expands control-R (ptse repeat) seq's out. Eats other PTSE code
nicely.
o Saving now trims all but the first blank line.
o Saving trims all but the last blank line.
o Saving prevents more than 5 blank lines in a row.
o Editors are now "split" packages; .01B and .02B are used.
Line Editor - Package #1
------------------------
o Added control-N (no format) - does a left-justify and kills all double
spaces.
o Added control-P (full/Paragraph format) - adds extras spaces in.
FSED - Package #2
-----------------
o Control-C control-C (hit twice) will [NOT YET WORKING] do full justify.
o Control-L control-L (hit twice) will [NOT YET WORKING] kill justify.
BITEDIT shell command
---------------------
o Reassembled to use new address of CIBmemory.
ANSI map
--------
o Corrected the problems with some of the PTSE not mapping correctly; the
display is now working, but since Ansi won't process the "fat" arrow control
codes, we have to repeat the arrows a little bit.
o Fixed the problem with the inverse/normal display.
ROT13 shell command
-------------------
o This command performs a ROT13 across a text/src file.
o Usage: ROT13 filename
Brian Tao
>
> Actually, wasn't he complaining about Futurevision and not Metal? (there's
> a big difference there)
He was complaining about processing keypresses, which would seem to
be part of METAL rather than FV. I didn't read his message too closely
though. Ensuing discussion seems to be centered around FV.
--
== Real name: Brian Tao (Dept. of Exobiology, University of Toronto)
== Preferred: ta...@r-node.pci.on.ca -->>> No Mail Over 15K Please!
== Free Plug: This message was prepared with =MuGS 2.0=, the only
== offline Internet mail reader for the Apple IIGS!
Greg Berigan
> Ron Dippold (rdip...@qualcom.qualcomm.com) wrote:
> : ds...@okcforum.osrhe.uoknor.edu (Roy Barrett) writes:
> : >I can't see how these people (Greg Berigan) bitches about a little
> : >technicality like hotkeys.
> :
> : Because it's a pain in the ass to recode the software every time to
> : support something that should be in the software to begin with? It's
> : a legitimate complaint - you will notice he didn't claim it was a
> : piece of worthless crap, rather that he took the time to make the
> : mentioned changes, which would seem to imply that he felt the software
> : was worth something.
>
> It's only a little change, changing a "get" to an "input"... nothing big
> at all...
Well there is a bit more to it. To then prevent the name of the command
appearing messily on the line directly under the prompt, you have to
construct a LONG IF BIT(57), put in all the current IFs, but delete the
commands from their THEN clauses except for the PRINTs/?s, have another
copy of them after the END IF with the PRINTs/?s deleted... and doing
this for every section of code.
And then doing it for every one of TcW's releases...
So apologies for how the first message came out. I was mistaken on who
was releasing the multiple FV4.0 versions, and I can see why TcW wouldn't
make such a drastic change to the FV source.
ber...@platte.unk.edu
I'd mail a copy of my mods, but transfer facilities are severely lacking
here.
Greg Boehnlein
>The following revelation escaped Shane M Zatezalo's lips:
>>
>> Actually, wasn't he complaining about Futurevision and not Metal? (there's
>> a big difference there)
>
> He was complaining about processing keypresses, which would seem to
>be part of METAL rather than FV. I didn't read his message too closely
>though. Ensuing discussion seems to be centered around FV.
Actually, he was complaining about the abiliity to disable keywords. Keywords
aren't a part of METAL, they are a part of the FutureVision software.
Keywords allow you to directly hop between sections of the BBS without going
through long involved menus or command lines.
For example, if I want to get to the message bases from the games section, I
simply type in \MB and I will instantly be at the message base prompt. Kinda
like the way that you type 'go post' on Freenet to get to the mailer. :)
Actually, it's really kick butt to work with, because you can have it load in
external programs.
Like, on my system, if I am coding some segment of METAL, and I need to refer
to the over 300K of METAL and FV docs, I have a menu driven METAL program that
I call via...
\DOCS
This then loads the external program and allows me to view the docs I need
to see. When I am done, I can exit with a Q (for quit to main) or go to any
other portion of the system by simply entering the keyword.
In any case, Brian, he was not talking about the way that METAL handles input.
He was discussing how FV handles the use of keywords.
Roy Barrett
X <enter>, instead of just hitting X for Moses... (e.g.; changing a "get i$"
to an "input i$", with associated modifications..)
Keywords do do basically the same thing, but then again, noone uses keywords
except staff on my BBS, like \M1, \M2, \M3, and \PT3...
Future Vision 5 _will not be_ freeware, FV v1.0-4.0d9d are, and Josh is still
deciding what to do with FV5. He has stated "FV 4.0d9 is now freeware, post
it to wherever you like, hell, post it to AOL if you like" or something liket
that..
Roy (suffering the pains of a laser 128 keyboard.)
Roy Barrett
LLUCE isn't very different from ACOS at _ALL_... It has basically
the same commands as ACOS, not as many new features, and Metal KILLS
LLUCE. LLUCE doesn't have any BBS program, except GBBS... That's why I'm
considering writing a Metal program to convert ACOS/MACOS/LLUCE code to
Metal code. If all people want is a better language, Metal beats all. Even
MACOS was better than LLUCE. The changes between Metal v1.06 and 1.09 are
greater than the whole ACOS to LLUCE upgrade. LLUCE is a very, very, very
glorified ACOS. Lance Taylor-Warren can't code for sh*t, if you ask me. I
think Greg Schaefer did better with ACOS/GBBS v1.3 than Lance has ever done.
If a _real_ programmer had bought ACOS, it might have become something. You
look at the 5 years or so that LLUCE has been under works. You look at the
3 years Metal has been under works. Metal has progressed more in 3 weeks
than LLUCE has in 5 years. If you want support, L&L Productions is NOT the
way to go. Too bad, eh?
Roy
Greg Boehnlein
+---------------
I just want to point out to all interested parties here, that these are the
opinions of Mr. Roy Barret, and NOT necessarily representative of....
1. Greg Boehnlein
2. Shane Zatezal
3. Joshua Thompson
Or any of the other METAL/FutureNet community. Please direct all "Slander"
messages to his Internet address and not ours. We really don't give a flying
**** about the ACOS / LLUCE / MACOS / METAL wars and are happy with the
product that we have chosen to run as our BBS program. It serves our purposes
quite well, thank you, and it has been quite well supported.
We have more important things to worry about than ripping on other languages.
Brian Tao
>
> Actually, he was complaining about the abiliity to disable keywords.
> Keywords aren't a part of METAL, they are a part of the FutureVision
> software.
Ah, that's where I misread Greg Berigan's post...
> Actually, it's really kick butt to work with, because you can have it
> load in external programs.
>
> Like, on my system, if I am coding some segment of METAL, and I need to
> refer to the over 300K of METAL and FV docs, I have a menu driven METAL
> program that I call via...
>
> \DOCS
Can this be used to run othr GS/OS or P8 software? i.e., boot up
MicroEMACS or WriteAway and pass it some filenames to open?
Greg Boh
>The following revelation escaped Greg Boehnlein's lips:
>>
>> Actually, he was complaining about the abiliity to disable keywords.
>> Keywords aren't a part of METAL, they are a part of the FutureVision
>> software.
>
> Ah, that's where I misread Greg Berigan's post...
>
>> Actually, it's really kick butt to work with, because you can have it
>> load in external programs.
>>
>> Like, on my system, if I am coding some segment of METAL, and I need to
>> refer to the over 300K of METAL and FV docs, I have a menu driven METAL
>> program that I call via...
>>
>> \DOCS
>
> Can this be used to run othr GS/OS or P8 software? i.e., boot up
>MicroEMACS or WriteAway and pass it some filenames to open?
Hehe...That WOULD be nice..Not directly, no. However, Brian, you COULD write a
program that will exit out of METAL and run a ProDos 8 program.
Example...
\MUGS <- COULD conceivably exit ProDos 8 to DaveX then bridge to GNO to run
mugs.
The possibilies are endless really. What you might want to keep in mind is
that the GS version of METAL runs Shell Exe's, so MicroEmacs should be able to
run under that.
System Administrator
ds...@okcforum.osrhe.uoknor.edu (Roy Barrett) blurts:
[These are selected snippets from a long, irritating post]
>Heheh.. ohhmygod... I just ran the LLUCE demo -- what a joke! :)
>Lance Taylor-Warren can't code for sh*t, if you ask me.
>If a _real_ programmer had bought ACOS, it might have become something.
>Metal has progressed more in 3 weeks than LLUCE has in 5 years.
>If you want support, L&L Productions is NOT the way to go. Too bad, eh?
>
>Roy
It's one thing to give a negative review, but in resorting to personal
attacks, you not only make yourself look bad but you also degrade the
integrity of METAL. Even if all of the above were true, that is not
justification to verbally molest someone in an international newsgroup.
Maybe it doesn't bother you that programmers are deserting the Apple
platform in droves, but it does bother me. It's people like you who are
helping to hasten the downfall of the Apple. If you are so eminently
qualified to comment on LLUCE and METAL, then how about giving us a
point-by-point comparison of them instead of 'LLUCE sucks, METAL rulez'.
Maybe then we could make an informed decision. As it was, your post did
not contain anything factual or useful - just your inflamed opinions.
------------------------------------------------------------------------------
Proline: tgeer@pro-gumbo Internet: tg...@pro-gumbo.cts.com
UUCP: crash!pro-gumbo!tgeer Fidonet: tom....@f20.n380.z1.fidonet.org
------------------------------------------------------------------------------
"Combat advice: Always remember, your weapon was made by the lowest bidder."
Shane M Zatezalo
>>
>> refer to the over 300K of METAL and FV docs, I have a menu driven METAL
>> program that I call via...
>>
>> \DOCS
>
> Can this be used to run othr GS/OS or P8 software? i.e., boot up
>MicroEMACS or WriteAway and pass it some filenames to open?
You obviously can't run a GS/OS based program from a p8 program, but under
Metal GS you might just be able to do the above. To find out for sure,
you'll have to ask the author, TC Wilson.
Roy Barrett
: I just want to point out to all interested parties here, that these are the
: opinions of Mr. Roy Barret, and NOT necessarily representative of....
There are 2 t's there.
: 2. Shane Zatezal
Zatezalo, if I remember right. :)
I promised Josh that I wouldn't post in the wars. I am not, however,
participating, just had to get some name changes. :)
Anyways, I heard that LLUCE is more advanced that the demo, what's
better here? Just wondering, and what are the PR specs?
Roy
Roy Barrett
:
: Example...
:
: \MUGS <- COULD conceivably exit ProDos 8 to DaveX then bridge to GNO to run
: mugs.
:
: The possibilies are endless really. What you might want to keep in mind is
: that the GS version of METAL runs Shell Exe's, so MicroEmacs should be able to
: run under that.
Under ProDOS 8 v2.0 and above, P8 can launch GS/OS programs from the P8 progs
if on a GS. If Tc would allow it, I'm sure it could happen.
Roy..
Steven H. Lichter
It is more advanced then the demo and is still changing. I'll dig up a
post or 2 that cam over Ogg-Net and post it here later.
.
*******************************************************************************
| -=- Sysop: Apple Elite II -=- an Ogg-Net BBS |
| (909) 359-5338 12/24/96/14.4 V32/V42bis |
| Internet co...@cleveland.Freenet.Edu (Steven H. Lichter) |
*******************************************************************************
Dave Huang
>Under ProDOS 8 v2.0 and above, P8 can launch GS/OS programs from the P8 progs
>if on a GS. If Tc would allow it, I'm sure it could happen.
Only if you booted into GS/OS first... and this has been in older 1.x
versions of P8 too. The new BASIC.SYSTEM (1.5) lets you "-" S16 files
though, which is pretty nice :-)
--
Dave Huang |
Internet: da...@ccwf.cc.utexas.edu | "Microwaves: They're not just
or { khym | pekb364 }@utxvms.cc.utexas.edu | for cooking anymore."
America Online: DrWho29 |