8bitfiles.net/archives

home *** CD-ROM | disk | FTP | other *** search

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / OMNI.TXT < prev next >

Wrap

Text File | 2019-04-13 | 32.3 KB | 651 lines

<C> 1994 by GEnie ========================================================================== This file is brought to you by The Commodore 64/128 RoundTable on GEnie This file may be published or excerpted in User Group newsletters providing credit is given in this manner: "Copyright 1994 by GEnie From the Commodore 64/128 RoundTable File#:#####" This file maybe be distributed, if distributed whole and unaltered, on non-profit BBSs or non-profit networks. For more information on GEnie call by modem: 1-800-638-8369 (8-N-1 300/1200/2400) Enter: HHH Then reply: xtx99018,commrt Then enter: Commodore And enjoy! ========================================================================== <GEOS-TIM> Welcome to the Omni 128 Conference with Omni creator - Brian Bell. <B.Bell> Thanks - I'm glad to be here - hope we can stay online for a while! <GEOS-TIM> Tonight's conference is hosted by GEOS-TIM (Tim Hewelt) with co -hosts Greg Noggle and Doc Tuomi. Welcome Greg and Doc. <Doctor> Hello, Tim. <Greg> Hi Tim <GEOS-TIM> The Capture and editing of tonight's conference is being done by the now famous editor - CBM-Bandit (Cam Stewart) <Bandit> Thanks Tim :) <GEOS-TIM> Special behind the scenes production is be handled by non other than C128-QT.Pie (Sherry Freedline). Hi QT <QT> Hiya ;) <GEOS-TIM> I would like to give a big welcome to the creator of tonight's featured program .Brian Bell !!! <B.Bell> Hello - and thanks again. Ready for any opening questions. <GEOS-TIM> We have them. We really feel fortunate to have such a talented programmer in for tonight's conference. Tonight's conference is divided into 5 topics - 1) The Beginnings. 2) Features of Omni 128. 3)Getting into Omni for the first time. 4)Questions from an active Omni user. 5) The Future. The room will be in listen mode. At the end of each topic, questions concerning that topic will be fielded from the audience. If you have a question type /rai and you will be called on in the order received. Please type "end" at the end of your message to indicate that you have finished your question. Please keep your questions in line with the topics. <GEOS-TIM> One of the things that is always interesting when computer users get together, is the talk eventually gets around to how they got into computing. How did you get into computing, Brian? <B.Bell> My involvement with computers started when I saw TI-994a's go to $49. I was curious, and couldn't resist the price since they were $999 before, so I had to see what they were about. After a few trips to the repair store in Redmond (they blew up from static electricity very easily) I stopped playing with it. Music is what led me into the Commodore scene. I became interested in MIDI, and a local store suggested I check out Dr. T's Keyboard Controlled Sequencer (excellent proggie by the way). He also mentioned that a C-128 version was due out. So I opted to get a C-128 and waited for the update to 128 mode of the program. This was in 1985. I didn't do much programming until early 1986 when a friend wanted me to help write a carrier detect routine for his BBS. I consulted a locally known 6502 guru named Dave Thompson and he taught me how to write an interrupt. It worked well, and I continued with ML for quite a while while a partner wrote BASIC. It was an early C-128 BBS called LOPI - quite nice for the time, but it was compiled and I wanted instant feedback on the changes in the program. So, I began to play with BASIC 7 (more) and wrote an overlay system to allow programs to load in on top of a "main" BASIC program. The machine language provided the basic terminal operations needed for a BBS and soon many other features were changed from BASIC to ML. Omni is the result of these last 9 years of programming. I don't have any intentions to quit programming this machine, although I like other machines too (have a little A-1200 for general work. maybe I should end this part here. *g* . <GEOS-TIM> Great answer, Brian !!! You covered all of my questions for this topic. <B.Bell> Hope no one fell asleep. <GEOS-TIM> But, I guess I have one I just thought of - What other puters do you have, besides the A 1200? <B.Bell> I've got three C-128 Flat models, a couple broken Plus 4's, a 64-C, a CDTV, and two Amiga 500's. <GEOS-TIM> Jetflight has a question. <JETFLIGHT> What are some of Mr. Bells prior shareware or commercial programs? <B.Bell> I've worked on: a 64 terminal called Bitmap term, which later became "Resterm" and after that SupeResTerm. It was/is a hi-res decoding terminal, the graphical part of which was written by a local named Bill Laughlin. I wrote multiple buffers and brought it from 300 to 1200 and finally 2400 bps support. I'm considering upgrading it to high-speed via SL- 232 in the future, but Omni is a full time job. <Doctor> What happened to the TI? <B.Bell> I've still got the TI but the color went out for some reason. Otherwise, I would like to play an occasional game of Parsec. <JETFLIGHT> Did you teach yourself programming or learn it somewhere else? <B.Bell> I got started in 6502 by the aforementioned friend - more, and then learned from books and examples like Mr Butterfield and others. <GEOS-TIM> Features of Omni 128.Brian, Could you tell us about the features of Omni 128? And what it is. <B.Bell> Omni has a huge list of features primarily because it has been in development for so long, and also because I found the need for many of the options. There are over 100 modules providing the standard functions of a BBS such as Message Base, Files Transfers, Sysop Maintenance, and numerous others. - taking individually - Message Base - has 20 main areas, each supporting up to 99,999 auxillary areas I call "lattices". The total number of separate areas could reach 990,001, but practical limits (file access time) would limit this somewhat. The message base uses a true post-response threading system, with unlimited responses to each posting. An auto-weeding system is built in and can be adjusted to remove percentages or numbers of old- responses in the threads, without affecting the original post. One of the neatest features is the ability to make a standard CBM text file into a post from anywhere on the system, not using the regular message base storage area. I use this to conserve space on my RAMlink, since there is only 4 megs in use for the BBS itself. This capability to post files as messages also allows normal responses which appear to be connected to the post, but are actually a part of the message base itself. Each message base can be adjusted to allow only ASCII codes, or more freedom in terms of Commodore style color code and cursor movements. The main message base areas are also access controllable according to a powerful flag system, which basically gives (memory refresh) 9 general access levels, each with approximately 80 adjustable flags which denote whether a user can perform or access an operation or area. The reading system is very flexible - a user can automatically read all new messages from the main or message base menu just by typing "r" or "ra". Multiple commands which are similar to several common BBS programs are provided to make migration more comfortable when a caller is more familiar with a different BBS. <GEOS-TIM> That sure sounds impressive, Brian!!! Go on.we are listening. <B.Bell> Thanks - screen clearing and pausing is among a large group of user editable parameters to make message base reading easier. There is a non-stop mode for those who wish to buffer an entire new-message session. One unusual feature I don't think is on any other system is a "speed" control, which lets the user adjust the output speed from full speed to very slow. This is useful for people who like to read smooth scrolling messages instead of paging them. A caller can set their own page length (asked at new-user login also) and the BBS will pause all text when this number of lines is reached. The reading system can also be called upon to read the message threads backwards, or from any specific response. A high-speed scan is used to locate specific responses in a thread. The time and date stamp system is very powerful - and is used to locate the new messages in a thread. The time is dependant on the length of the message, but is generally very fast on the RAMLink and HD series drives when used with the parallel cable. Some sysops have come up with unique ways to configure their message bases, making it into a "post- post-post" type system instead of allowing responses. This is preferred by some people who don't want the sheer capacity for unlimited responses. The time and date stamp consists of three elements - The last-call date, time, and place. Separate stamps are kept of the LCDT (last call date/time) for the main system, the message base, and the file transfer areas. If a caller loses carrier or prefers to use a special logoff system (%), their information will be kept untouched so they will not lose any new and possibly important messages or files. In the messsage editor, callers can merge in prepared text which has been uploaded via a protocol in the transfer area, or created in a "multi- send" message editor. A merged signature is also supported, which the user can create online. I'm especially proud of the speed of the message text-reading can acheive with a high speed modem using SwiftLink. It makes it useful for buffering. The file transfer area is structured similarly to the message base system, and has the same 20 general areas, each with 99,999 possible branches or lattices. However, the transfer area uses a new-files scanning system that checks areas in a decimal-incementing system - A main area with new files is immediately entered, and then a quick scan of (for instance) 1, 1.01, 1.02, 1.03 is performed, stopping only at the areas with new files present. A caller can select a batch of files during this new-files browse mode, within the specific areas, and is presented with the option to batch download them via their default protocol at that time. On-the- fly changing of the protocol is allowed. I know there is some interest in the supported protocols, so here are the current ones - (For download only mode first) Xmodem checksum, Xmodem-CRC, Xmodem-CRC 1k, Ymodem standard (128), Ymodem 1k batch, Punter C1, and multi-Punter. The upload protocols have a shorter list, but there is an unusual addition not normally found on a C= BBS - (Upload protocols) Xmodem checksum, Xmodem CRC, Punter C1, MultiPunter (type 2), and Zmodem 256 and Zmodem 1024. These last two are "experimental" though I and others use them everyday. I have determined a list of terminal for the Amiga and PC which succesfully use all of these protocols. - Zmodem 256 is used for text or uncompressed data transfers while the Zmodem 1024 is used for compressed files like LHArc or Lzh or Zipped programs or data. Performance of the protocols can be impressive - at 14.4k it is possible to download text at over 1400 cps and compressed data at over 1300 cps, depending on the receiving terminal. Uploads are not quite as fast, but it is important to point out that a file is uploaded only once, but usually downloaded many times. The Zmodem support alone has made it easy for me to automatically post information from larger networks and systems with little effort and time wasted. There is also an "exchange" style transfer area for those who want an extremely simple "free form" files area tailored for Commodore 64 or 128 support. This is a separate module with it's own feature list but without the large amount of more advanced functions that the main file transfer area has. Each uploaded file can be described by the caller in any length they wish, and pre-written descriptions can be uploaded under a specific filename along with the files themselves, and it will dissappear from the file listing and become the text about the file. In addition to the Y-modem batch standard and 1k, the same module also senses if the caller is using Ymodem-g and sends at break-neck speed. The difference is, if an error is encountered during a Ymodem-G transfer, the process is halted and must be started over. However it is worth mentioning. Also a note on the Zmodem 256 and 1024 implementation - it does not support resumption of an aborted transfer - but this is definately possible and I will certainly complete it and some more large block protocols this summer. I'm so close to the BBS I often forget how many features it has until I log onto some other local board of a different type. So - is this a good time to spotlight a different area or field any transfer area related questions ? <GEOS-TIM> We have one question by Jetflight <JETFLIGHT> How much memory, hard drive,RL etc. is required for the OMNI program? <B.Bell> Omni requires either a RAMLink with 4 megs, or a CMD hard drive for an expandable BBS - but a stripped down version could be configured to run on a few FD-2000's, 1581's, etc. There are a lot of files in the menus section (close to 300 on some systems) and the number of files in the "main" path can grow large if the system has a lot of transfer areas created. For high speed modem use I recommend a SL-232 interface (SwiftLink from CMD of course), though it can be run at 9600 only with a plain RS-232 interface that has hardware-handshake lines (RTS/CTS). But the performance and relability much higher with the cartridge. The best modem I have used on the system is the USR Sportster 14.4k, but I have also tested the Boca 14.4k, Supra 9600 and 14.4k, and did "remote" tests of a couple other brands that I didn't have in my hands. There is no problem supporting 28.8k modems (serial rate is always locked at 38400 bps on Omni when running at any bps rate) but I will need to procure one of these 28.8's to determine whether there are any special requirements. If USR gets their 28.8k Sportster de-bugged it may be the ideal modem for the system in the future. Currently, it has received poor ratings from sysops of all types in my area. <JETFLIGHT> What size is your HD? Thanks for all the info. <B.Bell> You are welcome - my hard drive WAS originally an HD-20 (I have a very early serial # job) but now it controls a 40 and 60 meg drive in an old IBM CPU case. Keep in mind that I only use the hard drive on my particular BBS for holding files and automatically backing the system up each night. The backup program is new and I should go into it a little later if things slow down. . zzz :) <Doctor> I was wondering what the maximum storage capacity that the transfer section could handle? <B.Bell> Storage capacity in terms of number of files, areas, or something else? <Doctor> Storage capacity in terms of number of files, and amount of mb's? <B.Bell> Each of the standard transfer areas, like the message base, can hold 100 files, meaning up to 100 for area 1, up to 100 for area 1.01, an (and) so on. There is also a way to support larger numbers of files per area which is not in general use yet. Like the message base, there can be up to 990,001 areas - which is nice for special support purposes example: you can create an area numbered "15.68798" just by typing that number when in the transfer area itself (sysop level). Omni's message base is similar - just type a number and you have created the area. Areas with more than two decimal places must be entered by typing the number itself, and are not part of the new-files scan, which deals only with areas 1, 1.01 - 1.99, 2, 2.01 - 2.99, and so on. In new files browse mode, Omni only scans up to 1910 areas. <GEOS-TIM> At this point, we are going into some questions a person that is going into using Omni 128 might want to know. Greg Noggle who is considering using Omni is going to host this section. <Greg> Thanks Tim. Brian, what in your opinion is the One best feature of the Omni BBS system? <B.Bell> I think the number 1 best feature is the fact that Omni has reliable support for the SwiftLink 232 cart when used along with the RAMLink unit. This is very important in these times when fast modems are cheap and callers want to be able to call a BBS with a high speed modem. It is the number one reason mentioned by callers who are requesting my system - they get many more calls with a high speed modem in areas where C-64's have dwindled. I spent a long time figuring out the intricasies of SwiftLink when it was still in it's early stages ( got one when Dr Evil was just transferring control to C.M.D.). Though many BBS's now have SL-232 support, I was the first commercial BBS program to use it, and I am told that it is the most reliable usage out there for the 128 today. So, that's what I consider the most important feature in terms of todays C= sysops and callers. <Greg> Thank you,I stilll got a few more here :) What kind of term programs can a user call into a omni system with i.e RIP, VT100, Commodore Graphics, ETC. <B.Bell> A caller can access the BBS using any of the several standard terminal types, and special support for some of the more exotic emulations is in place. A caller can use (of course) ASCII, Commodore 40 or 80 column color graphics, 80 column ANSI/VT-102/100, the before mentioned "SupeResterm" and RIP terms (Remote Imaging Protocol). Omni automatically detects ANSI mode, SupeRes mode, and RIP term mode, and displays appropriate menus for each emulation. RIP support is installed and more screens are being written and added to by other sysops and their friends each month. I am working on getting every single area of the BBS operational via RIP buttons, which will make remote control quite pleasant when calling from a computer using that protocol. There are multiple random intro screens possible in all the main modes (as well as logoff), and the ANSI/RIP/SupeRes output is all done direct to the modem for maximum speed. On these types of menus and screens, the local BBS side only shows a small message that the data is being output. I have PC BBS sysop friends who are impressed by the menu output speed. <Greg> Now other BBS programs like Color 64 support a Network does Omni? <B.Bell> Omni has a network which was originally based on the standard Color 64 network style, but evolved into two different directions - a stock mode which communicates and translates messages from Omni to Color 64 networked BBS's, and a more advanced mode with extended features used between two Omni systems. The networking system as it exists today is to remain in place and be used for "crash mail" or direct mail and bulletins, while I continue work on a more wide reaching net-system. This new network is being designed to be a "gateway" between different network systems. Primarily it consists of a backbone and hubs which carry master copies of networked message base areas, and the more numerous nodes which call in and maintain their desired message areas. Information from the "big" networks will flow into one or more of the backbone boards and be echoed to those systems that wish to "carry" specific topics. It should not matter which networks out there supply the information using this method. The current plan is to tap into the FIDO system in a passive way, automatically receiving and eventually sending messages back to that system. However, I'm lately more interested in USENET and internet groups for sources of information. There are some problems in establishing a fully functioning FIDOnet point on a C-128 - (practical problems) but no such difficulties using a cheap PC - or Amiga to "serve" the C= based BBS. So, I have written some scripting programs which allow messages to move to and from a FIDO node. - Because FIDO rules prohibit posting messages from "point" systems, it will be necessary for a full node to be established. These rules may not apply to internet data, hence the interest in that direction. <Greg> Well to the truth this is the reason why I am interested in the Omni system so I m going to indulge myself a little here. I have a fido net system here that gets the usenet use groups and has internet email capibilites also,and I want to point offf him,so would it be possible for other sysops to be a backbone for your envisioned omni network? <B.Bell> Yes - the backbones on the Omni system will be selected according to those who can invest in sufficient hard drive space, and likely the 28.8k modems - before other sysops do. I already know at least three other Omni sysops who are interested in helping form a good backbone for this network. And it should be stressed that the message base on each Omni board will also be networked together, - as I see a need for a direct echoed support base, for one major topic. By having the Omni's in their own domain - there will less delay and possible data loss which is so common on networks like FIDO, which seems to have reached it's practical size limit. Whether internet or FIDO feeds are requested by a particular sysop on our network, there will definately be a lot of interesting activity considering the number of BBS's that will participate. I am planning the structure well so as not to be plagued by duplicate messages or the usual "chaotic" appearance of most networks and IBM message bases. I am seeing to it that the networked message areas will read as close to nicely linked threads as possible. :) <Greg> Well thats it for me on this topic,thank you! <B.Bell> You are welcome Greg! <GEOS-TIM> We are going into the topic of what an experienced user of Omni 128 has to ask. Doc Tuomi is going to host this topic. <Doctor> Hello, everyone. Thanks for the introduction. Now, Brian. Omni BBS has its own built in scripting system. What are some of the ways which a sysop can use this built in scripting to do complex tasks on the BBS? And please define what scripting is on the BBS. <B.Bell> I'm glad you asked that. Omni's scripting system is built on an original "stacked command" option, which has undergone a few changes over the past couple years. First, a stack command is a group of standard BBS commands (both hotkeyed or multiple charactered) which execute in sequence. A stacked command can be up to 256 characters in more cases and each command is separated by a semi-colon (like on GEnie!). The scripting system allows you to write a file containing a stacked command string, and which you can also chain to other scripts if you need longer jobs done. Scripts are useful for many repetetive tasks which are done each night (in fact, special jobs at midnight update is one of the most common uses of stacks). They can do jobs like posting messages automatically in a specific message area, perform a specialized file copy operation, - well, just about any task that you want automated. The scripting language is not designed to sense "conditionals" but merely executes the commands in the exact order they are written. Even with this limitation, it is possible to do very powerful things with them. The can rename files on certain dates (for special greetings), perform "blind" jobs which will always be the same, etc. I'm probably missing some of the uses at this point, but you get the idea. <Doctor> Very nice. Omni 128 also has a feature which allows the BBS to shut itself down and run an external program. How would this be useful? And what sort of external programs are available? <B.Bell> The external program runner in Omni lets you define a non-BBS program such as a BASIC 7 or compiled program completely unrelated to the BBS to be executed by the BBS at a specific time and date or manually. This is especially useful for sysops who want to write programs that do not run within the more complex Omni environment - i.e. they can be written to run like regular BASIC or compiled programs, which is somewhat easier than writing a BBS module. Many more people are familiar with programming in their own way then to have to adhere to a specific set of rules that are new to them. - program currently using this - Ben Holmes has written a module (which is compiled in Blitz 128) to general an "AllFiles" listing of the entire contents of a BBS's transfer area. Another example is my "rl-back.c" program, which is executed to back the RAMLink up to an image file when it is desired. (mine runs at Midnight). Again, you can write online modules to do such tasks, but it is nice to be able to forget most all rules and just write like you would write a free-standing program. Note: for automatic re-starting of the BBS, a small command line is used at the finish of the external program. <Doctor> Okay, what sort of programs come with the BBS. And is it difficult to write modules that run 'under' the BBS? <B.Bell> The BBS has a whole range of program modules which cover the main functions of a BBS (like the message base and transfer area we discussed above) to programs like the built in terminal, modules for subops and sysops to control various features of the BBS, and online games. The "FILE COPIER" is one example of a relatively advanced module - and provides just about any combination of file copying and translation you might need today. (IBMascii/PETascii, UNIX-Amiga to PETascii, etc.). Actually, writing modules for the system can be smaller and easier then it is to write free-standing programs - but a little experience with the system is desireable. There are some real small game modules which provide good basic starting points for writing your own applications. <GEOS-TIM> Thanks for your insightful questions, Greg and Doc. Brian, I understand that a comprehensive manual for Omni sysops is in the offing What is the target date for release of the manual? What does the purchaser of Omni 128 get for printed documentation now? <B.Bell> The manual is being built of the years of accumulated wisdom of both sysops and the text documentation and notes gathered in the same period. It has turned out to be rather large in size, but I expect the first printing for to be complete before the summer is over. The purchaser of the system currently gets two documents - an 18 page "setup" and operational guide, complete with a hardware and trouble shooting checklist, and a large archive of chronological update texts, which amounts to about 170,000 bytes of text covering upgrades and additions to the system since 1991. There is also around 8 separate message base areas dealing with both the hardware and software aspects of the BBS, all accessable to the registered sysop. A public information base also contains some useful information. I do not weed the sysop support areas so all the information is there for reference and buffering. I also provide support via received FAXes and general targeted answers direct in the message base so all sysops can benefit from the questions that many might ask otherwise. <GEOS-TIM> Where can Omni 128 be purchased, and for how much? <B.Bell> First, I recommend that the interested sysop procure a copy of the information on the system, which I have in my message base area 9, in my transfer area 13, and soon to be uploaded here. (My BBS # is (206) 536-9353). I will also mail the information packet to anyone who requests info. Cost for the system is $65.00 U.S., and the manual is $15 when completed. Most sysops are pre-paid on the manual already. It's getting close now. <GEOS-TIM> Going over the answers that you have given tonight. I see there are quite a few future developments in the works. Access to Usernet, protocols, etc. Is there any we have missed tonight? <B.Bell> Yes, there are and will always be more to do with this system. Besides generally compacting and improving the general BBS itself, I have plans to implement some type of full-screen editor for ANSI mode, complete my work on .QWK packet support (another way for passive networking with any .QWK based BBS), and implement some form of compression for the text data online. A custom protocol for the new network is also a highly desireable goal. <GEOS-TIM> This certainly has been a comprehensive and interesting conference. I had no idea that a Commodore BBS program had so many features. I would like to thank my co hosts Greg Noggle, and Doc Tuomi for their great questions, and help in planning this conference. <Doctor> Thank you, Tim. <Greg> your welcome tim <GEOS-TIM> Brian you have done a great job of informing us of the features of Omni 128. And I want to thank you for coming in tonight. <B.Bell> Thanks for having me in here. I'll be available at any time if needed. <GEOS-TIM> I understand that you will be putting some information on our bullitin boards here in the Commodore area <B.Bell> Yes - I'll prepare an update of my BBS features list (many, many things were not covered, believe it or not) and will post it in the telecom area here. Also will see about uploading a text file concerning the system to the appropriate library in this area. <GEOS-TIM> I was about to suggest such an upload. Sounds like a lot of material. We are going into open forum and I'd like to thank everyone for coming.