Más de 2,500 Juegos

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

/ Más de 2,500 Juegos / CD2.iso / zipdat / 1347 / 1347.txt next >

Wrap

Text File | 1992-04-21 | 37.9 KB | 961 lines

____________________ / \ / Binary Armageddon (TM) \ / B.A.C.S. v1.40 \ ----------===========< By: Ed T. Toton III >===========---------- \ (c) copyright 1992 / \ All rights reserved. / \______________________/ Special thanks to Jeremy Kusnetz & Kenneth B. Foreman & Erik McClenney B.A.C.S. = (c) 1992 = Ed T. Toton III pg 0 --- Table of Contents --- Acronyms..........................................2 Overview, history, etc............................2 Things you should have............................4 Using BACS........................................4 Programming.......................................5 Variables/Labels.................................10 Staging a competition............................11 Trouble-shooting and Speed-control...............11 Legal stuff......................................12 Other Software...................................13 Final Notes......................................14 Changes..........................................15 [ ED. Note- It is HIGHLY suggested that you make a print-out of this file! ] B.A.C.S. = (c) 1992 = Ed T. Toton III pg 1 ----------------------------------------------------------------------------- ACRONYMS AND TERMINOLOGY In this documentation, I will be referring to several things which I will need to briefly describe here. Some are acronyms, some are abbreviations, the rest are simple terms. Term: Description: BA =Binary Armageddon BABL =The programming language. Pronounced "Babble". (Binary Armageddon Basic Language) BACS =acronym- Binary Armageddon Core Simulator. this is the program for which the documentation was written. Op Code =Operational Code. Op-Codes are the numbers that represent various commands in a program, and are what BACS actually interprets to execute the instructions. RAM =Random Access Memory ----------------------------------------------------------------------------- OVERVIEW, HISTORY, ORIGIN, CORE WARS, Etc.. Binary Armageddon is a game in which you write battle programs, and pit them against each other in a fight to the death. The programs are placed in the memory core in random locations, and none of them know where the others are. Some will be offensive, bashing everything, others may be more defensive and move out of the way of an oncoming rampamt program... The idea of programs battling one another within a computer is by no means a new idea. A number of years ago, some researchers from the Massachussetts Institute of Technology were working on artificial intelligence at AT&T's Bell Laboratories and at the Xerox Corporation research center. These programmers would on occasion rewrite various programs to eat each other, after their collegues had left for the day. This was the beginnning of what is now called "Core Wars". Here programmers would match wits by writing programs that would do battle with one another in the core of the mainframe. Eventually, Core Wars were banned in the workplace after a Xerox 530 became infested with these programs, and thus was the first computer to have a serious virus problem. But this was not the end, for in 1983, in a speech the ideas came forth, and in 1984 an article appeared in Scientific American containing information on viruses and Core Wars, and offered more details on writing them for a small fee of $2. At this point A. K. Dewdney and his friend David Jones started developing the game of Core Wars. They devised a system that would allow for writing simplistic programs in an assembly like language, and to have them battle within a simulated mainframe on a personal computer. They developed a programming language for it called Redcode, and a simulator called MARS (Memory Array Redcode Simulator). B.A.C.S. = (c) 1992 = Ed T. Toton III pg 2 Now where does Binary Armageddon come in? Well, a few weeks before I wrote this, I had come across some information pertaining to Core Wars, the original mainframe battles. I thought it would be fantastic to be able to simulate this on an IBM compatable computer, and set forth to create Binary Armageddon. But I had some difficulties in the design, there were holes in my plan. At this point I discovered Dewdney's Core Wars, and Redcode, and so forth. After seeing what they had done, it was a simple matter to incorporate a few of the ideas and finish Binary Armageddon. Binary Armageddon is being developed with the idea that programs written in it's language can compete against programs written in Redcode. This feature is now fairly well implemented, and should work. If you spot any problems, please contact me. To run a redcode program in BACS, you must insert a line at the top of the Redcode program that says "-Redcode". For more details, consult the file REDCODE.TXT. In BACS (pronounced "backs"), the programming language (BABL, which is pronounced "Babble") is a cross between PC assembly, ATRA (pronounced "Ay-truh", stands for Advanced T-Robots Assembly), and Redcode. The language is considerably different from Redcode in it's syntax, but all Redcode's commands are supported, and thus with a simple re-wording of them, most redcode programs can be converted to BACS. The programs DWARF.BA, IMP.BA, GEMINI.BA, and MEGAMOVE.BA were all originally written in Redcode, and have been converted in this manner. Now just what is all this? Binary Armageddon is the name of the game, and the game could feasibly be implemented in various manners, using different simulator programs. BACS is the name of the program itself for which this documentation was written. BACS is a program that allows you to play Binary Armageddon. In Binary Armageddon, you will write programs that will battle one another in a fight to the death. The programming language is very similar to assembly language, with some major differences. If you don't already know a fair amount about programming, you should stop here. You can pit up to 16 programs against each other at a time, and the graphic display on the screen shows all 8000 memory locations at once. These memory locations are color coded, and the colors can represent either the commands that are contained at those locations, or they can represent which program they belong to. You can switch between the two color options during the battle, thus allowing for a massive amount of flexibility, and provides for the maximum informative output possible during runtime. For more information, consult some of these fine books listed below... Bibliography: "Computer Viruses, Worms, Data Diddlers, Killer Programs, and Other Threats to your System." By John McAfee and Colin Haynes. 1989, St. Martin's Press, New York. "The Magic Machine, A Handbook of Computer Sorcery" by A. K. Dewdney 1990, W. H. Freeman and Company, New York B.A.C.S. = (c) 1992 = Ed T. Toton III pg 3 ----------------------------------------------------------------------------- THINGS YOU SHOULD HAVE Note- If you don't have an EGA or VGA, you're stuck unless you intend to run the program in trace mode all the time (yuck!). You need a text editor! Writing programs will be very difficult without one. DOS 5.0 has a nice editor (that's what I'm using to write this), or you can use a programming environment (like Turbo Pascal or C or Quick-Basic), or you can even use some word processors. If you use basic or or something like Word Perfect, you will need to remember to save it as "dos text" or "ascii format". Here are the files you should have: BA.EXE - The Binary Armageddon system (BACS). BA.DOC - This file. COMMENTS.TXT - File to read others' comments and for you to write comments of your own BADEMO.DAT - A sample config file BADEMO.BAT - A batch file to run the demo. PARABOLA.BA \ DWARF.BA >- These are some sample programs. SCRAMBLE.BA / ????????.BA - Other programs written for use with this BA. REDCODE.TXT - A description of how to convert Redcode to BABL, and the differences between them, and so forth.. ----------------------------------------------------------------------------- USING BACS Operating BACS is quite simple. The syntax to run it is simply "BA <config>" where <config> is the filename of the configuration file you wish to use. The config file is simply a text file telling BACS which programs to use in the simulation, and what settings to use. Here is an example: -d0 dwarf.ba parabola.ba In this example, BACS would load dwarf and parabola, and run the simulation with a speed delay of 0. Here is a list of all the paramers available: Item: Description: -D# Sets the delay in hundreds of a second (minimum period of time for each cycle in the simulation). Defaults to 1. -P# Sets the number of cycles between each timer check for the delay. Defaults to 1. -O Sets the color coding system to color by ownership instead of color by command. -CN Turns off the on-screen counter display. -T Trace mode. No graphics, simply an output showing what command each program is executing. Not very useful, was mostly used for testing BACS. B.A.C.S. = (c) 1992 = Ed T. Toton III pg 4 There are also a few keyboard commands you will want to know: Key: Description: Q Quit C Toggle counter display O Toggle color code mode P Pause Note that during trace mode, you can always press Ctrl-Break to exit it if 'Q' doesn't work (there is an on-screen pause, and on faster computers you may not have time to press 'Q' between pauses). In BACS, the screen is divided into several regions. The most important of which is the main window. In here is a graphic representation of the entire memory core. Each memory location is represented by a small rectangle within the window. These locations will be color coded. As to what the colors mean, well, that depends on which mode you have selected, and over on the left side of the screen it will show what the colors represent. The secondary region surrounds the first, and this is where the list of keyboard commands, the counter, and the lists of the color codes are kept. ----------------------------------------------------------------------------- PROGRAMMING in BABL It is unavoidable that in order to play Binary Armageddon, you must know how to make battle programs. The programming language is very similar to assembly, and has some similarities to Redcode which is used for Core Wars. Now remember, I can't teach you to program in general, entire text books have been written on the subject. All I can do is teach the commands. First off, some basics about how Binary Armageddon works. All the competing programs run simultaneously, taking turns executing instructions. This simulates multi-user systems on mainframes in that each program can operate in a simplistic manner, unaware of what the other programs do. Each program will continue to run until it tries to execute an invalid command, at which time it is considered dead. Some examples of invalid commands are "DATA" statements, and attempts to assign values to immediates, as outlined below. The simulation will also end when the cycle count gets to 65,536 (in other words, when the cycle count gets too large to store in one 16-bit number). At this time the game will be declared a draw. The memory core consists of 8000 memory locations, numbered 0 to 7999. The core is "circular", and thus absolute addressing is fairly useless. Since it is circular, you can tell BACS to deal with a memory location outside of the 8000, and have it "loop" around. For instance, if you want to write to memory location 9022, BACS will interpret that as 1022. Any number, positive or negative, will be looped around as much as necessary to get the intended effect. B.A.C.S. = (c) 1992 = Ed T. Toton III pg 5 All commands use a relative addressing system, instead of an absolute system. For instance, if you try to access location 1000, it won't be the 1000th location from the start of memory that you access. Rather, you will access the 1000th location from the command that is being presently executed. The statement "JMP 0" would be an endless loop, since it would send the instruction pointer 0 locations away, and thus execute the same command over and over. "JMP 1" would do nothing, effectively a "NOP" (No-Operation), since the IP (instruction pointer) would move along anyway. The addressing system is further simplified by the fact that each command is considered to take only one location in memory, as you may have already figured out. Adressing can be done in several manners. Operands can be any of four types. They are Registers, Immediates, direct addresses, and indirect addresses. An immediate is a number, plain and simple. In basic, if you were to say "let x = 5", the '5' is an immediate. Immediates can be used to specify specific numbers, but attempting to assign a value to one is an invalid operation, and thus your program will die. Immediates are assumed if a number is encountered with no difinitive symbol. However, just to be safe, you may want to use it's symbol anyway, which is a "#". A direct address is a memory location. These are denoted by a "@". Whatever number follows the "@" is the relative location in memory to look for the value to use, or the relative location to deal with. An example would be: DATA 5 MOV @-1 #9 In this example, the data starts off being 5, then the MOV command changes it to 9. Since the destination of the MOV is "@-1", it looks at the location 1 command back to set to the value of 9. An indirect address is a system for storing addresses in data areas. These are denoted by the symbol "&". Here is an example... DATA 3 MOV &-1 #9 JMP 5 DATA 0 In this example, the MOV command looks back one location, finds the 3, then looks forward 3 locations from the "DATA 3" statement to set the SECOND data statement equal to 9. It's very important that you understand how this works. The second data statement is 3 away from the first, and thus you need a 3 there. The addresses are thus cumulative (-1 + 3 = 2). The simplist program possible is called IMP. It consists of only one command. Here it is: MOV @1 @0 B.A.C.S. = (c) 1992 = Ed T. Toton III pg 6 Imp takes everything at location 0 (the MOV command itself, and all it's operands) and copies it to location 1 (the next line down). The instruction pointer will of course move to the next line afterwards, which is an exact copy of the MOV command. So, Imp goes rifing through the memory core at high speeds leaving a trail of old used MOV commands. Often times when Imp ploughs through another program, the other will end up executed one of Imp's old MOV's and thus become another Imp. In this event you will probably have a draw, since you will have multiple Imps chasing each other throughout eternity. You may want to ban these from competitions. And now for a library of the commands: Op-Code: Command: Operands: Description: 0 DATA B Sets up data area, initial value of B 1 MOV A B Sets A equal to B, (B unchanged) 2 ADD A B Sets A equal to A+B (B unchanged) 3 SUB A B Sets A equal to A-B (B unchanged) 27 MUL A B Sets A equal to A*B (B unchanged) 28 DIV A B Sets A equal to A/B (B unchanged) (returns integer part of quotient) 29 MOD A B Sets A equal to A mod B (B unchanged) (returns remainder of A/B) 4 JMP A Jumps to location A (A unchanged) 5 CMP A B Compares A and B, neither changed, result stored in CZ register. 6 JNE A Jumps to A if result of comparison is NOT EQUAL (CZ <> 0) 7 JEQ A Jumps to A if result of comparison is EQUAL (CZ = 0) 8 JLS A Jumps to A if result of comparison is LESS THAN (CZ < 0) 9 JGR A Jumps to A if result of comparison is GREATER THAN (CZ > 0) B.A.C.S. = (c) 1992 = Ed T. Toton III pg 7 10 IFE A B If A = B, then this will execute the whatever command follows it. Otherwise it will skip it. 11 IFN A B If A <> B, then this will execute the whatever command follows it. Otherwise it will skip it. 12 IFG A B If A > B, then this will execute the whatever command follows it. Otherwise it will skip it. 13 IFL A B If A < B, then this will execute the whatever command follows it. Otherwise it will skip it. 14 LOOP A Decrements the CT register. If CT is greater than 0 after decrement, then it will jump to A. 15 DO A For use with LOOP. This sets the CT register equal to A. 16 DJZ A B Decrement number at location B (no immediates for B!). Then if it is equal to 0, it'll jump to A. 30 DJN A B Decrement number at location B (no immediates for B!). Then if it is not equal to 0, it'll jump to A. 17 JMG A B Jumps to A if value at location B is greater than 0 (no immediates for B!) 18 JMZ A B Jumps to A if value at location B is equal to 0 (no immediates for B!) 19 XOR A B Bit-operator: Sets A equal to "A xor B" (B unchanged) 20 OR A B Bit-operator: Sets A equal to "A or B" (B unchanged) 21 AND A B Bit-operator: Sets A equal to "A and B" (B unchanged) 22 NOT A Bit-operator: Sets A equal to "NOT A" 23 SHL A B Bit-shifts A left B times (B unchanged) 24 SHR A B Bit-shifts A right B times (B unchanged) 25 ROL A B Bit-rotates A left B times (B unchanged) 26 ROR A B Bit-rotates A right B times (B unchanged) B.A.C.S. = (c) 1992 = Ed T. Toton III pg 8 31 PUT1 A B Sets the FIRST operand at location A to equal B. (note that using MOV will result in the target becoming a DATA statement. This can be used to edit commands in the core). 32 PUT2 A B Sets the SECOND operand at location A to equal B. (See note for PUT1). IMPORTANT NOTE- The commands MOV and CMP deal ONLY with the second operand of the target memory location when one of their own operands isn't a memory address. If they are both addresses, then they will deal with the target location as a WHOLE. A CMP will turn up negative if you compare "ADD @5 1" and "SUB @5 1" using a command similiar to "CMP @1 @2". If you don't want this to happen, use 'IFE' or a similar command. MOV -WILL- change the statement at the target address to a DATA statement if you assign it an immediate or a value from a register (example: "MOV @-1, #0"). All other commands that modify a memory location (except MOV) will change only the one operand. The registers: The registers are there for you to have a handy storage place for numbers. You have 8 at your disposal. There are 10 in all, one is used for loop counts, and the other is used for comparisons. By changing these you can confuse and trick the other commands into doing things! Here they are: AX, AY, AZ, BX, BY, BZ, CX, CY, CZ, CT CT is for loop counts, and CZ is used for comparisons. Note that you can't have DO..LOOPS inside one another (nested loops) unless you plan ahead and deal with the CT register. Here is an example of how you should go about making nested loops: DATA 0 ADD @-1 #1 DO 5 MOV CX CT DO 8 ADD @-5, 10 LOOP -1 MOV CT, CX LOOP -5 B.A.C.S. = (c) 1992 = Ed T. Toton III pg 9 In this example, the program sets the data area to 0. The net line adds 1, thus making it 1. After that, the CT register is set to 5 by the DO command, and is then stored in CX. After the inner loop is executed 8 times (adding 10 to the data value each time), the CT register is restored from CX, and the outer loop runs as iff there were never another loop. Since the CT register was 5, the entire thing is repeated 5 times, for a total of 40 ADD commands. At the very end, the data value is 401. I realize that this documentation makes the programming appear more complex than it really is. The best thing you can do is play with the sample programs and to see how they work. You'll find that most of the time, the registers and bit-operators are rarely used. They are provided to allow for more interesting and creative programs, but you need not understand them to create perfectly functional ones. ----------------------------------------------------------------------------- VARIABLE/LABELS This new feature will infinitely improve ease of programming for everyone out there. I have no doubt of this. Whenever the compiler encounters a label, it takes note of the location, and uses it to compile commands found later that access the label. You can use labels as you would in other languages, and as pseudo-variables. Here's an example: :Main do 5 mov &-2, 1 loop -1 jmp 2 :mynumber data 0 add @mynumber, #1 jmp main In this example, the program starts off doing a loop (5 times) that sets a memory location equal to one. We cannot see what memory location is being changed, since the program segment is incomplete, but that is unimportant. After the loop is complete, the "jmp 2" command jumps over the data (remember that labels do not count as commands), and executes the ADD command. This command adds one to the data statement preceding it. The '@' symbol must still be there, but the compiler figures out the number for you since you put the label name after it. Once that is complete, it executes a jump and starts the program over. You don't need a '@' here, since you normally don't need one anyway. THE LABEL REPLACES THE NUMBER ONLY, NO EXCEPTIONS. But again, the compiler figures out the number for you. Note that labels MUST be located before ALL commands that access them. There's no way around that. Also note that you may define up to 80 of them. For an example of a program that uses labels, see SCANMAN.BA. B.A.C.S. = (c) 1992 = Ed T. Toton III pg 10 ----------------------------------------------------------------------------- STAGING A COMPETITION First off, gather a few friends who are interested and show some level of enthusiasm (I know from experience it is almost impossible to force people to play!! Heheh <grin>). Then, you will need to decide on rules. If you wish you can set maximum and minimum program size limitations, or whatever. Also decide how long you have in which to complete your program. You may also want to decide in advance how many matches will be run. You could do something like ten matches, and whichever program wins the most wins altogether. You should also decide if you want teams. You could feasibly have teams of programs working together. It may prove interesting! Once everything is all together, run the simulation and watch!!! ----------------------------------------------------------------------------- TROUBLE-SHOOTING & SPEED-CONTROL The BACS program is basically fully automatic and self-contained. It will probably either work or it won't. If there is a problem, most likely (but not definitely) you are out of luck. Here are some possible causes of your difficulty: 1. Not enough memory. 2. Incompatable graphics adapter. 3. Damaged copy of BACS. 4. Computer is not sufficiently IBM compatable. 5. You haven't followed any of the instructions. 6. Computer is damaged or not performing properly. 7. You're using too early a version of DOS. (suggest DOS 3.3 or higher) If you HAVE gotten the program to run, but it's too slow, there are some things you can do to speed it up. First, You can try putting only 2 or 3 programs in the arena at once. You will find that the program slows down alot when you put a lot in. Another thing you can do is put the -D0 setting in. That will turn off the delay that is placed in the program to keep it running at the proper speed on faster computers. Another thing that can be done to speed up the simulation is to turn off the on-screen cycle counter. On a 12 mhz 286 computer, it has proven to speed up by over 5 times (rough estimation) after the counter was turned off. If the problem is that the program runs TOO fast, then put the -D1 setting in. The -P thing can be used as well to compensate for for excessive speed changes in the -D setting. B.A.C.S. = (c) 1992 = Ed T. Toton III pg 11 The correlation between -D and -P needs to be explained. The delay will be implemented every P cycles. Now here's how the delay works: If the number of hundredths of a second (as determined by -D) haven't gone by yet, then the program will sit and wait for the time to go by. If the amount of time HAS gone by, then it doesn't bother to wait for it. So if you set -P10 and -D10, you will probably not see any effect at all (unless your computer is pretty fast), simply because it will probably take more than ten hundredths (or rather one tenth) of a second to perform 10 cycles. ----------------------------------------------------------------------------- NOTICE: This program is being distributed on the "shareware" concept. It is by no means completely free. If you think the program is of use to you, please send a registration fee of $14. If you think that is rediculous, then send less (or more for that matter). If you hate the program or found too many bugs, write me and tell me, and include a graphic explanation (but don't be too harsh!! Heheheh). In any event, write to: Ed T. Toton III 7101 Talisman Lane Columbia Md 21045 And WHY should you register it? 1. Because you're supposed to. If you use BACS somehwat often, or several people use a copy off the same computer, or you keep it on your hard drive for lengthy periods, then it should be registered! 2. To support my continuing efforts to bring you some level of functional programs. If I get no cash, you get no improvements in these programs, and I won't be encouraged to make new and better software! 3. To get that warm glow for knowing that you supported the author of at least one of the many shareware programs you probably use. 4. To find out if there is a newer version. All you need to do is ask! But letters with money take priority! 5. You could be sick and demented and thus register everything you get your hands on. 6. To get a registered copy of StratSys 2.0!! If you register this program you will recieve a registered copy of StratSys 2.0 in the mail (please tell me what disk type you want). StratSys is VGA & Mouse required, and is explained in detail below... 7. To find out about my other programs you need only ask! But again, letters with money take precedence. Source code is not yet available. It may be in later versions. B.A.C.S. = (c) 1992 = Ed T. Toton III pg 12 ----------------------------------------------------------------------------- DISCLAIMER: This program is provided "AS IS" and I make no gauruntees about it's performance. I will not be and can not be held responsible for any damages incurred during it's use, or as a result of it's use. It's on a "use at your own risk" basis. Nothing at all should happen, the program is harmless, but I have to say it anyway. ----------------------------------------------------------------------------- COPYRIGHT: This program may be freely distributed (which is actually encouraged) AS IS. No one may modify this program in ANY way. ESPECIALLY where names and credit is given, and INCLUDING all the documentation, data files, and executable program files. It may NOT be used for comercial or profit-turning ventures of any kind, including sale by disk vendors, without the written consent by ME, with ONE exception: Disk vendors MAY sell it without my written consent ONLY if they charge no more than $5 higher then the cost of the disk (excluding any shipping and handling charges). NOTHING may be added to it either (except in the case of writing to the file COMMENTS.TXT, and in the case of adding more robot program files). NO BBS ads are allowed EXCEPT as zip comments, or as a single SEPERATE text file. Any programs you write for use with Binary Armageddon are yours and you may what you wish with them. It is encouraged that you distribute programs around as well as this program. ----------------------------------------------------------------------------- OTHER SOFTWARE: I have made several programs (not including the 7 or so games I made in quick-basic a while back) that may be of interest to you. Here is a list of some of them: (as of 4/17/92) Blaze v2.6 : =VGA screen-saver. Supports password security, and a customization system (config file). Has been known to travel quickly through BBS's. CompWar v2.6 : =Latest release of CompWar, the on-line game for use with WWIV BBS systems. Date-Matcher v1.2 : =On-line match-maker program for BBS's that support DOS interrupt driven door programs (such as WWIV). T-Robots v2.0 : =(one of my masterpeices) T-Robots is a system in which you program robots to fight one another. It uses a simple programming language, and you create the programs with your favorite text-editor. Great for competitions! Supports VGA, EGA, CGA, MCGA, Hercules, and many more graphics devices. B.A.C.S. = (c) 1992 = Ed T. Toton III pg 13 AT-Robots v1.0 : =Advanced T-robots. Extremely similar to T-Robots 2.0 except the system has been improved. It supports most graphics adapters in existance (CGA, EGA, VGA, MCGA, Hercules, etc). In this one you program the robots using ATR assembly (Advanced T-Robots Assembly). Now you design your own subroutines, and access specific device ports and memory locations. The ultimate in competions of logical thought. StratSys v2.0 : =A 2-player VGA combat strategy game. VERY flexible. Comes with 4 game scenarios (Cival War, Naval Battle, Robot Conquest, and a medieval scenario). Expansion packs are available (at the moment one with 12 scenarios). Comes with an editor for the images and maps, so you can make your own scenarios! My-Gags set 2.1 : =A set of small gag programs that I have made. They are designed to be placed in the autoexec.bat file. Over Half of them are TSR's, including one that creates "line-noise" through the keyboard buffer, one that beeps occasionally, and one that keeps changing you caps-lock/numlock/scroll-lock. Toton Utilities 1.0 =A set of 8 SMALL but potentially useful utilities. Most are TSR's. Several of them make alternate drive-lights out of other peripherals. You can make a drive LED on your screen in the corner, or make your scroll-lock act as a drive light. Included is also a program to make clicking sounds as you press keys, and a program to turn your num-lock off during boot-up (for those of you that hate your num-lock staying on after boot-up). ----------------------------------------------------------------------------- FINAL NOTE: If you have any questions, concerns, suggestions, criticisms, donations, remarks, praise or opinions, please write! I WANT TO HEAR FROM YOU!! (the address is listed above). Ed T. Toton III "Necromancer" -1992 B.A.C.S. = (c) 1992 = Ed T. Toton III pg 14 Oh, and one more thing. Your comments are welcome! If there are any statements or comments or suggestions you would like to make to those who later try to use BACS, please feel free to add them to the file called COMMENTS.TXT. And if you think the comments are good (either yours, or the ones already in your COMMENTS.TXT file), please send them to me! I might make them a part of the next release of the program (if there is one). ----------------------------------------------------------------------------- CHANGES: 1.1 - The CMP command functions properly now. It used to not work. I still can't believe we diodn't spot this sooner. 1.2 - Redcode support is now complete and functional. See the file "Redcode.Txt" for details. - Variables/Labels are now supported!!! 1.21 - Minor documentation changes. 1.3 - The color-coding system for the commands has been rearranged to be more meaningful. Commands of similar function have been grouped to have similar colors. - Four new commands added: DJN, MUL, DIV, MOD 1.4 - Two new commands added, and a major revision to how some of the others worked (commands are no longer turned into DATA statements by commands such as ADD, SUB, etc.. Only MOV will zap the entire target location when changing anything. Everything else changes ONLY the second operand). - The two commands added are PUT1 and PUT2. B.A.C.S. = (c) 1992 = Ed T. Toton III pg 15