From: KLOTZ@deimos.oit.umass.edu (Jay Klotz) Subject: Re: How learn ? Date: 5 Feb 1995 16:45:58 GMT Message-ID: <3h2vc6$hp1@nic.umass.edu> Try the anonymous ftp at ftp.csua.berkeley.edu in the pub/corewar directory. -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | jay klotz | Mae'n brydgell ac mae'r brochgim stwd | | klotz@phast.umass.edu | Yn gimblo a gyrian yn y mhello: | | UMass Amherst | Pob colomrws yr feddabwd | | 413-585-0760/413-545-0163 | A'r hoch oma'n chwibruo. | /////////////////////////////////////////////////////////////////////////////// i From: rrognlie@netcom.com (Richard Rognlie) Subject: Richard's PBeM Server (Monthly Post) Message-ID: Date: Sun, 5 Feb 1995 22:46:44 GMT Richard's Play-By-eMail (PBeM) Server Monthly Posting A generic Play-By-eMail Server has been set up at pbmserv@netcom.com. It currently supports four games (Trax, TwixT, Hex and Abalone) with others to be added in the future. In addition, the server now supports C++Robots. To get more information send mail to pbmserv@netcom.com with 'help' as the subject line. Games Currently Supported Trax ((c) David Smith) Trax is a game played with square tiles. Each tile is identical to all other tiles, one side has a white line connecting opposite edges and a black line connecting the other edges, and the other side has a white line connecting 2 adjacent edges and a black line connecting the other edges. The object of the game is to create a loop of your color while preventing your opponent from doing the same. An alternate winning condition is to create a line extending from one edge of the board to the opposite edge of the board when the board is at least 8 tiles wide (or tall). TwixT ((c) Avalon Hill) On a 24x24 board, players take turns placing pegs of their color on the board. Any time a peg is placed a "knight's move" from another peg of the same color, a strut is placed, connecting them. A strut can not cross over (through) another strut. The object is to connect your sides of the board while preventing your opponent from doing the same. Hex On a 11x11 diamond board, players take turns placing stones of their color on the board. The object is to connect your sides of the board while preventing your opponent from doing the same. Abalone On a hexagonal board (radius 5) two to six players have armies of marbles. Players take turns "pushing" 1, 2 or 3 linearly connected marbles, attempting to push their opponents' marbles off the board. C++Robots ((c) 1994 Richard Rognlie) An ongoing "King of the Hill" (KotH) tournament in which players use the C++ language to create a control program for a robot. Your robot then fights each of the other robots "on the hill". If you do well enough, your robot will "make the hill", bumping the lowest robot from the hill. Robots have the ability to scan for opponents, fire a cannon, move, and determine current position and status. Conceptually based on C-Robots written for the IBM PC by Tom Pointdexter. -- /\/\/\ | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA / \ \ \ | E-Mail: rrognlie@netcom.com *or* rognlie_richard@prc.com \ / / / | Phone: (Home) (703) 361-4764 (Office) (703) 556-2458 \/\/\/ | (Fax) (703) 556-1174 Subject: djn -3,<1499 Message-ID: <1995Feb6.170908.1817@rhodes> From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Date: 6 Feb 95 17:09:08 -0500 I've been looking at some code from code for warriors and feel like I am starting to get a handle on what is happening with many of them, but I still have questions. I have been looking at Rave and Coreclear (don't think that's its real name, but its by P.Kline I believe). Anyway, both of them have chunks like the following: (actually, this is the complete code I have for CoreClear) add off, 1 loc cmp 1, 50 slt #20, -1 djn -3, <1499 mov j, @loc dec mov s, Subject: qcmp/qscan Message-ID: <1995Feb7.064112.1825@rhodes> From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Date: 7 Feb 95 06:41:12 -0500 I keep seeing warriors with strategies saying qcmp or qscan? I know what a cmp-scanning or b-scanning warrior is. What is a qcmp or qscan warrior supposed to be? Randy From: pk6811s@acad.drake.edu Subject: Re: djn -3,<1499, cmp-scanning Date: 7 Feb 95 10:08:23 CST Message-ID: <1995Feb7.100823@acad.drake.edu> In article <1995Feb6.170908.1817@rhodes>, graham@harlie.mathcs.rhodes.edu (Randy Graham) writes: > I've been looking at some code from code for warriors and feel like I > am starting to get a handle on what is happening with many of them, > but I still have questions. I have been looking at Rave and Coreclear > (don't think that's its real name, but its by P.Kline I believe). > Anyway, both of them have chunks like the following: > (actually, this is the complete code I have for CoreClear) > > add off, 1 > loc cmp 1, 50 > slt #20, -1 > djn -3, <1499 > mov j, @loc > dec mov s, add new, @dec > jmz -6, #0 > mov s, 7+381 > add #381, 0 > j djn @-1, #6900 > s spl 0 > new mov -49, <-48 > off dat <-98, <-98 > Um... don't remember this one. Anyway the DJN XX, attack at a-pointer mov bjmp,@scan ; jmp half of the bomb scanptr mov bspl, The Robot Auto Racing Simulation (RARS) is a simulation of auto racing in which the cars are driven by robots. Its purpose is two-fold: to serve as a vehicle for Artificial Intelligence development and as a recreational competition among software authors. The host software, including source, is available at no charge. It currently runs under MSDOS; several persons are now working on ports to other platforms. This announcement introduces the third release of the software, which we call version 0.3: The Robot Auto Racing Simulation A Challenge for Evolutionary Programming A Competition for Programmers by Mitchell E. Timin (met7@cac.psu.edu) Version 0.3 of RARS is ready. It is written in the Borland flavor of C++ and has been compiled and tested with Borland C++ 3.1, to run under DOS. It should be easy to port to any C++ that has functions for drawing lines and arcs, a flood-fill or color fill function, and text output to the graphic screen. Hence it will not be difficult to make it run on a Macintosh or Unix system. C++ is not required for the robot "driver" programs. The race tracks are now defined by ASCII files. Several pre-defined tracks are supplied. The desired track is named on the command line. Users can create their own tracks using any text editor, although this is not a trivial process unless a CAD program is used to find the exact lengths, angles, and radii for the track segments. It is possible to do it by trial and error, however. There is now a RARS anonymous ftp site: magdanoz.mcafee.com in directory /bin/ftp/rars. Anyone can get any RARS stuff there, code, announcements, car controllers, documentation, etc. Jivko Koltchev is our benefactor there. (jivko@magdanoz.mcafee.com) There is now a listserver so that interested parties may discuss RARS by e-mail. To subscribe to the list service send e-mail to listserv@NETCOM.COM containing the message: subscribe rars-list RARS consists of a simulation of the physics of cars racing on a track, with a simple bird's-eye view of the race. The unique feature is that each car is controlled by a separate and independent control program. Each car is "driven" by its own control program, which receives information from the simulation telling it about the car's local situation. The "driver" (control program) adjusts the steering and throttle, and then the physics simulation moves the car a little. This happens many times per second, of course. Every car has exactly the same physical characteristics, only the "drivers" are different. Hence, the result is a competition between the control programs. Furthermore, the competition is visible as an auto race, with acceleration, passing, cornering, braking, etc. It is intended that many users will write their own robot "drivers". Six similar, but not identical, examples are supplied. These are meant to serve as examples for programmers wishing to develop their own. The control programs may be written in other languages, although for version 0.3 they must be linkable with the Borland linker. (or supplied in source form for C, C++, TASM or Pascal) For genetic programming, the races will be between several programs selected from an evolving population of programs. The racing may take place continuously for long periods of time, with the graphic display disabled for faster execution. Of course losers will be eliminated and winners will breed. Genetic Algorithm proponents will probably design robot drivers with a vector of parameters to be determined by evolution. Neural nets are also candidate "drivers". Wanted - People to do or help with any of the following: Porting to other platforms Testing the software and suggesting enhancements Improving the graphics Locating a corporate or university sponsor Act as a race director to manage a "race meet" Reporting, both to academic journals and popular magazines Improving the software in any of dozens of ways Adding sound effects (and of course, building "drivers" to compete in the races!) From: clay@engr.mun.ca (Clay Reimer) Subject: Simulator code Date: 7 Feb 1995 23:39:59 GMT Message-ID: <3h90cf$at1@coranto.ucs.mun.ca> Could someone please tell me where I can find the source for a core-wars program that is up to date with the ICWS standards? M. Reimer From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: qcmp/qscan Date: 8 Feb 1995 01:00:00 GMT Message-ID: <3h952g$qv1@agate.berkeley.edu> Randy Graham wrote: >I keep seeing warriors with strategies saying qcmp or qscan? I know >what a cmp-scanning or b-scanning warrior is. What is a qcmp or qscan >warrior supposed to be? It's a special type of cmp-scanning that uses a hardcoded scan pattern (instead of a scanning loop) to scan part of core very quickly (2 core locations per cycle, as opposed to .67 for a cmp-scanner). The basic quick-scan engine looks liks this: cmp loc1, loc2 ; loc1 and loc2 are 4000 apart mov #loc1, target ; if we found something, store location cmp loc3, loc4 ; loc3 is loc1+100, or close to that mov #loc3, target ... cmp loc39, loc40 mov #loc39, target target jmz failed, #0 ; see if we found anything mov target, target-1 mov bomb, vampire ;macro ; ----------- Quick-Scan Parameters (see diagrams at end of program) ------- OVERLAP1 equ 50 OVERLAP2 equ 0 BIGSTEP equ 100 OFFSET equ 150 BOMBDIR equ -1 ; 1 is forward, -1 is backward SPACE equ 6 ; -------------------------------------------------------------------------- STEP equ 3364 first spl split wimp jmp #0, <-15 look qscan for 6 sne.x (first+OFFSET+(qscan*2*BIGSTEP)), (first+(CORESIZE/2)+OFFSET+(qscan*2*BIGSTEP)) seq.x (first+OFFSET+BIGSTEP+(qscan*2*BIGSTEP)), (first+(CORESIZE/2)+OFFSET+BIGSTEP+(qscan*2*BIGSTEP)) mov.ab #(first+OFFSET+(qscan*2*BIGSTEP))-found, @found rof jmn found+1,found qscan for 6 sne.x (first+OFFSET+((qscan+6)*2*BIGSTEP)), (first+(CORESIZE/2)+OFFSET+((qscan+6)*2*BIGSTEP)) seq.x (first+OFFSET+BIGSTEP+((qscan+6)*2*BIGSTEP)), (first+(CORESIZE/2)+OFFSET+BIGSTEP+((qscan+6)*2*BIGSTEP)) mov.ab #(first+OFFSET+((qscan+6)*2*BIGSTEP))-found, @found rof jmn found+1,found qscan for 6 sne.x (first+OFFSET+((qscan+12)*2*BIGSTEP)), (first+(CORESIZE/2)+OFFSET+((qscan+12)*2*BIGSTEP)) seq.x (first+OFFSET+BIGSTEP+((qscan+12)*2*BIGSTEP)), (first+(CORESIZE/2)+OFFSET+BIGSTEP+((qscan+12)*2*BIGSTEP)) mov.ab #(first+OFFSET+((qscan+12)*2*BIGSTEP))-found, @found rof found jmz.b first, #0 add.b found, found2 sne.x @found, @found2 add.ab #(CORESIZE/2), found jmn.f 2, @found add.ab #BIGSTEP,found mkfang sub.ba found, qfang add.b found, qfang mov.i qfang, @qfang sub.f subber, qfang djn.b -2, #((BIGSTEP+(OVERLAP1+OVERLAP2))/SPACE)+1 found2 jmp first, #found+BIGSTEP qfang jmp (BOMBDIR*OVERLAP1)+pit+(qfang-found), #(-BOMBDIR*OVERLAP1)+found-qfang subber dat In article <3h8h71$pc8@hearst.cac.psu.edu>, met7@wileypost.cac.psu.edu (MITCHELL E TIMIN) says: >There is now a RARS anonymous ftp site: magdanoz.mcafee.com in >directory /bin/ftp/rars. Anyone can get any RARS stuff there, >code, announcements, car controllers, documentation, etc. >Jivko Koltchev is our benefactor there. (jivko@magdanoz.mcafee.com) Maybe I'm just catching them at a bad time, but magdanoz.mcafee.com is proving to be a very difficult system to talk to. What type of system is it anyway (just out of curiosity). It looks like it could be some DOS-ish type system (Netware, OS/2, maybe even DOS!) Not complaining, I'm just curious to hear whether or not others have had similar difficulties. I hate to rattle jivko's cage, since these guys are appearantly being fairly philanthropic (for computer folks, should that be geekophilic?) about giving RARS a home. Jeff Clough - Humble Programmer (oxymoron?) From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Simulator code Date: 8 Feb 1995 06:45:06 GMT Message-ID: <3h9p9i$8tf@agate.berkeley.edu> Clay Reimer wrote: >Could someone please tell me where I can find the source for a core-wars >program that is up to date with the ICWS standards? Try ftp.csua.berkeley.edu:/pub/corewar/systems/pmars06.*. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: fsljr@aurora.alaska.edu (Lance Roberts) Subject: Help Newbie Please Date: 8 Feb 95 22:17:27 -0900 Message-ID: <1995Feb8.221727.1@aurora.alaska.edu> Howdy, I've been reading this newsgroup for a while, since it looks like the type of thing I'd enjoy. I've yet to see a faq or any info on how to get started, could someone please send me the directions to the info I need? - Lance Roberts fsljr@aurora.alaska.edu From: ccapc@cyber.sell.com (Consumer Credit Advocates) Subject: GUARANTEED CREDIT REPAIR BY LAW FIRM Date: 9 Feb 1995 05:41:13 -0500 Message-ID: <3hcrg9$n7t@panix.com> Consumer Credit Advocates, PC 11 Pennsylvania Plaza, Suite 2101 New York, NY 10001 (212) 629-5261 (telephone) (212) 629-4762 (fax) E-MAIL: ccapc@cyber.sell.com Our LAW FIRM offers direct guaranteed effective credit restoration services by experienced attorneys. THIS IS NOT A DO-IT-YOURSELF KIT. What can we do? We have successfully facilitated the removal of Late Payments, Charge-offs, Foreclosures, Repossessions, Collection Accounts, Loan Defaults, Tax Liens, Judgments and Bankruptcies from our clients' credit reports. WE GUARANTEE THAT YOUR CREDIT CAN BE RESTORED!!! Who needs our services? Anyone who has experienced the inconvenience and embarrassment of being turned down for a credit card, a lease or a purchase of an automobile. Anyone who is unable to buy the house of their dreams due to denial of a mortgage application or who has to pay thousands of dollars more in mortgage interest than someone with good credit. Anyone who has been turned down for a job or promotion due to derogatory credit items on a credit report. Anyone in business who has lost a deal because a person or firm wanted to see his/her credit report before doing business. Anyone who has been unable to establish credit. THE FOUR GREAT MYTHS OF CREDIT: Myth #1: It is illegal or immoral to have your credit report cleared. Fact: It is not illegal nor immoral. In fact, that is what the Fair Credit Reporting Act is all about. The act was enacted by Congress in 1971. One of its purposes as to give consumers the protection of the law and to help guard against any unwarranted invasion of a consumer's right to privacy. Myth #2: The information on a credit report cannot be changed. Fact: Actually, the opposite is true under the Fair Credit Reporting Act. Federal and State laws require that items be removed if they are not 100% accurate or cannot be verified in a timely manner. Myth #3: It is impossible to get a bankruptcy off a credit report. Fact: Bankruptcies can come off credit reports like any other derogatory item. The nature of the derogatory item has nothing to do with its removal under the Fair Credit Reporting Act. Myth #4: Credit Reporting Agencies are empowered with some kind of governmental authority. Fact: Absolutely Not!! They are simply large corporations whose primary goal is to make a profit like any other business. If you have ever applied for or received credit, a file exists in one or more of the credit bureaus. These companies collect, store and distribute as much credit information as they can find, retaining negative information on a credit report for 7 to 10 years. This information is evaluated by potential creditors to determine your credit worthiness. Credit reporting agencies are in business to protect the interests of the creditors. the LAW FIRM's goal is to help and protect the individual consumer from inaccurate credit reporting. The president of our LAW FIRM has been practicing consumer law since 1984. The staff of our firm has successfully processed, disputed and challenged thousands of client credit reports. Our legal fee is based o the number of negative items that appear on a client's credit reports, issued b the three national credit bureaus. Our retainer agreement offers a MONEY BACK GUARANTEE stating that if any negative item is not deleted, upgraded or corrected from a client's credit file, it will give the client a full refund for that item or continue to process the client's file at no additional fee until that item is corrected, upgraded or deleted. THE ONLY THING YOU HAVE TO LOSE IS YOUR BAD CREDIT!! PLEASE CONTACT THE LAW FIRM AND LEAVE YOUR FULL NAME, MAILING ADDRESS AND TELEPHONE NUMBER SO WE MAY FORWARD FURTHER INFORMATION AND INSTRUCTIONS TO YOU ABOUT OUR SERVICE. Consumer Credit Advocates, PC 11 Pennsylvania Plaza, Suite 2101 New York, NY 10001 (212) 629-5261 (telephone) (212) 629-4762 (fax) E-MAIL: ccapc@cyber.sell.com Subject: preprocessor Message-ID: <1995Feb10.144726.1874@rhodes> From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Date: 10 Feb 95 14:47:25 -0500 Is there anything available that will unroll FOR/ROF stuff, giving me output like the assembled version would be, but still with labels, including expanded ones for the unrolled loop. I realize I CAN manually unroll them, or I CAN go back and edit/label the output from PMars, but would prefer something that did this for me, leaving it half way between source and assembled code. Basically a redcode PreProcessor. Thx, Randy From: morrell@jeeves.math.utah.edu (Steven C. Morrell) Subject: Re: djn -3,<1499 Date: Sat, 11 Feb 1995 02:58:07 GMT Message-ID: In article <1995Feb6.170908.1817@rhodes> graham@harlie.mathcs.rhodes.edu (Randy Graham) writes: One last thing. did the guy who wrote chapters 1 and 2 explaining imps and stones ever write a chapter 3 or higher? I really learned a lot from the book, but would like to know more. Better info of good paper code would be nice. Efficient ways to scan until reaching a certain stopping point other than bombing oneself (such as the djn above) would be nice. I haven't tried writing him yet because the book said his address was only good until last summer. Well, at first I thought I was getting out of school last year, but I see that I am still going. I'll be around for maybe three more years, working on my PhD. Meanwhile, the book is slowly getting finished, and I might be able to finish it before I leave. Chapter 3 is about halfway done. I hope to have it finished in about two weeks, so if you can wait until then, you will learn more than you ever wanted to know about scanners. P.S. That code looks a lot like Iron Sword by Wayne Sheppard. That's my vote who wrote it. Steven Morrell morrell@math.utah.edu From: msmoulton@aol.com (MSMoulton) Subject: RARS FTP? Message-ID: <3hheaq$pnm@newsbf02.news.aol.com> Date: 11 Feb 95 04:27:06 GMT I'm an AOL member, and our FTP interface doesn't use commands. But, in magdanoz.mcafee.com, I can't do a cd .. to get out of the uploads directory. Is there a mirror site? ********************************************* *Michael Moulton * *------------------------------------------------------* *Internet: MSMoulton@aol.com * * michael.moulton@gsh.com * *FidoNet: Michael Moulton (1:275/153)* ********************************************** From: sieben@imap1.asu.edu Subject: Re: preprocessor Date: 11 Feb 1995 05:24:01 GMT Message-ID: <3hhhlh$iqc@news.asu.edu> Randy Graham (graham@harlie.mathcs.rhodes.edu) wrote: : Is there anything available that will unroll FOR/ROF stuff, giving me : output like the assembled version would be, but still with labels, : including expanded ones for the unrolled loop. I realize I CAN : manually unroll them, or I CAN go back and edit/label the output from : PMars, but would prefer something that did this for me, leaving it : half way between source and assembled code. Basically a redcode : PreProcessor. : Thx, Randy Yes it's called macrored. Available on csua.berkeley.edu . Nandor. From: wangsawm@PEAK.ORG (Mintardjo W.) Subject: Re: preprocessor Date: 12 Feb 1995 08:53:12 -0800 Message-ID: <3hledo$obl@PEAK.ORG> In article <1995Feb10.144726.1874@rhodes>, Randy Graham wrote: >Is there anything available that will unroll FOR/ROF stuff, giving me >output like the assembled version would be, but still with labels, >including expanded ones for the unrolled loop. I realize I CAN >manually unroll them, or I CAN go back and edit/label the output from >PMars, but would prefer something that did this for me, leaving it >half way between source and assembled code. Basically a redcode >PreProcessor. > There is a switch -V to allow pmars gives more descriptive output about the assembled code. It's not really a preprocessor, but it might help. Mintardjo. From: beskedk@cnsvax.uwec.edu Subject: test Message-ID: <1995Feb12.181636.1@cnsvax.uwec.edu> Date: 13 Feb 95 00:16:36 GMT test From: chris@hiram.edu Subject: Re: preprocessor Message-ID: <1995Feb13.174659.371@hir800> Date: 13 Feb 95 17:46:59 -0400 In article <3hhhlh$iqc@news.asu.edu>, sieben@imap1.asu.edu writes: > Randy Graham (graham@harlie.mathcs.rhodes.edu) wrote: > : Is there anything available that will unroll FOR/ROF stuff, giving me > : output like the assembled version would be, but still with labels, > : including expanded ones for the unrolled loop. I realize I CAN > : manually unroll them, or I CAN go back and edit/label the output from > : PMars, but would prefer something that did this for me, leaving it > : half way between source and assembled code. Basically a redcode > : PreProcessor. > > : Thx, Randy > > Yes it's called macrored. Available on csua.berkeley.edu . actually it's on scotch. -- Chris Hodson | quis custodet custodes Hiram College | chris@hiram.edu | From: Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON) Subject: Crobots Message-ID: <132862@cup.portal.com> Date: 14 Feb 95 19:40:21 GMT I have a program that is similar in concept to CoreWars. It is called CRobots. I am looking for the author(a Tom Poindexter) or the source(which is supposed to be PD). I have a version for my Amiga which was ported by David Wright(so if he reads this please contact me). Is anyone familar with this game? It is simple, you write a program in a C like language for your robot, up to 4 robots complete at one time. The last robot alive wins. From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: preprocessor Date: 14 Feb 1995 22:32:56 GMT Message-ID: <3hrb2o$ess@agate.berkeley.edu> In article <1995Feb13.174659.371@hir800>, wrote: >In article <3hhhlh$iqc@news.asu.edu>, sieben@imap1.asu.edu writes: >> Yes it's called macrored. Available on csua.berkeley.edu . > >actually it's on scotch. Just to make this clear: all the corewar stuff is on ftp.csua.berkeley.edu, aka scotch.csua.berkeley.edu, aka 128.32.43.51. Don't confuse it with the old ftp site, which was soda.csua.berkeley.edu (aka csua.berkeley.edu, aka 128.32.43.52, and previously soda.berkeley.edu). If you try to ftp to csua, you will get soda.csua, and there are no files there. However, my mailing address is still at soda rather than scotch. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: tpoindex@nyx10.cs.du.edu (Tom Poindexter) Subject: Re: Crobots Message-ID: <3ht7dk$m27@nyx10.cs.du.edu> Date: 15 Feb 95 15:42:44 GMT In article <132862@cup.portal.com>, ANTHONY FRANCIS PRESTON wrote: >I have a program that is similar in concept to CoreWars. It is >called CRobots. I am looking for the author(a Tom Poindexter) >or the source(which is supposed to be PD). I have a version for my I'm here. Actually, I never released CROBOTS as public domain. I do hold the copyright. Feel free to email any questions. -- Tom Poindexter tpoindex@nyx.cs.du.edu From: dsh@skoardy.demon.co.uk (Darren Hebden) Subject: Have I missed the FAQ Date: Wed, 15 Feb 1995 19:31:25 +0000 Message-ID: <243765700wnr@skoardy.demon.co.uk> I joined this newsgroup a few days ago after finding out about it from a WWW page. I'm not sure how up to date the information was so what I was wondering is, is there a FAQ for this newsgroup? If there is, I guess I must have missed it by a day or two and I'm sorry to bug you all... ;) Darren S. Hebden ----+--------------------------------- 2+2=5. Maths for the | Email : dsh@skoardy.demon.co.uk Intel Generation... | dsh@krisalis.demon.co.uk ---------------------+--------------------------------- From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 16 Feb 1995 18:01:25 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/11/25 Version: 2.3.1 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 116 a copy of the current instruction set? 5. What is ICWS'94? Which simulators support ICWS'94? 135 6. What is the ICWS? 152 7. What is TCWN? 162 8. How do I join? 170 9. Are back issues of TCWNs available? 187 10. What is the EBS? 194 11. Where are the Core War archives? 208 12. Where can I find a Core War system for . . . ? 226 13. I do not have ftp. How do I get all of this great stuff? 275 14. I do not have access to Usenet. How do I post and receive news? 285 15. When is the next tournament? 303 16. What is KotH? How do I enter? 314 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 483 18. How does SLT (Skip if Less Than) work? 495 19. What does (expression or term of your choice) mean? 507 20. Other questions? 650 --------------------------------------------------------------------- Q 1: What is Core War? A 1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in two anthologies: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 Author: Dewdney, A. K. Title: The Magic Machine: A Handbook of Computer Sorcery Published: New York: W. H. Freeman (c) 1990 ISBN: 0-7167-2125-2 (Hardcover), 0-7167-2144-9 (Paperback) Library of Congress Call Number: QA76.6 .D5173 1990 A.K. Dewdney's articles are still the most readable introduction to Core War, even though the Redcode dialect described in there is no longer current (see Q 4). --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (ftp.csua.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) Steven Morrell (morrell@math.utah.edu) is preparing a more practically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. Michael Constant (mconst@ ftp.csua.berkeley.edu) is reportedly working on a beginner's introduction. --------------------------------------------------------------------- Q 5: What is ICWS'94? Which simulators support ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (ftp.csua.berkeley.edu pub/corewar/documents/icws94.0202.Z). You can try out the new standard by submitting warriors to the '94 hills of the KotH servers (see Q16). Two corewar systems currently support ICWS'94, pMARS (various platforms) and Redcoder (Mac), both available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on ftp.csua.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on ftp.csua.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q10: What is the EBS? A10: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites (see Q 5). ---------------------------------------------------------------------- Q11: Where is the Core War archive? A11: Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from ftp.csua.berkeley.edu (128.32.43.51) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@ftp.csua.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: Core War systems are available via anonymous ftp from ftp.csua.berkeley.edu in the pub/corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. It is a good idea to check pub/corewar/incoming for program updates first. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than ftp.csua.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-21.hqx - corewar for the Mac, supports ICWS'88 and '94 core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars06s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars06s.tar.Z - same as above pmars062.zip - PC executables with graphics display, req 386+ macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) buggy, no display MacpMARS.10.cpt.hqx - port of v0.6 for the Mac, with display and debugger MacpMARS.10s.cpt.hqx - C source (MPW, ThinkC) for Mac frontend ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincor11.zip - MS-Windows system, shareware ($15) ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. If you don't have access to the net at all, send me a 3.5 '' diskette in a self-addressed disk mailer with postage and I will mail it back with an image of the Core War archives in PC format. My address is at the end of this post. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. Informal double-elimination tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. ---------------------------------------------------------------------- Q16: What is KotH? How do I enter? A16: King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. The original KotH was developed and run by William Shubert at Intel, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch (tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies (sd@ecst.csuchico.edu). Both KotHs provide very similar services and are therefore covered together. The principal difference is that "pizza" has a much faster internet connection than "stormking". Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put a line starting with ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 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 daemon 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. There are currently six separate hills you can select by starting your program with ;redcode, ;redcode-x, ;redcode-icws, ;redcode-b, ;redcode-94, or ;redcode-94x. More information on these hills is listed below. 3) Mail this file to "koth@stormking.com" or "pizza@ecst.csuchico.edu". "Pizza" requires a subject of "koth" (use the -s flag on most mailers). 4) Within a few minutes (or the next day for "stormking") you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so (or the next day for "stormking") you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives during that time, 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 20 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 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. The server kills programs by assigning an impossibly low score; it may therefore take another successful challenge before a killed program is actually removed from the hill. SAMPLE ENTRY: ;redcode ;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 ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Here are the Specs for the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws", available at "stormking" only) coresize: 8192 instructions max. processes: 8000 per program duration: After 100,000 cycles, a tie is declared. max. entry length: 300 minimum distance: 300 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x", available at "pizza" only) coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza" only) coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "stormking" and "pizza") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document. All hills run portable MARS (pMARS) version 0.6, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes and addressing modes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) * - indirect using A-field as pointer { - predecrement indirect using A-field } - postincrement indirect using A-field ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Gate-busting - (also gate-crashing) technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates. Hybrids - warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone). Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Date: 17 Feb 95 21:17:46 -0500 I have been playing around with adding a qscan to my favorite warrior. I have it running, but it doesn't seem to be helping (but doesn't hurt either). So, I have some questions to see if I can get this working and improve my win rate. First, how long should the bombing run be after the qscan? I have tried running a 30 location cmp scan, moving to target (a dat line) if I find a difference. Obviously, this is 60 lines of code, plus a couple to put target after my bombing code. I have been running my bombs 64 spots back from target. If I found someone on line 6 of my scan, and target is at line 66, won't target be pointing 60 spots past what I actually found? Do I gain nything from using increment/decrement relative instead of absolute sites. That is, would cmp >351, >-351 be worth more than cmp 351, -351? I would think that the cmp is still useful in that if they are both empty, they will point to themselves. If either has a warrior it is unlikely that it will be pointing to empty core (although certainly possible). In addition, this changes the b-field to a 1, so djn cmp-scanners will fall through to their bombing run, slowing them down a little. Is there any benefit from breaking the qscan in two. That is, checking half the locations, then spltiing to code to do the next half while bombing if anything is found? This would slow down the second half, but if anything is found in the first half, it would be hit more quickly. Thus, scan 15 pairs of locations. spl to the second half. Then, jmz to the dat line if the dat line is 0, otherwise next line starts bomb. This allows for shorter bomb run, and only adds a couple of instructions to the total scan if nothing was found in the first half. Next, can anyone give me tips on how to come up with scan locations. Right now I do cmp C01, -C01 ... cmp C30, -C30. Is there any good way to come up with locations? Should I do them at a site and a site + offset instead (cmp C01, C01+OFFSET)? Finally (I think), how soon should I move my real warrior away? Do I run the full scan, do a bombing run, copy and start my regular warrior? Or, should I scan, then while bombing move and start? Or maybe start copying while scanning. This last doesn't seem likely, because it would slow down the scan, making it a slow quick-scan, but I suppose someone would want to do it that way. Thankx for all of you who made it this far. Any tips will be appreciated. Randy Graham Subject: step sizes Message-ID: <1995Feb17.212634.1939@rhodes> From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Date: 17 Feb 95 21:26:34 -0500 I have been working on a warrior for some time now, and finally got comfortably onto the beginner's 94 hill (Hunter V x.x). I have been playing around with the step size I use in my scan, and was wondering if there is a preferred size range. for example, when I started, I was a mod 4 b-scanner and used optima from Nandor Sieben (sp?) to get 3044 I believe. I later reduced the number below 100, and eventually went mod 2. The reduction improved my score some, and going mod 2 helped quite a bit. Now, I was wondering if I should go even lower. For example, would something in the 30-50 step range help any more than something in the 80-100 range? I thought the 3044 jumping all around core quickly would help, but it really has been better with the small step. I don't feel like investing the CPU time to try all the different < 100 mod-2 steps I could use, so I waws hoping someone could give me some tips. So, any advice? I plan on posting my regular version of hunter to this group soon to see if I can make it better, but I want to try a couple more things first. Especially getting a god qscan to work. Oh, by the way (OBTW), in case it matters, I am using 94 guidelines since that approximately doubled my score against the warriors I have. Thx, Randy From: pk6811s@acad.drake.edu Subject: Re: qscan Date: 18 Feb 95 17:21:05 CST Message-ID: <1995Feb18.172105@acad.drake.edu> In article <1995Feb17.211746.1938@rhodes>, graham@harlie.mathcs.rhodes.edu (Randy Graham) writes: > I have been playing around with adding a qscan to my favorite > warrior. I have it running, but it doesn't seem to be helping (but > doesn't hurt either). So, I have some questions to see if I can get > this working and improve my win rate. These are great questions Randy! Hopefully these answers will be as good :) > > First, how long should the bombing run be after the qscan? I have > tried running a 30 location cmp scan, moving to target (a dat line) if > I find a difference. Obviously, this is 60 lines of code, plus a Depends on the opponent. Sorry, but that's all you can say. See next answer for another idea... > couple to put target after my bombing code. I have been running my > bombs 64 spots back from target. If I found someone on line 6 of my > scan, and target is at line 66, won't target be pointing 60 spots past > what I actually found? > Probably the best way is to start your DAT at zero, then MOV "found location minus 30" to it. That way you start bombing 30 locations past the location and continue 30 locations ahead of it. > Do I gain nything from using increment/decrement relative instead of > absolute sites. That is, would > cmp >351, >-351 > be worth more than > cmp 351, -351? > I would think that the cmp is still useful in that if they are both > empty, they will point to themselves. If either has a warrior it is > unlikely that it will be pointing to empty core (although certainly However if 30% of your opponent's fields point outside of his code that reduces your attack effectiveness accordingly, and the whole point of quick-scanning is to find and kill. Since this method is _very_ effective against certain opponents (large imp startups and paper colonies) you don't want to dilute it. > possible). In addition, this changes the b-field to a 1, so djn > cmp-scanners will fall through to their bombing run, slowing them down > a little. Very little. You are scanning 60 locations right? 8000/60 = 133 locations apart, meaning you slow him down one time every 133 times through his loop. > > Is there any benefit from breaking the qscan in two. That is, > checking half the locations, then spltiing to code to do the next half > while bombing if anything is found? This would slow down the second >... Better just to JMN to your bombing run if DAT is no longer zero. > Next, can anyone give me tips on how to come up with scan locations. > Right now I do > cmp C01, -C01 ... cmp C30, -C30. > Is there any good way to come up with locations? Should I do them at > a site and a site + offset instead (cmp C01, C01+OFFSET)? > Experiment! Remember unless your bombing run attacks two (or four) locations in the same loop, you have to check which of the two (or four) CMP'd locations contains the opponent. > Finally (I think), how soon should I move my real warrior away? Do I > run the full scan, do a bombing run, copy and start my regular > warrior? Or, should I scan, then while bombing move and start? Or > maybe start copying while scanning. This last doesn't seem likely, > because it would slow down the scan, making it a slow quick-scan, but > I suppose someone would want to do it that way. > A tough one. I'm for scanning first, unless your real code is very short like 3-5 lines. Remember you are also a big target, so don't delay getting started. I know others have played with this. And someone just made the '94 hill with a qscan and core-clear combination, so there's plenty of room for more ideas. Paul Kline pk6811s@acad.drake.edu From: pk6811s@acad.drake.edu Subject: Re: step sizes Date: 18 Feb 95 17:32:14 CST Message-ID: <1995Feb18.173214@acad.drake.edu> In article <1995Feb17.212634.1939@rhodes>, graham@harlie.mathcs.rhodes.edu (Randy Graham) writes: > I have been working on a warrior for some time now, and finally > got comfortably onto the beginner's 94 hill (Hunter V x.x). I Way to go!!! > have been playing around with the step size I use in my scan, and was > wondering if there is a preferred size range. for example, when I > started, I was a mod 4 b-scanner and used optima from Nandor Sieben > (sp?) to get 3044 I believe. I later reduced the number below 100, > and eventually went mod 2. The reduction improved my score some, and > going mod 2 helped quite a bit. Now, I was wondering if I should go > even lower. > > For example, would something in the 30-50 step range help any more > than something in the 80-100 range? I thought the 3044 jumping all >... Step-size selection is a mix of art and science. You take the optima selection (or try reading the chicken bones inside my NUM8000 file :-) and try it against multiple opponents. If your opponent is using a small step size you can gain a definite advantage by using a slightly larger size and scanning in the opposite direction from him. Your step will cross the gap more quickly to him. With step sizes much larger than code-size it's not so easy, you are trying to find a number which is optimal for several different circumstances, including finding an opponent of size-a, and an opponent of size-b, is mod-something, kills 3-point imps effectively, etc. Paul Kline pk6811s@acad.drake.edu From: tusk@daimi.aau.dk (Martin M|ller Pedersen) Subject: Re: Have I missed the FAQ Date: 19 Feb 1995 15:34:52 GMT Message-ID: <3i7oes$h84@belfort.daimi.aau.dk> Thus spake dsh@skoardy.demon.co.uk (Darren Hebden): >I joined this newsgroup a few days ago after finding out >about it from a WWW page. I'm not sure how up to date the >information was so what I was wondering is, is there a FAQ >for this newsgroup? >If there is, I guess I must have missed it by a day or two >and I'm sorry to bug you all... ;) Here is a pointer to the faq: ttp://www.cis.ohio-state.edu/hypertext/faq/usenet/games/corewar-faq/faq.html you can also ftp the faq from rtfm.mit.edu. = tusk@daimi.aau.dk = "I d"I don't give a damn for a man that can only spell a word one way." -- Mark Twain (1835-1910) From: sbeitzel@netcom.com (Stephen Beitzel) Subject: Core War page Message-ID: Date: Tue, 21 Feb 1995 01:19:47 GMT Has anyone put all the published stuff about Core War under a single web page umbrella? I noticed that the FAQ has been converted to html (sort of) and I wonder if, for instance, the published warriors, the most current MARS programs, the email addresses of the KotH servers, the '88 specs, and the '94 specs have been gathered at one site? I've started building a page that will link to some of this stuff, and am happy to continue building it when I get time (on & off these days) but I don't want to duplicate somebody else's efforts. If you want to check it out, it's at: http://www.eworld.com/aos/people/beitzel/core.html Right now I've just got the '94 draft, the FAQ, and pMARS for Mac & DOS linked up. -- Stephen Beitzel (finger for PGP key) DoD# 4E71 '91 SwitchIt in-lines '93 Vision R40 '95 BMW K75 From: jfc@pacifier.com (Jim Cox) Subject: Is their a good file for core war beginers? Date: 21 Feb 1995 05:30:04 GMT Message-ID: <3ibtos$klr@news.pacifier.com> I was just wanted to know if their are any good files for core war beginers. Any help would be greatly appriciated. Thanks. From: ads@netcom.com (Anthony Spataro) Subject: Crime ring, onion ring, imp ing... Message-ID: Date: 22 Feb 95 01:29:41 GMT Yeah, that's me, another Core War newbie. I've gotten pMARS, read the tutorial.? and the awkwardly-formatted ICWS'88 specs, and a little bit of the partially-completed book on warriors. And, although I have managed to make a simple warrior that just runs through memory, I'm still very confused. The documentation, while doing a good job explaining addressing modes and Redcode syntax, ignored or only briefly mentioned quite a few things. I'm still in the dark about the spl and dat instructions--I know that spl "starts a new process" and dat "writes data and terminates the current process" but that doesn't mean a whole lot at the moment. And, perhaps the biggest of all, the apparent contradiction of how a warrior operates. After the first instruction is executed, the "instruction pointer" moves on, to the next instruction in memory--but unless the first instruction put something there, the warrior dies! How then does one manage to create a warrior that does anything besides staying one step ahead of itself? -- /ads@netcom.com [LC/Cardy/Kilwren/Cardenyl \PASO/Paradigm/Storm ----------------------------> You could get a new lease on life -- if only you didn't need the first and last month in advance. Subject: Help with Hunter Message-ID: <1995Feb22.122843.1965@rhodes> From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Date: 22 Feb 95 12:28:42 -0500 OK, here's where I have gotten my warrior so far. This is exactly the latest warrior I have on the beginner's 94 hill. So, anyone wanting to beat it can just target it and try to knock it off. The real reason I am posting it here though is to ask for help improving it. I realize going to a cmp-scanner instead should be better, but I have yet to get one correct. Mine all seem to end up with ~50/0/~50, so I know I am doing something wrong, but can't figure out what. I will work on this and ask for more specific help later. Right now, what do you think of hunter? Can anyone give some good tips for improving him? ;redcode-b ;Name Hunter v2.6 ;Author Randy W. Graham ;assert CORESIZE>1 ;strategy a-scanner based on XTC and rave. Don't bomb self, lay ;strategy carpet of spl bombs. After avoiding hitting ourself ;strategy several times (twice through core), sweep and sit. ;strategy As is true of all my programs, I still can't beat imps. ;strategy v2.5 Hey, '94 rules -- .f scan!!! Now catches imps some. ;strategy v2.6 Was using wrong 3/9 point imp gate. OPT equ 98 ;mod 2 BOMBS equ 12 LEN equ (fini-hunt) TIMES equ 16 ;how many times to hit ourself hunt add #OPT, ptr ptr jmz.f -1, ptr+OPT slt #LEN+1, ptr zero djn hunt, #TIMES jmz spltrap, zero mov #BOMBS, traps mov spltrap, >ptr traps djn -1, #0 sub #BOMBS, ptr jmp hunt, <2667 spltrap spl 0, #0 dosweep mov 1, <-1 dat <2667, <2667*2 fini end ptr Just some additional notes. I never put v0.1-v1.3 on the hill, and v2.3 was buggy. I have tried larger and smaller jumper sizes, and subtracting instead of adding. None seemed to make much difference. I am trying to add a qscan, but so far it hasn't made a difference. It seems to me I should be able to eliminate one line of code somewhere, but I can't figure out how. Thx in advance, Randy From: inf93a19@mini01.vejlees.dk (Daniel Mathiasen) Subject: Got a copy ? Date: 23 Feb 1995 14:19:33 GMT Message-ID: <3ii5hl$lpn@esanews.denet.dk> Can anyone tell me where I can get a version of Corewar ? -- #----------------------------------------------------------------------# | Daniel Walther Mathiasen * No man is wise enough | | Moelgaardvej 26 * Nor good enough | | 7173 Vonge * To be trusted with | | EU-Denmark * Unlimited power | | inf93a19@mini01.vejlees.dk * -A wise man | #----------------------------------------------------------------------# From: rrognlie@netcom.com (Richard Rognlie) Subject: C++Robots Standings Message-ID: Date: 23 Feb 95 16:19:28 GMT ------------------------------------------------------------------------------ | ______ ________ ____ __ | | /======\ \=======\ \===| _|==|_ | | / / \/ __ __ | ) | | (_ _) | | / / _|==|_ _|==|_ | __ / ____ | |__ ____ | | _____ | | \ \______(_ _)(_ _)| \ /====\ | \ /====\ | | /====/ | | \ / |__| |__| | |\ \ ( __ )| __ )( __ )| |_ \___ \ | | \______/ |__| \___\ \____/ |_____/ \____/ \___\ /____/ | | | | (c) 1995 Richard W. Rognlie | | | | Standings as of 11:15 AM EST on February 23rd, 1995 | | | | For full information, send a mail message to: pbmserv@netcom.com | | with "help summary c++robots" (sans quotes) as the Subject: line. | | | ------------------------------------------------------------------------------ Program Name Score W / L / T Age Author ================ ===== =========== === ===================================== 1 crawl 270 90/ 10/ 0 19 blikror@inet.uni-c.dk (Mogens Olesen) 2 one_man_one_bot 254 84/ 14/ 2 41 cfodor@megatek.com (Chris Fodor) 3 conan 222 74/ 26/ 0 10 tdavis@garnet.acns.fsu.edu (Thomas E. 4 damned1 198 66/ 34/ 0 11 hesiden@Stoner.COM (Mark Hesidence) 5 randwalk 196 65/ 34/ 1 12 hanwen@stack.urc.tue.nl (Han-Wen Nien 6 inyourface 185 60/ 35/ 5 21 hesiden@Stoner.COM (Mark Hesidence) 7 terror 184 61/ 38/ 1 48 robc@bigb.stortek.com (Rob Creager x2 8 ittybittykitty 181 58/ 35/ 7 31 hansk@netcom.com (Hans Kellner) 9 snip3 164 50/ 36/ 14 17 hanwen@stack.urc.tue.nl (Han-Wen Nien 10 tracker 162 51/ 40/ 9 2 rrognlie@netcom.com (Richard Rognlie) 11 proto5 130 43/ 56/ 1 22 robc@bigb.stortek.com (Rob Creager x2 12 pointnshoot 130 42/ 54/ 4 42 jbreed@doink.edaal.ingr.com (Jim Reed 13 boxer 126 40/ 54/ 6 28 wfp5p@tigger.itc.virginia.edu (Bill P 14 newsitter3 118 38/ 58/ 4 27 gl8f@fermi.clas.virginia.edu (Greg Li 15 orion 113 37/ 61/ 2 13 hanwen@stack.urc.tue.nl (Han-Wen Nien 16 sponge2 109 36/ 63/ 1 43 garlock@iron.afsac.wpafb.af.mil (Erin 17 agility 97 32/ 67/ 1 51 dhouston@nynexmc.co.uk (David Houston 18 cylon 96 32/ 68/ 0 1 rrognlie@netcom.com (Richard Rognlie) 19 hereicome 85 28/ 71/ 1 49 jbreed@doink.edaal.ingr.com (Jim Reed 20 lazzo 78 26/ 74/ 0 45 jimwong@netcom.com (Jimmy K. Wong) -- /\/\/\ | Richard Rognlie / Sr. Computer Analyst / PRC Inc. / McLean, VA / \ \ \ | E-Mail: rrognlie@netcom.com *or* rognlie_richard@prc.com \ / / / | Phone: (Home) (703) 361-4764 (Office) (703) 556-2458 \/\/\/ | (Fax) (703) 556-1174 From: pk6811s@acad.drake.edu Subject: Spl-Zero Bomb Sizes Date: 23 Feb 95 16:46:40 CST Message-ID: <1995Feb23.164640@acad.drake.edu> R. Graham's Hunter program got me to thinking about the optimum size for a spl-zero bomb. 13 seems to be a popular number (Agony et al) but it always seemed a little on the large size to me. Sure - it's very discouraging to get hit with 13+ spl-zeros, but what makes that a magic number? With the help of Redcoder I monitored a single process working its way through spl-zero bombs ranging in size from 4 to 9 and compared them to a bomb of 16 for 4000 cycles. Actually after 4096 cycles only the 14th spl-zero has been entered, so bombs longer than 14 are probably wasteful. In fact it takes until the 2048th cycle to get to the 13th spl-zero. In 2048 cycles a standard cmp-scanner will have scanned 2048 * 2/3 = 1365 locations or every 5.8th location in core, meaning that the scanner will have re-attacked and lengthened the first bomb well before the trapped processes begin to fall out of it. Herein is the key to optimizing a spl-zero bomb size. There are three basic scanning speeds: add/jmz = 50% of the time actually scanning add/cmp = 67% "" sne/seq = 80% "" Let's say you are a cmp-scanner like Agony. You scan 2 locations in a 3-instruction loop for a 67% rate. If you drop a 4-spl bomb on your opponent he will begin to generate excess processes. For the first few cycles he will generate them at the same rate as if you had dropped a 16-spl bomb, but shortly his processes will begin to move out of the bomb and escape. The question is, in the time it takes you to re-scan and lengthen your first bomb, how well did your bomb do compared to a 16-spl bomb? In the first 500 cycles a 16-spl bomb generates 501 processes, a 4-spl bomb generates 248 processes or about 50% as many. Meanwhile you have had time to scan every 32nd location. It will take you about 3000 cycles to re-scan your first bomb. In 3000 cycles a 16-spl bomb would have generated 3001 processes, a 4-spl bomb only 943 processes or 31.4%. Since that seems a little weak, how about a 5-spl bomb? In 3000 cycles a 5-spl bomb would have generated 1467 processes = 48.9%, much better. However, re-scanning a 5-spl bomb should only take about 2500 cycles. In 2500 cycles a 5-spl bomb would have generated about 50.2% as many processes as a 16-spl bomb. Still a little weak, how about a 6-spl? In 2500 cycles a 6-spl bomb generates 1691 processes = 67.6%. However re-scanning a 6-spl bomb should only take about 2000 cycles. In 2000 cycles a 6-spl bomb generates about 69.9% as many as a 16-spl. Now we're getting somewhere. In the time it takes to re-scan it, a 7-spl bomb generates about 85% as many processes as a 16-spl. An 8-spl bomb about 95% as many. Here is the table showing the number of processes generated for a given number of cycles (increments of 500), and the mod-scan that can be accomplished by the three scanner forms in that number of cycles. A mod-scan of 8 should re-scan a size-8 bomb in the corresponding number of cycles, so using a larger bomb would be wasteful. t = number of cycles b = bomb-size = number of spl-zeros r = scanning rate Mod-scan do-able ----Number of processes generated by bomb---- in 't' cycles t | b=4 b=5 b=6 b=7 b=8 b=9 b=16 | r=.5 r=.67 r=.8 ---- | ---- ---- ---- ---- ---- ---- ---- | ---- ---- ---- 500 | 248 343 437 485 499 501 501 | 32.0 24.0 20.0 1000 | 405 599 783 929 983 999 1001 | 16.0 12.0 10.0 1500 | 551 837 1103 1291 1427 1482 1501 | 10.7 8.0 6.7 2000 | 681 1079 1399 1713 1911 1981 2001 | 8.0 6.0 5.0 2500 | 807 1257 1691 2031 2279 2425 2501 | 6.4 4.8 4.0 3000 | 943 1467 2051 2409 2723 2909 3001 | 5.3 4.0 3.3 3500 | 1027 1657 2241 2843 3177 3393 3501 | 4.6 3.4 2.9 4000 | 1161 1833 2495 3125 3641 3891 4001 | 4.0 3.0 2.5 Now here is the table showing number of processes as a percentage of that for a 16-spl bomb so we can compare effectiveness: -------Number of processes as % of b=16------- t | b=4 b=5 b=6 b=7 b=8 b=9 b=16 | r=.5 r=.67 r=.8 ---- | ---- ---- ---- ---- ---- ---- ---- | ---- ---- ---- 500 | 49.5 68.5 87.2 96.8 99.6 100.0 100.0 | 32.0 24.0 20.0 1000 | 40.5 59.8 78.2 92.8 98.2 99.8 100.0 | 16.0 12.0 10.0 1500 | 36.7 55.8 73.5 86.0 95.1 98.7 100.0 | 10.7 8.0 6.7 2000 | 34.0 53.9 69.9 85.6 95.5 99.0 100.0 | 8.0 6.0 5.0 2500 | 32.3 50.3 67.6 81.2 91.1 97.0 100.0 | 6.4 4.8 4.0 3000 | 31.4 48.9 68.3 80.3 90.7 96.9 100.0 | 5.3 4.0 3.3 3500 | 29.3 47.3 64.0 81.2 90.7 96.9 100.0 | 4.6 3.4 2.9 4000 | 29.0 45.8 62.4 78.1 91.0 97.3 100.0 | 4.0 3.0 2.5 Here is a truncated table for a 50% scanner, showing the lowest effectiveness possible for each bomb-size. The effectiveness can't drop lower than this because the original bomb will be re-attacked and lengthened to prevent more processes escaping. -------Number of processes as % of b=16------- t | b=4 b=5 b=6 b=7 b=8 b=9 b=16 | r=.5 ---- | ---- ---- ---- ---- ---- ---- ---- | ---- 500 | 49.5 68.5 87.2 96.8 99.6 100.0 100.0 | 32.0 1000 | 40.5 59.8 78.2 92.8 98.2 99.8 100.0 | 16.0 1500 | 36.7 55.8 73.5 86.0 95.1 98.7 100.0 | 10.7 2000 | 34.0 53.9 69.9 85.6 95.5 99.0 | 8.0 2500 | 32.3 50.3 67.6 81.2 | 6.4 3000 | 31.4 48.9 | 5.3 3500 | 29.3 47.3 | 4.6 4000 | 29.0 | 4.0 Here is the truncated table for a 67% scanner: -------Number of processes as % of b=16------- t | b=4 b=5 b=6 b=7 b=8 b=9 b=16 | r=.67 ---- | ---- ---- ---- ---- ---- ---- ---- | ---- 500 | 49.5 68.5 87.2 96.8 99.6 100.0 100.0 | 24.0 1000 | 40.5 59.8 78.2 92.8 98.2 99.8 100.0 | 12.0 1500 | 36.7 55.8 73.5 86.0 95.1 98.7 100.0 | 8.0 2000 | 34.0 53.9 69.9 85.6 | 6.0 2500 | 32.3 50.3 | 4.8 3000 | 31.4 | 4.0 3500 | | 3.4 4000 | | 3.0 Here is the truncated table for an 80% scanner: -------Number of processes as % of b=16------- t | b=4 b=5 b=6 b=7 b=8 b=9 b=16 | r=.8 ---- | ---- ---- ---- ---- ---- ---- ---- | ---- 500 | 49.5 68.5 87.2 96.8 99.6 100.0 100.0 | 20.0 1000 | 40.5 59.8 78.2 92.8 98.2 99.8 | 10.0 1500 | 36.7 55.8 73.5 86.0 | 6.7 2000 | 34.0 53.9 69.9 | 5.0 2500 | 32.3 | 4.0 3000 | | 3.3 3500 | | 2.9 4000 | | 2.5 (Sorry, Anders, you'll have to work out the table for Leprechaun-style scanning yourself :-) From the tables we can see that a 7-spl bomb should be 81-86% as effective as a 16-spl, with an 8-spl 95-98% as effective. So these would seem to be optimum sizes. However: Some cmp-scanners have to bomb the whole distance between their two pointer locations, which is probably much longer than 8. Pre-decrement bombing would mean that only part of the bomb is laid on the found location and some if it is wasted - much better to use post-increment bombing to ensure that the whole bomb is used. A larger bomb may be more effective against certain multi-processing opponents (however it is hard to see how anyone can overcome 8-spl bombs no how strong they are :-). Paul Kline pk6811s@acad.drake.edu From: Levis_Tremblay@UQAT.UQUEBEC.CA () Subject: C++Robots like but Turbo Pascal Message-ID: Date: Thu, 23 Feb 1995 20:09:31 GMT Well, the title said much about my question... I need a program wich look like C++Robots, but in Turbo Pascal (or Pascal). I've seen many in other languages (BASIC, ASM, C++) but ANY in Pascal... &^( -DeathStroke Subject: Re: Spl-Zero Bomb Sizes Message-ID: <1995Feb23.205437.1988@rhodes> From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Date: 23 Feb 95 20:54:36 -0500 pk6811s@acad.drake.edu wrote: : R. Graham's Hunter program got me to thinking about the optimum size : for a spl-zero bomb. 13 seems to be a popular number (Agony et al) but : it always seemed a little on the large size to me. Sure - it's very : discouraging to get hit with 13+ spl-zeros, but what makes that : a magic number? [More good info deleted] : Some cmp-scanners have to bomb the whole distance between their two : pointer locations, which is probably much longer than 8. Well, shortly after posting Hunter I figured out how to make him a cmp-scanner. HUGE performance increase. But along the way I ran into exactly this problem. Currently my scan pointers are about 1/3 of the OPT value I use apart. So, I have to scan across my gap plus a little extra for good measure. I use 4 beyond right now, but I'm not sure that is enough. As for the original Hunter, well I scanned a little extra because I assumed that they might have moved some since I found them or that I am catching the tail of an imp. Thus, I need to bomb a little extra. Also, it takes a couple of instructions to set up the bomb, and of course, each bomb takes two cycles to plant. Now, once you get someone, you'll get the benefit of extra bombs no problem. However, if they are moving ahead of where you found them (Chimera for example), then you have to hope your bombs are laid more quickly than they are moving. I did find out through experimentation that increasing my bomb run beyond 12 didn't gain much, and slowed me down enough for a few others to get me a little more often - net result of a decrease in score. However, reducing gave me less wins, which I assumed was because I caught others less frequently. : Pre-decrement bombing would mean that only part of the bomb is laid on : the found location and some if it is wasted - much better to use : post-increment bombing to ensure that the whole bomb is used. Yes, I quickly found out that laying a < bomb stream was FAR less effective than a > bomb run. In fact, someone who helped me with tips on Hunter adjusted him to lay down < bombs and saved me two instructions through re-arranging code. However, the bombs hit less effectively and I ended up with only 1/2 my typical wins. 1/2 of those were additional ties, 1/2 were additional lossed. So, I decided if you are going to lay a < bomb run, you MUST use spl -1 or move your pointer (like XTC) and bomb from there. Even then, I have found spl 0 going > to be more effective. : A larger bomb may be more effective against certain multi-processing : opponents (however it is hard to see how anyone can overcome 8-spl bombs : no how strong they are :-). Again, the little extra in my particular case is to catch up with their code in case they move (dang imps!!! ;-}). : Paul Kline : pk6811s@acad.drake.edu Randy Graham : (Sorry, Anders, you'll have to work out the table for Leprechaun-style : scanning yourself :-) And just as an aside, what is Leprechaun-style scanning??? From: mathva@aol.com (MaThVa) Subject: Re: Got a copy ? Date: 24 Feb 1995 07:24:28 -0500 Message-ID: <3ikj5s$li3@newsbf02.news.aol.com> You can find a copy at ftp.csua.berekely.edu:/pub/corewar/systems/ From: schitzo+@CMU.EDU (Michael N Nonemacher) Subject: Re: Help with Hunter Message-ID: <0jHTzmG00iWPI2oZtK@andrew.cmu.edu> Date: 24 Feb 95 15:49:06 GMT Excerpts from netnews.rec.games.corewar: 23-Feb-95 Re: Help with Hunter by pk6811s@acad.drake.edu >Finally, since the spl executes half the time it must also support the gate: > > spltrap spl 0, <-19 > dat <-20, <-20+2667 > >Since the b-field on spltrap is part of the gate you will have to find >another b-field to decrement from dosweep, like maybe your 'zero' location. But this introduces another problem that will slow down your scan: Once you find something, and bomb it with "spl 0, <-19" or whatever, subsequent scans will find your bomb run, making you VERY susceptible to decoys, inc/decrements, etc. I would advise a gate like spl #0, #0 dat >-20, >-20+2667 But this gate may not be as effective against non-3-point imps. An increment gate is a bit more stable than a decrement gate (but both can still be crashed by 2668, 2667 imps), and since this is a less-than-100% gate, you need all the stability you can get. :) But try it out, run some tests, and see how well it does against imps. It should be a perfect gate against 3-point imps, but I'm not sure how it'll hold up against others. You might also try gates with these dat statements: dat >-20, >-20 dat >-20, >-21 Or something like that. Experiment, let us know how stuff works (especially those of us who are too lazy to actually exit and try it out ourselves... :) Good luck! Mike ------------------------------- Schitzo ------------------------------ "For the sinful nature desires what is contrary to the Spirit, and the Spirit what is contrary to the sinful nature..." Galatians 5:17 (NIV) ---------------------------------------------------------------------- "First came stats pulling habits out of rats, Now they may need more attention..." - Steve Taylor, "Jung and the Restless" --------------------------------------------- Michael N Nonemacher schitzo+@cmu.edu From: godling@best.com (Dan Melchione) Subject: Re: C++Robots simulator for unix available Date: Sun, 26 Feb 95 04:05:24 GMT Message-ID: <3ioujv$4tf@news1.best.com> What directory did this get stored in? In article <3i2eck$shl@snail.stack.urc.tue.nl>, hanwen@stack.urc.tue.nl (Han-Wen Nienhuys) wrote: >Hi! > >I have just uploaded the last version of my and Frank's (unfinished but >working) C++Robots simulator to ftp.csua.berkeley.edu. The file is called >cpprsim.zip From: pk6811s@acad.drake.edu Subject: Mail-to-Usenet Gateway? Date: 27 Feb 95 16:52:45 CST Message-ID: <1995Feb27.165245@acad.drake.edu> The mail-to-usenet gateway I was using to auto-post the Pizza Hill standings has closed permanently (@decwrl.dec.com). Does anyone have another? Paul Kline pk6811s@acad.drake.edu From: Michael N Nonemacher Subject: Drowning III source Date: Mon, 27 Feb 1995 17:10:29 -0500 Message-ID: Hmm... Just realized this is pretty old and it hasn't been posted yet. Drowning never quite worked as well on the hill as it did in my tests, but it's one of those warriors that, theoretically, should beat anything. In reality, it doesn't. Here it is: ;redcode-94 ;name Drowning III ;author Mike Nonemacher ;strategy Drowning With Land In Sight ;strategy F-scan -> silk paper ;strategy coreclear if F-scan found anything ;strategy testing... ;kill Drowning ;assert CORESIZE==8000 ;F-scan, mod 1, till we find something. When we find something, bomb it ;with an indirect jump to the pit, and decrement DELAY. The next stage ;of Drowning III is brought on in one of three ways: ; 1. When DELAY=0, that is, when we have found and bombed DELAY ; things, start silk paper and a wimp. The wimp ensures a win if ; any processes are caught in the pit, and the silk paper has been ; bombed. ; 2. When we get done NSCANS scans, trap is moved onto tr, BUT NOT ; SUBTRACTED FROM, which makes the indirection point to m (which ; always points to done. We then jump to done, and start silk ; paper and a wimp. ; 3. When an opponent jumps into the pit, sig is decremented. ; Looking at the line before r (r holds #DELAY) makes the djn.b ; fall thru, and starts a perpetual coreclear. It clears forward, ; while decrementing backward, and should hit the pit last. Any ; processes in the pit will be spl-bombed last, and will die last. ; After writing the spl to all core locations, the coreclear writes ; a dat statement to all core locations, over and over again. This ; strategy works very well against opponents using silk paper. ; ;The scanner/pit part should take care of scanners. I have tried to set ;the program components up so that, if a scanner is trapped in the pit, ;and the pit is intact, it doesn't matter where my code has been hit, I ;will get the win. Against stones (including imp-stones), case 1 will ;trigger the silk paper, which should get a win. Against paper opponents, ;case 3 is the desired outcome, and should result in a win, but case 1 ;often occurs, guaranteeing a tie. ;scans self at: ; 34 47 60 73 86 99 12 25 38 51 64 77 90 3 ; 3 12 25 34 38 47 51 60 64 73 77 86 90 99 STEP EQU 239 INIT EQU tr-(STEP*NSCANS) NSCANS EQU 1137 DELAY EQU 25 PC1 EQU 299 PC2 EQU 1021 org scan a add.ab #STEP, @tr ;line 0 scan jmz.f -1, INIT mov.i trap, @scan tr sub.ba @0, @scan sig djn.b a, r jmz.b done, r jmp clear ;line 6 for 7 dat.f 0, 0 rof paper spl 1, #1 ;line 14 spl 1, #1 mov.i -1, #1 r spl p2, #DELAY p1 spl @0, PC1 mov.i }-1, >-1 mov.i b1, >-2 mov.i b1, }2241 mov.i b1, >4000 jmp @0, {p1 b1 dat.f >2667, >5334 ;line 24 dat.f 0, 0 p2 spl @0, PC2 ;line 26 mov.i }-1, >-1 mov.i b2, >-2 mov.i b2, }2241 mov.i b2, >4000 jmp @0, {p2 b2 dat.f >2667, >5334 ;line 32 for 19 dat.f 0, 0 rof pit spl #0, #2 ;line 52 mov.i clr, >clr m mov.i j, #done ;make sure next line only runs once jmp -3, 2667, #50 for 17 dat.f 0, 0 rof done spl paper ;line 74 wimp jmp #0, <-100 j jmp -2, #done-m ;line 76 dat.f 0, 0 trap jmp @pit-scan, #40 ;line 78 for 15 dat.f 0, 0 rof cptr dat.f #clear, #clear+5 ;line 94 dat.f #1, @6 clear spl #1, @6 mov.i *cptr, >cptr ;forward perpetual coreclear djn.f -1, <-56 ;line 99 END From: groger@infi.net (Roger A. Grimes) Subject: CoreWar from the 60's Date: 28 Feb 1995 09:34:57 GMT Message-ID: <3iuqo1$m2e@lucy.infi.net> I didn't see this covered in the FAQ, but I just read it quickly, so don't flame me if it is already been covered. I remember reading, in some anti-virus journal, that the original core war game was started by Robert Morris, Sr. at some Bell Lab/MIT school. He was an instructor there, and he challanged his students to make core war bombs. The game quickly caught on, and soon his students activities were stopped by school officials. I find it moronic that the same guy who started core wars had a son, Robert Morris, Jr. who made the Internet Worm. Anyone ever disproved the story? CC: to roger_grimes@bshsi.com if can. From: cfp100@minster.york.ac.uk (Colin F. Plummer (1X0)) Subject: Re: C++Robots like but Turbo Pascal Message-ID: <793964606.1@cs.york.ac.uk> Date: 28 Feb 1995 09:43:26 GMT Levis_Tremblay@UQAT.UQUEBEC.CA wrote: : Well, the title said much about my question... I need a program wich look : like C++Robots, but in Turbo Pascal (or Pascal). I've seen many in other : languages (BASIC, ASM, C++) but ANY in Pascal... &^( : -DeathStroke There is one for the PC... PCRobots, it has librarys so that you can write Pascal, C or assembler robots. I don't know where you could get hold of it though :) Panther Subject: P.Kline Code Message-ID: <1995Feb28.122450.2029@rhodes> From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Date: 28 Feb 95 12:24:49 -0500 I've been pulling and looking at previous months postings, pulling out the good ones, and trying to improve my code. In Sep94, I found this snippet by P.Kline step equ 13 bomb dat step+step tstdjn dat -1, -1 inc dat 3*step, 3*step next add inc, scan mov bomb, @scan scan seq.x 10*step, @9*step sne *scan, tstdjn djn next, #7700/(step*3) attack ... Ok, I understand how scan and scan-1 are testing and bombing different locations. And I understand how the seq.x catches imps, and even how scan+1 only bombs if the difference isn't caused by a djn.f stream. BUT, How in the world does this thing keep from destroying itself. I haven't tested this too much, but it seems that with an increment of 39 it would eventually mov bomb onto itself somewhere. I'm not sure how it keeps from nailing itself since 39 isn't a factor of CORESIZE. Thanx for help Randy Subject: tcwn and 94 info Message-ID: <1995Feb28.123415.2030@rhodes> From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Date: 28 Feb 95 12:34:14 -0500 I've gotten some old tcwn stuff from scotch/soda/whatever :-) and seem to have a little trouble with them. They have names like tcwn0994.z. Well, the .z to me means pack, but they certainly aren't (the header says binary created by MAD). So, Mark (or anyone else), what format are they in, and how do I pull them out in Unix or Dos? On another note, have the '94 rules ever been finalized? I keep hearing about the 94 draft, and even use it extensively. However, I can't find a "Final" version. I figure since so many people use SEQ/SNE, I ought to at least find a copy of the standard which includes these "Officially." One of the things I've seen in 94 stuff which I don't like is knowledge of things like CORESIZE, MAXLENGTH, etc. Now I will admit to using them in designing my warriors. I also don't want to get started another holy war about whether or not these should be available. I just want to say that I will use certain assumptions in writing warriors (such as CORESIZE==xxx), but will also code around these assumptions. That is, I may not fight as well in an 8493 core arena as in an 8000 core arena, but at least I can still fight without catching myself. I just wondered if others do the same. Occasionally I run private tournaments of sort in which I change the CORESIZE. Many warriors break, so I just wondered. Maybe I should try running a server which changes size +-Rand(500) each fight?? Probably not, but it is an interesting thought. Randy Subject: QCmp-Hunter Message-ID: <1995Feb28.174529.2031@rhodes> From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Date: 28 Feb 95 17:45:28 -0500 Ok, here's my attempt at a QCmp program. I end up copying myself away (Cmp-Hunter v1.2) and starting that. While I am open to suggestions, I am more posting this as a way to give new folks an idea of how to set up a quick scan with sne/seq lines. I still need to work in figuring out optimal scan locations, but that will come in time I imagine. Right now, I do marginally better vs. the imps I have access to, but significantly worse against the likes of Rave or Charon. I have tried scanning a constant distance apart (QDIFF between each), and a small step within a line (QSTEP), a large step between lines (QDIFF*2). This one obviously has QSTEP scanning. That way I can just plaster the whole range if I find something. Using QDIFF*2 I had to check if *a or @b was different and bomb the correct location. By the way, anyone wanting the latest Cmp-Hunter, just pull the last few lines from adder to fini. This is exactly my 94b warrior (still miss the real 94 hill by a couple of points). Anyone with questions, feel free to contact me. I just learned Quick-scans last week, but I'll be glad to share my knowledge with anyone wanting it. --------[Snip, Snip]--------------------------------------------- ;redcode-b ;Name Qcmp-Hunter v0.5 ;Author Randy W. Graham ;assert 1 ;strategy OK, here's an attempt at a qscan Cmp-Hunter. OPT equ 44 ;mod 4 LEN equ (fini-adder) DIFF equ 13 BOMBS equ DIFF+setup-adder MOVETO equ B03-BACK-LEN-1 ;where we move to QDIFF equ 88 QSTEP equ 13 A01 equ 200 A02 equ A01+(QDIFF*4) A03 equ A01+(QDIFF*8) A04 equ A01+(QDIFF*12) A05 equ A01+(QDIFF*16) A06 equ A01+(QDIFF*20) A07 equ A01+(QDIFF*24) B01 equ A01+(QDIFF*28) B02 equ A01+(QDIFF*32) B03 equ A01+(QDIFF*36) B04 equ A01+(QDIFF*40) B05 equ A01+(QDIFF*44) B06 equ A01+(QDIFF*48) B07 equ A01+(QDIFF*52) C01 equ A01+(QDIFF*56) C02 equ A01+(QDIFF*60) C03 equ A01+(QDIFF*64) C04 equ A01+(QDIFF*68) C05 equ A01+(QDIFF*72) C06 equ A01+(QDIFF*76) C07 equ A01+(QDIFF*80) BACK equ 15 QBOMB equ BACK+BACK ;qscan scanner qscan for 7 sne.i A&qscan, A&qscan+(QSTEP) seq.i A&qscan+(QDIFF*2), A&qscan+(QDIFF*2+QSTEP) mov.a #A&qscan-target, target rof ;mov.a makes sure to move so we still point at same location jmn.a gobomb, target qscan for 7 sne.i B&qscan, B&qscan+(QSTEP) seq.i B&qscan+(QDIFF*2), B&qscan+(QDIFF*2+QSTEP) mov.a #C&qscan-target, target rof jmn.a gobomb, target qscan for 7 sne.i C&qscan, C&qscan+(QSTEP) seq.i C&qscan+(QDIFF*2), C&qscan+(QDIFF*2+QSTEP) mov.a #C&qscan-target, target rof jmz.a moveme, target ;if we haven't found anything gobomb add.ab target, target ;get two pointers set up sne.i *target, @target ;if these differ, use them add.i nope, target ;else, add our offsets qbomb mov.i spltrap, }target ;lay carpet on a-field djn.b qbomb, #QBOMB moveme spl 1, <2667 ;2 instructions leave mov.i -1, #0 ;3 instructions leave spl 1, <2667 ;6 instructions leave spl 1, <2667 ;12 instructions leave mov.i }datsite, >datsite djn.b nope, #LEN spl.a cmper+MOVETO-1, >fini+1 clear mov.i traps, datsite ;hide pointers to self mov.i traps, -2 nope dat.f >(QDIFF*2), >(QDIFF*2) target dat.f #0, #QSTEP datsite dat.f adder, MOVETO ;the real cmp-hunter adder add.f spltrap, cmper ;increment pointers cmper cmp.i adder-DIFF-OPT, adder-OPT ;small scan distance slt.ab #LEN+BOMBS, cmper ;don't bomb ourself unless @adder djn.i adder, <-381 ;need to check -381 for better value setup mov.ab #BOMBS, traps ;set up djn line mov.i spltrap, }cmper ;bomb a-field traps djn.b -1, #0 sub.a #BOMBS, cmper ;reset scan line a-field jmz.i adder, adder-1 ;fall out when we bomb ourself spltrap spl.a #0-OPT, <0-OPT ;here and datadd after sweep make gate dosweep mov.i 1, I have the FAQ, the tutorial, and a doc. that came with pMARS, but I'm still confused. Does anyone know of a good beginner doc? Thanks From: estrathm@bu.edu (Eric Strathmeyer) Subject: Uuuuuummm? Date: 28 Feb 1995 22:13:39 GMT Message-ID: <3j076j$t02@news.bu.edu> I posted a message about ten minutes ago, and it was here. I came back, and it was gone? Is there a good reason for this?