Category : A Collection of Games for DOS and Windows
Archive   : BACS140.ZIP
Filename : BA.DOC

 
Output of file : BA.DOC contained in archive : BACS140.ZIP








____________________
/ \
/ 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 " where 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 ).

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


  3 Responses to “Category : A Collection of Games for DOS and Windows
Archive   : BACS140.ZIP
Filename : BA.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/