From: jesensky@nevrast.endor.cs.psu.edu (James J Jesensky) Subject: Need C code for crobots (C-robots?) Message-ID: <5hdHtphr4@cs.psu.edu> Date: Fri, 3 Jan 1992 03:35:08 GMT If anybody has C code for crobots (or C-robots) I'd be thankful for a copy through e-mail or the location of an ftp site. Thanks James Subject: New unix version of Core Wars available!!! From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Date: 3 Jan 92 16:48:34 GMT Message-ID: <4606@oucsace.cs.OHIOU.EDU> I have finally finished the program I set out to do a long time ago (just got lazy, that is all)! :-) I wrote it with intentions to write redcode that fully conforms to the '88 Standards, as well as for me to conduct tournaments in various ways. It comes with a curses display, which you may turn off and on at will. It is available at soda.berkeley.edu in the 'incoming' directory for the time being. It will hopefully get moved to the 'systems' directory at a later time. If you do not have ftp access, I will be more than happy to send it through mail (2 parts, shell archive). My EMail address is the following: sadkins@bigbird.cs.ohiou.edu <---- most of the time here sadkins@oucsace.cs.ohiou.edu <---- try here if mail problems Here is the FEATURES file that comes with my program: Core Wars Deluxe v1.1 ------------------------------------------------------------------------------- Here is what it has: 1) Assembles programs and loads them on the fly... this keeps the clutter of files down a bit. If one file has an error, then Core Wars is aborted without playing. All errors are fairly descriptive. 2) You may fight up to 16 programs at the same time in the arena, or you may opt to fight one program against a set of programs, or even conduct a full Round Robin event with every program fighting against each other, one at a time. There is also the ability to battle programs repeatedly and then display the total results. 3) You may specify a configuration file on the command line to change any of the default options. This allows you to change the size of the Core, number of cycles for each battle, the number of battles per game, whether you want statistics displayed, the fighting mode, etc. 4) There is a nice curses display for arena battles, keeping track of all programs fighting, their tasks, current cycle being executed and the final winner of the fight. You may change in the defaults file a number of options, such as refresh rate and fading of core (aging effect). Up to 16 programs can be monitored on this display. 5) I have a debugging mode where you can test one program if you choose. It has a lot of room for improvement, but it is a start. 6) Lots and lots more... I am going to have a job documenting this whole system, so I hope it is easy enough to use until then. Full around with the Configuration file some, you will find that you can do a lot of stuff! Scott Adkins sadkins@bigbird.cs.ohiou.edu From: wms@iwarp.intel.com (William Shubert) Subject: KotH downtime Message-ID: <1992Jan5.230023.7656@iWarp.intel.com> Date: Sun, 5 Jan 1992 23:00:23 GMT In case anybody didn't see my pre-holiday post, I was on vacation Dec. 21 until Jan. 5. I left KotH up, but on December 27 a network problem where I work crashed my system. Just today I came back and restarted King of the Hill and things are back to normal. -Bill (wms@iwarp.intel.com) -- Hi! I'm a .signature virus. Copy me into yours and join the fun! From: ASMQK@ASUACAD.BITNET Subject: Re: KotH downtime Message-ID: <92005.174019ASMQK@ASUACAD.BITNET> Date: 6 Jan 92 00:40:19 GMT What are the actual constans? Coresize, ... From: tpoindex@isis.cs.du.edu (Tom Poindexter) Subject: Re: Need C code for crobots (C-robots?) Message-ID: <1992Jan6.041654.3605@mnemosyne.cs.du.edu> Date: Mon, 6 Jan 92 04:16:54 GMT In article <5hdHtphr4@cs.psu.edu> jesensky@nevrast.endor.cs.psu.edu (James J Jesensky) writes: >If anybody has C code for crobots (or C-robots) I'd be thankful >for a copy through e-mail or the location of an ftp site. Thanks CROBOTS is not generally available via ftp or public sources. I license (still reasonable) the source to CROBOTS on a shareware basis. Those interested should contact me at this email address, or write to: Tom Poindexter 6864 Amherst Ct. Highlands Ranch, CO 80126 tpoindex@nyx.cs.du.edu Subject: Core Wars Deluxe From: sadkins@bird24.cs.ohiou.edu (Scott W. Adkins) Date: 8 Jan 92 21:40:31 GMT Message-ID: <4646@oucsace.cs.OHIOU.EDU> Hi there! I posted an article about a week ago that I had a version of Core Wars available through Email and ftp. I have receive many replies and am very greatful! :-) Now I have a request! I have kept the names of all the people that have replied to the posting and I will send the newest version to all of them. Do not be surprised that I do not reply for awhile or at all for the next week, since I will be making some big changes in the compatibleness of the program and I attend many classes and work in between them. So, please be patient. Also, for all of those who haven't sent me mail yet and will about wanting a copy of the game, please enclose the type of system you are running on. Thanks... :-) Ok, now for the changes... I have been notified by a couple of actively debugging people that System V is a problem in compiling in some cases. I just got a new SysV account today, so I will be working on that as well. I will also be making changes to the assembler, probably from now on making commas in between fields a requirement... (not sure yet). This is to make it easier to have expressions in each of the field. The third thing I will be working on is improving the debugger to make it easier in developing programs. And the final, planned thing I am going to do is find the nasty Core Dump that happens when certain redcode programs fight in the arena... (Cowboy is one, and there are a couple of other isolated incidents.) >From those people that have older copies of the program now, I would appreciate greatly to have the reports of bugs sent to me now, or sometime soon. I want to clean the code up and get it working as fast as possible, and need to have the list of bugs to help me in this process. I am very gratified to receive bug reports from anyone out there (and I have had some very big one reported...) Well, thanks and I will get back to you later! (Also, would anyone object to me in actually posting the program to this newsgroup when I feel it is completely ready? I have had lots and lots of mail, and see that it may be beneficial in general.) Scott Adkins bigbird.cs.ohiou.edu From: ddt@ccwf.cc.utexas.edu (David Taylor) Subject: National Programming Contest Draft Report Message-ID: <64767@ut-emx.uucp> Date: 9 Jan 92 01:06:17 GMT The following is a draft report on the 1991 National Programming Contest held at the University of Texas at Austin. We are releasing it early to keep our contestants and sponsors informed. Note that this is not the final report and that we have not yet provided a list of expenditures. The IEEE CS First Annual National Progrmming Contest November 30, 1991 David Taylor, NPC Chair Jeff Schaver, NPC CoChair Ashish Parikh, IEEE CS President Introduction: The IEEE CS National Programming Contest (NPC) is a new form of computer programming contest geared towards undergraduate students. The NPC is based on the Statewide Programming Contest, which the IEEE CS has held 9 times semi-annually with great success. Besides the scope of the contests, they are slightly different in implentation, the most significant difference being that the NPC is conducted using UNIX. The contest consisted of 16 teams with three contestants per team. Each team was from a different university. Each university was selected by a group of five distinguished members of the IEEE CS whose names shall remain anonymous. Some teams, who were not selected by that group, were selected on the basis of their university's history of similar computer contests and the skill of their proposed entrants. We, the contest administrators, wrote a computer game. The contestants' goal was to play that game as best they could. The catch was that they were not allowed to play the game themselves. They had to write programs to control their players for them. Whereas humans are very good at playing strategic games and seeing the overall view, computers are very good at reflexes. The challenge was to approach a human's ability to play a game. This is no trivial feat. On top of this, we wrote a 6-player game, which meant that the three players on a side (team) must cooperate with one another. Both the statewide and national contests are organized completely by students. This year's NPC was held at the University of Texas at Austin in the Alumni Center on November 30, 1991. The elimination was completed on December 14, 1991. Preparation for the NPC began in May, 1991. Code preparation began in September, 1991. Sponsors: The finances for this year's contest came from the following sponsors: Financial- IEEE Central Texas Section.................. $7500.00 IEEE CS Technical Committee on Software Eng. $1000.00 Motorola.................................... $1000.00 Southwestern Bell........................... $1000.00 UT College of Engineering................... $500.00 UT Electrical Engineering Dept.............. $500.00 TOTAL: $11500.00 Hardware- Sun Microsystems: 16 Sparcstation 2's, 1 Sparcstation IPX, 1/4in. tape drive, 1.3Gb drive, CD ROM, SunOS. NCD: 32 X terminals, NCD X terminal boot tapes. St. Claire Systems: 17 transceivers, 47 lengths of cable, 2 terminators. Technical Educational Services: Chromalux RGB projector Airlines- Delta: 10% discount off best individual offers or 45% off retail. Prizes- Microsoft: Winning team's choice from following list of products- Microsoft Excel (PC or Mac), Microsoft Word (PC or Mac), Microsoft C Compiler, Microsoft Windows, Microsoft Visual Basic, or Microsoft Quick C Hewlett Packard: 3 calculators Origin: 3 games- Wing Commander, Savage Empire, Martian Dreams Special Thanks- UT Police Department, for keeping the Alumni Center open the entire night before the contest. Computation Center, for an increased disk quota and consulting help. Advanced Graphics Lab, for the protracted use of their Mac's, scanners, and workstations. Dr. Rahmeh, for the use of his ENS Sparc lab, used to develop the NPC game code. AT&T, for finding us a great speaker. Overview: Location- Alumni Center at the University of Texas at Austin Speaker- Dr. Andrew Koenig of AT&T: "The Art of the Hack" Special guests- Dr. and Mrs. Mario Gonzalez, Chairman of UT ECE Dept. Drs. Laurie and John Werth, UT CS Dept. Brief computer game description- The game contestants had to create players for was called "Gobble". It was basically a capture-the-flag game. The object was to get one of your players to the middle of the screen, pick up the turkey, and return it to your side. On each team were three players, Ma, Pa, and Squirt. Ma was very strong and was armed with a frying pan which could be swung very quickly but had a short range, and she moved slowly. Pa was almost as strong as Ma, but he was armed with a hoe which has a slightly longer reach but less power than a frying pan; he was slightly faster than Ma. Squirt is the weakest but fastest player, armed with a slinshot which takes a long time to shoot but has an infinite range. If a player is hit enough times (depending on his strength), he or she will pass out temporarily and recuperate his/her strength. There is no way to kill another player permanently, and the turkey could not be killed. Furthermore, the person carrying the turkey cannot shoot and moves at half speed. Contestants- The following teams participated in the 1991 IEEE CS NPC. All teams submitted an application detailing the qualifications of their members. Alma College: E-mail: Brian Ridgely (ridgely@alma.edu) Contestants: Phil Haar (3934@alma.edu) Paul Kassal (3952@alma.edu) David Martinelli (3983@alma.edu) Berkeley: E-mail: Jon Blow (blojo@scam.berkeley.edu) Contestants: Dan Wallach, Jr. Sean N. Welch Jon Blow Caltech: E-mail: Dave "Fru" Frumin (thefru@tybalt.cco.caltech.edu) Contestants: Birhcard Bang (rbang@through.ugcs.caltech.edu) Dave "Fru" Frumin (thefru@tybalt.cco.caltech.edu) Alf Mikula (mikula@plague.ugcs.caltech.edu) Cornell: E-mail: Dan Jenkins (jenkins@cs.cornell.edu) Contestants: Brian Freyburger Jon Kleinberg Michael Swift Kansas State: E-mail: James Hu (jxh@cis.ksu.edu) Contestants: James C. Hu (jxh@cis.ksu.edu) Joseph F. Young (jfy@cis.ksu.edu) Spencer B. Smith (sxs@cis.ksu.edu) MIT: E-mail: Samuel P. Kho (samkho@athena.mit.edu) Contestants: Samuel P. Kho (samkho@athena.mit.edu) David Evans Brennan Gaunce Oberlin: E-mail: Rhys Price Jones (rhyspj@occs.cs.oberlin.edu) Contestants: Carl Erikson John Grigsby Kanchan Mitra U. Penn: E-mail: David Elliston (elliston@central.cis.upenn.edu) Contestants: David Elliston (elliston@central.cis.upenn.edu) Dmitry Cherkassky Mohammed Rezaei Rice: E-mail: Shawn Dube (jsd@owlnet.rice.edu) Contestants: Shawn Dube (jsd@owlnet.rice.edu) Mike Hewitt Amit Paetl Stanford: E-mail: Michael Grant (mcgrant@isl.stanford.edu) Contestants: Matt Rhoten (mrhoten@neon.stanford.edu) Dan Sommerfield (zargon@leland.stanford.edu) Alexander Wiesen (loki@leland.stanford.edu) Toronto: E-mail: Arthur Tateishi (ruhtra@turing.toronto.edu) Contestants: Arthur Tateishi (ruhtra@turing.toronto.edu) Jody Goldberg (g9goldbe@cdf.toronto.edu) Wayne Hayes (g9wayne@cdf.toronto.edu) Trinity: E-mail: Christopher Barkley (cbarkley@tusol.turing.cs.trinity.edu) Contestants: Christopher Barkley (cbarkley@tusol.turing.cs.trinity.edu) Sean Elfstrom (selfstro@tusol.turing.cs.trinity.edu) Patrick Magruder (pmagrude@tusol.turing.cs.trinity.edu) Central Florida: E-mail: David Van Brackle (vanb@eola.cs.ucf.edu) Contestants: Don Gross Glenn Martin Derek Tolley UCLA: E-mail: David Smallberg (das@cs.ucla.edu) Contestants: Dave Harkness Carey Nachenberg Jawson Robbins Wisconsin: E-mail: Greg Hawley (hawley@cae.wisc.edu) Contestants: Greg Hawley (hawley@@cae.wisc.edu) Jeff James (jeffreyj@cae.wisc.edu) Paul Schaff (schaff@cae.wisc.edu) Texas: E-mail: Joseph Dang (x606@cs.utexas.edu) Contestants: Joseph Dang (x606@cs.utexas.edu) Philip Hardin Joseph Skrovan The week of the contest: Wednesday (Nov. 27th): Setup- Sun and NCD X terminals arrived. Installed with help of representatives from both Sun and NCD. Thursday (Nov. 28th): Installation completed. Remaining machines installed, extra software installed. Alumni Center ready to go. Friday (Nov. 29th): Game code transferred to installed machines. Debugged through the night. 6:30-9pm- Contestants arrive, treated to fajita dinner buffet. Announced attendees, passed out t-shirts. Saturday (Nov. 30th): Dr. Koenig arrives at 4pm. 7:30-8:30am- Breakfast served at the hotel 9-10am- Contest rules and game described to participants 10-noon- Contestants program noon-1pm- Lunch (Double Dave's Pizza) 1-5pm- Contestants program 5-5:30pm- Reception 5:30-7pm- Dinner 7-8pm- Dr. Koenig's "The Art of the Hack" speach 8-10pm- Contestants program (extended time) 10pm-late Tournament late- Tournament postponed. Discussion. Sunday (Dec. 1st): Contestants flew/drove home. Take-down (Sparcstations) Tuesday (Dec. 3rd): Take-down (NCD X Terminals), shipped off. Double Elimination: The tournament was posponed due to several uncorrected bugs in the game server. However, it was conducted again, with a new set of match ups, two weeks later (Dec. 14th), after having removed all the remaining bugs. Berkeley and U.Penn did not submit entries, so the Caltech/KSU teams were randomly picked to start on the next level. The elimination follows: Winners' Bracket: Alma --\ +- Oberlin --\ Oberlin --/ \ +- MIT --\ MIT --\ / \ +- MIT --/ \ Cornell --/ \ + U.Texas --\ U.Texas --\ / \ +- U.Texas --\ / \ Wiscon --/ \ / \ +- U.Texas --/ \ UCLA --\ / \ +- UCF --/ \ UCF --/ \ +- Rice -\ / + Rice Rice --\ / MIT -/ +- Rice --\ / Stanford--/ \ / +- Rice --\ / Trinity --\ / \ / +- Trinity --/ \ / Toronto --/ \ / + Rice --/ Caltech --\ / +- Caltech --/ KSU --/ Losers' Bracket: Cornell --\ +- --\ Wisconn --/ \ +- Alma --\ Alma --\ / \ +- Alma --/ \ UCLA --/ \ + Alma --\ Stanford--\ / \ +- Stanford--\ / \ KSU --/ \ / \ +- Stanford--/ \ Toronto --\ / \ +- Oberlin --/ \ Oberlin --/ \ +- MIT -\ / + MIT / U.Texas -/ UCF --\ / +- Trinity --\ / Trinity --/ \ / +- MIT --/ Caltech --\ / +- MIT --/ MIT --/ The 1991 NPC Winner is Rice University. Second place was MIT. The tie between Cornell and Wisconsin resulted in both teams losing. These were part of the rules as stated in the handout packet. Problems/Comments: Hotel: The hotel was very-well handled. They provided van service to shuttle the contestants and were relatively inexpensive. We made the mistake of assuming, however, that each team would be able to share a room. Whereas this was true for the most part, we had one potential team who had a girl on it, and they would've been forced to rent another room had they come. The downtown Radisson hotel went above and beyond our expectations. Alumni Center: The Alumni Center turned out to be very expsensive. We were charged a dollar per soft drink or coffee, and the reception room looked very drab. The dinner was very well-cooked and well-catered, however. We had trouble keeping the place open and had to rent a security guard to do so. This was very expensive and very inconvenient. There were also power problems. The ballroom did not have adequate power for 32 X terminals and 17 workstations. We tripped the circuit breaker before finding an additional circuit. The Alumni Center was a bittersweet experience. Going with the Erwin Center or some other convention center next time would be worth looking into. Game server: Perhaps the most disasterous thing that happened at the contest was that the game server was not ready by the contest day. There were still several bugs left, and there was very little documentation. On top of this, we asked participants to copy constants from the game code instead of providing a separate header file. There was also a misunderstanding about how ranges worked in the game. This led to programs that attacked very rarely if at all. The game coding was badly handled. The programmers worked continuously in shifts for an entire week before the contest. This was extremely disruptive to schoolwork and made for sloppy debugging. The organization of the code into several clients and servers, although very modular, was also questionable. Launching a game was very difficult and made the debugging cycle too long. Documentation: Also bad. The contestants needed a clearer view of how ranges worked. Staff and duties: Administration- Ashish Parikh, IEEE CS President: Money, hardware, prizes David Taylor, NPC Chair: Money, hardware, prizes, admin Jeff Schaaver, NPC Co-Chair: Hotel, Alumni Center, airlines, admin Programmers- Steve Coffee: Game server John Dawson: I/O, client, server interfaces, heartbeat server David Taylor: Graphics & sound servers, projector Rob Mayoff: Optimizations, system administration, tourney launcher Artists- Josh Prikryl: Movie and game animator Brian Brocklesby: Coloring, digitizing, tesselating John Rosalier: Coloring Bob Anderson: Background Special Thanks- Mike Schoenfelder: Sound, score, hardware setup Chirag Ghandi: Invitations Rob Gowin: Hardware setup Babi Saurav Seal: Stuff Survey Results: At the end of the contest, we handed out surveys to get people's opinions of the contest. Although the game server had failed, most gave positive responses and were appreciative of our efforts. However, the most common comment was a need to work harder on playtesting and debugging before the contest. Conclusions: Our largest problem was with the game server. The code was simply not debugged and playtested adequately. Unfortunately, this is perhaps the worst thing that could have happened to the contest. It made the contest results questionable and the contest day anti-climactic. Although we had the talent to make the game server work, we did not schedule ourselves well. The programmers spent the last two weeks writing code in tight shifts to get it finished and debugged in time. We received detailed suggestions and complaints from both MIT and Cornell concerning the contest. We have read and incorporated many of those suggestions in our schedule for the '92 NPC. We appreciate the feedback. The great volume of artwork required for the game was very tedious to scan, color, reduce, and pre-process. Although the game looked much better for it, we must either find an easier way to pull this off next time or choose a game which requires less artwork. Next Year: To be sure that we do not have a problem with the game server again, we are slated to finish a prototype of the '92 game by April 1. Note that game design has started immediately, and if you have suggestions, they should be sent to npc@austin.eds.com or mayoff@ccwf.cc.utexas.edu. Next year, we are going to try to get 50 workstations instead of 17. The number of teams should stay the same. To do this, we will need a slightly larger room with much more power available. Next year's game will utilize 3D graphics, which means that we will also be seeking high-performance graphics workstations or graphics accelerators. Several contestants asked for tours and other activities while they were in Austin, so we are also going to work on getting demonstrations/tours available either the day of or day after the contest. Work has already begun on the '92 NPC. There appears to be a USSR team interested in competing, and we are working hard to make sure that they can attend. If we do get such a team, we are also going to work harder on getting the press to attend. Hopefully, after the '92 contest, we will be able to find a school interested in hosting the '93 contest. We want the NPC to continue to grow and travel to other schools. The USSR has invited us to come compete over there, but the expense may be a little too high for most schools. The NPC does not have the funding to pay for contestants' flights as of yet. The prizes this year, although very welcome, would be better suited to our state-wide contest. We must work harder on gettng more prizes, especially hardware, for the contest. The (very) tough part is gettng three of each prize. Further information: "Movies" of the tourney will be placed on the bongo.cc.utexas.edu ftp site sometime in mid January of '92. They can be watched with any color Sparcstation. We hope to release the game server code soon afterwards. Any NPC '91 contest questions should be directed to: Jeff Schaver: jschaver@ccwf.cc.utexas.edu, or Ashish Parikh: ashish@ccwf.cc.utexas.edu Any technical/NPC '92 questions should be directed to: David Taylor: ddt@ccwf.cc.utexas.edu To send mail to a discussion group on next year's game, send e-mail to: npc@austin.eds.com To get on this distribution list, write: mayoff@ccwf.cc.utexas.edu The IEEE CS office number is (512) 471-5038. We do have an answering machine, but the office will be closed until mid January when school starts again. NOTES: Please note that this report does not contain a list of our expenditures. Jeff Schaver will append this information to the report as soon as we have received all of our bills. This report was written by David Taylor and does not necessarily reflect the views of the entire NPC staff. From: solman@athena.mit.edu (Jason W Solinsky) Subject: Re: National Programming Contest Draft Report Message-ID: <1992Jan9.023254.15933@athena.mit.edu> Date: Thu, 9 Jan 1992 02:32:54 GMT All undergraduates in IEEE region I (and maybe even region II !!!!!) should look towards a regional programming contest to be held in Boston in early May of this year. At this point a contest is likely (80% chance). The preliminary round of the contest will use one of the previous codes created by David Taylor et al and be played over the net. The final round (the top sixteen teams would come to Boston) would be based on the code used for the preliminaries, but a change will be made which will force all of the teams to change their strategies considerably during a limited period of time. If any body from MIT is reading this and interested in helping out with the programming, please contact me in a month. There will probabally be a couple of half-time (5 hrs. per week at MIT minimum wage ($6.75 ?)) UROPs offered. The winner would then be entered in the NPC and provided airfare (up to $1200) by the contest. Look for further announcements. Jason W. Solinsky From: jrd@gagme.chi.il.us (John R. Dennison) Subject: Re: Core Wars Deluxe Message-ID: <1992Jan9.215538.14410@gagme.chi.il.us> Date: 9 Jan 92 21:55:38 GMT In article <4646@oucsace.cs.OHIOU.EDU> sadkins@bird24.cs.ohiou.edu (Scott W. Adkins) writes: >(Also, would anyone object to me in actually posting the program to this >newsgroup when I feel it is completely ready? I have had lots and lots >of mail, and see that it may be beneficial in general.) No objections from me. I would also suggest comp.sources.games as a good place to post it. Perhaps even better then this newsgroup. -- UUCP: "jrd@gagme.chi.il.us" NovaNET: "dennison / wright / nova" || "dennison / uasite / nova" Internet->NovaNET: "dennison-wright%nova@uhplato.uhcc.hawaii.edu" Subject: 88 CoreWars specification? Message-ID: From: norrish@rata.vuw.ac.nz (Michael Norrish) Date: Fri, 10 Jan 1992 23:33:17 GMT This should be in a FAQ, but I haven't seen one in the last month or so, so could someone please post the full Redcode specification or mail it to me? I have never played, but got inspired by a set of articles in A.K. Dewdney's "The Armchair Universe". Unfortunately, this is the 1986 version, and some of the discussions about the Split command here have left me completely bewildered. Michael. -- Michael Norrish. norrish@rata.vuw.ac.nz ----------------Victoria University of Wellington--------------------- "I can't believe *that*!" said Alice. "Can't you?" the Queen said in a pitying tone. "Try again: draw a long breath, and shut your eyes." From: wms@iwarp.intel.com (William Shubert) Subject: Lost touch with Campbell Fraser Message-ID: <1992Jan11.011456.214@iWarp.intel.com> Date: Sat, 11 Jan 1992 01:14:56 GMT King of the Hill has just recently been unable to get in touch with Campbell Fraser (the address being used is "fraserc@dcs.glasgow.ac.uk"). Since he is the author of Intangible Worm 88.2, the #3 program on the top ten, quite a bit of mail is getting bounced around. The reason for the mail failing is stated: 421 dcs.glasgow.ac.uk.: Connection refused by sun2.nsfnet-relay.ac.uk Does anybody know what is going on? If Campbell is out there, can you get in touch with me? -- -Bill (wms@iwarp.intel.com) Hi! I'm a .signature virus. Copy me into yours and join the fun! From: vishart@ubvmsb.cc.buffalo.edu (Joseph Hart) Subject: looking for CoreWars for Amiga Message-ID: <1992Jan11.233237.22395@acsu.buffalo.edu> Date: 11 Jan 92 23:34:00 GMT I am looking for corewars software for the Amiga. Does anybody know what is available either commercially or PD ? Thanks in advance..... ___________________________________________________________________ Joe Hart | /// Internet: vishart@ubvmsd.cc.buffalo.edu NewMedia Inc. | \\\/// Plink: OSS542 Niagara Falls, NY | \XX/ AMIGA - Computers for REAL MEN =================================================================== From: kdmiller@athena.mit.edu (Kenneth D Miller) Subject: Re: looking for CoreWars for Amiga Message-ID: <1992Jan12.165250.3344@athena.mit.edu> Date: 12 Jan 92 16:52:50 GMT In article <1992Jan11.233237.22395@acsu.buffalo.edu>, vishart@ubvmsb.cc.buffalo.edu (Joseph Hart) writes: |> |> I am looking for corewars software for the Amiga. |> Does anybody know what is available either commercially or PD ? |> Thanks in advance..... Check on ab20, in directory "incoming/amiga/DEMOS/", filename "MADgic.corewar.lzh". I got it, and it's pretty good. However, this is the "stripped" version--it contains only two programs, and they're both really lame (IMP and DWARF...bleh). I've been looking for the Scientific American articles that covered corewar, but haven't succeeded yet... -- kdmiller@athena.mit.edu | Yep, it's KENNY MILLER... /// | DESTINED TO BE THE GREATEST PROGRAMMER \XX/ Amiga Mania! | *** E V E R ! ! ! *** Subject: King of the Hill From: wms@iwarp.intel.com (William Shubert) Date: 12 Jan 92 17:30:33 GMT Message-ID: <1992Jan12.173033.9609@iWarp.intel.com> Well I've recently gotten a bunch of mail requests about King of the Hill so I guess it's time to repost the entry instructions. Here they are. ---------------------------------------------------------------------- Entry rules for King of the Hill "standard" Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. In addition, writing ";redcode verbose" or ";redcode quiet" will alter how much information you get on your program. See part 5) below. Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail demon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program compiled correctly or not. If it did compile correctly, sit back and wait; if not, make the change required and re-submit. 5) In a hour or so you should get more mail telling you how your program performed against the current top 10 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 10 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 10 list. That's it! MORE ON KOTH COREWAR IMPLEMENTATION Core size: 8,000 instructions Max processes: 8,000 per program Duration: After 80,000 cycles per program a tie is declared. SAMPLE ENTRY: ;redcode verbose ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb dat #0 dwarf add #4,bomb mov bomb,@bomb jmp dwarf end dwarf Rule variants for "eXperimental" corewar: The same as above but use ";redcode-x" to start your program. Your program will be entered into a second tournament with slightly different rules. The ruels are: - All addressing modes are allowed with all instructions. - When a process executes a "SPL" instruction the children processes share the PARENT'S cpu time only. For example: start spl loop2 spl loop3 loop1 jmp loop1 loop2 jmp loop2 loop3 jmp loop3 end start In this example, the loop "loop2" will get 1/2 of the CPU time (it gets 1/2 of it's parent's time, and it's parent was the original process) while "loop1" and "loop3" will each get 1/4 of the CPU time (their parent was a child of the original process, so they each get 1/2 of 1/2 of the CPU time.) The order of execution would be like this: loop2 loop1 loop2 loop3 loop2 loop1 ...etc... ---------------------------------------------------------------------- -- -Bill (wms@iwarp.intel.com) Hi! I'm a .signature virus. Copy me into yours and join the fun! Subject: King of the Hill From: kwhyte@math.uchicago.edu (Kevin Whyte) Date: 12 Jan 92 20:38:08 GMT Message-ID: <1992Jan12.203808.23985@midway.uchicago.edu> King of the Hill has been going for a while now, and I imagine we all have had some experience with it. Strangely, the entrants don't seem to be getting much better with time ( I can even still get things in the top ten :) ) Anyway, I just wanted to comment on something i thought a bit strange: The program XTC from the '90 competition was submitted early on and did quite well. Eventually it got driven of the hill. Well, some of my programs made it to the hill, but XTC could stomp on all of them, so I re-submitted XTC. As of now, it's at #3. A similiar thing happened with one of my programs (submitted, made it into the top 5, eventually got kicked off, resubmitted and again in the top 5). So why isn't the hill getting tougher? Are we just designing programs to beat the ones in the top 10 and then ones to beat those, which in turn are beaten by the original 10? I suggest that anyone who has ever had a program in the top 10 periodically resubmit it, until it becomes clear that it is truely obscure. This way, hopefully, the hill will evolve better and better programs, and therefore no one without net access will ever have a chance in ICWS tourneys again! Kevin :x Subject: Eratosthenes From: neur0mancer@maple.circa.ufl.edu (Neuro Mancer) Date: 12 Jan 92 23:23:22 GMT Message-ID: <1992Jan12.231800.5031@math.ufl.edu> ;redcode ;author Simon Arthur (neur0mancer@oak.circa.ufl.edu) ;name Eratosthenes ;strategy Bombs at large intervals. begin mov loc,@loc sub #391,loc jmp begin loc dat #-7 ====== neur0mancer%maple.decnet@pine.circa.ufl.edu neur0mancer@oak.circa.ufl.edu (maybe) 73@arms.uucp (checked least often) Subject: Crazy Jane From: neur0mancer@maple.circa.ufl.edu (Neuro Mancer) Date: 12 Jan 92 23:23:18 GMT Message-ID: <1992Jan12.231712.4977@math.ufl.edu> ;redcode ;author Simon Arthur (neur0mancer@oak.circa.ufl.edu) ;name Crazy Jane ;strategy bombs with spl 0 then with DAT's start mov loc , -2 sub #390 , start djn start , start next mov (loc+2), -10 jmp next , kwhyte@math.uchicago.edu (Kevin Whyte) writes: > King of the Hill has been going for a while now, and I imagine >we all have had some experience with it... Well, my 6 instruction program kicked your 2 instruction program off :-). However, your program could usually beat my program. Also, Dwarf knocked my program off. >So why isn't the hill getting tougher? >Kevin Here's how I see it: the programs in the top 5 are really the best ones. The Bottom 5 is really easy to break into and they serve as a sort of test for the top programs. Don't get too cocky if you can break into the top 10. (Although I admit that it was great the first time that I did!) I don't think that there has been enough information and discussion here lately. I will post my two best programs here for everyone to comment on. They seem pretty tough to me so why didn't they win? ====== neur0mancer%maple.decnet@pine.circa.ufl.edu neur0mancer@oak.circa.ufl.edu (maybe) 73@arms.uucp (checked least often) Subject: dwarfer.red From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Date: 13 Jan 92 02:46:56 GMT Message-ID: <4671@oucsace.cs.OHIOU.EDU> ;redcode verbose ;name Dwarfer ;author Scott Adkins (sadkins@bigbird.cs.ohiou.edu) ; ;strategy Copies a one dwarven fighter out into the core every 200 locations ;strategy and starts each one. After this is done, it continually refreshes ;strategy each fighter in case they have been damaged. This program is very ;strategy very fast and has a bit of split bomb immunity built into it. ; start mov d2, ;redcode verbose ;name Killer ;author Scott Adkins (sadkins@bigbird.cs.ohiou.edu) ; ;strategy A simple program that copies itself to another location, starts ;strategy that copy, and then spends its remaining lifetime bombing memory ;strategy near itself. It is more or less a dwarf-like mice program. ; src dat #0, #10 start mov #10, src copy mov @src, ;redcode verbose ;name Virus ;author Scott Adkins (sadkins@bigbird.cs.ohiou.edu) ; ;strategy Copies itself through memory (slowly) to help ensure survival. It ;strategy also launches two dwarves to help out with cleaning the memory. It ;strategy then spends the rest of the time splitting to memory locations, ;strategy hoping that it will execute and enemy program and make it all that ;strategy much harder to win. ; src dat #0, #0 start mov dst, loc1 mov src, loc2 mov #111, host mov #111, dst spl dwarf1 spl dwarf2 spl virus copy mov #30, src loop mov @src, The MADgic Core for the Amiga is also available on soda.berkeley.edu where you will also find many, many Redcode programs and other systems and files of interest to the Core War community. MAD From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Re: King of the Hill Message-ID: <1676D8EE1.DURHAM@ricevm1.rice.edu> Date: Mon, 13 Jan 1992 16:09:17 GMT In article <1992Jan12.203808.23985@midway.uchicago.edu> kwhyte@math.uchicago.edu (Kevin Whyte) writes: > So why isn't the hill getting tougher? The hill is not getting tougher because it has no memory. Each time a program is submitted, an entirely new tournament is run with just the eleven participants currently available. In order to make it on to the hill (or stay there), you only need to be better than one other program. I think the hill would improve if the programs there were judged by not only how they do in the tournament run when a new warrior is submitted, but also how well they did in past tournaments. Perhaps a running average could be kept for programs on the hill. That way a program that had been doing well on the hill would not suddenly disappear because of just one bad round. Also, new warriors would have to perform very well to attain the hill and show an ability to deal with many different programs to stay there. MAD Subject: Re: King of the Hill From: wms@iwarp.intel.com (William Shubert) Date: Mon, 13 Jan 1992 17:02:05 GMT Message-ID: <1992Jan13.170205.1721@iWarp.intel.com> Mark Durham posted: >I think the hill would improve if the programs there were judged by not >only how they do in the tournament run when a new warrior is submitted, >but also how well they did in past tournaments. I'm perfectly willing to make changes to KotH if anybody can come up with a scoring algorithm that is better than the current one. I tried to think of one that was superior, but I couldn't. One thing I don't want is an algorithm that favors programs already on the hill; if you enter a program, it should have the same score regardless of whether it just arrived or it has been there for months. A good program is a good program. >That way a program that had been doing well on the hill would not suddenly >disappear because of just one bad round. Actually, this can't happen. Because the complete tournament is not re-run with each new entry, but old scores are kept around, a bad round can only effect 1/10th of your score, MAX. And because in any given round your program fights 40 times, let's say "a bad round" means you suffer 10 losses that should have been wins (that's pretty unlikely anyway). That a difference of only 30 points; enough for any of the bottom 5 to fall off (which is probably why they do fall off constantly) but not enough for the top 5. One improvement that could definitely be made would be to lengthen the hill. I will probably be getting a much more powerful workstation within the next few months and when it arrives I should be able to keep around the top 25 programs. Hopefully this will make the top 10 to 15 programs fairly stable. -- -Bill (wms@iwarp.intel.com) Hi! I'm a .signature virus. Copy me into yours and join the fun! From: kurt@crash.cts.com (Kurt Werle) Subject: Re: King of the Hill Message-ID: <1992Jan13.172042.2505@crash.cts.com> Date: 13 Jan 92 17:20:42 GMT In article <1992Jan12.203808.23985@midway.uchicago.edu> kwhyte@math.uchicago.edu (Kevin Whyte) writes: ... > > Are >we just designing programs to beat the ones in the top 10 and then ones to >beat those, which in turn are beaten by the original 10? Yeah, I suspect this is the case. Perhaps it's time to make it the top 20? I know this eats CPU, but it is one possible solution... Kurt Date: Monday, 13 Jan 1992 18:48:58 EST From: Message-ID: <92013.184858JJJ101@psuvm.psu.edu> Subject: Possible C-robot tournament Greetings... I'm thinking of running a C-robot tournament in the near future. To get an idea of how many contestants there will be, send me an e-mail reply if you think you will be interested. DON'T SEND ANY PROGRAMS YET! James Subject: Re: King of the Hill From: snewman@Neon.Stanford.EDU (Steven Newman) Date: Mon, 13 Jan 1992 19:26:28 GMT Message-ID: <1992Jan13.192628.22360@CSD-NewsHost.Stanford.EDU> > [discussion of why the Hill isn't getting tougher] Well, I think one reason is that it's hard to write really sophisticated programs in standard Core Wars, but I don't want to start that thread again. (And no, I haven't submitted anything to the experimental Hill, but that's just due to lack of time.) The major reason is that there isn't enough feedback. The ;strategy lines are nice to see, but not everyone uses them, and even with them it's hard to know why your program wins or loses against another. You really have to see two programs fighting on a visual display to understand why one beats another, and how you might modify yours to do better. In the interests of stimulating the Hill, I'll post source to my dodgem6 program (which, contrary to assertions as to the stability of the top 5, has been observed to leap from position 1 to position 10 or vice-versa in just a few rounds): ;redcode ;name dodgem6 ;author Steve Newman (snewman@cs.stanford.edu) ;strategy Write out a bunch of flag values and wait for the enemy ;strategy to bomb one. Analyze enemy's bomb location. Copy a dwarf ;strategy type program to a location that appears safe and transfer ;strategy control to it. Large size is due to a simple one-shot ;strategy redundancy mechanism that helps resist damage in early stage ;strategy of play. bomb EQU start-60 ;Presumed to be a DAT 0,0 instruction. ;Write a flag value (77) to 64 well-scattered locations. start SUB #248,-15 MOV #77,<(start-15) MOV #77,<(start-15) DJN start,#32 ;Now repeatedly check the 64 locations until one of them is altered. search SUB #248,start CMP #77,= 4) to deal with programs that start bombing immediately ;behind themselves. copyOffset EQU 2399+end1-dwarf1 copyLen EQU end1-start1+1 sum DAT #122 cargo1 ADD #copyOffset,start copyLp1 MOV ;redcode ;name Sargent ;author Kevin stomp dat #0,#0 start add offset,bomb jmz start,@bomb slt us,bomb jmp recruit,0 mov offset,pit jmp start ,0 recruit mov #46,recruit sub offset,bomb loop add step,bomb mov bomb,@bomb djn loop,recruit jmp start,0 labor mov help,stomp pit spl -1,0 jmp -1,0 help spl 14,0 bomb jmp -3,0 us dat #0,#-20 offset dat #-23,#23 step dat #-3,#3 Subject: Fleas From: kwhyte@dickson.uchicago.edu (Kevin Whyte) Date: 13 Jan 92 21:07:24 GMT Message-ID: <1992Jan13.210724.29530@midway.uchicago.edu> ;redcode verbose ;name Fleas ;author Kevin start mov <-1,<-1 jmp start,<-2 begin mov start+1,@target mov start, Date: 14 Jan 92 15:32:03 GMT Being relatively new to this group (but not corewars) I have not heard of C -robots befor.Are they programs similar to redcode programs and in what they do or are they something completely different? Can they be written using a normal C compiler or do they require some special libraries? Incidently are there any corewars systems/interpreters whatever for HP-UX? Neil Robertson LUT Leicestershire England Date: Tuesday, 14 Jan 1992 16:39:46 EST From: Message-ID: <92014.163946JJJ101@psuvm.psu.edu> Subject: What is C-robots? Here is the documentation for C-robots... ----------------------CUT------------------------ ##### ###### ####### ###### ####### ####### ##### # # # # # # # # # # # # # # # # # # # # # # # # # ###### # # ###### # # # ##### # # # # # # # # # # # # # # # # # # # # # # # # ##### # # ####### ###### ####### # ##### (C) Copyright 1985, All rights reserved. CROBOTS is copyrighted by: tpoindex@isis.cs.du.edu Tom Poindexter 6864 Amherst Ct. Highlands Ranch, CO 80126 CROBOTS (C) Copyright 1985 by Tom Poindexter. Table of Contents 1. License agreement and disclaimer of warranty...........2 2. Introduction 2-1. Description........................................3 2-2. Intended audience..................................3 2-3. Machine requirements...............................3 2-4. User interface.....................................3 3. Types of play Single Play........................................4 Match Play.........................................4 4. Running CROBOTS 4-1. Command line options...............................4 4-2. Examples...........................................5 5. Game Parameters 5-1. Battlefield........................................5 5-2. Robot offense......................................5 5-3. Robot defense......................................6 5-4. Disabling robots...................................6 5-5. Sample display.....................................7 6. CROBOTS CPU............................................8 7. CROBOTS C Compiler 7-1. Description........................................8 7-2. Features missing from standard C...................8 7-3. CROBOTS language...................................9 7-4. Compiler limits...................................11 7-5. Error and warning messages........................11 8. CROBOTS C Intrinsic Function Library scan()............................................12 cannon()..........................................13 drive()...........................................13 damage()..........................................13 speed()...........................................13 loc_x(), loc_y()..................................14 rand()............................................14 sqrt()............................................14 sin(), cos(), tan(), atan().......................14 9. CROBOTS C Program Structure 9-1. Structure.........................................15 9-2. Sample: "sniper.r"................................15 10. CROBOTS CPU Architecture 10-1. Stack.............................................20 10-2. Link list.........................................21 10-3. Instruction set...................................22 10-4. Machine level debugging...........................23 11. Implementation Notes..................................24 12. Order Form............................................25 Page 1 CROBOTS (C) Copyright 1985 by Tom Poindexter. 1. License agreement: You may make copies of this program, manual, and other files and give it to your friends, upload it to bulletin boards, or include it in the library of a non-profit computer club. I expressly forbid any for-profit venture from selling this software and manual, either separately or as part of a "library" diskette. SUPPORT SHAREWARE! If you find this software has any value for you, please send a contribution. For contributions of $20 or more, you will receive the full source code to CROBOTS on diskette. Use the order form at the end of the documentation. Your contribution will encourage me to enhance the program, by expanding the CROBOTS C compiler, adding graphics, sound, etc. Whether or not you contribute, please share this software with others. DISCLAIMER OF WARRANTY THIS SOFTWARE AND MANUAL ARE PROVIDED "AS IS" WITHOUT WARRANTY OF AND KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS OF PURPOSE. THE USER OF THIS SOFTWARE AND MANUAL ASSUME ALL RISKS. Page 2 CROBOTS (C) Copyright 1985 by Tom Poindexter. 2. Introduction 2-1. Description CROBOTS ("see-robots") is a game based on computer programming. Unlike arcade type games which require human inputs controlling some object, all strategy in CROBOTS must be complete before the actual game begins. Game strategy is condensed into a C language program that you design and write. Your program controls a robot whose mission is to seek out, track, and destroy other robots, each running different programs. Each robot is equally equipped, and up to four robots may compete at once. CROBOTS is best played among several people, each refining their own robot program, then matching program against program. CROBOTS consists of a C compiler, a virtual computer, and battlefield display (text graphics only, monochrome or color). The CROBOTS compiler accecpts a limited (but useful) subset of the C language. The C robot programs are aided by hardware functions to scan for opponents, start and stop drive mechanisms, fire cannons, etc. After the programs are compiled and loaded into separate robots, the battle is observed. Robots moving, missiles flying and exploding, and certain status information are displayed on the screen, in real-time. 2-2. Intended audience CROBOTS will most likely appeal to programmers (especially those who think they can write the "best" programs), computer game enthusiasts, people wishing to learn the C language, and those who are interested in compiler design and virtual computer interpreters. 2-3. Machine and software requirements - IBM-PC, or other close MS-DOS computers that use INT 10H video calls - 192k ram - DOS 2.0 or higher - One disk drive - Monochrome or Color/Graphics display - Text editor (PC-DOS Edlin, or your own favorite) 2-4. User interface CROBOTS does not use menus, windows, pop-ups, or any other user-friendly interface. Since the emphasis is on designing and writing robot control programs, CROBOTS is started as a compiler might be started, from the DOS command line. Page 3 CROBOTS (C) Copyright 1985 by Tom Poindexter. 3. Types of play CROBOTS can either run one match (single play), in which the full screen, realtime battlefield display is used, or several matches (match play), in which only the name of the winner is printed after each match. Single play is the default. Match play is intended to see how robot programs perform on the average. Match play can consume several hours of computer time depending on the number of matches and cpu cycle limit, and can be run overnight. 4. Running CROBOTS 4-1. Command line options CROBOTS is started from the DOS prompt: A>crobots [options] robot-program-1 [robot-program-n] [>file] Valid options and parameters are: -c (opt) Compile only, and produce virtual machine assembler code and symbol tables. -d (opt) Compile one program, and invoke machine level single step tracing. -mxxx (opt) Run a series of matches, were "xxx" is the number of matches. There should be no spaces between "-m" and the number. If "-m" is not specified, then the default is to run one match and display the realtime battlefield. -lxxx (opt) Limit the number of machine cpu cycles per match when "-m" is specified. There should be no spaces between "-l" and the number. The default cycle limit is 500,000 when -m is specified robot-programs (required) The file name of the CROBOTS source program(s). Up to four files may be specified. If only one file is specified, it will be "cloned" into another, so that two robots (running the same program) will compete. Any file name may be used, but for consistency use '.r' as an extension. >file (opt) Use DOS 2.0+ redirection to get a compile listing ("-c" option) or to record matches ("-m" option). Page 4 CROBOTS (C) Copyright 1985 by Tom Poindexter. 4-2. Examples: 1) Watch three robots compete with full display: A>crobots robot1.r robot2.r robot3.r 2) Compile one robot, and save the listing: A>crobots -c robot1.r >robot1.lst 3) Debug a robot (first get an assembler code listing, as in example 2: A>crobots -d robot1.r 4) Run 50 matches, limiting total cpu cycles to 200,000, and save results: A>crobots -m50 -l200000 robot1.r robot2.r >save 5. Game parameters 5-1. Battlefield The battlefield is a 1,000 by 1,000 meter square. A wall surrounds the perimeter, so that a robot running into the wall will incur damage. The lower left corner has the coordinates x = 0, y = 0; the upper right corner has the coordinated x = 999, y = 999. The compass system is oriented so that due east (right) is 0 degrees, 90 is north, 180 is west, 270 is south. One degree below due east is 359. 135 90 45 \ | / \ | / 180 --- x --- 0 / | \ / | \ 225 270 315 5-2. Robot offense The main offensive weapons are the cannon and scanner. The cannon has a range of 700 meters. There are an unlimited number of missiles that can be fired, but a reloading factor limits the number of missiles in the air at any one time to two. The cannon is mounted on an independent turret, and therefore can fire any direction, 0-359, regardless of robot heading. Page 5 CROBOTS (C) Copyright 1985 by Tom Poindexter. The scanner is an optical device that can instantly scan any chosen heading, 0-359. The scanner has a maximum resolution of +/- 10 degrees. This enables the robot to quickly scan the field at a low resolution, then use maximum resolution to pinpoint an opponent. 5-3. Robot defense The only defense available are the motor drive and status registers. The motor can be engaged on any heading, 0-359, in speeds from 0-100 percent of power. There are acceleration and deacceleration factors. A speed of 0 stops the motor. Turns can be negotiated at speeds of 50% and less, in any direction. Of course, the motor drive can be engaged any time, and is necessary on offense when a target is beyond the 700 meter range of the cannon. Certain status registers provide feedback to the robot. The primary registers indicate the percent of damage, and current x and y locations on the battlefield. Another register provides current drive speed. 5-4. Disabling opponents A robot is considered dead when the damage reaches 100%. Percent of damage is inflicted as follows: 2% - collision into another robot (both robots in a collision receive damage) or into a wall. A collision also causes the motor drive to disengage, and speed is reduced to 0. 3% - a missile exploding within a 40 meter radius. 5% - a missile exploding within a 20 meter radius. 10% - a missile exploding within a 5 meter radius. Damage is cumulative, and cannot be repaired. However, a robot does not loose any mobility, fire potential, etc. at high damage levels. In other words, a robot at 99% damage performs equally as a robot with no damage. Page 6 CROBOTS (C) Copyright 1985 by Tom Poindexter. 5-5. Sample display (Status (x=999,y=999) blocks) +------------------------------------+ 1 fubar.r | | D% 015 Sc 218 | \|/ 1 | Sp 000 Hd 090 | (missile exploding) -#- | ------------------ | /|\ | 2 snafu.r (y | | D% 050 Sc 275 | + (missiles | Sp 100 Hd 180 a | + flying) | ------------------ x | 2 | 3 bimbo.r i | | D% 000 Sc 045 s) | 3 | Sp 000 Hd 000 | / | ------------------ | (robots) ----\ | 4 kumquat.r | 4 | D% 100 Sc 050 | | Sp 000 Hd 335 | | | | +------------------------------------+ CPU Cycle: 4500 (x=0,y=0) (x axis) Each status block shows the file name of the robot, the damage incurred, the current scan degrees, and the speed and heading. Robots are represented on the field by '1', '2', etc., according to the status block position. The number of elapsed robot cpu cycles is shown at the bottom of the status blocks. The CROBOTS program can be stopped at any time, by using Ctrl-Break. Page 7 CROBOTS (C) Copyright 1985 by Tom Poindexter. 6. CROBOTS CPU The robot cpu is a simple stack-oriented computer. It operates at very slow speeds (on a 4.77MHz 8088 PC with two robots running, the average speed is 270 instructions per second, .00027 mips!!). The word size is 32 bits, allowing integer values from -2,147,483,648 to 2,147,483,647. There are internal pointer registers that manage stack usage, but are not accessable from a robot program. The same is true for an implicit accumulator. The maximum code space is 1,000 instructions. All instructions are equal in length. The maximum stack size is 500 words, which is used for data and function call/returns. The stack grows upward for data usage, and downward (from the end) for function call/returns. Three words are used for each function call, and are release upon the function return. The data portion and call/return portion are managed by separate internal stack pointers. If the data stack pointer and call/return stack pointer collide, a stack overflow occurs. In this case, the robot is restarted at the 'main' function, with the stack reset to all zeroes. For more information, see the section on machine instructions and theory. 7. CROBOTS C compiler 7-1. Description The CROBOTS compiler accepts a limited subset of the C language. There is no provision for separate compilation, i.e., all modules of a program must be in one file. No preprocessor is provided for "#define", "#include", etc. Identifiers are significant to 7 characters, although any length may be used. The compiled machine code is loaded into the robot cpu, and cannot be saved. 7-2. Features missing from standard C Major language features missing from K&R are: floating point variables, structures, unions, pointers, initializers, arrays, character data, typedefs, for statment, do..while statement, switch..case statement, break, continue, gotos and labels, ternary and comma operators, octal and hexadecimal constants, no parameters to main(), and all preprocessor directives. My apologies to "The C Programming Language" by Brian W. Kernighan and Dennis M. Ritchie, Prenctice-Hall, 1978. Page 8 CROBOTS (C) Copyright 1985 by Tom Poindexter. 7-3. CROBOTS language The language features that are present are entirely suitable for writing robot control programs. Basic programming constructs of if..then..else, while, and function calls can be used freely. Full expression evaluation is also provided, so that statements such as: if ((x = func1(y,1,++z,func2(c))) > 0) a = 0; else a = x; are perfectly legal. Ifs and whiles may be nested, and recursion is supported. Variables declared outside a function definition are global in scope, whereas variables declared inside a function definition are local to that function. The following keywords are recognized: comments: "/* ... */" comments cannot be nested constants: any decimal digits, optionally preceeded with a '-' declarations: "int" variable declare "long" same as int "auto" default storage scope, optional "register" legal, but ignored, same as auto "function (parms,.....)" function definition logic control: "if (expr) STMT else STMT" iteration: "while (expr) STMT" function return: "return" return "return expr" return a with value assignment operators: "=" assignment ">>=" assignment shift right "<<=" assignment shift left "+=" assignment addition "-=" assignment subtraction "*=" assignment multiplication "/=" assignment division "%=" assignment modulo "&=" assignment and "^=" assignment exclusive or "|=" assignment inclusive or Page 9 CROBOTS (C) Copyright 1985 by Tom Poindexter. bit-wise operators: ">>" shift right "<<" shift left "&" and "!" unary not "~" unary one's complement "^" exclusive or "|" inclusive or increment/decrement operators: "++" prefix increment, see derivations "--" prefix decrement, see derivations logical operators: "&&" logical and "||" logical or "<=" logical less than or equal ">=" logical greater than or equal "==" logical equal "!=" logical not equal "<" logical less than ">" logical greater than arithmetic operators: "-" subtraction or unary negation "+" addition "*" multiplication "/" division "%" modulo misc: ";" statement terminator or null statement "{ }" compound statement "," parameter separator in function definition or call "( )" expression or function definition or call Precedence and order of evaluation are the same as in K&R. Operator Associativity () left to right ! ~ ++ -- - right to left * / % left to right + - " " " << >> " " " < <= => > " " " == != " " " & " " " ^ " " " | " " " && " " " || " " " = -= += etc. right to left Page 10 CROBOTS (C) Copyright 1985 by Tom Poindexter. Major derivations from K&R: -Local variables need not be declared before reference, i.e., any undeclared variable will default to a local variable. -Postfix increment and decrement ("var++" or "var--") are recognized, but the result is the same as prefix increment/decrement ("++var"). -Intrinsic function names are reserved. 7-4. Compiler limits defined functions: 64 local variables per function: 64 external variables: 64 if nest level: 16 while nest level: 16 7-5. Complier error and warning messages: The compiler has no error recovery and will stop on the first error found. Sorry. Warning messages do not stop the compiler. Error messages "syntax error" - Any input that results in improper C syntax will yield "syntax error", with an indicator pointing to the unrecognizable input. "instruction space exceeded" - compiler tried to generate more than 1000 machine instructions. "symbol pool exceeded" - the maximum local variable, external variable, or function definition symbol table was exceeded. "function referenced but not found" - a function was referenced that was not defined in the input file or is not an intrinsic function. "main not defined" - the input file did not define a 'main()' function. "function definition same as intrinsic" - a function was defined with the same name as an intrinsic function, which are reserved. "if nest level exceeded" - more than 16 'if's were nested. "while nest level exceeded" - more than 16 'while's were nested. "yacc stack overflow" - the compiler's parser overflowed, probably due to complex expressions and/or extreme nesting. Page 11 CROBOTS (C) Copyright 1985 by Tom Poindexter. Warning messages These messages will not cause the compiler to fail, but may cause the program to executed unexpectedly. "unsupported initializer" - variable declares cannot include an initializer. For future releases. "unsupported break" - the 'break' statement was found and ignored. For future releases. "n postfix operators" - postfix increment or decrement operators were used, and are coerced into prefix expressions. "n undeclared variables" - one or more variables were implicitly declared. "code utilization: n%" - reports the capacity of machine instructions generated. 8. CROBOTS C Intrinsic Function Library The intrinsic function library provides machine level control and certain arithmetic functions. These functions do not consume any of the program code space or data stack, except for the three words for call/return sequences. No explicit linking is required to use any intrinsic function. scan (degree,resolution) The scan() function invokes the robot's scanner, at a specified degree and resolution. scan() returns 0 if no robots are within the scan range or a positive integer representing the range to the closest robot. Degree should be within the range 0-359, otherwise degree is forced into 0-359 by a modulo 360 operation, and made positive if necessary. Resolution controls the scanner's sensing resolution, up to +/- 10 degrees. Examples: range = scan(45,0); /* scan 45, with no variance */ range = scan(365,10); /* scans the range from 355 to 15 */ Page 12 CROBOTS (C) Copyright 1985 by Tom Poindexter. cannon (degree,range) The cannon() function fires a missile heading a specified range and direction. cannon() returns 1 (true) if a missile was fired, or 0 (false) if the cannon is reloading. Degree is forced into the range 0-359 as in scan(). Range can be 0-700, with greater ranges truncated to 700. Examples: degree = 45; /* set a direction to test */ if ((range=scan(degree,2)) > 0) /* see if a target is there */ cannon(degree,range); /* fire a missile */ drive (degree,speed) The drive() function activates the robot's drive mechanism, on a specified heading and speed. Degree is forced into the range 0-359 as in scan(). Speed is expressed as a percent, with 100 as maximum. A speed of 0 disengages the drive. Changes in direction can be negotiated at speeds of less than 50 percent. Examples: drive(0,100); /* head due east, at maximum speed */ drive(90,0); /* stop motion */ damage() The damage() function returns the current amount of damage incurred. damage() takes no arguments, and returns the percent of damage, 0-99. (100 percent damage means the robot is completely disabled, thus no longer running!) Examples: d = damage(); /* save current state */ ; ; ; /* other instructions */ if (d != damage()) /* compare current state to prior state */ { drive(90,100); /* robot has been hit, start moving */ d = damage(); /* get current damage again */ } speed () The speed() function returns the current speed of the robot. speed() takes no arguments, and returns the percent of speed, 0-100. Note that speed() may not always be the same as the last drive(), because of acceleration and deacceleration. Examples: drive(270,100); /* start drive, due south */ ; ; ; /* other instructions */ if (speed() == 0) /* check current speed */ { drive(90,20); /* ran into the south wall, or another robot*/ } Page 13 CROBOTS (C) Copyright 1985 by Tom Poindexter. loc_x () loc_y () The loc_x() function returns the robot's current x axis location. loc_x() takes no arguments, and returns 0-999. The loc_y() function is similar to loc_x(), but returns the current y axis position. Examples: drive (180,50); /* start heading for west wall */ while (loc_x() > 20) ; /* do nothing until we are close */ drive (180,0); /* stop drive */ rand (limit) The rand() function returns a random number between 0 and limit, up to 32767. Examples: degree = rand(360); /* pick a random starting point */ range = scan(degree,0); /* and scan */ sqrt (number) The sqrt() returns the square root of a number. Number is made positive, if necessary. Examples: x = x1 - x2; /* compute the classical distance formula */ y = y1 - y2; /* between two points (x1,y1) (x2,y2) */ distance = sqrt((x*x) - (y*y)); sin (degree) cos (degree) tan (degree) atan (ratio) These functions provide trigometric values. sin(), cos(), and tan(), take a degree argument, 0-359, and returns the trigometric value times 100,000. The scaling is necessary since the CROBOT cpu is an integer only machine, and trig values are between 0.0 and 1.0. atan() takes a ratio argument that has been scaled up by 100,000, and returns a degree value, between -90 and +90. The resulting calculation should not be scaled to the actual value until the final operation, as not to lose accuracy. See programming examples for usage. Page 14 CROBOTS (C) Copyright 1985 by Tom Poindexter. 9. CROBOTS C Program Structure 9-1. Basic program structure CROBOTS programs are not unlike other C programs. The minimum CROBOTS program consist of a function named "main". Additionally, other functions can be defined, along with external variables. 9.2 "sniper.r" The following CROBOTS program is provided as an example. /* sniper */ /* strategy: since a scan of the entire battlefield can be done in 90 */ /* degrees from a corner, sniper can scan the field quickly. */ /* external variables, that can be used by any function */ int corner; /* current corner 0, 1, 2, or 2 */ int c1x, c1y; /* corner 1 x and y */ int c2x, c2y; /* " 2 " " " */ int c3x, c3y; /* " 3 " " " */ int c4x, c4y; /* " 4 " " " */ int s1, s2, s3, s4; /* starting scan position for corner 1 - 4 */ int sc; /* current scan start */ int d; /* last damage check */ Page 15 CROBOTS (C) Copyright 1985 by Tom Poindexter. /* main */ main() { int closest; /* check for targets in range */ int range; /* range to target */ int dir; /* scan direction */ /* initialize the corner info */ /* x and y location of a corner, and starting scan degree */ c1x = 10; c1y = 10; s1 = 0; c2x = 10; c2y = 990; s2 = 270; c3x = 990; c3y = 990; s3 = 180; c4x = 990; c4y = 10; s4 = 90; closest = 9999; new_corner(); /* start at a random corner */ d = damage(); /* get current damage */ dir = sc; /* starting scan direction */ while (1) { /* loop is executed forever */ while (dir < sc + 90) { /* scan through 90 degree range */ range = scan(dir,1); /* look at a direction */ if (range <= 700 && range > 0) { while (range > 0) { /* keep firing while in range */ closest = range; /* set closest flag */ cannon(dir,range); /* fire! */ range = scan(dir,1); /* check target again */ if (d + 15 > damage()) /* sustained several hits, */ range = 0; /* goto new corner */ } dir -= 10; /* back up scan, in case */ } dir += 2; /* increment scan */ if (d != damage()) { /* check for damage incurred */ new_corner(); /* we're hit, move now */ d = damage(); dir = sc; } } if (closest == 9999) { /* check for any targets in range */ new_corner(); /* nothing, move to new corner */ d = damage(); dir = sc; } else /* targets in range, resume */ dir = sc; closest = 9999; } } /* end of main */ Page 16 CROBOTS (C) Copyright 1985 by Tom Poindexter. /* new corner function to move to a different corner */ new_corner() { int x, y; int angle; int new; new = rand(4); /* pick a random corner */ if (new == corner) /* but make it different than the */ corner = (new + 1) % 4;/* current corner */ else corner = new; if (corner == 0) { /* set new x,y and scan start */ x = c1x; y = c1y; sc = s1; } if (corner == 1) { x = c2x; y = c2y; sc = s2; } if (corner == 2) { x = c3x; y = c3y; sc = s3; } if (corner == 3) { x = c4x; y = c4y; sc = s4; } /* find the heading we need to get to the desired corner */ angle = plot_course(x,y); /* start drive train, full speed */ drive(angle,100); /* keep traveling until we are within 100 meters */ /* speed is checked in case we run into wall, other robot */ /* not terribly great, since were are doing nothing while moving */ while (distance(loc_x(),loc_y(),x,y) > 100 && speed() > 0) ; /* cut speed, and creep the rest of the way */ drive(angle,20); while (distance(loc_x(),loc_y(),x,y) > 10 && speed() > 0) ; /* stop drive, should coast in the rest of the way */ drive(angle,0); } /* end of new_corner */ Page 17 CROBOTS (C) Copyright 1985 by Tom Poindexter. /* classical pythagorean distance formula */ distance(x1,y1,x2,y2) int x1; int y1; int x2; int y2; { int x, y; x = x1 - x2; y = y1 - y2; d = sqrt((x*x) + (y*y)); return(d); } /* plot course function, return degree heading to */ /* reach destination x, y; uses atan() trig function */ plot_course(xx,yy) int xx, yy; { int d; int x,y; int scale; int curx, cury; scale = 100000; /* scale for trig functions */ curx = loc_x(); /* get current location */ cury = loc_y(); x = curx - xx; y = cury - yy; /* atan only returns -90 to +90, so figure out how to use */ /* the atan() value */ if (x == 0) { /* x is zero, we either move due north or south */ if (yy > cury) d = 90; /* north */ else d = 270; /* south */ } else { if (yy < cury) { if (xx > curx) d = 360 + atan((scale * y) / x); /* south-east, quadrant 4 */ else d = 180 + atan((scale * y) / x); /* south-west, quadrant 3 */ } else { if (xx > curx) d = atan((scale * y) / x); /* north-east, quadrant 1 */ else d = 180 + atan((scale * y) / x); /* north-west, quadrant 2 */ } } return (d); } Page 18 CROBOTS (C) Copyright 1985 by Tom Poindexter. Notes: The distance() and plot_course() routines are quite handy. Save them for your programs. Also, note that the main scan routine will "back up" a few degrees after a target has been found and fired upon. This should catch robots trying to flee away from the direction you are scanning. If the target moves the other way, the normal scan increment will find it. See the other sample CROBOTS program files. Page 19 CROBOTS (C) Copyright 1985 by Tom Poindexter. 10. CROBOTS CPU Architecture and Theory This information is provided if you need to use the debug facility, or are curious about the virtual machine interpreter. Don't bother reading this section if you not so inclined; it is not needed for normal play. 10-1. Stack usage: That stack is controlled implicitly by several pointers. Stack pointers are not accessable through machine instructions. Most instructions will either push data onto the stack, or pop data off the stack. The stack is used from the bottom up (low memory) for data and temporary storage, and is used from the top down (high memory) for saving stack pointers and the program counter on function call/return. External (global) variables are allocated at the very bottom of the stack, and the local mark pointer for 'main' starts just after the externals. External variables are addressed from the beginning of the stack, by offset. When a function is called (including 'main'), the stack pointer is marked (local mark) and is increased by the number of local variables needed for that function. Local variables are addressed relative to the local mark, by offsets. All calculations, function calls, and constants are pushed on and popped off the stack as needed (temporary mark or top of stack). A function call also saves its current stack pointers (local variable mark and frame mark) and program counter. This return information grows from the top down. Arguments are passed to functions by value. The first argument in a function call becomes the first local variable for the called function. Consider the following: main() { /* main has three local variables: */ int a, b, c; ....; sub1 (a,b/2,c+1); /* call sub1, and pass arguments */ ....; } sub1 (x,y,z) /* sub1 takes three parameters and */ int x, y, z; { /* has one local variable */ int result; result = x + y + z; return (result); } Page 20 CROBOTS (C) Copyright 1985 by Tom Poindexter. The main() function allocates three local variables on the stack, sets its local mark at 'a', and sets the temporary stack pointer beyond the locals. Just before sub1() is called, the value of 'a' is pushed, followed by the result of 'b/2', and 'c+1'. When sub1() is called, it sets its local mark where the value of 'a' is, so that 'a' is know as 'x' in func1(), likewise 'b/2' is known as 'y' and 'c+1' is known as 'z'. Sub1() also allocates one more word for 'result', and sets the temporary mark after the storage for 'result'. The following diagram illustrates the stack usage: +------------+ <-- end of stack, high memory |main return | <-- return info for main +------------+ (frame,ip,local mark) |sub1 return | <-- return info for sub1 +------------+ (etc.) | | | | v | <-- additional function call return | | info grow downwards | | | | | | | ^ | <-- additional function calls and | | | expressions grow upwards |expressions | +------------+ <-- temporary mark (top of stack) |sub1 locals | +------------+ <-- local mark: sub1 function |main locals | +------------+ <-- local mark: main function | | | Externals | | | +------------+ <-- beginning of stack 10-2. Link list The link list is a list built by the compiler that contains the names and link information of the functions within the program. The link information contains the starting location of the function within the code, the number of parameters, and the number of other local variables within the function. The link list cannot be accessed by the user program. Page 21 CROBOTS (C) Copyright 1985 by Tom Poindexter. 10-3. Instruction set The CROBOTS cpu has 10 instructions. Each instruction occupies the same amount of storage, with or without operands. FETCH offset (external | local) - Fetch will retrieve a word from either the external variable pool or the local variable pool and push it onto the stack. The offset has its high-bit set (or'ed with 0x8000) if it is an external (offset from the beginning of the stack), otherwise it is a local (offset from the local variable mark). See STORE. STORE offset (external | local), opcode - Store pops the top two items, applies the arithmetic opcode to the two operands, pushes the result on the top of the stack and stores it in the variable referenced by the offset. Offsets are either external or local, according to the method described in Fetch. The result of the opcode is left on the stack. See FETCH and BINOP. CONST k - Const will push a constant onto the stack. BINOP opcode - Binop will pop the top two items as top of stack = y, next to top of stack as x, apply the arithmetic opcode as (x opcode y), and push the result on the stack. Opcodes are decimal representations of 'C' operators such as '+', '/', '>=', etc. See STORE. FCALL link-offset - Fcall performs a high level function call facility. The link-offset operand specifies an entry in the link list table. Fcall pushes its return information: the next instruction counter and the current local variable mark. A new local variable mark and temporary mark (top of stack pointer) is set. The cpu then branches to the first instruction of the function. See RETSUB and FRAME. RETSUB - Retsub returns from a function, leaving the return value on the top of the stack. Retsub restores the previous local variable pool, the next instruction counter, and re-adjusts the stack frame to the point just before the call. The C compiler generates code to return a dummy value if the function does not explicitly return one. See FCALL and FRAME. BRANCH instruction - Branch pops the top of the stack and branches to the instruction if the value is zero. The next sequential instruction is executed if the value is anything other than zero. CHOP - Chop discards the top of the stack by popping it into obilvion. Page 22 CROBOTS (C) Copyright 1985 by Tom Poindexter. FRAME - Frame facilitates fcall/retsub by saving the current top of stack pointer (temporary mark) in anticipation of a fcall statement. The top of stack pointer is saved in the call/return stack as a frame marker. See FCALL and RETSUB. NOP - No operation. Is used as a mark indicating the end of code. 10-4. Machine level debugging Debug mode is used to trace by single stepping machine instructions. Use this only if you need to see your program execute, or are just curious. First, get a listing on paper of a compile with full information by using the '-c' option: A>crobots -c yourpgm.r >prn: Next, start CROBOTS again with the '-d' flag: A>crobots -d yourprm.r Your robot will be placed randomly in the field, and a target robot will be placed at the center of the field (x=500,y=500) so your robot program can find and shoot at a target. The virtual machine interpreter will single step through your program (machine instructions, that is). At every instruction, an machine instruction is disassembled, and the top of stack pointer and value are printed. The top of stack and value are after the results of the instruction. Other information may also be printed, such as function calls searching the link list, etc. On every step, you are prompted "d,h,q,:". Entering 'd' will dump external and local variable pools, as well as vital information of your robot: coordinates, heading, speed, damage, etc., and the status of any missiles your robot may have fired. Entering 'h' will simulate your robot taking a 10% damage hit, so you can check damage detection, etc. Entering 'q' will quit the program immediately, and return you to DOS. A carriage return alone will continue the stepping process. All responses ('d','h', or 'q') should be in lower case only. You should refer to the compile listing for offsets into the external and local variable pools, C code, etc. Page 23 CROBOTS (C) Copyright 1985 by Tom Poindexter. 11. Implemetation notes CROBOTS is written entirely in 'C'. The compiler section was developed with the aid of the Unix* (TM) programs 'yacc' and 'lex'. Yacc (yet another compiler-compiler) accepts a 'grammar', which describes the CROBOTS 'C' language. Yacc produces a 'C' function known as a parser. The parser is the heart of the compiler, recognizing vaild 'C' constructs. Lex (lexical analyzer) accepts a list of token combinations, and produces a 'C' function to scan the compiler input for the tokens. The yacc generated parser, yyparse(), repeatedly calls the lex generated analyzer, yylex(), to process the source program. The initial screen display routines were developed with the 'curses' screen library. The 'C' source code was then ported to MS-DOS** (TM), and recompiled using the Lattice*** (TM) 2.15E compiler, using the 'small' memory model. The screen display functions were modified to use 'int86()', accessing the rom INT 10H cursor postitioning functions in the IBM-PC bios. * Unix is a trademark of Bell Telephone Laboratories. ** MS-DOS is a trademark of Microsoft, Inc. *** Lattice is a trademark of Lattice, Inc. **** IBM is a trademark of International Business Machines, Inc. Page 24 CROBOTS (C) Copyright 1985 by Tom Poindexter. CROBOTS Order Form: +------------------------------------------------------------+ | 1. Complete and sign the source code license. | | | | 2. Send this completed form along with $20 check or | | money order to: | | | | Tom Poindexter | | 2903 Winchester Drive | | Bloomington, Illinois 61701 | | | | -For orders outside the U.S., add an additional $5, and | | enclose an international money order, payable in | | U.S. currency. | | | | | | | | _________________________________________ | | Name | | | | _________________________________________ | | | | _________________________________________ | | Address | | | | | | ______________________ ________ ____________ | | City State Zip | | | | | | Source code license: | | Source code to CROBOTS is provided for personal use only. | | You may incorporate portions of CROBOTS into your own | | programs. | | | | I agree not to distribute CROBOTS source code to anyone | | without prior written permission from the copyright | | holder, whether a fee is charged or not. | | | | | | ________________________________________ ______________ | | Signature Date | | | +------------------------------------------------------------+ Page 25 CROBOTS (C) Copyright 1985 by Tom Poindexter. Page 26 Date: Tuesday, 14 Jan 1992 16:43:55 EST From: Message-ID: <92014.164355JJJ101@psuvm.psu.edu> Subject: Where is C-robots? Here are some possible ftp sites: Note1: I just pasted this file into the article without editing. Note2: I am not affiliated with the author. Just a happy user. --------------------------CUT------------------------- Received: from utorugw by PSUVM.PSU.EDU (Mailer R2.08) with BSMTP id 1867; Thu, 19 Dec 91 19:51:35 EST Received: from oliver.cs.mcgill.ca ([132.206.1.5]) by ugw.utcs.utoronto.ca with SMTP id <23731>; Thu, 19 Dec 1991 19:47:32 -0500 Received: from quiche.CS.McGill.CA by oliver.cs.mcgill.ca (5.61+ (*mx)) with SMTP id AA11215; Thu, 19 Dec 91 19:45:51 -0500 Received: by quiche.CS.McGill.CA (4.1/SMI-4.1.b) id AA24021; Thu, 19 Dec 91 19:40:06 EST Date: Thu, 19 Dec 1991 19:40:06 -0500 Message-Id: <9112200040.AA24021@quiche.CS.McGill.CA> From: archie@quiche.CS.McGill.CA To: Subject: archie reply: prog "CRobot" ... Sorting by hostname [12 Dec 1990] *** The database is a bit messed up. If you get errors please try again tomorrow... it should be fixed by then. Mail-only users may access anonymous ftp by mail through an ftp-mail server. BITNET/EARN/NetNorth users may use the server at bitftp@pucc.princeton.edu Other users may use the server ftpmail@decwrl.dec.com In both cases send 'help' (no signatures) in a message for information on how to use them. Please note that problems with the ftpmail server have been reported but we have been unable to resolve them. *** Three New North American archies archie available The archie service which has been provided by archie.mcgill.ca is now available on archie.sura.net archie.ans.net archie.unl.edu All three methods of lookup are supported (telnet,client,mail-request) on all sites. Search request for 'C-Robot' No match for 'C-Robot'. Sorting by hostname [12 Dec 1990] *** The database is a bit messed up. If you get errors please try again tomorrow... it should be fixed by then. Mail-only users may access anonymous ftp by mail through an ftp-mail server. BITNET/EARN/NetNorth users may use the server at bitftp@pucc.princeton.edu Other users may use the server ftpmail@decwrl.dec.com In both cases send 'help' (no signatures) in a message for information on how to use them. Please note that problems with the ftpmail server have been reported but we have been unable to resolve them. *** Three New North American archies archie available The archie service which has been provided by archie.mcgill.ca is now available on archie.sura.net archie.ans.net archie.unl.edu All three methods of lookup are supported (telnet,client,mail-request) on all sites. Search request for 'C-robot' No match for 'C-robot'. Sorting by hostname [12 Dec 1990] *** The database is a bit messed up. If you get errors please try again tomorrow... it should be fixed by then. Mail-only users may access anonymous ftp by mail through an ftp-mail server. BITNET/EARN/NetNorth users may use the server at bitftp@pucc.princeton.edu Other users may use the server ftpmail@decwrl.dec.com In both cases send 'help' (no signatures) in a message for information on how to use them. Please note that problems with the ftpmail server have been reported but we have been unable to resolve them. *** Three New North American archies archie available The archie service which has been provided by archie.mcgill.ca is now available on archie.sura.net archie.ans.net archie.unl.edu All three methods of lookup are supported (telnet,client,mail-request) on all sites. Search request for 'CRobot' Host gatekeeper.dec.com (16.1.0.2) Last updated 13:09 16 Dec 1991 Location: /micro/amiga/fish/f3/ff345 FILE r--r--r-- 111261 Aug 20 1990 CRobots.zoo Location: /micro/amiga/fish/f3/ff331 FILE r--r--r-- 106122 Aug 20 1990 CRobots.zoo Location: /micro/amiga/fish/f3/ff311 FILE r--r--r-- 107467 Aug 20 1990 CRobots.zoo Host nic.funet.fi (128.214.6.100) Last updated 20:39 12 Dec 1991 Location: /pub/amiga/fish/disks300-399/ff311 FILE rw-rw-r-- 107467 Mar 10 1990 CRobots.zoo Location: /pub/amiga/fish/disks300-399/ff331 FILE rw-rw-r-- 106122 May 1 1990 CRobots.zoo Location: /pub/amiga/fish/disks300-399/ff345 FILE rw-rw-r-- 111261 May 9 1990 CRobots.zoo Host ux1.cso.uiuc.edu (128.174.5.59) Last updated 23:36 12 Dec 1991 Location: /amiga/fish/f3/ff311 FILE rw-rw-r-- 107467 May 6 1990 CRobots.zoo Location: /amiga/fish/f3/ff331 FILE rw-rw-r-- 106122 May 6 1990 CRobots.zoo Location: /amiga/fish/f3/ff345 FILE rw-rw-r-- 111261 May 6 1990 CRobots.zoo Host wuarchive.wustl.edu (128.252.135.4) Last updated 00:22 13 Dec 1991 Location: /systems/amiga/fish/fish/f3/ff345 FILE rw-rw-r-- 111261 Aug 19 1990 CRobots.zoo Location: /systems/amiga/fish/fish/f3/ff331 FILE rw-rw-r-- 106122 Aug 19 1990 CRobots.zoo Location: /systems/amiga/fish/fish/f3/ff311 FILE rw-rw-r-- 107467 Aug 19 1990 CRobots.zoo Sorting by hostname [12 Dec 1990] *** The database is a bit messed up. If you get errors please try again tomorrow... it should be fixed by then. Mail-only users may access anonymous ftp by mail through an ftp-mail server. BITNET/EARN/NetNorth users may use the server at bitftp@pucc.princeton.edu Other users may use the server ftpmail@decwrl.dec.com In both cases send 'help' (no signatures) in a message for information on how to use them. Please note that problems with the ftpmail server have been reported but we have been unable to resolve them. *** Three New North American archies archie available The archie service which has been provided by archie.mcgill.ca is now available on archie.sura.net archie.ans.net archie.unl.edu All three methods of lookup are supported (telnet,client,mail-request) on all sites. Search request for 'Crobot' No match for 'Crobot'. Sorting by hostname Sorting by hostname [12 Dec 1990] *** The database is a bit messed up. If you get errors please try again tomorrow... it should be fixed by then. Mail-only users may access anonymous ftp by mail through an ftp-mail server. BITNET/EARN/NetNorth users may use the server at bitftp@pucc.princeton.edu Other users may use the server ftpmail@decwrl.dec.com In both cases send 'help' (no signatures) in a message for information on how to use them. Please note that problems with the ftpmail server have been reported but we have been unable to resolve them. *** Three New North American archies archie available The archie service which has been provided by archie.mcgill.ca is now available on archie.sura.net archie.ans.net archie.unl.edu All three methods of lookup are supported (telnet,client,mail-request) on all sites. Search request for 'c-robot' No match for 'c-robot'. [12 Dec 1990] *** The database is a bit messed up. If you get errors please try again tomorrow... it should be fixed by then. Mail-only users may access anonymous ftp by mail through an ftp-mail server. BITNET/EARN/NetNorth users may use the server at bitftp@pucc.princeton.edu Other users may use the server ftpmail@decwrl.dec.com In both cases send 'help' (no signatures) in a message for information on how to use them. Please note that problems with the ftpmail server have been reported but we have been unable to resolve them. *** Three New North American archies archie available The archie service which has been provided by archie.mcgill.ca is now available on archie.sura.net archie.ans.net archie.unl.edu All three methods of lookup are supported (telnet,client,mail-request) on all sites. Search request for 'crobot' Host ab20.larc.nasa.gov (128.155.23.64) Last updated 18:01 12 Dec 1991 Location: /usenet/comp.binaries.amiga/volume90/fun DIRECTORY rwxrwxr-x 512 Jan 17 1991 crobots-2.1 DIRECTORY rwxrwxr-x 512 Jan 17 1991 crobots-2.3 Location: /usenet/comp.binaries.amiga/volume2/fun FILE rw-rw-r-- 46065 Dec 7 1988 crobots.uu1.Z Location: /usenet/comp.binaries.amiga/volume90/fun DIRECTORY rwxrwxr-x 512 Jan 17 1991 crobots-2.2 Location: /usenet/comp.binaries.amiga/volume2/fun FILE rw-rw-r-- 26921 Dec 7 1988 crobots.uu2.Z Host alex.stacken.kth.se (130.237.237.3) Last updated 18:03 12 Dec 1991 Location: /disk1/pc/c FILE r--r--r-- 77824 Dec 10 1990 crobots.arc Host athene.uni-paderborn.de (131.234.2.32) Last updated 18:16 12 Dec 1991 Location: /pcsoft/amiga/games/tactics FILE rw-r--r-- 86866 Dec 12 1990 crobots.lzh Location: /news/amiga/bin/volume90/fun DIRECTORY rwxr-xr-x 512 Jul 15 14:26 crobots-2.3 Host f.ms.uky.edu (128.163.128.6) Last updated 19:03 12 Dec 1991 Location: /pub/msdos/Games FILE rw-rw-r-- 77824 Oct 23 1990 crobots.arc Host nic.funet.fi (128.214.6.100) Last updated 20:39 12 Dec 1991 Location: /pub/msdos/languages/c FILE rw-rw-r-- 53795 May 18 1991 crobots.lzh Host procyon.cis.ksu.edu (129.130.10.80) Last updated 13:39 16 Dec 1991 Location: /pub/PC/Util/C FILE rw-rw-r-- 77824 Aug 16 1990 crobots.arc Host rigel.acs.oakland.edu (141.210.10.117) Last updated 21:32 12 Dec 1991 Location: /pub/msdos/c FILE rw-r--r-- 77824 Jan 8 1988 crobots.arc Host sabrina.dei.unipd.it (147.162.2.106) Last updated 21:50 12 Dec 1991 Location: /pub/ibmpc/games FILE r--r--r-- 53560 Feb 28 1991 crobots.zip Host src.doc.ic.ac.uk (146.169.3.7) Last updated 13:03 19 Dec 1991 Location: /ibmpc/wsmr-simtel20.army.mil/c FILE rw-r--r-- 77824 Jan 9 1988 crobots.arc Host trantor.ee.msstate.edu (130.18.64.2) Last updated 23:11 12 Dec 1991 Location: /files/IBM.games FILE rw-r--r-- 77824 Mar 28 1990 crobots.arc Host uunet.uu.net (137.39.1.2) Last updated 23:25 12 Dec 1991 Location: /systems/msdos/simtel20/c FILE rw-r--r-- 77824 Jan 7 1988 crobots.arc Host ux1.cso.uiuc.edu (128.174.5.59) Last updated 23:36 12 Dec 1991 Location: /pc/exec-pc FILE rw-rw-r-- 67763 Jul 21 1989 crobot.zip Host wolfen.cc.uow.edu.au (130.130.68.4) Last updated 00:19 13 Dec 1991 Location: /ab20/usenet/comp.binaries.amiga/volume90/fun DIRECTORY rwxr-xr-x 512 Aug 1 15:52 crobots-2.3 DIRECTORY rwxr-xr-x 512 Aug 1 15:42 crobots-2.1 Location: /ab20/usenet/comp.binaries.amiga/volume2/fun FILE rw-rw-r-- 46065 Aug 1 01:16 crobots.uu1.Z Location: /ab20/usenet/comp.binaries.amiga/volume90/fun DIRECTORY rwxr-xr-x 512 Aug 1 15:46 crobots-2.2 Location: /ab20/usenet/comp.binaries.amiga/volume2/fun FILE rw-rw-r-- 26921 Aug 1 01:16 crobots.uu2.Z Host wuarchive.wustl.edu (128.252.135.4) Last updated 00:22 13 Dec 1991 Location: /usenet/comp.binaries.amiga/volume90/fun DIRECTORY rwxrwxr-x 512 Feb 8 1991 crobots-2.3 DIRECTORY rwxrwxr-x 512 Feb 8 1991 crobots-2.2 Location: /mirrors/msdos/c FILE rw-r--r-- 77824 Jan 9 1988 crobots.arc Location: /usenet/comp.binaries.amiga/volume2/fun FILE rw-rw-r-- 26958 Dec 15 1988 crobots.uu2.Z Location: /usenet/comp.binaries.amiga/volume90/fun DIRECTORY rwxrwxr-x 512 Feb 8 1991 crobots-2.1 Location: /usenet/comp.binaries.amiga/volume2/fun FILE rw-rw-r-- 46102 Dec 15 1988 crobots.uu1.Z Date: Tuesday, 14 Jan 1992 16:48:41 EST From: Message-ID: <92014.164841JJJ101@psuvm.psu.edu> Subject: Sample C-robot program: rook.r /* rook.r - scans the battlefield like a rook, i.e., only 0,90,180,270 */ /* move horizontally only, but looks horz and vertically */ int course; int boundary; int d; main() { int y; /* move to center of board */ if (loc_y() < 500) { drive(90,70); /* start moving */ while (loc_y() - 500 < 20 && speed() > 0) /* stop near center */ ; } else { drive(270,70); /* start moving */ while (loc_y() - 500 > 20 && speed() > 0) /* stop near center */ ; } drive(y,0); /* initialize starting parameters */ d = damage(); course = 0; boundary = 995; drive(course,30); /* main loop */ while(1) { /* look all directions */ look(0); look(90); look(180); look(270); /* if near end of battlefield, change directions */ if (course == 0) { if (loc_x() > boundary || speed() == 0) change(); } else { if (loc_x() < boundary || speed() == 0) change(); } } } /* look somewhere, and fire cannon repeatedly at in-range target */ look(deg) int deg; { int range; while ((range=scan(deg,2)) > 0 && range <= 700) { drive(course,0); cannon(deg,range); if (d+20 != damage()) { d = damage(); change(); } } } change() { if (course == 0) { boundary = 5; course = 180; } else { boundary = 995; course = 0; } drive(course,30); } /* end of rook.r */ From: JJJ101@psuvm.psu.edu Subject: Sample C-robot program: sniper.r Message-ID: <92014.165145JJJ101@psuvm.psu.edu> Date: 14 Jan 92 21:51:45 GMT /* sniper */ /* strategy: since a scan of the entire battlefield can be done in 90 */ /* degrees from a corner, sniper can scan the field quickly. */ /* external variables, that can be used by any function */ int corner; /* current corner 0, 1, 2, or 2 */ int c1x, c1y; /* corner 1 x and y */ int c2x, c2y; /* " 2 " " " */ int c3x, c3y; /* " 3 " " " */ int c4x, c4y; /* " 4 " " " */ int s1, s2, s3, s4; /* starting scan position for corner 1 - 4 */ int sc; /* current scan start */ int d; /* last damage check */ /* main */ main() { int closest; /* check for targets in range */ int range; /* range to target */ int dir; /* scan direction */ /* initialize the corner info */ /* x and y location of a corner, and starting scan degree */ c1x = 10; c1y = 10; s1 = 0; c2x = 10; c2y = 990; s2 = 270; c3x = 990; c3y = 990; s3 = 180; c4x = 990; c4y = 10; s4 = 90; closest = 9999; new_corner(); /* start at a random corner */ d = damage(); /* get current damage */ dir = sc; /* starting scan direction */ while (1) { /* loop is executed forever */ while (dir < sc + 90) { /* scan through 90 degree range */ range = scan(dir,1); /* look at a direction */ if (range <= 700 && range > 0) { while (range > 0) { /* keep firing while in range */ closest = range; /* set closest flag */ cannon(dir,range); /* fire! */ range = scan(dir,1); /* check target again */ if (d + 15 > damage()) /* sustained several hits, */ range = 0; /* goto new corner */ } dir -= 10; /* back up scan, in case */ } dir += 2; /* increment scan */ if (d != damage()) { /* check for damage incurred */ new_corner(); /* we're hit, move now */ d = damage(); dir = sc; } } if (closest == 9999) { /* check for any targets in range */ new_corner(); /* nothing, move to new corner */ d = damage(); dir = sc; } else /* targets in range, resume */ dir = sc; closest = 9999; } } /* end of main */ /* new corner function to move to a different corner */ new_corner() { int x, y; int angle; int new; new = rand(4); /* pick a random corner */ if (new == corner) /* but make it different than the */ corner = (new + 1) % 4;/* current corner */ else corner = new; if (corner == 0) { /* set new x,y and scan start */ x = c1x; y = c1y; sc = s1; } if (corner == 1) { x = c2x; y = c2y; sc = s2; } if (corner == 2) { x = c3x; y = c3y; sc = s3; } if (corner == 3) { x = c4x; y = c4y; sc = s4; } /* find the heading we need to get to the desired corner */ angle = plot_course(x,y); /* start drive train, full speed */ drive(angle,100); /* keep traveling until we are within 100 meters */ /* speed is checked in case we run into wall, other robot */ /* not terribly great, since were are doing nothing while moving */ while (distance(loc_x(),loc_y(),x,y) > 100 && speed() > 0) ; /* cut speed, and creep the rest of the way */ drive(angle,20); while (distance(loc_x(),loc_y(),x,y) > 10 && speed() > 0) ; /* stop drive, should coast in the rest of the way */ drive(angle,0); } /* end of new_corner */ /* classical pythagorean distance formula */ distance(x1,y1,x2,y2) int x1; int y1; int x2; int y2; { int x, y; x = x1 - x2; y = y1 - y2; d = sqrt((x*x) + (y*y)); return(d); } /* plot course function, return degree heading to */ /* reach destination x, y; uses atan() trig function */ plot_course(xx,yy) int xx, yy; { int d; int x,y; int scale; int curx, cury; scale = 100000; /* scale for trig functions */ curx = loc_x(); /* get current location */ cury = loc_y(); x = curx - xx; y = cury - yy; /* atan only returns -90 to +90, so figure out how to use */ /* the atan() value */ if (x == 0) { /* x is zero, we either move due north or south */ if (yy > cury) d = 90; /* north */ else d = 270; /* south */ } else { if (yy < cury) { if (xx > curx) d = 360 + atan((scale * y) / x); /* south-east, quadrant 4 */ else d = 180 + atan((scale * y) / x); /* south-west, quadrant 3 */ } else { if (xx > curx) d = atan((scale * y) / x); /* north-east, quadrant 1 */ else d = 180 + atan((scale * y) / x); /* north-west, quadrant 2 */ } } return (d); } From: JJJ101@psuvm.psu.edu Subject: About the smaple C-robot programs Message-ID: <92014.165235JJJ101@psuvm.psu.edu> Date: 14 Jan 92 21:52:35 GMT I should have mentioned that I didn't write them--they are usually included as samples with the C-robot package. Anyway, I put sniper.r against rook.r. Sniper.r won 20 times in a row. James From: cyoon@utdallas.edu (Chang K. Yoon) Subject: Re: Possible C-robot tournament Message-ID: <1992Jan14.220255.24127@utdallas.edu> Date: 14 Jan 92 22:02:55 GMT ------- BEGIN INCLUDED MESSAGE ------- Being relatively new to this group (but not corewars) I have not heard of C -robots befor.Are they programs similar to redcode programs and in what they do or are they something completely different? Can they be written using a normal C compiler or do they require some special libraries? Incidently are there any corewars systems/interpreters whatever for HP-UX? Neil Robertson LUT Leicestershire England -------- END INCLUDED MESSAGE -------- C-robots is similar to Corewars, but instead of writing in assembly (redcode), you write in C using special routines that are specially made for the game. In C-robots, you write an "electronic" robot which goes around shooting things. It has a certain number of "hit points" before it can be killed. ------------------------------------------------------------------------------- Chang Yoon | DISCLAIMER: My thoughts (and no one cyoon@utdallas.edu | else's) ------------------------------------------------------------------------------- "Our children know EVERYTHING, we have cable." - Ms. Penbroke, C 'n C ------------------------------------------------------------------------------- From: tpoindex@isis.cs.du.edu (Tom Poindexter) Subject: Re: Possible C-robot tournament Message-ID: <1992Jan15.030324.22493@mnemosyne.cs.du.edu> Date: Wed, 15 Jan 92 03:03:24 GMT Just a note to let everyone know that I'm available to answer questions about CROBOTS. I also follow this newgroups on a regular basis. Good luck to everyone that would participate in a tourney. I won't be entering myself (not to say that I'd write the winner anyway ;-) Tom Poindexter - author of CROBOTS tpoindex@nys.cs.du.edu ps. for those who have trouble contacting my in the past, my new address is: 6864 Amherst Ct. Highlands Ranch, CO 80126 Subject: Re: King of the Hill From: wolfe@bmerh707.bnr.ca (Ian Woollard) Date: 15 Jan 92 21:39:36 GMT Message-ID: <1992Jan15.213936.28541@bmerh2.bnr.ca> In article <1992Jan13.170205.1721@iWarp.intel.com> you write: >Mark Durham posted: >>I think the hill would improve if the programs there were judged by not >>only how they do in the tournament run when a new warrior is submitted, >>but also how well they did in past tournaments. > Of course this is a standard problem, with standard solutions in human games such as chess, tennis etc. Suggested 'optimal' solution: 1. Keep all the entrants. 2. Maintain a score from tournament to tournament 3. Randomly play off entrants (as many games as you have time for!) 4. Update the scores based on how good each player is thought to be, and whether they won or lost. Anybody know a good algorithm for 4? I used to have one that I grabbed off the net from rec.games.chess... -Ian. Min. sig. of world unite! -- -- From: aspgpas@cidsv01.cid.aes.doe.ca (Peter Silva) Subject: Generic CoreWar for one of SGI,SUN,MIPS,PC desired. Message-ID: <1992Jan15.221748.26652@cid.aes.doe.CA> Date: 15 Jan 92 22:17:48 GMT I'm just looking for a simple Core-war implementation that works on one (or more) of the machines listed above. No fancy output required. ICWS'88 or some extended version thereof would be nice. KotH would be even nicer, since William Shubert has been kind enough to supply some documentation for it. I have ftp access. -- anthony Subject: Re: King of the Hill From: Date: Thursday, 16 Jan 1992 00:05:14 EST Message-ID: <92016.000515JJJ101@psuvm.psu.edu> In article <1992Jan15.213936.28541@bmerh2.bnr.ca>, wolfe@bmerh707.bnr.ca (Ian Woollard) says: > >In article <1992Jan13.170205.1721@iWarp.intel.com> you write: >>Mark Durham posted: >>>I think the hill would improve if the programs there were judged by not >>>only how they do in the tournament run when a new warrior is submitted, >>>but also how well they did in past tournaments. >> > >Of course this is a standard problem, with standard solutions in human >games such as chess, tennis etc. This a little off subject, but an interesting idea might be to run all 10 (11?) programs in the core simultaneously. Repeat this 50 times. If first place per round is 10 pts., max score is 500. Coresize and MAXPROC would need to be raised. This is also a good scenario to test the "window" idea. -- James Date: Thursday, 16 Jan 1992 00:14:49 EST From: Message-ID: <92016.001449JJJ101@psuvm.psu.edu> Subject: Omega? I think there is some kind of commercial software called Omega which uses a BASIC/English syntax to program tanks. 1. Anyone ever hear of this game? 2. Is it too aimed at the non-programmer to appeal to corewar/c-bots players? 3. A review would be nice. -- James From: pwb@newt.phys.unsw.oz.au (Paul W. Brooks) Subject: Crobots - King of the Hill? Message-ID: <1992Jan16.035031.15571@usage.csd.unsw.OZ.AU> Date: 16 Jan 92 03:50:31 GMT I FTP'ed the Crobots distribution last night, then got hooked writing robots, and forgot to sleep! the result of my labours - hunter.r - always beats three simultaneous snipers, sometimes without losing a point in damage :-) I would certainly like to enter it into a Crobots King of the Hill competition, but in the meantime, does anyone have other designs (apart from the three in the archive) they would be willing to mail to me? Any and all will be received with gratitude... Regards, Paul Brooks |Internet: pwb@newt.phys.unsw.edu.au Uni. of N.S.W. |If you have trouble sleeping, try lying on the end of Kensington NSW 2033| your bed. With a little luck you'll drop off. AUSTRALIA | - Mark Twain. Subject: Re: Omega? From: polari!mrp@sumax.seattleu.edu Date: 16 Jan 92 04:41:35 GMT Message-ID: <1992Jan16.044135.12549@polari.uucp> In article <92016.001449JJJ101@psuvm.psu.edu> JJJ101@psuvm.psu.edu writes: >I think there is some kind of commercial software called Omega which >uses a BASIC/English syntax to program tanks. For the Apple II series, there's Robot War, a game very much like c-robots but which uses a graphic display (rather than character-based) for the combat arena and a BASIC-like language and structures. For the Macintosh series, there's RoboWars, 'bots, and one other game (MegaBots, I think) that are all essentially the same as Robot War. Having tried them all, I've found 'bots to be the most interesting, since each robot may have a variety of weapons, abilities, and defensive systems. I've never heard of Omega, though. From: lidl@Pix.COM (Kurt J. Lidl) Subject: RFD: rec.games.xtank.{coding|play} Message-ID: Date: 16 Jan 92 14:23:23 GMT Following is a Request For Discussion for two new newsgroups. Both newsgroups are related to the game Xtank. Briefly put, Xtank is a multi-player vehicular-based (normally combat-oriented) game played in mazes of various sizes and types. Humans control a vehicle (usually a tank) equipped with a variety of armor and weaponry. Your objective depends on the type of game you play. (Combat, War, Ultimate, Capture the flag, or Race). Xtank runs under X11R[345], on a variety of hardware platforms: Sun3, Sun4, RS6000, IBM PC/RT, Vaxes, DECstations, Silicon Graphics, Motorola SysV boxes, Encore Multimaxes (Sys 5 universe). (Not all features are supported on all platforms.) One of the more unique features about xtank is that it is a multi-threaded game. This allows players to load a robot program file (either written in "C" or a "C" linkable language) into the running Xtank image and start playing with that program. Thus, each player can "submit" a program that can control a vehicle for the duration of a game. Now that you know what Xtank is about, here's the newsgroup proposals. The PROPOSED TITLE of the first group is: rec.games.xtank.play The CHARTER of rec.games.xtank.play is to promote the exchange of ideas and strategy for human players of the game. STATUS: unmoderated The PURPOSE OF THE GROUP is the discussion of a game play between humans and robots. Winning combinations for robot competitions and especially interesting human play games welcome. The REASON FOR CREATING A GROUP is that there is no other way to efficiently distribute electronic information to such a large community of people. The current mailing list takes over an hour to process the full queue, and is causing quite a strain on our systems. Furthermore, a newsgroup should allow more people to become exposed to the game. The PROPOSED TITLE of the second group is: rec.games.xtank.coding The CHARTER of rec.games.xtank.coding is to promote the exchange of ideas and coding tips for people who are coding game-playing robots and making modifications to the core Xtank program, or its user interface program(s). STATUS: unmoderated The PURPOSE OF THE GROUP is the discussion of modifications to the code of the program and the robot programs that are contained in the Xtank distribution. Additionally, programmers of xtank robot programs should use this group to solicite feedback from others as to their programming efforts and for bug reports and fixes for their robots. The REASON FOR CREATING A GROUP is that the current xtank mailing list is getting too large and has a slow turn-around time for critical issues. The current mailing list takes over an hour to process the full queue, and is causing quite a strain on our systems. Furthermore, a newsgroup should allow many more people to become exposed to the game, and the wonders of robot programming. -- /* Kurt J. Lidl (lidl@pix.com) | Unix is the answer, but only if you */ /* UUCP: uunet!mimsy!pixcom!lidl | phrase the question very carefully. */ Subject: Re: Omega? From: dkoski@noao.edu (David Koski) Date: 16 Jan 92 23:42:04 GMT Message-ID: <1992Jan16.234204.13529@noao.edu> In article <92016.001449JJJ101@psuvm.psu.edu> JJJ101@psuvm.psu.edu writes: >I think there is some kind of commercial software called Omega which >uses a BASIC/English syntax to program tanks. > >1. Anyone ever hear of this game? Yes, I have it for the Atari ST. It is from Origin, makers of Ultima and Wing Commander. >2. Is it too aimed at the non-programmer to appeal to corewar/c-bots > players? Well, not really. You can do some advanced stuff with it like have teams of tanks cooperating. It supposedly has 'AI', but I can't see any (unless you write the code yourself). It gets fairly boring to watch once you get to OMEGA class, so I never play it any more. Anyway the programming can be very verbose if you want, but the allow you to abbreviate everything. You can have loops, procedures, etc. You have to deal with the equipment your tank has too. For instance most of my tanks had a turbo laser, it fired quickly, but didn't do much damage. I would race into range and just start blasting my target (without following its movement, hopefully I would be fast enough to do major damage) and then run away. I got all the way to OMEGA class (you must beat a computer tank 70% of the time to go up in class) using this tank. >3. A review would be nice. It was OK. I paid about $25 for it, and I guess it was worth it. I use xtank on my NeXT now, and xtank is better... free too. David Koski Subject: Re: Omega? From: mcganm@aix02.ecs.rpi.edu (Mark Robert Mcgann) Date: 17 Jan 92 04:27:57 GMT Message-ID: In article <1992Jan16.234204.13529@noao.edu> dkoski@noao.edu (David Koski) writes: >In article <92016.001449JJJ101@psuvm.psu.edu> JJJ101@psuvm.psu.edu writes: >>I think there is some kind of commercial software called Omega which >>uses a BASIC/English syntax to program tanks. >> >>1. Anyone ever hear of this game? > >Yes, I have it for the Atari ST. It is from Origin, makers of Ultima and >Wing Commander. I own this game for the IBM. Its actually the reason I looked up this news group. I'm looking for other people who own the game who would be interested in swapping tanks. The biggest problem I had with the game was after I beat all the computer tanks I had nothing to fight by my own. If anybody out the is interested please e-mail me. -Mark McGann -mcganm@rpi.edu Subject: Re: Omega? From: ajpierce@med.unc.edu (Andrew Pierce) Date: 17 Jan 92 14:04:06 GMT Message-ID: <1992Jan17.140406.3437@samba.oit.unc.edu> In article <92016.001449JJJ101@psuvm.psu.edu> JJJ101@psuvm.psu.edu writes: >I think there is some kind of commercial software called Omega which >uses a BASIC/English syntax to program tanks. >1. Anyone ever hear of this game? >2. Is it too aimed at the non-programmer to appeal to corewar/c-bots > players? >3. A review would be nice. There is indeed such a program, in fact, I have it for the Amiga. It is a lot of fun. There is a BASIC/English like command language with which you write the tank's AI and a section for designing the various parameters of the tank's physical nature such as weight, engine type, weaponry systems etc. Initially, you start out limited in the number of physical systems you can use. Gradually, as you advanvce (by defeating the computer test-tanks) you can add on more and more equipment. There is no such limit on the AI and a tank at any level can have the same AI, however, as new equipment is added (for example a scanner lock/jammer combination) you need to add new AI to control the new gear. I have found that usually when I start from the beginning again, the tank needs to go through about 2 radical redesigns as it advances. Ultimately, all restrictions are removed and you can have whatever gear you want. This ultimate step appears to not be the most fun to play though as a tank with a "sit and wait to kill the other guy" with some rudimentary tit-for-tat and retreat intelligence seems to have a significant edge. More fun is to impose a restriction on the amount of credits usable to build the tank. C-bots players would probably love this. It is identical to c-bots, except that the tanks fight where there is terrain to figure in, and different equipment to figure in too. Also, there is a feature whereby tanks can communicate with each other which allows "team-tank" strategies although I haven't messed with that a whole lot. The game is sufficiently interesting that I still dig it out from time to time years after I got it. Where to get it: Origin Systems Inc., P.O. Box 161750, Austin, Texas 78716, or at least this is what it says on my (several years old) box for it. -Andy ajpierce@med.unc.edu Subject: POLL From: solman@athena.mit.edu (Jason W Solinsky) Date: 17 Jan 92 20:40:23 GMT Message-ID: <1992Jan17.204023.14582@athena.mit.edu> Should SPL as it is defined in the International Core War Society Standard of 1988* remain in any future standard(s)? YES: SPL should remain unchanged. This does not preclude altering Core War in other ways (e.g. range addressing) or the possible inclusion of additional task-launching opcodes and instructions. NO: SPL as it exists in ICWS'88 should be changed, replaced, or dropped entirely from future standards. This is merely an opinion poll and is non-binding on the ICWS. Send replies to: solman@Athena.MIT.EDU Votes should be clearly indicated either YES or NO, but comments are welcome. * SPL as it is currently defined in ICWS'88 places the new task at the back of the task queue such that all previously existing tasks (including the currently executing task with the SPL instruction) will execute one instruction each prior to the new task executing its first instruction. Each task has an equal share of the warrior's processor time (one instruction per turn). Jason W. Solinsky Subject: POLL II From: solman@athena.mit.edu (Jason W Solinsky) Date: 17 Jan 92 20:54:24 GMT Message-ID: <1992Jan17.205424.15620@athena.mit.edu> I am collecting possible implementations of SPL for a future poll. The poll will list all possible variations of SPL and will ask people that answer it to rank as many choices as they wish. The choice with the lowest number of first place votes will then be eliminated and its votes spread amongst the other choices by second choices. This will be repeated until there are two left. If all the ranked options on a given ballot are eliminated, then that ballot will be discarded. This system, used in Cambridge Cuty Council elections, makes sure that very similar options do not hurt each other. Once one of the options is eliminated, it will inheret the other's vote. The poll will be non-binding for the ICWS. The following options have been identified thus far. Please send mail describing any options not listed. A) Keep SPL exactly the way it is B) Keep SPL as it is, but put the new task at the begining of the queue C) Keep SPL as it is, but put the new task at the end of the queue and BEFORE the original task. D) Change SPL by splitting the parents time between its children E) Change SPL by splitting the parent's time between its children and make sure that the next time the new task executes is after the next time the old task executes. I expect to get ATLEAST 10 other variants. Jason W. Solinsky From: fau@po.CWRU.Edu (Francis A. Uy) Subject: new subscriber Message-ID: <1992Jan18.021453.13794@usenet.ins.cwru.edu> Date: Sat, 18 Jan 92 02:14:53 GMT Two comments: 1) I use a Mac. What's the latest + greatest corewar simulator for it? I think I can get a hold of Core! v1.0 by Jon Newman, but is there a newer version, or a successor? 2) I would like to see the code for this XTC. There's a lot of talk about it here. Thanks much. More later. -- Francis A. Uy 410.465.1316 "You must rely on the lightning and not fau@po.cwru.edu 410.461.0960 forecast the dance." -- Van, quoting Graves, messing with my mind Subject: C-robots testing... From: JJJ101@psuvm.psu.edu Date: 18 Jan 92 20:31:32 GMT Message-ID: <92018.153132JJJ101@psuvm.psu.edu> I took 8 crobot programs and ran each unique group of 4, 5 times. This is a total of 350 matches. (70*5). Scoring: 3 points for a win, 1 point each for a tie, 0 points for mutual destruction. Results: (Highest possible score is 525) pingpo.r 414 sniper.r 135 scan.r 129 h-k.r 108 hak3.r 90 t.r 87 counter.r 57 rook.r 9 Comment1: It took my PS/2 model 30-286, 3 hours to run all the matches Comment2: All eight programs came with my crobots package. Comment3: If you would like the results of each match, send e-mail. (The file is 2607 lines, so I'm not posting it.) Subject: Corewars Deluxe Version 1.3 From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Date: 18 Jan 92 21:23:39 GMT Message-ID: <4711@oucsace.cs.OHIOU.EDU> Once again I will announce another delay in the distribution of the Core Wars Deluxe V1.3 program. The new version has lots of bugs fixed, and I am now working on a couple of other things. Included will be support for System V and Berkeley Unix, as well as support for X Windows and Curses. There is also an option for both X Windows and Curses together and will automatically detect the type of display you are running on and set up accordingly. The reason for the delay is because of the X Windows module being added and integrated into my code. I now have a friend helping me a lot in getting this done, for which I am grateful. Another thing I will do before releasing the newer version is to add a little documentation about the assembler, program, and the display. I will also add some comments to the code, since that time has come. The new version will still not support the following: Fully operational debugger (maybe in V1.4). EQU statements in the Redcode. Parenthesis and proper handling of expressions in the Redcode. I will gladly still take requests for the proram, and I will also be posting the program to this Newsgroup (and maybe some others, but here first) in the future. Thank you for your patience and support. For those sending in requests, I request the following information: The type of system and version of system you are running on... (for example: BSD Unix 4.3 Reno) The correct address to send the program to... (for example: sadkins@bigbird.cs.ohiou.edu) The reason for the last is that some address are non-returnable and hard to decipher. I would appreciate addresses so that I can reply faster and more correctly. Keep in mind that your address may work fine for you, but may be not-so-good for me. Thank you and Happy programming!!! :-) Scott Adkins sadkins@bigbird.cs.ohiou.edu Subject: Update to CoreWar Pro (PC) available at soda From: stst@vuse.vanderbilt.edu (Stefan Strack) Date: 19 Jan 92 21:52:55 GMT Message-ID: <1992Jan19.215255.14094@vuse.vanderbilt.edu> Finally got to upload the result of some spare time over Christmas to soda: CoreWar Pro version 3.02 is now available by anonymous FTP from soda.berkeley.edu as pub/corewar/{incoming|systems}/corwp302.zip This is an extended ICWS'88 Core War system for PC-compatibles with a windowing and menu-driven interface and strong debugging support. What's new: A new indirect addressing mode, post-increment indirect (">"). A number of non-standard instructions are no longer supported. Since pre-decrement and post-increment indirect addressing together can be used to implement a "software stack", the dedicated stack-instructions (GSB, RET, PSH, POP, SSZ) are no longer needed and were thus eliminated. The process control instructions SSP and RLS were abandoned, because SSP has overwhelming offensive potential (pointed out by several people on rec.games.corewar). The two operand version of SPL (Split with descendant count) has been debugged and renamed to SPC to avoid confusion with ICWS'88 SPL. The descendant_count(on/off) switch is therefore superfluous. The B-operand of MOV, ADD, SUB, RND and EXC can now be immediate for compatibility with ICWS'86 programs. An inconsistency in the order of operand evaluation in ADD and SUB instructions has been fixed. Interface: program prompts now allow editing the default string (thanks to Per Pilse for the modified ioreadln library module). For validation of archive integrity here's the output of "pkzip -v": Length Method Size Ratio Date Time CRC-32 Attr Name ------ ------ ----- ----- ---- ---- ------ ---- ---- 8321 Implode 3465 59% 01-19-92 13:15 7170d4c6 --w CORE.DOC 60311 Implode 18302 70% 01-16-92 01:32 1b94501a --w COREMAN.DOC 78090 Stored 78090 0% 01-19-92 03:14 0940c0bb --w CORE.EXE 1103 Implode 579 48% 12-20-91 14:48 b3732b9f --w CORE.SYS 1721 Implode 822 53% 12-18-91 23:59 3009b864 --w CORESTD.SYS 6418 Implode 2091 68% 10-20-91 01:34 9340a795 --w COREMUS.DEF 102 Shrunk 75 27% 12-04-91 02:58 9d090241 --w DWARF.RED 1614 Implode 668 59% 11-19-91 01:53 779489ee --w DAGGER.RED 518 Implode 304 42% 01-19-92 12:52 51de31c4 --w XTC.RED ------ ------ --- ------- 158198 104396 35% 9 DIR CORWP302.ZIP CORWP302.ZIP 105834 1-19-92 13:15 Your feedback is welcome. Enjoy, Stefan (stst@vuse.vanderbilt.edu) From: royce@splunge.uucp (Royce Howland) Subject: Speaking of Crobots... Message-ID: <1992Jan20.034247.20927@splunge.uucp> Date: 20 Jan 92 03:42:47 GMT Having seen Crobots commentary in this group, I guess I'll post this here. Being a fan of Robotwar in the ancient Apple ][ days, I've often wished there was something available for my Atari ST or NeXT of a similar nature. I've seen Crobots for MS-DOS around, but when I checked it out a few years back, no source was available. The archie database currently lists Crobots distributions for DOS and Amiga only. Is there any source floating around? -- Royce Howland | "I can eat enormous quantities royce@splunge.uucp (NeXTMail OK) | of ice-cream without being sick, C-86Net: Mr. Neutron@RT.AB | Mrs. S-C-U-M." --Mr. Neutron From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Re: King of the Hill Message-ID: <1992Jan20.175806.27317@samba.oit.unc.edu> Date: 20 Jan 92 17:58:06 GMT Hi people. I just got into corewars but by now the instructions on how to post progs. to the hill have expired here. Can someone help me out by mailing me how to submit progs. to the hill again? Thanks. -Andy ajpierce@med.unc.edu From: davewt@NCoast.ORG (David Wright) Subject: Re: Speaking of Crobots... Message-ID: <1992Jan21.030249.1920@NCoast.ORG> Date: 21 Jan 92 03:02:49 GMT In article <1992Jan20.034247.20927@splunge.uucp> royce@splunge.uucp (Royce Howland) writes: >Having seen Crobots commentary in this group, I guess I'll post this here. >Being a fan of Robotwar in the ancient Apple ][ days, I've often wished there >was something available for my Atari ST or NeXT of a similar nature. I've >seen Crobots for MS-DOS around, but when I checked it out a few years back, >no source was available. The archie database currently lists Crobots >distributions for DOS and Amiga only. Is there any source floating around? Being the person who ported it to the Amiga, maybe I can lead you to the source. The original author DOES give out the source, but as far as I know he requests a donation for it (something like $15US, pretty reasonable). Of course, what you will be getting is the Unix/DOS source, which means ANSI-type text graphics only, no bitmaps or anything. I would think you would have little or no trouble porting that to either the ST or the NeXT within those limits. Of course, all the graphics code in the Amiga version is (c) by me, and will not be included. Also note: The version of C-Robots he is distributing does NOT (as far as I know) include any of the enhancements to the language that I added (postfix operators, etc). But if you would like to contact him, his address is: Tom Poindexter 6864 Amherst Ct. Highlands Ranch, CO 80126 USA Dave From: peaki@cs.uq.oz.au (Ian Peake) Subject: Re: Speaking of Crobots... Message-ID: <6273@uqcspe.cs.uq.oz.au> Date: 21 Jan 92 09:29:27 GMT In <1992Jan21.030249.1920@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >In article <1992Jan20.034247.20927@splunge.uucp> royce@splunge.uucp (Royce Howland) writes: >>[Looking for CROBOTS port to MS-DOS or source..] > Being the person who ported it to the Amiga, maybe I can lead you to >the source. The original author DOES give out the source, but as far as I >know he requests a donation for it (something like $15US, pretty reasonable). >Of course, what you will be getting is the Unix/DOS source, which means.. ^^^^^^^^^^^^^^^ >..ANSI-type text graphics only, no bitmaps or anything. I would think you would >have little or no trouble porting that to either the ST or the NeXT within >those limits. Of course, all the graphics code in the Amiga version is >(c) by me, and will not be included.. Is there a kind person out there who could point the way to a UNIX (sun4) binary? Many thanks, Ian Peake -- Ian Peake (EMAIL: i_peake@cs.uq.oz.au) Computer Science Department University of Queensland AUSTRALIA 4072 Subject: Announcement: 1st rec.games.corewar Crobots Tournament From: Date: Tuesday, 21 Jan 1992 17:50:32 EST Message-ID: <92021.175032JJJ101@psuvm.psu.edu> Announcing the 1st rec.games.corewar Crobots tournament. 1. HOW TO SUBMIT: Mail one and only one crobots program to jjj101@psuvm.psu.edu OR jjj101@psuvm.bitnet, with the following header: // // // // where is your name. (like J. Smith) is your e-mail address is the name of your crobots program is a LEGAL IBMPC filename with extension .r Example: //James Jesensky //jjj101@psuvm.psu.edu //Sniper 1.2 //sniper.r 2. WHAT NEXT? Within 24 hours you should receive a notice, indicating your program has been received. Within 48 hours you should receive a notice indicating if the program compiled correctly. 3. WILL MY CROBOTS WORK WITH YOUR CROBOTS? I have no idea. I'm using Crobots for DOS by Tom Poindexter. If you have questions of compatibility, send me a note asking for a copy of my crobot.doc file. It should work with all Amiga versions if none of the extensions to the original language are used. 4. FORMAT OF TOURNAMENT: Not 100% sure yet. Basically multiple round robins. CPU cycle limit is set at 500,000. There will always be 4 hostile robots run together, that is, 1 on 1 on 1 on 1 instead of 1 on 1 matches. Scoring for each match: win - 3 pts. tie - 1 pt each. mutual destruction - no points A programs total score is the sum of its score for all its matches. Each program 'fights' in the same number of matches. (Estimate: 1000) Note: Sniper.r will be used if an even number of programs are needed. 5. DEADLINE!! The unofficial deadline is Sun 26 at midnight. This may be extended. 6. MISC: I will be entering the tournament also. Note that I will NOT run my program against yours before the tournament. For honesty reasons, I will post my source before the tournament begins. I will glance at the comments of incoming programs but not the code. I you don't want me looking at the comments, delete them from the source file. Also, I won't make any changes to my program until after the tournament. *END* Subject: Mac: Robo War From: fau@po.CWRU.Edu (Francis A. Uy) Date: Tue, 21 Jan 92 19:51:47 GMT Message-ID: <1992Jan21.195147.4772@usenet.ins.cwru.edu> Just wanted to mention that the Macintosh has a shareware program called RoboWar which is, as far as I can tell, very similar to Tom's CROBOTS game. RoboWar was written by some California kids (I think). I could look it up when I go home if anyone's interested. There is also another Mac robot-programming game called 'Bot, which was written by someone at Harvard and should be available by ftp from one of the husc servers. I've never tried it. -- Francis A. Uy 410.465.1316 "You must rely on the lightning and not fau@po.cwru.edu 410.461.0960 forecast the dance." -- Van, quoting Graves, messing with my mind Subject: Ideas ... From: kwhyte@math.uchicago.edu (Kevin Whyte) Date: 22 Jan 92 04:06:49 GMT Message-ID: <1992Jan22.040649.9708@midway.uchicago.edu> There seem to be two major components to writing good core war programs: Coming up with a good idea. Coding that idea sneakily. (The general desire to change corewar comes from a desire to place greater emphasis on 1 ... I don't know, the harsh efficiency acid test gives the truly good programs a "rose in the desert" kind of beauty) Now, I'm not really a very good programmer ... at least, not anymore (I sold my soul to abstract mathematics). This means I have several ideas that I can't code. Some of these I know to be totally unworkable, and some I would like to see: MAKING the opponent do useful stuff: Bad idea. Even if you manage to get the opponent to spend all of his time doing stuff for you, your effective speed only doubles. What you care about is the ratio of your effective speed to the opponents. By making them split, you quickly reduce their effective speed by large fectors, which gives a gain of much larger than 2. Now, it is useful to know when you've caught something (because now you should just bomb all of core with dat #0's to kill everything, since nothing is fighting back anymore). Self-Repair: Clearly a nice idea if you can do it. Unfortunately it doesn't win on it's own, at best it survives. Thus you need to run an attacking program as well. However, the self repair has to be FAST, or else you will have split so many times, it won't matter what you're trying to do. So, the attacking goes slowly. So the trade of is something like : it is 10x as hard to kill you you kill other things 20x as slowly. Thus a net factor of just slowing down the attacking program. Now, it's not impossible that the net effect could be a speed up, but I can't even come close (+ against programs which bomb with jumps, it is virtually irrelevant whether or not you repair the code, you still lose). Battery: The idea is to have several process split off to a jmp 0. Then, if you need extra speed, you can just change the jump zero to a jump to your program. Of course this only makes sense if you have several other processes running at the same time. The "best" idea I've had is to use this as a protection from spl bombs. Namely, have your code do its loop by telling the battery to jump to the beginning of the loop, and dying. Thus if your code is hit, you will no longer request processes from the battery (which should be basically a spl 0 or jmp 1 , jmp 1 , spl -2 type of thing). The idea is that if several processes are feeding off this battery at just the right rate to make it stable, then when one dies, the others will get more and more as the battery overcharges, largely counteracting the opponent making your capured process split. This doesn't seem really practical either, as your opponent will make you split faster than you can split and do something productive, so you still lose just slightly slower. The only real use I see is in cooperation with the self-repair idea to gain time to repair yourself after being hit with split bombs. Double search. A search loop someting like: add offset, 1 cmp 100,-100 jmp bombing routine jmp -3 offset dat #4,#-4 This checks 2 locations for enemies every 3 cycles instead of the standard 1 location every 2 cycles. The draw back is that the program has to be longer (how do you efficiently bomb something that you only have an A-field pointing to? The only way I can think of, is to notice that it is the negative of the B-field, and do a subtraction. So, if it doubles the length of the program, it isn't worth it (you kill things 1.33 times as fast, but get killed twice as fast ... a net loss). It would be beneficial for any program which is really large already, but I don't know of any viable large programs). That's enough for now, I just wanted to stimulate corewar discussion. Kevin kwhyte@math.uchciago.edu Subject: Re: p-robots is fun too. From: Date: Wednesday, 22 Jan 1992 13:47:21 EST Message-ID: <92022.134721JJJ101@psuvm.psu.edu> In article , orman@iastate.edu (David L Orman) says: > >Perhaps this is a little immature for the average C programmer/ Corewar >player, but there is a Pascal version of C robots called p-robots, For >those of you who dont like or are not comfortable with C. > >Anyway, Is there any interest in a tourament of this type? I would assume one could write a flex program to convert a p-robot program to a c-robot program and vs. versa. But consider a ?-robot based on a non-procedure programming language. Some possible examples: prolog -- This would be interesting. Scheme -- Scheme is a subset of Lisp; also should be interesting. Maybe an event driven langauge like HyperTalk(tm). Other thoughts? James Subject: How to find out if a given instruction is a JMP From: kokeritz@lne.kth.se (Anders Kokeritz) Date: 22 Jan 92 16:12:51 GMT Message-ID: Is there any way to find out what instruction there is on a given address i RedCode? What I really want to do is to test if an address contains a JMP. From: orman@iastate.edu (David L Orman) Subject: p-robots is fun too. Message-ID: Date: Wed, 22 Jan 1992 17:10:01 GMT Perhaps this is a little immature for the average C programmer/ Corewar player, but there is a Pascal version of C robots called p-robots, For those of you who dont like or are not comfortable with C. Anyway, Is there any interest in a tourament of this type? -- _______ ___ _________ +-------------------------------------+ Date: Wednesday, 22 Jan 1992 18:46:37 MST From: Message-ID: <92022.184637AZNXS@ASUACAD.BITNET> Subject: displaying Is there any standard to display? Could somebody send some good ideas? Nandor. Subject: Re: How to find out if a given instruction is a JMP From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Date: 22 Jan 92 20:57:34 GMT Message-ID: <4744@oucsace.cs.OHIOU.EDU> In article kokeritz@lne.kth.se (Anders Kokeritz) writes: >Is there any way to find out what instruction there is on a given address i >RedCode? What I really want to do is to test if an address contains a JMP. The problem is that there is no way to really test for an instruction of any type without wasting a lot of time doing it. I guess it can be done... Let me see... I can't guarentee the following code to work, but I will give it a swing... loc jmp 124, 0 ;To be examined in memory... . . . dst dat #0, loc ;Pointer to possible jmp instruction hold jmp 0, 0 ;For holding the contents zero dat #0, #0 ;For adding operations add loc, hold ;hold is now "jmp 124, 0" cmp loc, hold ;if they are equal skip next jmp noteq ;nope, do something else jmp equal ;it is a jmp instruction!!! Now there are problems with all of this... What if the jmp statement has a different mode in either of the fields? Then this would naturally fail. I think in the case of the Leech prorgram, this method would work. In case of other types of vampiric programs, it would fail against the following: jmp @0, 124 -- OR -- jmp @1 dat #124 What do you think? My way is to just search for a non-zero statement and ASSUME that it is a jmp statement. I then use the address to trace back to the enemy program and bomb that location. This does not work well against programs that bomb with DATs instead of JMPs. Scott Adkins sadkins@bigbird.cs.ohiou.edu Subject: Re: How to find out if a given instruction is a JMP From: rogue@cellar.org (Rachel McGregor) Date: 22 Jan 92 22:13:50 GMT Message-ID: kokeritz@lne.kth.se (Anders Kokeritz) writes: > Is there any way to find out what instruction there is on a given address i > RedCode? What I really want to do is to test if an address contains a JMP. you can use the CMP instruction or one of its derivatives to see whether your target cell contains a JMP instruction, but it will only work if you know the data that should be in the cell. Therefore, you can use JMPs in a trap, which you can later check to see if it's been sprung, but unless you're lucky, you're not going to find a JMP trap before you step in it. *Unless*... Considering the fact that most JMP traps are JMP 0 instructions, you can code the following: JMP 2 JMP 0 CMP -1 target What you do from there is up to you. --- "As they say around the [Texas] Legislature, if you can't | Rachel McGregor drink their whiskey, screw their women, and vote against | rogue@cellar.org 'em anyway, you don't belong in office." -- Molly Ivins | Public Usenet/BBS Subject: Re: Ideas ... From: ajpierce@med.unc.edu (Andrew Pierce) Date: 22 Jan 92 22:34:13 GMT Message-ID: <1992Jan22.223413.17101@samba.oit.unc.edu> Hi everyone. I have been playing at corewars for a few days now, including KOTH (auger, 7th or 8th grade prog that was on yesterday for a while). Sometimes it is possible to make progs that don't fare well in an all out destructo fight but that can still be fun to look at. I submitted one called "Spreel". What it did is that the prog made an exact copy of itself and then started a casual bombing routine. The neat part was that the child of the parent program then did the same thing, making a child of itself (a grandchild of the original) and then going into the casual bombing routine. The bombing routines were set up such that each process, if all went well, should be killed by its grandchild. There was a timer in the progs such that if the program sensed that it was still alive after the time at which it should have been killed by it's grandchild, it assumed that either its child or its grandchild or both had gone wrong and so it then went back to the beginning and had another child, copied to the same location as the original child. Then it would again wait to be killed by its grandchild etc. It was a beautiful little prog and it was kind of fun to watch as it delicately stepped through memory, occasionally activating the repair circuit. It did reasonably well against a lot of the simpler programs but didn't have that combination of resistivity, speed and sheer destructive power that seems to be required to get on the hill (it got massacred). Still, the idea of modelling "life-like" situations like that with redcode is still something to kick around. I notice that various people have tried a variety of "virus-like" and "parasitic" progs that have had a greater or lesser degree of success. -Andy ajpierce@med.unc.edu P.S. Is the hill really flooded at the moment? I submitted a prog about 16 hours ago and still no word. P.P.S Code for "Spreel" to follow. Thanks to the others who posted code. I find that "Fleas" is a good test prog. Unfortunately, I haven't managed to get "Sargent" to work. Is whoever made it out there? Subject: Re: How to find out if a given instruction is a JMP From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Date: Thu, 23 Jan 1992 00:23:27 GMT Message-ID: <16776102A8.DURHAM@ricevm1.rice.edu> I assume that people want to know how to check for instructions with a particular opcode and do not know (or do not care about) the associated operands. The original question was about JMP, so I will use that as my example. x ??? a, b ; Unknown instruction. ... start MOV x, copy ; Make a copy for non-destructive test. SUB copy, copy ; Subtract copy from itself to zero operands, CMP test, copy ; and compare. ... test JMP 0, 0 ; Opcode of interest and zeroed operands. copy ??? a, b ; Does not matter. We'll copy over it. This is not perfect though. The comparison depends on the modes of the operands. JMP I finally announce that the program is ready to distribute!!! :-) Now, the only problem I have found was that there was many, many requests for the program, making it difficult for me to send it to everyone. Since all of the requests were generated from this Newsgroup, and since I have heard quite a few "Yeahs" and no "Nays" about posting the program here, I will now do so. I will also, from this point on, send the program to any new people who could not get it from here for whatever the reason. It will make it easier for me to get this to as many people as possible. Also, I will place it in the /pub/corewar/incoming directory of the soda.berkeley.edu ftp site. I will post the shar archives here, and put the tar archive at the ftp site. I will be glad to help anyone who does not know how to get the program using these two means. The next 5 postings will be the shar archive. Be sure to strip off the post header at the front of the archive before running them through the "sh" command. Good luck and I hope you enjoy it! Thanks, Scott Adkins sadkins@bigbird.cs.ohiou.edu From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Core Wars Deluxe V1.3 (Part 1/5) Message-ID: <4751@oucsace.cs.OHIOU.EDU> Date: 23 Jan 92 01:57:43 GMT #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'DOCUMENTS/ASSEMBLER' <<'END_OF_FILE' X Core Wars Deluxe v1.3 X------------------------------------------------------------------------------- X XThe assembler provided with the Core Wars Deluxe program was designed to be Xas up-to-date and as forgiving as possible. I am afraid that not everything Xhas been completely written for it yet, but I intend to finish it before the Xnext release. X XHere is a list of features and short comings the assembler has: X X 1) Labels may be of any length and are case sensitive. Any colon that X follows a label will be ignored. X X 2) Fields may optionally be seperated by commas. I highly recommend X there use, for reasons that I will describe. Since fields may X actually be made up of expressions, it is possible that the B-field X could be incorporated into the expression, whether you intend it X to be or not. For example: "mov #0 -1" would be interpreted as X "mov #-1 #0" and "mov -1 -1" would be interpreted as "mov -2 #0". X In these cases, use "mov #0,-1" and "mov -1,-1" instead. X X 3) Expressions are still not handled to the full specifications of the X standards. All labels are converted to their proper addresses, X and figured into the expressions. All expressions are calculated X from left to right, and no order of precendence exists. You may X use the +-*/ operators and parenthesis are not supported. All X division is integer division. So, keep in mind that "1+3*2" is X currently calculated as "8" and not "7". I will correct this in X a future version of the program. X X 4) The standards also specify the use of the EQU compiler directive. X I have included it as a future expansion to my assembler, but is X not currently supported in Redcode programming. I will include it X in a future version of the program. X X 5) The END compiler directive is also supported. At the end of your X Redcode program, include the line "END