We have completed work on breaking out LarKen MaxCom into manageable pieces for the Timex-Sinclair 2068 computer. In so doing, memory Was found for some additional features, and processing speed is enhanced.
We discuss three different areas here, features gained and lost, a change in CODE for remote character input, and future prospects.
We break MaxCom out into two versions, BOTH with and without Dallas SmartWatch, four versions in all.
Features Gained and Lost
MaxCom.BX does not use the clock and implements remote input, BBS MODE. Additional features, beyond Larry’s product, include QUICKLOAD, BACKUP, LINE EDITOR, SWITCH MESSAGE BASE (at Larry’s suggestion,) expanded STATUS list, on-line users’ choice of four Message Bases, and lots of HELP FILES.
QUICKLOAD changes operating mode from MENU to BBS, while LOADing the GENERAL MESSAGES message base. BACKUP SAVEs program and variables to the current disk and reLOADs. QUIT performs a LarKen NEW operation on the RAMDISK, replacing MaxCom.BX with the AUTOSTART file on channel 4. The line editor is an amendment to the WRITE MESSAGE facility of the remote BBS. It is required by the half duplexity of the WRITES. The ability to switch to arbitrary MBs is available only to the SYSOP, since it accesses the system drive. Users already have a choice of four such MBs as well as many HELP files.
MaxCom.BT does the same as MaxCom.BX with addition of access to the DALLAS SmartWatch. We get time on, time off, elapsed time, current times, expressed in the STATUS reports and the stamping of remote message receipt.
TERMax.BX adds some features to Larry’s product also, such as QUICKLOAD, SQUEEZE Message Base, BACKUP, QUIT, ZAP remote messages, VIEW FILE, and LINE EDITOR, amended to message entry.
QUICKLOAD goes from MENU mode to Message Menu, while LOADing the GENERAL MESSAGES Message Base. First, SQUEEZE does a CAT of the system disk and then regains message slots, by moving active messages to occupy ZAPped message slots, freeing up their former locations for new messages. Progress is monitored by timely LISTs and STOPs, before proceeding with a CONTinue. You don’t want to lose anybody’s information now, do you? On the other hand, any message can be VIEWed and ZAPped here, too. Arbitrary ASCII files also can be VIEWed in either 32 columns or 64 columns.
TERMax.BT does the same as TERMax.BX with the addition of ability to READ the time stamps of messages plus some timing of its own.
Neither MaxCom,BX nor MaxCom.BT implements a CAPTURE buffer. There are no AUTODIAL facilities either. Thus, TERM mode (local access) is a little bit limited. There is, of course, less FREE RAM in any of these versions of LarKen MaxCom, due to the addition of so many features. And, lastly, duplexity has been reduced from FULL to HALF in the remote messaging system. The loss of FULL duplexity in trying to speed up LarKen MaxCom is what makes the line editor mandatory. For, with Larry, what you see-is-what-I-get. But now, what you see is what you requested. If you want to see what I get, then you have to go to EDIT.
With both versions of TERMax, we lose BBS mode and remote messaging, thus freeing up loging and commands sections for SQUEEZE, etc. Bottom line, we have less FREE RAM than with Larry’s product.
The BIG CHANGE in coding philosophy for remote messaging is one use of INPUT#7 for a message line, rather than as many as eighty uses of INKEY$7 for the same message line. Larry complimented us on the slow performance of the latter with FULL duplex, but Don Walterman’s use of the line editor convinced us to go with the former and HALF duplex. I mean, INKEYS#7 with FD is slow and gives immediate feedback on the integrity of the last character ENTERed. But, INPUT#7 with HD is FAST, and the integrity of ALL the lines ENTERed can be confirmed by POST-EDIT, a more satisfactory solution all around, except in the case of cheap-skates who don’t care what OUR version of THEIR message looks like
So now, message entry is RAPID and ACCURATE, subject only to a very minor irregularity in WORD-WRAP, which does not even show up in the received message.
Prospects
Our main interest in engineering is MODELING and SIMULATION. We have developed our own simulation language. Systems-Oriented Language, and we got into messaging, only as a way of sending SOL over the phone. We have found, that phone connections are conserved, even after performing a LOAD and a SAVE, at least they are under SOL BBS. And, we are anxious to report on the results of our continued attempts to SEND SOL. Think we’ll need to send graphics though. We’ll let you know in the pages of UPDATE magazine!!