System messages

Revision as of 04:24, 16 February 2026 by Admin (talk | contribs)

InstallationThe System Messages

With your parameters defined and your Program and Boot files properly installed, it is time to create and customize your System Messages. This is where your BBS begins to take on its personality.

The install disk includes sample system message files. Many contain placeholder content explaining when the file is displayed or what it is used for. Use a file copier to transfer all desired sample "system messages" onto the drive assigned for your System Files.

As noted earlier, all BBS system filenames must include the check mark character (shifted @) as the first character of the filename.

Creating and Editing System Messages

There are several ways to create or modify system messages:

  • A word processor that saves SEQ text files (such as Easy Script)
  • The stand-alone BBS message editor
  • The built-in message editor within the BBS DOS section
  • Kaleidoscope (recommended for menu-style screens)

To use the stand-alone message editor, load and RUN the program "+editor" from your Boot disk (for floppy-based systems).

After loading, you will see a menu similar to this:

The “Read Newsletter” option is a legacy item from the original 8.0 release when a Color 64 newsletter was planned. It remains as an artifact of that era.

Editing a Message File

To edit a message on any drive:

  • Press F1.
  • Enter the device number of the drive that contains (or will contain) the message file.
If the number shown in brackets is correct, press RETURN.
  • Enter the drive number (0 or 1). Again, press RETURN to accept the default.
  • Enter any drive initialization command if required.

Normally, you will press RETURN for the init command. However, special configurations may require commands such as:

  • `u0>h1` for the back side of a 1571
  • `u0>m1` to place a 1571 into 1571 mode
  • Hard drive partition commands as needed

Finally, enter the filename — remembering to include the required prefix character:

  • “√” for protected system files
  • “@” when appropriate for hidden description files

If the file exists, it will load into memory for editing. If it does not exist, it will be created when saved.

Example screen:

Editor Capabilities

The stand-alone editor functions the same way as the online message editor used for public and private messages.

Key differences:

  • The stand-alone editor allows messages up to approximately 500 lines.
  • It supports full color control codes.
  • The online editor is limited to the “Maximum lines per message” value defined in the “√bbs.parms” file.

This makes the stand-alone editor ideal for creating longer system files such as welcome screens, information files, menus, and help documentation. The table below provides the list of system message files that Color 64 uses:

System Message Files
File Example Description
√systemstart
This is the very first file displayed when a user connects. You should keep everything in lower case and graphics-free in case the caller is using an ASCII terminal (it will display as upper case to them). You can have your BBS Name, date, time, or some sort of initial response to the user.
√systemstart2
This file immediately follows √systemstart and should ask the user to press their DEL or Backspace key for the Commodore graphics check. Again, it should be in lower case, no graphics, but is there for you to customize as you would like for your BBS.
  • √banner
  • √abanner
These two files follow the graphics check if the caller uses PETSCII or ANSI graphics.
  • √banner = Commodore terminals
  • √abanner = ANSI terminal

Graphics are permitted for both and you can start using C64 graphical characters.

√welcome1
This is the main “Hello!” screen to a user after the graphic check is done and is displayed to the user just before their login credential entry occurs.
√welcome2
Displayed after successful credentials match. This can be a large splash screen or something simple.
  • √logon stats
  • √logon stats80
This file is displayed next after √welcome2 and gives the user the current status of the BBS and their account. It is one of the few files that has the option for either 40 or 80 column specific display files, and will depend on what the user has set in their settings (40 or 80 column).
  • √logon stats = 40 column display
  • √logon stats80 = 80 column display

The file performs extensive use of the Variable MCI commands. Until you are familiar with these, you should not do a lot of editing on these.

  • √sysopin
  • √sysopout
Depending on if the Sysop flag is “In” or “Out”, the appropriate file will be displayed. You can be as graphical as you like!
√level # msg
This is displayed to the user and is dependent on their access level. You can have a file for any or all levels.

When the system is loaded up, it looks on the system messages drive for "√level 1 msg", "√level 2 msg", "√level 3 msg", etc., and sets a flag for each one it finds. So, if you want to send a message to all level 3 callers, and all level 7 and 8 sysops, just create the appropriate message files and name them "√level 3 msg", "√level 7 msg", and "√level 8 msg", respectively. If the BBS is already running when you create or remove any of these messages, use (F4) at the WFC screen to reset the date and time; this routine will also reset the level message flags.

√wall
This is the User Wall / Guestbook. It is optional. If you don’t desire to have one, you can delete the file, but be sure to remove the command “W” for it in your “BBS Commands” portion of your setup!

You would edit this file if you desire to have some sort of header at the top of the wall content; and you will need to edit this periodically to keep it from getting too long.

√sysop news
Sysop news is a file that allows you to enter specific news occurring for your BBS. You’ll see in this example I have two dates listed. Once a reader has read an entry (in this case, 08/01/2025), they will not see it again. But if they have not viewed “08/11/2025”, that will be displayed. You can continue adding entries in this manner; just make sure when you add a date in to the news file, it is immediately following the last line of the previous entry as shown here.

Keep in mind that you don’t want this file to get too long. New users will see every single news entry when they go through their logon process.

This file is optional.

√menu#
This is the menu file displayed to the user and is one of the most frequently used screens. There is one menu for each access level. Example: displayed here is “√menu4”. You can get as graphical as you like and even have multiple pages, but remember, it *is* a heavily used screen, so multi-page might get annoying to the end user.

For my Sysop file menu (√menu9), I kept mine very simple and avoided any “fluff” so I could have all the commands fit nicely on one displayable page.

Included in the setup disks is a menu maker program that will generate menus for you if you’d like something quick. Use it after you have completed your SETUP process as it uses information from you “BBS Commands” settings.

√chat enter
Displayed when the Sysop invokes a chat session or responds to a user chat request.
√chat exit
Displayed when the chat session is closed by the Sysop
√new user msg1
Displayed after a new user has logged into the system and is assigned details about their account. You will want to keep this file short and without any screen-clear command, so their details do not scroll off the screen.
√new user msg2
Displayed after a new user has completed their application for access. If there are additional steps the user needs to know about getting full access, you should include them here.
√application
This is displayed to the user, but the display will be different than what you see here as it is being run as a script.

The application is a combination of a regular text and special "prompt lines" that will cause the BBS to stop and wait for the caller's r==esponse to the application question. Any line beginning with a "#" (number sign) will not be printed but instead will cause the application routine to stop and wait for the caller to type something. The text after the "#" symbol will then be part of the application information that is put in your mailbox. Then the next bit of text will be printed until the next prompt, where the BBS will wait for another response, and this repeats until the last line of the file is used. Then it prints everything back to the caller and asks if this is correct. If they answer "N", then the application routine will begin again. Otherwise, the answers are stored in your mailbox and in a file called “√questXX" where XX is the number of the month (e.g. √quest07 for July). The "√questXX" file is stored in the Private Files section. You will be able to print your mailbox for a hard copy while all your remote SYSOPs will be able to see the same answers in the "√questXX" file.

These days, people are uncomfortable with providing their “home address” or even their birthday – not to mention both together. Think about what information is pertinent when it comes to your user and the use of your BBS. On my BBS, it’s a 50/50 shot that I will even get their full name, let alone their first. That said, if you feel you don’t have enough to trust the user with a C64 BBS system, then you can always delete them or not approve access. See the section on “Application” for more information.

√bbs closed Create this file if you do not wish to accept new callers to your BBS. When the system receives a user name of “New”, it looks to see if this file exists; if it does, it will be displayed and they will not be granted access. If made, consider lower case / non-graphical for ascii callers.
√membership full
Presented to the user if the attempt to create an account, but the BBS is at the max limit of users.
√member list msg
Presented to the user just before the membership list is displayed.
√membership list Automatically generated by the BBS and will present a list of users to … well, the user.
√information
This file should be updated to describe the type of system you are running or any pertinent information about your BBS you wish to convey to your users. Users typically would like to know what type of setup you are using, and this is the best place for that. It is callable from the menu commands for users.
√no mail
This screen will be displayed to the user if they have no private mail waiting. Optional.
√sysop not here
Displayed when the user submits a Chat request, but the Sysop has not responded.
√still not here
Displayed on subsequent Chat requests, and still no response from Sysop.
√sayings#
Random sayings to be displayed to the user just before the first command prompt. Numbered 1-6.

√sayings1, √sayings2 … √sayings6 Optional.

√games menu
If you choose the option to run your Games on AUX3 (instead of the Mod Menu), then you will need to create a games menu to display to the user; the file is expected in the AUX3-designated location.

Conversely, if you are choosing to use the Mod Menu option, you will want to ensure your spare command “1” for games is disabled.

√logoff
Displayed just prior to user disconnect. Optional.
√upload msg
Message displayed to user when they request to perform an upload of a file to the BBS. Optional.
√upload held
Displayed to the user after the upload is complete, and only if the caller’s access level is below the "auto release" level defined in the UPLOAD/DOWNLOAD section of SETUP.
Other Notable Screens
√doshelp
Displayed to SYSOP (or remote SYSOP) when “?” is entered at DOS Wedge.
√msg menu
Message Menu commands listing displayed upon user request of (H)elp.
√wfc
OK, I digress. THIS is probably the most used screen for the BBS, but only if you are the Sysop!

This is your console display when the BBS is “Waiting for Call” or “WFC”. This file makes heavy and impressive use of Variable MCI, and while modifying it can be done, it is tricky.

If you become brave enough to tinker with it, do note that the “Status” field is populated by a ML routine that will always place the details in that specific area between the “> <” brackets. So that particular space should be considered reserved for the modem status details. Save a backup before editing!

Also note the “BBS Name” just below “Last Caller” in this screenshot is only populated if you have Network 1.26a running.

√mod edit menu
File used as a help file for the mod menu
√mod sub menu
Same as above.

Special Provisions for ASCII callers

Normally when a BBS uses a large amount of PETSCII graphics, non-graphic (ASCII) callers can have difficulty understanding what is displayed on their screen. Fortunately, Color 64 v8.1 and above handle most screen conversions automatically, making the system usable for both PETSCII and ASCII users.

That said, certain screens — particularly menus with heavy graphics — may not translate cleanly. For these situations, Color 64 provides an optional method for creating alternate system files specifically for ASCII callers.

Included with the system is a merge file called afr.ovxx (AFR = ASCII File Read). This merge can be applied to all overlays except for the Network overlays.

How the ASCII Alternate File System Works

  • Create your standard system file as usual.
  • If you want an ASCII-friendly version, create a second file:
    • Use the same filename.
    • Remove or simplify any troublesome PETSCII graphics.
    • Add a plus sign (+) to the end of the filename.

Example:

  • √menu1 (standard PETSCII version)
  • √menu1+ (ASCII alternate version)

When an ASCII caller accesses the system, the BBS will automatically display the “+” version of the file if it exists.

Important Limitations

System files that function as scripts rather than simple display files cannot use this method. Examples include:

  • √application
  • √sysop news

These files are executed as part of program flow rather than being read directly to the modem, and therefore cannot be converted using the AFR method.

Next Section: Help & Text Files

Installation