Centipede was conceived of about three years prior to its actual release. Such a large system takes a long time to create, and Bugsoft's quality standards prevented any premature releases.

Below, you will find some historical announcements from Centipede's author, pulled from the Bugsoft archives.

Jump straight to the product announcement!
Jump straight to the early technical details!

This message was originally posted on V128's ComLink network on January 30th, 1995, as an announcement to all Color 64 and Version 128 SysOps.

FROM THE BEGINNING...

I started on a c128 version of Color 64, four years ago, because as a programmer, I liked Color 64's flexibility and large selection of mods and games, but wanted to use c128 mode. Initially all V128 was, was Color 64 running in c128 mode. That made it faster, and let us add more mods without worry of running out of memory. V128 has evolved greatly since its first release three years ago. Myself and others, have added feature upon feature to V128, in the forms of both mods and upgrades. It has surpassed its Color 64 heritage, and become a far more powerful entity. Unfortunately, this same heredity that V128 originally used as a crutch to launch it into rapid popularity, is now serving as shackles, limiting it from full maturity and expansion.

First, V128 must be built upon an operating Color 64 system. Initially, this helped earn easy converts over from Color 64, to the new software. But now, it only serves to complicate setting up a new system. In order to use V128, a new SysOp must first get Color 64, then convert it to V128, then pile on layer after layer of mods and upgrades, just to achieve was is commonly considered a base system. This does not make a very marketable product. While a freeware Color 64 can help with much of this problem, this one dilemma is not the entire story.

Color 64's, and thus V128's, base code is obsolete and difficult to work with! When Greg Pfountz started splitting the system into separate overlays, about a decade ago, he was using cutting edge programming. However, overlays are bulky and inefficient in their repetitive code and long loading times. While the onset of hard drives have assisted to minimize this problem, it still remains. Color 64 was created to run on floppy drives. Now hard drives, with sub-directories and fast access, are the norm. The difficulty of working with Color 64 and V128 systems is that they have undergone so many changes since the basic structure was created. One of the prime reasons V128 has yet to have a functional Ymodem protocol, is due to the absolute mess of the upload and download BASIC coding. It is what we programmers call "spaghetti code." It's all a big jumble of branching around and "hacks" to add features and fixes, all the way back to when Greg Pfountz added multi-Punter!

All of V128's layers and layers of mods, even once all merged in, leads to conflicts. There is just too much code, fighting over the same lines and the same variables. It all leads to conflicts. This is all especially difficult for those who don't consider themselves programmers. I spend much of my time helping people track down conflicts between mods. We aren't just running one BBS program here. This is V128 plus a mesh of mods, upgrades and "hacks." What is needed, is a fresh start. A new system, and a new standard. One that has what we all want built in, and lets you add what YOU want, without worry of conflicts. A system with a base flexibility that can have every system look and act completely different, without changing a single line of BASIC. And, a system that is built on a base structure, designed and intended to be expanded upon. What we need, is Centipede!

BACKING UP A LITTLE...

I recognized the need for this system long ago, as did all those who nagged me to write it. But I didn't want to leave Color 64. It is the base of V128's being, and what I had learned to blindly love. Things started to change when Fred Ogle ended Color 64 v7.3's life on the market. He believed he was serving the fatal blow to V128. He'd be kicking himself now to learn his act was the catalyst to the next evolutionary step for Color 64 and V128!

My original intent was to make "System V128," which was described as Color 64 v7.3 with V128 and many of the existing V128 mods built in as standard features. This would include a new manual that would combine Color 64's and V128 into a single work. Had I stuck to that plan, System V128 would probably be out by now. But I didn't. Before going too far into System V128, I asked for input from existing V128 owners via a survey of twenty-one questions. The results were startling! More people than I had expected had realized the need for a larger overhaul. EVERY respondent was ready and willing to scrap their hard fought for main overlays, for new ones. This support from my customers gave me the push to start seriously considering some more drastic steps in improving V128. I started with a new menu structure based upon the same concepts of the highly flexible, and highly popular G-Menu mod. With a new, fully customizable menu and command structure, I began to modularize the BBS. Initially, I simply starting with what would have been System V128, and rearranging and renumbering code into smaller modules. I then saw the use in multiple layers of modules. Then levels of variable killers. Then I started discovering some secrets of Commodore BASIC: Hidden variables, great speed increases via less individual variables and arrays, and reading variables in as program code rather than from sequential files. Even the machine language began to modularize for easy additions. A new BBS program was forming before my eyes. Past suggestions, thoughts, and experiences flowed from my hands onto paper and keyboard alike. Simply assimilating it all into a manageable form took a couple of weeks! The resulting code that I am now laboriously typing out will be, Centipede. It's the system you've always wanted. A system whose abilities include what I have talked about here, plus so much more, while STILL running all those hundreds of on-line games that have been written for Color 64 and V128 over the past decade!

I had intended to wait until Centipede was in beta testing before composing this message. Unfortunately, with little information comes the rumors, misunderstandings and fears. I'd like to conclude this message with my assurances that I am NOT dumping Version 128 or Color 64! Those systems are, in essence, the father and grandfather of Centipede. Centipede may be the new kid on the block, but I will not forget its proud lineage. I will continue to provide Color 64 and V128 support and V128 sells up to and following the release of Centipede.

As always, your suggestions and questions are not only welcome, but actively solicited. Thank you for taking the time to read this message.

Adam Fanello of Bugsoft
4822 Larwin Ave, Cypress CA 90630-3515.

Nature Reserve BBS - 714-828-7296 and 714-952-2696 (Handle: Ant).

Internet: adam_fanello@*****.edu. <Internet Email is now at ant@fanello.net>

The message was originally posted on V128's ComLink network on February 20th, 1995. Much has changed from these early development days, but much is also the same...
------------------------

There has been many questions (prodding actually) on some specifics about Centipede... so I am typing up some here from my notes. I have two notebooks and a disk box of 4x5" cards full of data. One notebook has the computer's memory map, and the other contains BASIC variables and file formats. The cards describe each BASIC overlay and module, and, each script, machine language, and variables file. The following is information from these notes. While in some sort of order in my notes (usually numeric or alphabetic), they will probably appear to be random by topic. Some will be general ideas, some specific programming techniques, and whatever else comes to mind. Information will be presented at all levels of expertise. Some may require detailed programming knowledge, some Color 64 or V128 knowledge, and some nothing beyond what you already know about telecommunications. It's all mixed together here. I'm leaving it up to you to get what you can out of it all. This should answer many of your questions, while doubtlessly creating new ones. (Sigh.) ;)

----------------------

The c128 has two TOD (time-of-day) clocks. Color 64 uses only one of them for, you guessed it, the time of day. It uses what is called the jiffy-clock for keeping track of time online or idle time. The jiffy-clock, however, is not very accurate. Centipede uses the second TOD clock to keep the jiffy-clock accurate. Thus we have the accuracy of a TOD clock, with the ease of use of the jiffy-clock.

I haven't done anything on it yet, but I hope to use the extra 48k of those with 64k of video RAM for the local buffer. Your users have a buffer in their term program, why shouldn't you? V128 uses whatever space is left over in the BASIC program area for the buffer, and Centipede will continue to do so for those of us with only 16k of video RAM.

SwiftLink support will be included in the basic package.

Also in planning, is BURST mode reading of SEQ files on Burst compatible drives, and direct access to the SCSI drive on Lt.Kernal systems. Both offer incredible speed increases. Oh.. also for downloading files.

A 26th screen line will be added at the bottom, containing a little info on the current user online. This will be in addition to the (modified) SysOp View Panel will full detail that you can bring up at almost any time without notice to the user online.

Centipede will not be running in 40c mode. Users can of course still call in 40c and Centipede will use a simulated 40c screen, but still be in RGB mode. Supporting two screens creates a small slow-down and puts some memory out of use, as well as creating other programming headaches. I've yet to find anyone to continue running V128 on a composite screen for a great length of time, so I'm dropping that.

Split screen chat mode is of course in here, and I'm working on a full-screen editor.

File transfer protocol ML files are self-serving. What I man by that is that they handle any details specific to their own protocol internally, so that you can mix and match any file xfer protocols into your bbs, without any modification to BASIC. If you don't want to run all the protocols, you don't have to, and any new protocols can be added simply by copying them to your HD and adding them in the Protocol Maintenance area.

Text can be output to the modem by why of a modified basic PRINT command. Instead of Color 64's a$="text":sysc(0) to output a string, you may use [print"text" instead. The old Color 64 commands still work, but the new Centipede way gives us the full flexibility of the print command, including PRINT USING formatting.

Color 64's sysc(5) and sysc(8) (input strings from disk and modem) are supplemented to put the results in any string you want, rather than just tx$. To read a complete seq file into the a$() array: a=0 : do until st : a=a+1 : sysc(8):=a$(a) : loop

One overlay and up to three levels of modules may be in memory at a time. So the list of files in memory may look like: "ovl.main", "mdl.upload", "mdl.ud-dir". (I couldn't find any example using all four levels, but it's nice to have it available.) You may also have two modules of the same level in memory at once using a technique of 'hiding' one of them. This allows you to sort-of 'gosub' to a routine in another module. Such as uploading from the email module.

Which brings me to private files transfers. You 'e-mail' a private file to another user, by attaching an upload to a piece of mail. A use may have any number of private files at a time. They are held or deleted with the email they are attached to.

Files can be copied between two drives or the same one, by opening the two files, and executing a single SYS call.

A SYS call lets you set the cursor at any line and column on the screen. The ML finds the shortest path there in c/g, or pops you directly there for ANSI callers.

Another SYS lets you scan a file for a specific character.

Centipede has four individual levels of dim and variable killers.

Translation routines for ASCII, Commodore color/graphics, and ANSI are separate ML files. New ones can be easily added.

Overall variable structure has been changed a bit. Many individual variables from Color 64 have been moved into one of two arrays: d%() and d$(). Using d$(2) may not be as clear as pw$ for the user's password, but it's a trade off for memory and speed. BASIC's ROM code can calculate the exact memory location of an array index much faster than it can do a sequential search through every variable name in search of an individual variable. Continuing the same example, d$(2) has a three-byte overhead in the variable space, while pw$ uses seven! More commonly used variables such as lv for the user's level were left alone.

There is a maximum of 15 message bases, with 26 categories in each.

Create your own menus. Sample ones will be included as starting points. Starting with the main menu and standard sysop menu, you can define every hotkey to run whatever routine you like, including other menus! Hence, sub menus. Each hotkey has the following attributes: command name, access level, killer type (dim or variable), graphics requirements, filename of module or overlay, routine number in that module, and new program and support files directories to use in that routine.

Scripts of up to 25 lines use the same attributes for loading modules as menus, plus can display seq files and display and respond to simple Y/N prompts.

Directory locations, as mentioned above, can be modified from their defaults from menu options. Each location is defined by it's device number (8-15), file prefix, and one or two disk commands. The prefix option is particularly useful for CMD owners, who can create prefixes such as "3:/msgbase2/" for the second message base on partition #3, in the subdirectory msgbase2. You can also send the two commands of "cp3" and "cd//msgbase2", but I'm told the prefix method is faster.

Users can set their own experience levels between: Beginner, Knowledgeable, and Expert. This effects things such as the detail of help automatically shown at menus and prompts.

Users may setup their own default message base scans to read or skip any message bases they wish, automatically.

You may lock users out of any message base or u/d category, regardless of their access level. You may also set daily time limit adjustments for each user, which will give them more or less time than normal at their access level.

Short-View file descriptions in the directory listing (up to 38 characters) offers more detail than a little 16 character file name. Users may select whether or not they wish to have them displayed. This only supplement the full detailed file descriptions in the Color 64 style.

Caller log and variables are saved right after user logs off, rather than after five minutes of idle time. At present, the idle script is only used for calling networks, and time for this script can be set between one and sixty minutes.

Screen savers are separate modules, making for easy changing screen savers. You may also select the delay for the saver to kick in, between one and fifteen minutes, or not at all.

You set multiplication factors for credits awarded for downloading and uploading. Using this, you can select whether a user gets credits right away for uploading something, or when somebody downloads their upload, or a combination of the two.

If you so setup your menus, you can allow users to flag files for download while viewing a directory listing. Up to 50 files may be flagged, from any combination of directories.

Flags indicate if your modem supports DTR, if you wish the BBS to take the modem off-hook when you are using it, and if you are using a SwiftLink. Baud rates supported are 300-4800 on the rs-232 port, and 300-38400 with SwiftLink.

You may select whether or not you want Menu Phrases shown for each menu, and phrases are accessed faster than V128's Prompt Macros are.

There is built-in support for Network 64 v1.26, and ComLink.

You may enter a line of any misc information about a user in their account record. There is also a field for a real name, if you allow handles, for possible support of other networks in the future that demand real names.

You may use a local mode password to keep house guest from getting into areas of the BBS they should not be poking around in.

Will us the proper terminology of "RETURN" or "ENTER" depending on the user's graphics mode.

Menu hotkeys and levels when reading messages are customizable: Quit, reply in public, private reply, reread previous, reread last, skip forward, skip backward, jump thread, backup a thread, jump category, non-stop read, post in other thread or begin new one, scratch, edit, move, scratch thread, change thread subject, download message.

Mailbox email reading hotkeys are also customizable: Edit user's account (level 9 only), reread same, backup one, delete, hold, reply, download, quit.

And finally, the message editor commands: Attach a file (email only), quote from reference msg, upload msg, full-screen edit, continue line edit, clear msg, list lines, edit lines, delete lines, insert lines, send, abort.

There are up to 15 U/D categories with up to 26 directories in each. Each directory has the attributes: name, disk location, allow downloads, allow uploads, access level.

Caller log is more flexible than Color 64. The log for the current call is stored in a 'hidden' variable array, so as to not create any variable conflicts. The permanent log is stored in a REL file, of which you define the length. The REL format allows for fast searches and viewing in either direction. It also saves memory.

Support for dual-lined system on multiplexed Lt.Kernal. (And CMD HD if CMD ever makes a real multiplexer.)

Rewritten, faster, message threading, message regeneration, and u/d directory regeneration routines than Color 64 or V128.

File transfer protocols: ascii, Xmodem Checksum, CRC, and 1k, Ymodem and Ymodem-Batch, and Punter and Mutli-Punter.

In addition to the old Color 64 message subject for a thread (now called a thread name), the users may change the message TOPIC field for each message. Message headers in the file contain only the data. The actual header format is created via BASIC, and can be modified. Two columns are used for 80c users.

A modem module handles initializing, answering, hanging up, on/off hook, baud rates, and other modem commands. Specialized modules can be created for each modem type.

Date and Time can be read from a CMD device, or entered manually.

Variables can be stored in program form and quickly loaded (much faster than reading from a SEQ file) and can be easily modified by putting the changes in an array and GOSUBing to a routine. For those who are familiar with them, it is similar to .INI files under Microsoft Windows.

Here is some of the features of V128 that I ran across in my notes, while are defiantly still a part of Centipede: Split screen chat mode, local buffer, SysOp View Panel, Programmable function keys, RAMDOS support, MCI, Superes detect and ANSI auto-detect, auto-pause (may expand on it), digitation player, ANSI translation, Sim40c, Message threading (although handled in a faster manor), MembVars, plus pretty much everything else I forgot to mention.

Yow! That was all quite a book! You asked for it though. ;)

As always, your suggestions and questions are not only welcome, but actively solicited. Thank you for taking the time to read this message.

Adam Fanello of BugSoft
4822 Larwin Ave, Cypress CA 90630-3515.

Nature Reserve BBS - 714-828-7296 and 714-952-2696 (Handle: Ant).

Internet: adam_fanello@*****.edu. <Internet Email is now at ant@fanello.net>

©1998 Bugsoft