8-Bit Software Online Conversion

                      Version 2.10 by Steven Flintham (15A) Technical information This section provides information which most users will not need but which may be of interest. It includes an explanation of some of the restrictions imposed by the program. Changes from version 2.00 The only change from version 2.00 is the introduction of a new file format. Version 2.10 cannot handle files created using earlier versions and vice versa. The program used by the editor to collect messages can handle both the new and old formats. This is partly to allow people to continue using older versions if they wish, but also for the reasons described below in 'Disc space and secrecy'. The new file format is described in detail below. It has the disadvantage that the message file is now extremely large (100K), but in return for this sacrifice it never needs to extend the message file and so there is no possible risk of a 'Can't Extend' error occurring. This makes it possible to have other files on the same disc. When first creating a new message file there must obviously be enough space on the disc for it. You may need to *COMPACT the disc first if there is more than 100K free but not all in one block. Disc space and secrecy In practice the large message file should not be a problem, as in the past most people were probably forced to dedicate a whole disc to the message file in a (not always successful) attempt to avoid 'Can't Extend' errors. However, if you are sending in a lot of submissions you may not want to waste 100K of the submission disc on the message file. If you need to reduce the amount of space required by the message file you can convert it into the old format, which is more compact. You should keep a copy of the new format version in case you wish to edit any of the messages in it. This will not make it any easier or harder for the editor to handle your messages, so do not go to the trouble of converting the message file in the belief that a smaller file will be quicker for the editor to deal with. (Of course, I just might be wrong about this; if so I'm sure he will point it out in a future issue.) Another reason for wanting to convert the message file to the old format is that in the new format, deleted messages may still be present and could (in theory) be read by the editor even though they will not be published. In the unlikely event that this is a problem for you, converting the file to the old format will get rid of all the deleted messages. To convert a new format message file to the old format just run the program New2Old and put the disc containing the message file in the drive when asked. It will be renamed to !MsgOld so that you have a copy and afterwards the !Mesg file will contain the messages in the old format. The message editor The main limitation of the message editor is the lack of any form of automatic paragraph reformatting when words are inserted and deleted. The real difficulty is that the editor allows the use of mode 7 control codes to implement colour and graphics. This means that any code to reformat paragraphs would have to try to keep any control codes inserted in the text to change the colour and it would ideally also have to avoid distorting any graphics in the message. Using filing systems other than DFS and ADFS The program is only designed to work with DFS and ADFS. If you have another filing system then the program may work but no guarantees can be given. Pressing SPACE at the prompt to insert your submission disc will leave the current filing system selected. The file format If you want to write any utilities which handle message files (or even write your own replacement message creation program!), the file !Mesg has the following format: Version byte - 0 at present (see below) Sender's ID - a three character string read using BASIC's INPUT £chan%, id$ command Sender's name - a twenty character string (padded with spaces at the end) read using BASIC's INPUT £chan%, name$ command. It may be just spaces if the sender wishes to remain anonymous. The file contains a fixed number of message 'slots', each of which may contain a message. At present there are 25, but you might wish to deduce the number from the length of the file using the formula ((EXT £chan%)-256)/4096. The message slots are numbered 0-24, with the nth message slot starting at offset 256+n*4096 within the file. Each message slot has the following format: Destination ID - a three character string read using BASIC's INPUT £chan%, id$ command Deleted flag - a single byte (see below) The message itself - pure mode 7 "text" containing control codes and terminated by a 152 byte Your program must complain if the version byte is not one, as this will indicate that the file format has changed. If you wish your program can try to handle earlier version 0 files as well. The deleted flag can be any of 0, 1 or 255. 1 means that this message slot contains random junk from when the message file was first created. In this case the message itself is not present and so you cannot rely on there being a 152 byte at any point following the deleted flag. A deleted flag of 0 means that this message slot contains a valid message which is to be published or sent on to the recipient. A deleted flag of 255 means that this message slot contains a valid message which has been deleted and will be ignored by the message collection program used by the editor. Message slots with a deleted flag of 255 can be sensibly 'undeleted' by setting their deleted flag to 0. When the messaging system adds a new message to the file it first tries to find a slot with a deleted flag of 1. If it succeeds, the new message is placed in that slot. If not, it tries to find a slot with a deleted flag of 255 and uses that, replacing the old deleted message. If this fails as well then there are no free slots in the file. The message itself must obviously be short enough to prevent it running over into the next message slot. The messaging system currently limits messages to 4080 bytes. Many thanks to Jon Ripley for his suggestions for a new file format. Although the new format is much simpler and cruder than his suggestion it is very loosely based on it.                   