[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LLUCE vs. METAL: A losing battle



As quoted from <wH2cyB1w165w@cybernet.cse.fau.edu> by gberigan@cybernet.cse.fau.edu (Greg Berigan):

+---------------
> 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