From: durham@cup.portal.com (Mark Allen Durham) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Message-ID: <68717@cup.portal.com> Date: Sun, 1 Nov 92 11:23:14 PDT These are the Frequently Asked Questions (and answers) from rec.games.corewar as compiled by Mark A. Durham (durham@cup.portal.com). Last Update: November 1, 1992 TABLE OF CONTENTS ----------------- 1. What is Core War? 2. Is it Core War or Core Wars? 3. Where can I find more information about Core War? 4. What is the ICWS? 5. What is TCWN? 6. How do I join? 7. Are back issues of TCWNs available? 8. What is the EBS? 9. Where are the Core War archives? 10. Where can I find a Core War system for . . . ? 11. I do not have ftp. How do I get all of this great stuff? 12. I do not have access to Usenet. How do I post and receive news? 13. When is the next tournament? 14. What is KOTH? How do I enter? 15. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 16. Other questions? --------------------------------------------------------------------- Q1: What is Core War? A1: 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 possesion 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. ---------------------------------------------------------------------- Q2: Is it "Core War" or "Core Wars"? A2: 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. ---------------------------------------------------------------------- Q3: Where can I find more information about Core War? A3: 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 an anthology: 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 --------------------------------------------------------------------- Q4: What is the ICWS? A4: 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). --------------------------------------------------------------------- Q5: What is TCWN? A5: 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 on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q6: How do I join? A6: For more information about joining the ICWS (which includes a subscription to TCWN), 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 dues are $15.00 in US currency. If you wish to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please send it to me at Mark A. Durham 18 Honeysuckle Terrace Spartanburg, SC 29307-3760 email: durham@cup.portal.com ---------------------------------------------------------------------- Q7: Are back issues of TCWN available? A7: Back issues of the TCWN (up to Winter 1991) are available from AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 or contact William R. Buckley at xwbuckley@fullerton.edu. Prices are unknown at this time, but should be around $5.00 (the original cover price). More recent issues can be found on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q8: What is the EBS? A8: 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 will be 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 in preparation for the tenth anniversary of Core War in May of 1994. Its immediate business will be to set up a Charter and establish its officers. Contact me (see Q6) if you are interested in helping serve the EBS. ---------------------------------------------------------------------- A9: Where is the Core War archive? Q9: 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 soda.berkeley.edu (128.32.131.179) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. 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. ---------------------------------------------------------------------- Q10: Where can I find a Core War system for . . . ? A10: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are Unix X-Window, IBM PC-compatible (sorry, no systems specifically designed for MS-Windows yet), Macintosh, and Amiga Core War systems available there. 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 soda.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. Please post or email to me any review of any Core War system you have tried out so that others may learn from your experience. ---------------------------------------------------------------------- Q11: I do not have ftp. How do I get all of this great stuff? A11: 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. ---------------------------------------------------------------------- Q12: I do not have access to Usenet. How do I post and receive news? A12: The Usenet email server at ucbvax.berkeley.edu does not seem to be functioning at this time. I am trying to find alternate servers and verify their function. If anyone knows of any, please let me know so I can include it in the next FAQ. If you somehow receive rec.games.corewar but just can't post, you might try emailing your post to rec-games-corewar@cs.utexas.edu. Disclaimer: I have not verified that this works yet. ---------------------------------------------------------------------- Q13: When is the next tournament? A13: The 1992 Annual ICWS tournament will be held December 15th, 1992. The rules are currently ICWS'88, core size of 8192, maximum number of processes per warrior of 8000, and ties declared after 100 000 cycles. The format is round-robin. Scoring is three points per win, one point per tie, and no points for losses. To enter you must be a member of the International Core War Society or successfully participate in one of the Branch Section preliminary tournaments ("successfully" meaning finish in the top five/ten [see below]). Valid entries should be sent to Jon Newman either via email to jonn@microsoft.com of via mail on 3.5" disk (800K Mac or 720K IBM), 5.25" disk (720K IBM or 1.2MB IBM), or printed. Disk entries should be in a simple ASCII text format and on virus-free disks. ICWS Members may submit one entry or two entries if in electronic form. Branch Sections may submit five entries, or ten if in electronic form. Entries are limited to 50 instructions, 300 if in electronic form. No scatter loading will be supported (instructions must be contiguous). All entries become public domain on submission. The ICWS will keep them confidential until after the tournament has been completed. The EBS will hold its preliminary tournament November 15th, 1992. This is the last FAQ before the EBS tournament! The EBS is open to all persons with access to electronic mail. Please limit submissions to two unique entries. Send submissions to durham@cup.portal.com and clearly indicate their purpose (i.e. ;For November 15th, 1992 EBS preliminary tournament) as well as author, name, and contact address. The EBS rules are necessarily the same as the ICWS rules. ---------------------------------------------------------------------- Q14: What is KOTH? How do I enter? A14: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with email provided by William Shubert (wms@iwarp.intel.com). 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". If your program finished in the top twenty, it will remain on the hill until such time as it finishes twenty-first against another challenger, at which time it "falls off" the hill. 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 the line ";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 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 an hour or so you should get more mail telling you how your program performed against the current top 20 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 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. 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. Max entry length: 100 instructions Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. 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 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 rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. - A tie is not declared until 150,000 cycles per program have elapsed. KotH runs on any Unix system with an X windows interface. The source code to KotH is available by email from William Shubert. Write to him at (wms@iwarp.intel.com) for a copy or get it by anonymous FTP from soda.berkeley.edu in the pub/corewar/systems directory. ---------------------------------------------------------------------- Q15: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A15: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH) 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. ---------------------------------------------------------------------- Q16: Other questions? A16: Just ask. Either ask in the rec.games.corewar newsgroup or send your question(s) to me at durham@cup.portal.com. I will do my best to answer your question(s) or put you in touch with someone who can. Mark A. Durham MAD From: durham@cup.portal.com (Mark Allen Durham) Subject: Anniversary Message-ID: <68718@cup.portal.com> Date: Sun, 1 Nov 92 11:25:18 PDT Happy Anniversary! rec.games.corewar is celebrating its FIRST anniversary! It was established one year ago today. Mark A. Durham MAD durham@cup.portal.com From: durham@cup.portal.com Subject: Test Date: 1 Nov 1992 13:31:39 -0600 Message-ID: <9211011131.3.18782@cup.portal.com> This is a test of the Usenet mail server rec-games-corewar@cs.utexas.edu. From: paul@wolf.demon.co.uk (Paul Smith) Subject: PCRobots Date: Mon, 2 Nov 1992 00:22:53 +0000 Message-ID: <720681444snx@wolf.demon.co.uk> I just thought I'd announce this here, as there may be people interested and I can't think of any more suitable place... PCRobots is a program I wrote several months ago, it's an enhanced PC-only version of CRobots, but it'll run robots written using any standard DOS compiler/assembler (eg Borland C++, Turbo C++, Microsoft C, Turbo Pascal, QuickBasic, MASM etc). It has all the old CROBOTS functions, plus lots more for inter-robot communications, finding the way around a definable arena (rather than the plain open arena that CRobots was limited to). It also has a better graphical display - but this means you need an EGA or VGA display to use it. The program uses a cooperative multitasker to switch between robot tasks (which are .COM or .EXE files - this means that only certain functions (like scanning, moving or shooting) cause the next robot to run, so a robot can do complex calculations without being penalised. Also, because the programs are executables it means that they can be distributed without giving away all your algorithm secrets. An earlier version of this program was used as the basis for a competition run by a magazine in the UK (and they got an overwhelming response - literally...), so I thought I would make it available to the world at large. The original CRobots was intended as a learning aid to C - PCRobots *isn't* (you have been warned... :-) ). It should be available for anonymous FTP from ftp.demon.co.uk sometime soon (I've only just uploaded it there so I don't yet know what directory it will be in). Paul Smith -------------------------------------------------------------------- paul@wolf.demon.co.uk | psmithb@cix.compulink.co.uk | 100023.25@compuserve.com | | -------------------------------------------------------------------- From: sscdawso@medusa.itc.gu.edu.au (Glen Dawson) Subject: Please Ignore Test Only Message-ID: <1992Nov2.055350.13541@griffin.itc.gu.edu.au> Date: Mon, 2 Nov 92 05:53:50 GMT This is Only a test. Message-ID: Date: Mon, 2 Nov 92 14:51:09 MST From: $dougn@sasb.byu.edu (Douglas R. Nebeker - MIS_SAS) Subject: RED Code wanted Hello there! I've recently begun writing my own little warriors for corewars, but I think I'm using a non-standard system. I am very interested in getting in on this King of the Hill war, so I need to find a list of commands and syntaxes for KotH. I've looked at soda.berkley, but it looks like what I need is made for UNIX ( the .Z compression). I'm using a PC--so, is there a list of official corewar instructions in a simple text file anywhere?!? Please let me know!! THANKS! From: wms@ssd.intel.com (William Shubert) Subject: KotH 3.1 available Message-ID: <1992Nov2.184232.4776@iWarp.intel.com> Date: Mon, 2 Nov 1992 18:42:32 GMT I tried to send this before but didn't see it so I'm reposting; sorry if you get two copies. As the header states, there is a new version of King of the Hill ready. It's available by anonymous FTP to soda.berkeley.edu; currently it is in the directory "pub/corewar/incoming" but I expect that it will be moved to "pub/corewar/systems" eventually. The file name is "koth31.shar.Z". This new version has disassembly windows to aid debugging programs. It also should also be more portable since I finally ripped out the signal code and replaced it with calls to select() (I really really hope that select() isn't just a BSDism). KotH is the corewar simulator used to run the tournament. It also has an X windows interface and should run on almost any Unix/X11 system. -Bill (wms@ssd.intel.com) From: starr-daniel@yale.edu (Daniel Starr) Subject: Did anyone ever try parent's-cycles-only SPLs? Date: 3 Nov 1992 01:25:45 -0500 Message-ID: <1d5619INNc97@MINERVA.CIS.YALE.EDU> I've just discovered this group (and rediscovered Core Wars)... I was browsing through the digests, and discovered a very long thread about encouraging smarter (and necessarily longer) programs. In particular, everyone seemed to agree that one of the major problems with long programs is their vulnerability to SPL attacks, which not only are more likely to find them but also ruin the possibility of self-repair (unlike a simple DAT bomb) by freezing the program in its tracks. One of the suggested solutions I liked was: Give to each daughter process one-half of the cycles of the parent process (as opposed to 1/Nth of the total cycles of the warrior), so that a SPL 0 effectively just cuts off a given process (while holding onto its cycles) rather than affecting the speed of other forks; the SPL takes cycles from the process that was using them, not from the warrior as a whole. Recap for those who didn't see the thread: E.g., if we start with the execution pattern 1a, 2, 1b, 2, 1a, 2, 1b, 2, 1a... and 1b hits an SPL, instead of 1a, 2, 1ba, 2, 1bb, 2, 1a, 2, 1ba... (the usual: global shares) we go to 1a, 2, 1ba, 2, 1a, 2, 1bb, 2, 1a... (local shares) so that process 1a's share of cycles isn't affected by whether its sibling process splits or not; 1ba and 1bb share their parent 1b's cycles only. Further, if 1b had hit a SPL loop, further subdivisions wouldn't make a difference to 1a either... 1b is frozen, but only the cycles it originally had are taken, not 1a's. All you'd need (as someone noted) would be a binary tree; the root.left node would be warrior 1, root.right warrior 2. For each cycle one would start from the root and do (pardon my pseudocode) descend(THISNODE) { if terminal(THISNODE) execute(THISNODE); else { descend(THISNODE.THATNODE); if THISNODE.THATNODE == THISNODE.LEFTNODE THISNODE.THATNODE = THISNODE.RIGHTNODE; else THISNODE.THATNODE = THISNODE.LEFTNODE; } } And whenever a SPL is executed, the current node produces two daughters, with its THATNODE = LEFTNODE. This rules change would have two advantages that I can see, a practical one and a philosophical one: 1. It makes longer, smarter programs viable, since one SPL hit doesn't utterly ruin them... repair from SPL becomes workable. It naturally also encourages a more sophisticated use of SPLs. 2. It's a more logical treatment of SPLs because it doesn't require a process to have the global knowledge of which warrior owns it, merely the local knowledge of which process spawned it; in fact it lets us think of the two warriors themselves as the first two sibling processes, so the whole cycle- allocation system is symmetrical. (The current system is asymmetrical in that where you'd expect all processes to share equally in entire system resources, they only share within each warrior, which suggests that the (assumed) split into the two warrior processes is different from the splits produced by an SPL.) Anyway... did anyone ever try this? Has this ever been on the X-Hill? If not, do people think it's worth a try? -- -------------------------------------------------------------------- |Daniel Starr | "Wait! Wait! Maybe THIS will work!" | |dstarr@minerva.cis.yale.edu | | -------------------------------------------------------------------- From: hastings-matthew@yale.edu (Matthew Hastings) Subject: Re: the imp-ring problem Message-ID: <1d6jqeINNrj8@MINERVA.CIS.YALE.EDU> Date: 3 Nov 92 09:27:10 GMT One of the simplest tricks for beating the IMPs is to modify the core-clear bomb to be dat <2667,<-{some number so as to set up an IMP gate}. The modified bomb is much more effective at clearing partially stunned IMPs-it's used in Pale Shears4-accounting for the high score against Imprimus-(although I should note that PS4 should actually have a slight losing record instead of a slight winnning one-the KotH score is a minor statistical fluctuation-at least a total of about 500 battles here show that it should be more like 44-40 instead of 40-44). Pale Shears4 goes even further, modifying the dropped bomb to spl 0,<-10 {artifact resulting from setting up gate in the core clear} jmp -1,<2666 {to help further wipe out IMP by getting captured procs. to do something-note that jmp -1,<2667 is a _bad_ idea as it causes further on procs. of the IMP to release the trapped one, <2666 causes previous procs. to stall before hitting the trapped one}. From: pk6811s@acad.drake.edu Subject: the imp-ring problem Message-ID: <1992Nov3.083911.1@acad.drake.edu> Date: 3 Nov 92 14:39:11 GMT I know a lot of people are working on the imp-ring problem, (me too). Here are some ideas for experimentation. New bombs: dat <2666,<-2667 or sub <2666,<-2667 It is also easy to catch an imp by the tail with some kind of stun bomb, the problem is killing a complete layer before a new layer is formed. The points are so far apart that the standard sequential core clear isn't fast enough to catch them all in time. Maybe the answer is a clear routine like: mov bomb,ptr add #2667,ptr jmp -2 which will attack all three points (of a 3-point ring) at the same time. Some people are having success, though they are keeping pretty tight-lipped. Here is the latest round of scores for Imprimis, my own stone-ring combo. (%wins for Imprimis/%wins for opponent/%ties) Medusa's v1 53/34/13 Nazgul 27/38/35 anti-body 42/46/12 Impression v3 1/ 0/99 Pale Shears4 40/44/16 Agony 2.5 37/ 0/63 Winter Werewolf 28/27/45 Sauron 49/28/23 Sender of Eight 0/ 2/98 Atomic Sheep 7/ 1/92 B-scanners l.i.v. 57/21/22 Jehannum 76/18/ 6 PLASMA 18/10/72 Emerald 57/ 5/38 Nimbus 14/ 3/83 Kobold 6b 78/ 6/16 I tried a couple of variations on Imprimis, but could not improve the score, so put the original back up. It's presently in second or third place, behind Medusa's v1. I will publish the live version of Imprimis in time for people to have a shot at it before the tournament. Paul Kline pk6811s@acad.drake.edu From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: Imp-killing and more... Message-ID: Date: 3 Nov 92 16:06:42 GMT After a few attempts I find that ring/spiral-killing is much harder than I first thought... My thought-to-be imp-killing vampire 'Jehannum' really doesn't do well at all againts the newest spiral/dwarves. (And I have to admit I don't quite understand why...). It is pretty much a standard vampire with the main loop modified to do imp-stomping at the same time: bait jmp pit, 0 . . . loop add const, bait mov bait, Date: Tue, 3 Nov 1992 18:24:06 GMT Daniel Starr asks whether an SPL variant that splits the parent's cycles (instead of group sharing) was tried. Yes, for a time the x-hill was run that way. It was finally scrapped because it just didn't produce interesting programs. It seemed like a great idea, but the final result (as I remember; maybe I'm wrong here) was that something like 1/4th of the hill were imp/ imp-stomper combinations. Maybe people didn't try hard enough, but it really just didn't work out to be all that interesting so I finally even ripped the code out of KotH that did that. I was pretty disappointed. I really liked the idea, it just didn't seem to pan out. -Bill (wms@ssd.intel.com) From: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) Subject: ShotGun 1.00 [X-hill source] Message-ID: <1992Nov3.231735.20356@unlv.edu> Date: Tue, 3 Nov 92 23:17:35 GMT It just occured to me that I haven't posted any source lately. Here's Shotgun 1.00, which came onto the hill at third place, and has dropped to 4th with the advent of Corona. The concept is similar to Loki, but where Loki places the empasis on the ambusher, rather than the jumper, Shotgun has no ambusher, and relies on the jumper for just about all of its offensive ability. ;redcode-x ;name Shotgun 1.00 ;author Eric J. Schwertfeger ;strategy A Jumper with monitor. Jumper bombs with ;strategy JMP PIT instructions, where pit is ;strategy (SPL 0,2;MOV -1,>-1), you figure it out. ;strategy monitor kills jumper after 3 passes, and starts ;strategy core clear. ;strategy v 1.00 Finally got the obvious bugs worked out :-) ;strategy Submitted: @date@ ;kill Shotgun 0.80 STEP EQU 240 OFFS EQU 10 INC EQU 30 CSTEP EQU 24 RSTEP EQU -24 RLAUNCH MOV #-250-6+RSTEP,RBDST-RSTEP MOV #2+(RSTEP*2),RCDST-RSTEP MOV #-250-6+RSTEP,RBDST MOV #2+(RSTEP*2),RCDST SPL 1 SPL 1 SPL 1 JMP RCSRC DAT 0,0 DAT 0,0 DAT 0,0 RCSRC MOV #8,#0 MOV RBDST-RSTEP,>RBDST-RSTEP MOV RBDST-RSTEP,>RBDST-RSTEP MOV RBDST-RSTEP,>RBDST-RSTEP MOV 0,@BOMBS JMP LOOP+STEP TRAP SPL 0,2 MOV -1,>-1 LAST DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 DAT 0,0 CLAUNCH SPL RLAUNCH MOV #250-8+CSTEP,CBDST-CSTEP MOV #2+(CSTEP*2),CCDST-CSTEP MOV #250-8+CSTEP,CBDST MOV #2+(CSTEP*2),CCDST SPL 1 SPL 1 SPL 1 JMP CCSRC DAT 0,0 CCSRC MOV #8,#0 MOV CBDST-CSTEP, Date: 3 Nov 92 23:58:22 GMT JMP 0, /* Sender: W. Mintardjo (wangsawm@prism.cs.orst.edu) */ main() { printf(".sig? what's .sig?\n"); } From: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) Subject: Re: Imp-killing and more... Message-ID: <1992Nov4.013115.25408@unlv.edu> Date: Wed, 4 Nov 92 01:31:15 GMT In article , d91andiv@IDA.LiU.SE (Anders Ivner) writes: ) From: d91andiv@IDA.LiU.SE (Anders Ivner) ) After a few attempts I find that ring/spiral-killing is much harder ) than I first thought... ) ) My thought-to-be imp-killing vampire 'Jehannum' really doesn't do ) well at all againts the newest spiral/dwarves. (And I have to admit ) I don't quite understand why...). It is pretty much a standard vampire ) with the main loop modified to do imp-stomping at the same time: ) ) bait jmp pit, 0 ) . ) . ) . ) loop add const, bait ) mov bait, Date: Wed, 4 Nov 92 02:08:06 GMT Snare uses what I call a passive defense system, that is, it lays down a pattern that traps the 2 instruction, two process decoy that I used to be so fond of. The trap consists of a large pattern of SPL 0,4 JMP -1,3 SPL 0,4 JMP -1,3 SPL 0,4 JMP -1,3 SPL 0,4 JMP -1,3 And on and on. Snare copies the trap, until it ois over 200 cells long. Now lets examine what happens when this DSTEP EQU (200) LAUNCH SPL DECOY DJN 0,#80 JMP START DECOY SPL 1 MOV Date: Wed, 4 Nov 1992 15:13:54 GMT In article <1992Nov4.013115.25408@unlv.edu>, maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) writes: > > It's likely that none are getting past bait, but since they're writing large > distances ahead, they don't have to get past it, unless bait is a large distance > from the main body, the imp ring will overwrite your code before getting to > bait. > I would guess a likely explanation is that the stone component is too strong. The stone in Imprimis gets nearly all the cycles in the early battle, and is of the Emerald class, bombing/mutating at 133% of c. Your pit-viper writes bombs at 33% of c, a 4-to-1 deficit. Note that a decrement in your code leaves you wide open for imp attack. Suggest you change the loop line to: loop add const, @2 which will harden it against a single decrement. Paul Kline pk6811s@acad.drake.edu From: pk6811s@acad.drake.edu Subject: Imprimis - "in the first place" Message-ID: <1992Nov4.094802.1@acad.drake.edu> Date: Wed, 4 Nov 1992 15:48:02 GMT There are at least two programs now prevailing against Imprimis, so here is the code. Let everyone in on the fun. And if Cisek, Strack, and Campbell see something in there that they think is unfair, my deepest apologies. NOT! ;redcode ;name Imprimis ;kill Imprimis ;author P.Kline d equ 2667 datzero equ inc-5 inc dat #0-2365,#2365 emerald spl 0 stone mov Date: Wed, 4 Nov 1992 16:42:52 GMT Well, I'm a few days late, but hey. Again, a bunch of imp spirals, but they don't dominate the hill like they did at one time. # %W/ %L/ %T Name Author Score Age 1 42/ 17/ 41 Imprimis P.Kline 168 10 2 39/ 22/ 39 Impression v3 Dan Nabutovsky 157 113 3 46/ 42/ 13 Emerald P.Kline 149 12 4 43/ 40/ 17 Sauron Matt Hastings 145 33 5 45/ 46/ 10 Medusa's v1 W. Mintardjo 143 31 6 43/ 44/ 12 Jehannum Anders Ivner 142 27 7 36/ 30/ 35 The Sender of Eight Matt Hastings 142 256 8 41/ 44/ 15 Grimm's Vampyre c w blue 139 14 9 39/ 40/ 21 Agony 2.5 M. Hastings & S. Str 139 209 10 42/ 46/ 11 anti-body nandor sieben 139 121 11 42/ 46/ 12 Nazgul Anders Ivner 138 37 12 40/ 42/ 17 B-scanners live in vain Hastings&Mintardjo 138 185 13 38/ 38/ 24 Winter Werewolf W. Mintardjo 138 234 14 41/ 46/ 12 No More Mucking About Campbell Fraser 136 13 15 34/ 33/ 33 Atomic Sheep c w blue 136 384 16 39/ 43/ 18 Charon (hates imps) J.Cisek & S.Strack 135 4 17 38/ 41/ 21 Pale Shears4 Matt Hastings 134 26 18 32/ 33/ 34 Escalation P.Kline 132 7 19 38/ 47/ 15 Test Warrior from Hell c w blue 129 1 20 38/ 49/ 13 cproba nandor sieben 128 6 Imprimis, the #1 program, has been posted here; good thing, it has no ";strategy" lines. On the x-hill, the #1 program is "Corona", another imp ring. 1 45/ 10/ 45 Corona 1.1 Alex MacAulay 180 5 2 45/ 27/ 28 Shotgun 1.00 Eric J. Schwertfeger 163 19 3 46/ 31/ 23 Sonic Boom 2.40 Eric J. Schwertfeger 161 17 4 42/ 24/ 33 Sledge 1.3 Alex MacAulay 160 59 5 43/ 30/ 27 Scorpion 3.3 Alex MacAulay 155 112 6 45/ 35/ 20 Snare 1.00 Eric J. Schwertfeger 155 18 7 34/ 22/ 43 Edge 1.1 Alex MacAulay 146 113 8 29/ 15/ 56 Springer 1.1 Alex MacAulay 142 11 9 28/ 18/ 54 impo-x nandor sieben 139 1 10 30/ 23/ 46 El Papel Unknown 138 37 11 38/ 44/ 18 Loki 2.50 Eric J. Schwertfeger 132 26 12 37/ 46/ 18 Halberd 1.70 Eric J. Schwertfeger 127 61 13 34/ 45/ 21 Deep Green Sea Pierre Baillargeon 123 83 14 34/ 46/ 20 Scylla and Charybdis V1.0 Jeff Berry 122 84 15 21/ 21/ 58 Sigil Matt Hastings 120 185 16 35/ 54/ 11 Fence Leaper-X 1.0 Jeff Raven 115 93 17 19/ 23/ 58 Time Machine X4.2 Pierre Baillargeon 114 6 18 18/ 25/ 58 Troll 2.1 Dan Nabutovsky 111 51 19 20/ 32/ 48 Trap 6 Kent Peterson 108 8 20 20/ 36/ 45 LongWorm 1.2 Dan Nabutovsky 104 54 Corona's strategy: ;strategy Creates a 63-point 2-process ring, waits, then sends out a ;strategy core-clear which kills off the ring and the subverted enemy. ;strategy 1.1 - Uses core-clear instead of jumper - better vs replicators. As usual, KotH source code is available from soda.berkeley.edu. Submission instructions are in the FAQ or available from me via email. -Bill (wms@ssd.intel.com) From: achamber@cs.weber.edu (Tony Chamberlain) Subject: Koth and X-hill Message-ID: <1992Nov4.181127.9694@fcom.cc.utah.edu> Date: Wed, 4 Nov 92 18:11:27 GMT I've noticed both references to koth and X-hill, and i realize both are competetions but what is the difference between the two. I thought they were pretty much the same thing till I saw the post with 2 different standings for each one. Can a program but submitted to both? Or are the so different that isn't feasible... Thanx in advance for the info, Tony Chamberlain achamber@cs.weber.edu From: maniac@unlv.edu (Eric J. Schwertfeger) Subject: Re: Koth and X-hill Message-ID: <1992Nov4.202937.2760@unlv.edu> Date: Wed, 4 Nov 92 20:29:37 GMT In article <1992Nov4.181127.9694@fcom.cc.utah.edu> achamber@cs.weber.edu (Tony Chamberlain) writes: >I've noticed both references to koth and X-hill, and i realize both are >competetions but what is the difference between the two. I thought they >were pretty much the same thing till I saw the post with 2 different standings >for each one. Can a program but submitted to both? Or are the so different >that isn't feasible... The major difference between the Standard hill and the X-Hill is that the X-Hill imposes a write limit on any write. An instruction cannot modify any cell more than 250 away from itself. Simple enough. This causes several effects. Programs must move in order to do well. Not the entire program must move as Spider clearly demonstrated, however. You also have more time to react to attacks, because while you can scan all of core, you can't be attacked by anything not within the write limit. As to which is better, I'd say that the standard hill promotes more programming tricks, but the X-Hill promotes more ideas. This is almost any programming trick that applies to the Hill can be applied to the X-Hill, but ideas that depend on the write-limit to protect them while setting up will fail miserably on the Standard hill, because they will get hit long before they get close. When "The Impire Strikes back" was rewritten for the X-Hill, it didn't do nearly as well as on the standard hill, so the x-Hill is competitive. The X-Hill is generally easier to make, though, because of reduced competition. I gave up on the standard hill after everyone eliminated a weakness that I was taking advantage of, and haven't had a program higher than 18th since then. On the X-Hill, I have so many high programs I sometimes think that we need a third hill, just for Alex and I :-) Anyway, I posted a long tutorial a few months back on the differences, including what strategies worked well on the X-Hill. I have a copy somewhere, which I'll mail to you if you are interested. -- Eric J. Schwertfeger, maniac@cs.unlv.edu From: cowan@cerianthus.pinetree.org (Darin Cowan - root) Subject: Corewars on a PC Message-ID: Date: Thu, 05 Nov 92 12:42:43 GMT Is a DOS version of corewars still available? I used to have it but can't find it any more... Message-ID: <#|#@byu.edu> Date: Thu, 5 Nov 92 15:46:50 MST From: $dougn@sasb.byu.edu (Douglas R. Nebeker - MIS_SAS) Subject: Re: Corewars on a PC In article cowan@cerianthus.pinetree.org (Darin Cowan - root) writes: >Subject: Corewars on a PC >From: cowan@cerianthus.pinetree.org (Darin Cowan - root) >Date: Thu, 05 Nov 92 12:42:43 GMT >Is a DOS version of corewars still available? I used to have it but can't >find it any more... > I got a cool graphical one from a university in Indiana. It is NOT ICWS compliant though (for one thing, it has a random instruction). Still, it's fun to watch what is going on. If you're interested, let me know and I'll find the ftp address. ____ Douglas R. Nebeker Internet: $dougn@sasb.byu.edu Message-ID: <+|#@byu.edu> Date: Thu, 5 Nov 92 16:58:33 MST From: $dougn@sasb.byu.edu (Douglas R. Nebeker - MIS_SAS) Subject: Max DAT Value Hi there, fellow warriors! What is the maximum value a DAT can hold? I've read the FAQ, the tutor and the ICWS 86 and 88 standards, but haven't run across this yet. Also, what does DAT #0, #0 do? (How can a DAT hold two values?) THANKS ____ Douglas R. Nebeker Internet: $dougn@sasb.byu.edu Subject: Re: Max DAT Value Message-ID: <1992Nov6.183106.2476@drycas.club.cc.cmu.edu> From: KENT@dirac.physics.jmu.edu (Kent Peterson) Date: 6 Nov 92 18:31:05 -0500 In <+|#@byu.edu> $dougn@sasb.byu.edu writes: > Hi there, fellow warriors! Hi. > What is the maximum value a DAT can hold? The size of the core minus one. Therefore, this will vary depending on what coresize you're playing with - for example in a coresize of 8192, the maximum value would be 8191, and in a coresize of 8000, the maximum value would be 7999. These would both be treated as -1 for all practical purposes. However, this does not mean that you cannot add a number to this value; the result will be the remainder gotten after division by the coresize. For instance, adding 456 to 7999 in a coresize of 8000 would give you 8455, which gets turned into 455. > Also, what > does DAT #0, #0 do? (How can a DAT hold two values?) It doesn't do anything, except kill any process that tries to execute it. DATs have A- and B-fields just like all other Redcode instructions, however "ADD #x, y", "SUB #x, y", and pre-decrement only change the B-field. To change the A-field, you need to add or subtract an entire instruction to the DAT, like "ADD x, y" or "SUB x, y". Also, indirect addressing uses only the B-field. For these reasons, when DATs are used as pointers, it is often easier to use only the B-field and ignore the A-field. Kent Peterson From: cowan@cerianthus.pinetree.org (Darin Cowan - root) Subject: Re: Corewars on a PC Message-ID: Date: Fri, 06 Nov 92 21:04:45 GMT $dougn@sasb.byu.edu (Douglas R. Nebeker - MIS_SAS) writes: > > I got a cool graphical one from a university in Indiana. It is NOT ICWS > compliant though (for one thing, it has a random instruction). Still, it's > fun to watch what is going on. If you're interested, let me know and I'll > find the ftp address. > Sounds interesting. Let me know where I can pick it up... thanks From: vwulpen@cs.kuleuven.ac.be (Henk Van Wulpen) Subject: SLT Message-ID: <1992Nov8.195147.29858@cs.kuleuven.ac.be> Date: 8 Nov 92 19:51:47 GMT Hello, after having read a lot of stuff about Core War (all doc from soda, and I've started reading all digests !!!), I have the following question. How does SLT exactly work ???? I mean, how can one number be less than an other one !!??? Since Core is circular, all addresses are to be interpreted as modulo CORESIZE. But as far as I know comparison isn't defined in modulo- calculus. Is it just that all addresses should be converted to the range of 0..CORESIZE-1, and then compare these representations ? Another question concerns the tournaments. Can a program be entered in both KotH and the EBS preliminaries ??? Thanks. Henk. ----------------------------------------------------------------------------- Henk Van Wulpen | Words and eggs must be handled with care. Engineering and Computer Science | Once broken they are impossible senior at the K.U.Leuven | things to repair. vwulpen@cs.kuleuven.ac.be | (Anne Sexton, The Awful Rowing Toward God) ----------------------------------------------------------------------------- Message-ID: <&}#@byu.edu> Date: Mon, 9 Nov 92 14:49:11 MST From: $dougn@sasb.byu.edu (Douglas R. Nebeker - MIS_SAS) Subject: Re: Corewars on a PC >$dougn@sasb.byu.edu (Douglas R. Nebeker - MIS_SAS) writes: > >> >> I got a cool graphical one from a university in Indiana. It is NOT ICWS >> compliant though (for one thing, it has a random instruction). Still, it's >> fun to watch what is going on. If you're interested, let me know and I'll >> find the ftp address. >> > >Sounds interesting. Let me know where I can pick it up... > >thanks > The graphical version was from (I believe) ftp.cica.indiana.edu , and CorewarPro (or something like that) is available as corwpXX.lzh from soda. berkley.edu. CorewarPro isn't as good graphically as the program from indiana, but it can be ICWS 86, 88 or even X-Hill compatible. It has a built in editor, core inspector, etc. CorewarPro is the best all around system for the PC that I've come across yet (but the graphics aren't that great). Good Luck ____ Douglas R. Nebeker Internet: $dougn@sasb.byu.edu From: xyzzy@mertwig.UUCP (Daniel Drucker) Subject: latest version for MS-DOS Message-ID: Date: Mon, 09 Nov 92 19:42:04 EST Could someone please uuencode and send to me the latest corewars interpreter or whatever it is the runs the programs (i'm a beginner) through email? Please ask first so I don't get swamped. mertwig!xyzzy@jaflrn.uucp or utoday!jaflrn!mertwig!xyzzy@uunet.uu.net thanx Daniel Max P. Drucker | #define SLOGAN Hey! Lets port it to COBOL! The 14 year old LISP/C++ genius. | Disclaimer: I don't know COBOL. /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\/~\/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ / Difficulty! It's the single simplest machine in the entire Universe! \ \__________________________________________________________________________/ / Is there anyone out there in net.land in Port Washington, New York? \ \______a m a t e u r____r a d i o____c a l l s i g n____p e n d i n g______/ From: vwulpen@cs.kuleuven.ac.be (Henk Van Wulpen) Subject: Re: Corewars on a PC Message-ID: <1992Nov9.223928.24097@cs.kuleuven.ac.be> Date: 9 Nov 92 22:39:28 GMT In article <&}#@byu.edu>, $dougn@sasb.byu.edu (Douglas R. Nebeker - MIS_SAS) writes: |> >$dougn@sasb.byu.edu (Douglas R. Nebeker - MIS_SAS) writes: |> > |> >> |> >> I got a cool graphical one from a university in Indiana. It is NOT ICWS |> >> compliant though (for one thing, it has a random instruction). Still, it's |> >> fun to watch what is going on. If you're interested, let me know and I'll |> >> find the ftp address. |> >> |> > |> >Sounds interesting. Let me know where I can pick it up... |> > |> >thanks |> > |> The graphical version was from (I believe) ftp.cica.indiana.edu , and |> CorewarPro (or something like that) is available as corwpXX.lzh from soda. |> berkley.edu. CorewarPro isn't as good graphically as the program from |> indiana, but it can be ICWS 86, 88 or even X-Hill compatible. It has a |> built in editor, core inspector, etc. CorewarPro is the best all around |> system for the PC that I've come across yet (but the graphics aren't that |> great). |> |> Good Luck |> |> ____ |> |> Douglas R. Nebeker Internet: $dougn@sasb.byu.edu The only problem with it is that it is incredibly slow, especially when lots of processes are SPLit off. I believe it is because it was written in Prolog, and therefore handles linked lists (the process-queues) in a very inefficient way. Actually, I already got an error message (from the program) saying that a system error occured. I think it is because the program ran out of memory trying to create a new item in the queue. Possibly the program doesn't deallocate the space of killed processes. The same problem occurs with KotH for PC. As long as the number of rounds played is reasonably low and there aren't many SPLs, the program runs ok. But with too many rounds or process-creation, the program halts saying that it ran out of memory creating a new thread. Since increasing the number of rounds should have no effect on the use of memory, I guess that also here the problem is that memory isn't freed upon removal of items in the queue. Just my opinions though. Any comments of the authors ??? Henk. ----------------------------------------------------------------------------- Henk Van Wulpen | Words and eggs must be handled with care. Engineering and Computer Science | Once broken they are impossible senior at the K.U.Leuven | things to repair. vwulpen@cs.kuleuven.ac.be | (Anne Sexton, The Awful Rowing Toward God) ----------------------------------------------------------------------------- Subject: test Message-ID: <1992Nov10.073652.1@musctn.monsanto.com> From: cdmcke@musctn.monsanto.com Date: 10 Nov 92 07:36:52 GMT test From: sfdijk@cs.ruu.nl (Steven van Dijk) Subject: FAQlist request Message-ID: <1992Nov10.083233.1559@cs.ruu.nl> Date: Tue, 10 Nov 1992 08:32:33 GMT Hi everybody, can someone send me a FAQ-list concerning corewar? It might prevent some 'stupid' questions (like: 'what IS corewars?' ;-)). -- CU ZVD ------------------------------------------------------------------------------ From: keong@ecr.mu.OZ.AU (Wee-Keong LIM) Subject: Re: SLT Message-ID: <9231710.16573@mulga.cs.mu.OZ.AU> Date: Wed, 11 Nov 1992 23:47:45 GMT In article <1992Nov8.195147.29858@cs.kuleuven.ac.be> ( number 1456 to me ) Henk Van Wulpen writes: > after having read a lot of stuff about Core War (all doc from soda, and > I've started reading all digests !!!), I have the following question. How > does SLT exactly work ???? I mean, how can one number be less than an other > one !!??? Since Core is circular, all addresses are to be interpreted as > modulo CORESIZE. But as far as I know comparison isn't defined in modulo- > calculus. Is it just that all addresses should be converted to the range > of 0..CORESIZE-1, and then compare these representations ? As I understand the SLT command, the numbers in the fields should be treated as the appropriate kind of address. The values that are compared are the B-field values at the specified addresses. For example, SLT 1, 2 would check whether the B-field value in location 1 is less than the B-field value in location 2 ( relative to the current location, of course ). The indirect, and predecrement indirect have the usual meanings. The only other restriction is that immediate values ( e.g. #5 ) can only be in the A-field. I'm not sure why, since it still makes sense to comare the value at some location in A-field with the immediate value given in the B-field. In any case, using immediate mode is the only case where the actual numbers in the fields are used in the comparison. I'm not sure how this confusion arose, since this is how I interpreted the docs ( I usually just refer to the '88 standard ). Oh well, I had trouble too - I read the docs about 5 times before I understood it :-). I'm glad to have some discussion about the specs. Is there any movement towards a new specification ( or a refinement of the old ones ) ? I'd be interested to know. Thanks, in advance. Keong. +-----------------------------------------------------------------------------+ |e-mail: keong@ecr.mu.oz.au University of Melbourne, Melbourne, Australia. | | | | "The difficult we can do right away, the impossible takes a little longer." | | Hence, "Nothing is Impossible" | +-----------------------------------------------------------------------------+ +-----------------------------------------------------------------------------+ |e-mail: keong@ecr.mu.oz.au University of Melbourne, Melbourne, Australia. | From: vwulpen@cs.kuleuven.ac.be (Henk Van Wulpen) Subject: Re: SLT Message-ID: <1992Nov12.163801.29914@cs.kuleuven.ac.be> Date: Thu, 12 Nov 1992 16:38:01 GMT In article <9231710.16573@mulga.cs.mu.OZ.AU>, keong@ecr.mu.OZ.AU (Wee-Keong LIM) writes: |> |> |> In article <1992Nov8.195147.29858@cs.kuleuven.ac.be> ( number 1456 to me ) Henk |> Van Wulpen writes: |> |> |> > after having read a lot of stuff about Core War (all doc from soda, and |> > I've started reading all digests !!!), I have the following question. How |> > does SLT exactly work ???? I mean, how can one number be less than an other |> > one !!??? Since Core is circular, all addresses are to be interpreted as |> > modulo CORESIZE. But as far as I know comparison isn't defined in modulo- |> > calculus. Is it just that all addresses should be converted to the range |> > of 0..CORESIZE-1, and then compare these representations ? |> |> |> As I understand the SLT command, the numbers in the fields should be |> treated as the appropriate kind of address. The values that are compared are the |> B-field values at the specified addresses. |> |> For example, SLT 1, 2 would check whether the B-field value in location 1 |> is less than the B-field value in location 2 ( relative to the current location, |> of course ). The indirect, and predecrement indirect have the usual meanings. |> The only other restriction is that immediate values ( e.g. #5 ) can only be in |> the A-field. I'm not sure why, since it still makes sense to comare the value at |> some location in A-field with the immediate value given in the B-field. |> Well that isn't exactly what my problem is... Take the following code for instance : JMP lbl, #-1 DAT #0, #0 SLT -1, -2 Now, the SLT compares #0 to #-1, but is #0 less than or greater than #-1 ??? Is #-1 converted to CORESIZE-1 ??? Or does the comparison evaluate as true (i.e. #-1 is less than #0) ? Henk. From: sah@castle.ed.ac.uk (Juggler) Subject: Re: Corewars on a PC Message-ID: <28067@castle.ed.ac.uk> Date: 12 Nov 92 16:49:01 GMT vwulpen@cs.kuleuven.ac.be (Henk Van Wulpen) writes: >The only problem with it is that it is incredibly slow, especially when >lots of processes are SPLit off. I believe it is because it was written >in Prolog, and therefore handles linked lists (the process-queues) in a >very inefficient way. Actually, I already got an error message (from the >program) saying that a system error occured. I think it is because the >program ran out of memory trying to create a new item in the queue. >Possibly the program doesn't deallocate the space of killed processes. >The same problem occurs with KotH for PC. As long as the number of rounds >played is reasonably low and there aren't many SPLs, the program runs ok. >But with too many rounds or process-creation, the program halts saying that >it ran out of memory creating a new thread. Since increasing the number of >rounds should have no effect on the use of memory, I guess that also here the >problem is that memory isn't freed upon removal of items in the queue. >Just my opinions though. Any comments of the authors ??? I'll second that. I suffer from the choice of painstakingly loading my programs into Corewars pro, and having to wait for 20 - 30 minutes for a result - and that's on a 486 - or setting the koth process limit to 600, which makes some of the spl 0 killing routines I'm attempting to design inaccurate. What's more, the debugging facilities of Corewars pro are completely brill, so having to wait for 5 minutes in order to use them to fine-tune code (or to find that *invisible* bug thats mysteriously fouling up your groundbreaking new 200%xC scanner+replicator+bomber+imp) is nail-shreddingly frustrating (well, actually, that's exaggerating a bit. I usually just nip off for a cup of tea). Are there any *fast* PC redcode processors with debugging facilities? Talking of frustration, whenever I try to perfect my 200%xC scanner+etc (see above), it moves through various incarnations until it's perfect, at which stage I usually realise that it's actually just Emerald (or Nomuckingabout or Imprimis or whatever) with a couple of numbers changed. All my wholly original codes get completly gubbed by the "state of the net" ones (why didn't *I* think of impire :-(). In the true style of most research, I'm therefore limiting my search for novelty to one (1) original line in any new redcode. With this groundbreaking new design methodology, I've just sent my latest and greatest offering to koth (it's called SlowWorm, 'cause it's slow, and it keeps getting trodden on), with the objective of breaching that psychological 80 points barrier, which should put it on the hill in around 35th position... Watch me scale those (largely) unconquered heights! Si. xxx -- S.A.Hovell,Dept. Electrical Engineering,University of Edinburgh,U.K. (+31) 650-5655 (Juggler@ed.ac.uk) ----- ----- Subject: Re: SLT Message-ID: <92317.183133JAR129@psuvm.psu.edu> From: Jeff Raven Date: Thu, 12 Nov 1992 18:31:33 EST >Well that isn't exactly what my problem is... Take the following code for >instance : > JMP lbl, #-1 > DAT #0, #0 > SLT -1, -2 >Now, the SLT compares #0 to #-1, but is #0 less than or greater than #-1 >??? >Is #-1 converted to CORESIZE-1 ??? Or does the comparison evaluate as true >(i.e. #-1 is less than #0) ? In corewars, there is no such thing as a negative value - all arithmetic is done modulo CORESIZE. When the above commands are assembled, the lines will become (assuming CORESIZE = 8000) : JMP lbl, #7999 DAT #0, #0 SLT 7999, 7998 Therefore, the comparison will be between 0 and 7999. Then the SLT will evaluate as true since 0 < 7999. The modulo arithmetic applies to every command - so one DAT #2 two DAT #1 SUB one, two will change things to one DAT #2 two DAT #7999 SUB one, two Answer your question? Jeff Raven jar129@psuvm.psu.edu From: pk6811s@acad.drake.edu Subject: Re: Original and Copycatting Message-ID: <1992Nov12.133836.1@acad.drake.edu> Date: Thu, 12 Nov 1992 19:38:36 GMT In article <28067@castle.ed.ac.uk>, sah@castle.ed.ac.uk (Juggler) writes: > > Talking of frustration, whenever I try to perfect my 200%xC > scanner+etc (see above), it moves through various incarnations until > it's perfect, at which stage I usually realise that it's actually just > Emerald (or Nomuckingabout or Imprimis or whatever) with a couple of > numbers changed. All my wholly original codes get completly gubbed by > the "state of the net" ones (why didn't *I* think of impire :-(). In the > true style of most research, I'm therefore limiting my search for > novelty to one (1) original line in any new redcode. With this > groundbreaking new design methodology, I've just sent my latest and > greatest offering to koth . . . One of the risks of publishing a good program is that others will make a minor change to it and send it up. Almost immediately after publishing Imprimis a couple of *presumably-similar* programs appeared (Plasma Sheep and - oh what's the name of that other one - +1 Tearjerker or something). But in the long run, that's not really a problem. The more versions of similar programs that get put up, the more likely someone will write a program that attacks just those programs successfully and move them down the ladder. Then someone will work out an improvement on the base design that differentiates their version, and that gets everyone going again. For example, Flash Paper was very successful over the summer, until some act-alikes made their way onto the hill. It couldn't beat them so its' own score began to slide. Eventually, even Matt took another look at the program and worked out an improvement. First introductions of new concepts are usually open for major improvements - witness Impire. Of course no one wants 20 versions of Imprimis or Emerald or ScamScan or whatever, so everybody continues to work on improving the designs of all (now) four types of fighters - bombers, scanners, replicators, and imps. Each has a natural advantage over at least one of the others and can be improved to do better against the rest. For the continuing good of the game, we need to see more good code published. Maybe next week, after the EBS tourney, folks will open up a bit? Please? Paul Kline pk6811s@acad.drake.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Corewars on a PC Message-ID: Date: Thu, 12 Nov 1992 20:45:09 GMT In article <1992Nov9.223928.24097@cs.kuleuven.ac.be> vwulpen@cs.kuleuven.ac.be (Henk Van Wulpen) writes: >[Speaking about CoreWar Pro] >The only problem with it is that it is incredibly slow, especially when >lots of processes are SPLit off. I believe it is because it was written >in Prolog, and therefore handles linked lists (the process-queues) in a >very inefficient way. Actually, I already got an error message (from the >program) saying that a system error occured. I think it is because the >program ran out of memory trying to create a new item in the queue. >Possibly the program doesn't deallocate the space of killed processes. >The same problem occurs with KotH for PC. As long as the number of rounds >played is reasonably low and there aren't many SPLs, the program runs ok. >But with too many rounds or process-creation, the program halts saying that >it ran out of memory creating a new thread. Since increasing the number of >rounds should have no effect on the use of memory, I guess that also here the >problem is that memory isn't freed upon removal of items in the queue. >Just my opinions though. Any comments of the authors ??? > >Henk. As the author of CoreWar Pro and the "porter" of KotHPC I oughta reply to this. And yes, my name and email address is listed prominently in the doc's to both packages. Anyway, Henk is right, CoreWar Pro is slow because it is written in Prolog (PDC Prolog, former Turbo Prolog to be exact). No remedy for that unless I get the funds for the lastest version of the compiler (3.3) which has an array datatype (makes for a much more efficient implemetation of the process queue). As for KotHPC, the reason that the programs bombs earlier when "rounds" is high is that the free() in Turbo C 1.5/2.0 is not 100% efficient. Hope this helps, Stefan (stst@vuse.vanderbilt.edu) P.S.: Those in need of a speedy, good-looking PC version of corewar that has reasonable debugging features should check out Nandor Sieben's MARS. I had the pleasure to try out an alpha-version of V2.0 and it looks good. I don't know if Nandor uploaded the latest version to soda yet. Nandor? From: durham@cup.portal.com (Mark Allen Durham) Subject: EBS Tournament Message-ID: <69418@cup.portal.com> Date: Thu, 12 Nov 92 21:33:20 PST Dear Core War Enthusiasts, This is your LAST CALL for submitting Redcode warriors to the Electronic Branch Section's Qualifying Tournament. Deadline for submissions is November 15, 1992. (If you did not see this message until after the deadline and still want to submit, I am willing to accept legitimate latecomers). To submit, send your warrior to durham@cup.portal.com. Be sure to include your email contact address. The top-ten finishers will advance to the annual ICWS tournament. All may enter, but non-ICWS members will be given preference for advancement since ICWS members may submit their programs individually. Contest rules follow: The rules are ICWS'88, core size of 8192, maximum number of processes per warrior of 8000, and ties declared after 100 000 cycles. The format is round-robin. Scoring is three points per win, one point per tie, and no points for losses. Entries are limited to 300 instructions (excludes comments, blank lines, etc.). No scatter loading is supported (instructions must be contiguous). All entries become public domain on submission. The ICWS will keep them confidential until after the tournament has been completed. Questions to me: Mark A. Durham durham@cup.portal.com From: jrauser@staff.tc.umn.edu (Johnny R.) Subject: The crobots guy Message-ID: Date: Fri, 13 Nov 1992 05:22:51 GMT Hello all, I would very much like to get in touch with the author of crobots, Tom Poindexter. Do any of you know if he has an email address, or know if his 1988 US Mail address is still correct? Thank you for any and all help, John -- John Rauser jrauser@staff.tc.umn.edu jmr@ddt.biochem.umn.edu mf12003@sc.msc.edu From: durham@cup.portal.com (Mark A. Durham) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 13 Nov 1992 06:00:34 GMT Message-ID: Archive-name: corewar-faq Last-modified: 1992/11/11 Version: 1.2 These are the Frequently Asked Questions (and answers) from rec.games.corewar as compiled by Mark A. Durham (durham@cup.portal.com). Last Update: November 11, 1992 TABLE OF CONTENTS ----------------- 1. What is Core War? 2. Is it Core War or Core Wars? 3. Where can I find more information about Core War? 4. What is the ICWS? 5. What is TCWN? 6. How do I join? 7. Are back issues of TCWNs available? 8. What is the EBS? 9. Where are the Core War archives? 10. Where can I find a Core War system for . . . ? 11. I do not have ftp. How do I get all of this great stuff? 12. I do not have access to Usenet. How do I post and receive news? 13. When is the next tournament? 14. What is KOTH? How do I enter? 15. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 16. Other questions? --------------------------------------------------------------------- Q1: What is Core War? A1: 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 possesion 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. ---------------------------------------------------------------------- Q2: Is it "Core War" or "Core Wars"? A2: 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. ---------------------------------------------------------------------- Q3: Where can I find more information about Core War? A3: 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 an anthology: 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 (See Also Q9). --------------------------------------------------------------------- Q4: What is the ICWS? A4: 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). --------------------------------------------------------------------- Q5: What is TCWN? A5: 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 soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q6: How do I join? A6: For more information about joining the ICWS (which includes a subscription to TCWN), 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 dues are $15.00 in US currency. If you wish to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please send it to me at Mark A. Durham 18 Honeysuckle Terrace Spartanburg, SC 29307-3760 email: durham@cup.portal.com ---------------------------------------------------------------------- Q7: Are back issues of TCWN available? A7: Back issues of TCWN (up to Winter 1991) are available from AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 or contact William R. Buckley at xwbuckley@fullerton.edu. Prices are unknown at this time, but should be around $5.00 (the original cover price). More recent issues can be found on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q8: What is the EBS? A8: 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 will be 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 in preparation for the tenth anniversary of Core War in May of 1994. Its immediate business will be to set up a Charter and establish its officers. Contact me (see Q6) if you are interested in helping serve the EBS. ---------------------------------------------------------------------- A9: Where is the Core War archive? Q9: 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 soda.berkeley.edu (128.32.131.179) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. 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. ---------------------------------------------------------------------- Q10: Where can I find a Core War system for . . . ? A10: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are Unix X-Window, IBM PC-compatible (sorry, no systems specifically designed for MS-Windows yet), Macintosh, and Amiga Core War systems available there. 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 soda.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. Please post or email to me any review of any Core War system you have tried out so that others may learn from your experience. ---------------------------------------------------------------------- Q11: I do not have ftp. How do I get all of this great stuff? A11: 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. ---------------------------------------------------------------------- Q12: I do not have access to Usenet. How do I post and receive news? A12: The Usenet email server at ucbvax.berkeley.edu does not seem to be functioning at this time. I am trying to find alternate servers and verify their function. If anyone knows of any, please let me know so I can include it in the next FAQ. If you somehow receive rec.games.corewar but just can't post, you can email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q13: When is the next tournament? A13: The 1992 Annual ICWS tournament will be held December 15th, 1992. The rules are currently ICWS'88, core size of 8192, maximum number of processes per warrior of 8000, and ties declared after 100 000 cycles. The format is round-robin. Scoring is three points per win, one point per tie, and no points for losses. To enter you must be a member of the International Core War Society or successfully participate in one of the Branch Section preliminary tournaments ("successfully" meaning finish in the top five/ten [see below]). Valid entries should be sent to Jon Newman either via email to jonn@microsoft.com of via mail on 3.5" disk (800K Mac or 720K IBM), 5.25" disk (720K IBM or 1.2MB IBM), or printed. Disk entries should be in a simple ASCII text format and on virus-free disks. ICWS Members may submit one entry or two entries if in electronic form. Branch Sections may submit five entries, or ten if in electronic form. Entries are limited to 50 instructions, 300 if in electronic form. No scatter loading will be supported (instructions must be contiguous). All entries become public domain on submission. The ICWS will keep them confidential until after the tournament has been completed. The EBS will will hold its preliminary tournament November 15th, 1992. Submissions to durham@cup.portal.com. Late entries may be accepted if you received this FAQ after November 15th. ---------------------------------------------------------------------- Q14: What is KOTH? How do I enter? A14: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with email provided by William Shubert (wms@iwarp.intel.com). 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". If your program finished in the top twenty, it will remain on the hill until such time as it finishes twenty-first against another challenger, at which time it "falls off" the hill. 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 the line ";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. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes 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 you should get more mail telling you how your program performed against the current top 20 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 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. 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. Max entry length: 100 instructions Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. 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 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 rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. - A tie is not declared until 150,000 cycles per program have elapsed. KotH runs on any Unix system with an X windows interface. The source code to KotH is available by email from William Shubert. Write to him at (wms@iwarp.intel.com) for a copy or get it by anonymous FTP from soda.berkeley.edu in the pub/corewar/systems directory. ---------------------------------------------------------------------- Q15: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A15: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH) 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. ---------------------------------------------------------------------- Q16: Other questions? A16: Just ask. Either ask in the rec.games.corewar newsgroup or send your question(s) to me at durham@cup.portal.com. I will do my best to answer your question(s) or put you in touch with someone who can. Mark A. Durham MAD From: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) Subject: Lazy imp-ring defense [X-hill] Message-ID: <1992Nov15.204451.9870@unlv.edu> Date: 15 Nov 92 20:44:51 GMT Imp rings on the X-hill tend to work differently than they do on the standard hill. Among the reasons for this, the largest step an imp-ring can use on the X-hill is 250, which limits you to a few values, like 127, 63, and 21. One of the effects this has on gating is that you can't be sure what step is being used in the attack, so you need to make your gates adaptive. The problem with this is that X-hill programs tend to be larger, hence more vulnerable to imp rings and my adaptive gates tend to be just large enough that it either won't fit, or makes the program too big of a target. Well, I came up with what I call the lazy imp-ring defense, which is to launch an imp if you unexpectedly find yourself outside your program. Many of my programs use monitors, which just wait for a certain number of clock cycles to occur, then do some action. Here is how it looks in most of my programs MOV #WAIT, DELAY DELAY DJN DELAY,#0 JMZ DOIT,DELAY MOV 0,1 Basically, as soon as the imp ring writes (MOV 0,STEP) to DELAY, it drops out of the delay loop, and since DELAY isn't 0, we know we left abnormally. Now, an imp isn't the best imp-ring defense, but I find it scores much better than many of my own programs (Sonic Boom in particular) and at any rate, deprives the opponent of a lot of points. -- Eric J. Schwertfeger, maniac@cs.unlv.edu Subject: Impression v3 Message-ID: <1992Nov16.064702.10776@wisipc.weizmann.ac.il> From: fedimit@wisipc.weizmann.ac.il (Dan Nabutovsky) Date: Mon, 16 Nov 1992 06:47:02 GMT Hi all, This is my program Impression v3. As you can see, the main principles of imp-writing are: - Make spiral not ring - One Ring is the best architecture - Dwarf must get most of CPU time. And, most important: - Don't send your program to pdk. This schmuck will make minor changes, send it to Koth under his name, and then he'll blame you in copycatting. ;redcode ;name Impression v3 ;kill P. Kline for plagiate ;author Dan Nabutovsky ;strategy 2 imp spirals + self-splitting dwarf d EQU 2667 i EQU imp-2000 imp: mov 0,d start: mov imp, i spl 32 spl 16 spl 8 spl 4 spl 2 jmp i+d*0 jmp i+d*1 spl 2 jmp i+d*2 jmp i+d*3 spl 4 spl 2 jmp i+d*4 jmp i+d*5 spl 2 jmp i+d*6 jmp i+d*7 spl 8 spl 4 spl 2 jmp i+d*8 jmp i+d*0 spl 2 jmp i+d*1 jmp i+d*2 spl 4 spl 2 jmp i+d*3 jmp i+d*4 spl 2 jmp i+d*5 jmp i+d*6 spl 16 spl 8 spl 4 spl 2 jmp i+d*7 jmp i+d*8 spl 2 spl dwarf spl dwarf spl dwarf DAT #0 DAT #0 DAT #0 DAT #0 DAT #0 DAT #0 DAT #0 inc dat #-2045,#2045 dwarf spl 0,100 stone mov Date: Tue, 17 Nov 1992 13:45:16 GMT In article <1992Nov16.064702.10776@wisipc.weizmann.ac.il> fedimit@wisipc.weizmann.ac.il (Dan Nabutovsky) writes: >Hi all, > This is my program Impression v3. As you can see, the main >principles of imp-writing are: ...[stuff deleted]... >And, most important: > - Don't send your program to pdk. This schmuck will > make minor changes, send it to Koth under his name, > and then he'll blame you in copycatting. Harsh, harsh, harsh. Corewar is a rough game, it appears. Jim, here, was thinking about trying it out; after this posting, however, it seems that he may not be up to the task. Perhaps a little weight-lifting first, eh? Jim From: ford@zeta.uleth.ca (Roger Ford) Subject: Copy cats Message-ID: Date: 17 Nov 92 22:57:21 GMT Paul and I have had a little discussion about copycat source I publish the letters in thier entire in hopes of promoting discussions. I have writen to other people who submit to the hill and will correspond with anyone who emails. The letters follow: =============================================================== Date: Tue, 17 Nov 1992 16:24:59 -0600 (CST) From: PDK@ADMIN.DRAKE.EDU Message-Id: <921117162459.49d@ADMIN.DRAKE.EDU> Subject: RE: Copy cats and other things to whine about To: ford@zeta.uleth.ca X-Vmsmail-To: SMTP%"ford@zeta.uleth.ca" Chris, I want you to post your note on rec.games.corewar so we can get some general discussion going. I think it needs to happen. Especially for people just coming into the game, they need to have some guidance on whether what they are writing is sufficiently original to claim ownership. BTW, I got a fairly abusive note from Dan claiming that Imprimis was a knockoff of Impression, which source he sent me some time ago. I don't know whether he sent you a copy of Impression, but it contains line-for-line code which I published previously, and incorporates concepts which I 'originally' published earlier as well. Some other facts: There is more to Emerald than the stone component. Emerald beats Kobold 60/30. Imprimis 2 beats Impression 15/0, and is the only ring program that consistently scores 10-20% wins against other rings. (FYI, I have a new version of paper that beats Sucker5 94/6, but unfortunately loses big time to scanners) I'm returning your note in case you didn't keep a copy: ---------------------------------------------------------------------------- I am writing this letter to you rather than post it to the net, there are a few things that bother me about your posting. There are a finite number of ways to implement Red Code warrriors, just as an example. Both Sucker 4 and the first Kobold both use a step rate of 37. Granted one bombs and one slaves are we going to say that one guy copied another. No matter what you change the step rate to Emerald is just Kobold is just Stone. No Mucking About is just another Sissors scanner. Impire may be the original, But...then is IMPressive just a copy. If so Imprimus is a clone of IMPressive....Sad but true there are very few original ideas on the hill......Imitation seems to be the way to inovation. Emerald with the mov Date: 17 Nov 92 17:30:55 GMT I started subscribing to this group at the beginning of the summer (my work's been going downhill ever since :-(), around the time when flash paper,note paper, etc were at their prime. Unfortunately, I missed the code for them, (if code was posted), and I wondered if someone could post/ mail them - or other similar ones - to me, so that I can compare them with my own attempts, and (I hope) be inspired to great things... Cheers, Si. xxx -- S.A.Hovell,Dept. Electrical Engineering,University of Edinburgh,U.K. (+31) 650-5655 (Juggler@ed.ac.uk) ----- ----- From: pk6811s@acad.drake.edu Subject: The shmuck responds Message-ID: <1992Nov17.171301.1@acad.drake.edu> Date: Tue, 17 Nov 1992 23:13:01 GMT Well, I see after our private conversation, Dan is still unhappy and has gone public with his complaint. Let me share two pieces of code that I published BEFORE Impression appeared on the hill, and before I received a copy: ;redcode ;name Emerald ;author P.Kline inc dat #-2045,#2045 emerald spl 0,100 stone mov Date: Wed, 18 Nov 92 12:36:39 MST From: $dougn@sasb.byu.edu (Douglas R. Nebeker - MIS_SAS) Subject: Definition Help! Could someone briefly describe a gate, spiral and a ring? Thanks ____ Douglas R. Nebeker Internet: $dougn@sasb.byu.edu From: sah@castle.ed.ac.uk (Juggler) Subject: Re: Copy cats Message-ID: <28334@castle.ed.ac.uk> Date: 18 Nov 92 12:48:36 GMT I'm feeling slightly guilty, as I may have inadvertantly sparked off this small contoversy about originality (Should we be discussing this on alt.intellectual.property? :-)). I am now going to implement the strategy which I declared then, and cut bits from everybody's posts, add one line and call the result my own! Here's the copied bit: Roger Ford (or is it Chris??) writes: There are a finite number of ways to implement Red Code warrriors, just as an example. Both Sucker 4 and the first Kobold both use a step rate of 37. Granted one bombs and one slaves are we going to say that one guy copied another. No matter what you change the step rate to Emerald is just Kobold is just Stone. Paul Kline writes: I estimate I spent over 40 hours experimenting with different constants in Emerald to give it an effective (and unique) bombing pattern. There is more to Emerald than the stone component. Emerald beats Kobold 60/30. Imprimis 2 beats Impression 15/0, and is the only ring program that consistently scores 10-20% wins against other rings. He also says: There are differences between Impression and Imprimis. [differences duly pointed out] then Jim (jtf9s@poe.acc) comments: Harsh, harsh, harsh. Corewar is a rough game, it appears. Jim, here, was thinking about trying it out; after this posting, however, it seems that he may not be up to the task. Perhaps a little weight-lifting first, eh? And here's my bit: I reckon that this debate can be split into two questions, and Jim implicitly raised a third. Firstly: who did what first? Obviously I've got no idea about who wrote anything or when it was written. I must admit, I've always seen it as a sort of universal drive towards excellence on everybody's part. Secondly: What constitutes "new" code? After reading the unabridged versions of the above posts, and many others, I can think of two criterion that I would apply to my own warriors (if they ever stood a chance of getting onto the hill...). Firstly (as I've mentioned before), if the code contains at least one new (and functional) line, such as the awesome "dat #0" in, erm ... was it imprimus?. Secondly, in light of the above discussion, if the redcode does better than it's peers (i.e. changing the numbers in, for example, No Mucking About (what a *nice* name) and getting a 5 point improvement in it's score). It being that koth is such a clever little program, I don't see why people (like me ) who are prone to blatant copying in lieu of sparkling intellect, shouldn't add a ;strategy line, or an ;author line acknowledging the person with the original idea. It works for Gnu software. Thirdly: What provisions are there for new subscribers? Despite the (very informative) FAQ, wouldbe new talent is chucked in right at the deep end. The programmes on koth are sophisticated, n-th generation warriors, and bloody hard to understand (I speak from hours of experience!). As a consequence, newcomers have two choices, namely accept that their first dozen codes will be disasters, or take some proven code, alter it minimally, and experience the thrill of being on koth (gosh). Which would you do in that situation? As an afterthought, and a blatant attempt to get more involved in the copycat game, here is some code of my own (at least, I *hope* that nobody's thought of it already, anyway). Please take it, copy it, and call it your own. I'd be dead chuffed if other people found uses for it. It trashes stoners, but isn't much good against anything else, as it warps core rather than actually bombing. it also suffers the (minor) problem of commiting hari-kiri after 3 Twill-like self mutations. Nevertheless, it achieved my highest score (ninety-something) on koth yet. TTFN,folks Si. xxx ;redcode verbose ;name Road Hammer 0.3 ;author Simon Hovell ;date Nov 1992 ;strategy warps core ;strategy inspired by emerald and twill ; bomb1: spl 0 clear: mov Message-ID: <92323.132838AZNXS@ASUACAD.BITNET> Subject: Re: Corewars on a PC I have the same problem with new-dispose (Mars88 is in Pascal) and I think the solution is not to use new-dispose. I'm not absolutely sure about the heap management routines, but I think It would be faster to create a list of memory chunks (size 2*8000) and then use this list instead of new and dispose. So we need 2*8000 new at the begining of the program and 2*8000 dispose at the end of the program, but we need to do it just once in. In the next battle the free-list already exists. I'm not sure if it's really faster, but I'd like to try it out so please send me a note if you think it's nonsense. Nandor. From: pk6811s@acad.drake.edu Subject: Re: Copy cats Message-ID: <1992Nov18.085805.1@acad.drake.edu> Date: Wed, 18 Nov 1992 14:58:05 GMT More on copycatting: In reality we all build on what others have done. Even IMPire built on the old imp strategy. I think most people get stuck trying to make an existing strategy more efficient - less lines of code, instead of mixing strategies or trying something new. The originator has probably tested many variations already, so we're not likely to improve an existing program, and as the other guy (I forgot who's note I was replying to) stated, "my variations usually degenerate into the existing Emerald or Nomuckingabout or whatever". There are certain redcode irreducibles: an imp, a three-line bomber, a six-line mouse, stone, etc. These have aged sufficiently to be considered 'components', which can be incorporated into new, more complex programs. Some other code-parts are also available: the gate-form published by Mintardjo which he later stated is not original/unique. I also don't believe step-sizes should be proprietary. When N. Sieben published a number of optimum step-sizes, was he not recommending them for use? Most importantly, we can't claim ownership to idea/strategy/concept. Once the general idea has been made public, you can't claim it for yourself. Only the specific implementation in your own code belongs to you. So everyone is free to write their own bomber/stone, replicator/ paper, scanner, pittrapper, imp-ring, stone-paper combo, or whatever. I made the statement that in the long run, copycatting is not an effective strategy. Your program will slowly slide down the hill - along with the original - as other developers attack your common strategy. I think this is a true statement. Flash Paper was basically undone by the appearance of other stone-paper fighters. I did not intend by that statement to approve knocking off someone else's code, only to make an observation. The question of where originality comes in is a hard one to answer in general terms. I suggest the answer is in forced publication. If all programs on the Hill over four weeks old were published, the participants could judge whether someone was unfairly copying others' code. As long as everyone understood when they submitted their programs that if they become successful, they will be made public, there should be no problem with publishing them. As for Emerald being a clone of Kobold, Emerald beats Kobold something like 60/30. Here's the latest code for Emerald. Is it different enough from Kobold/Twill/Stone for me to claim ownership? (BTW, Matt, I removed the reflections. Since Charon and NMA disappeared, they were only drawing the attention of other scanners. But I still know where they are if I need them. :) ;redcode ;name Emerald ;kill Emerald ;author P.Kline ;strategy stone with djn stream ;strategy attempting a gate spacing equ 2365 hide1 spl 0,<-6 hide2 mov 49,<-20 hide3 dat <-7,<-8 hide dat #inc+1037-130+1020 start mov hide3,inc+1037+48-130+1020 mov hide2,gate code mov hide1, Date: Wed, 18 Nov 1992 16:30:15 GMT In article <28334@castle.ed.ac.uk> sah@castle.ed.ac.uk (Juggler) writes: > >Roger Ford (or is it Chris??) writes: >There are a finite number of ways to implement Red Code warrriors, >just as an example. Both Sucker 4 and the first Kobold both use a step >rate of 37. Granted one bombs and one slaves are we going to say that >one guy copied another. No matter what you change the step rate to >Emerald is just Kobold is just Stone. > Well, in this case it's genuinely "parallel development". Sucker 4 entered the hill sometime May/June, but I didn't post the code until it got pushed off two weeks ago. The code to Kobold was posted somewhere between those two time points, I think. A good constant can make the difference between doom and success on KotH, but it strikes me as silly to claim "intellectual property" for a number. I personally have no problem with copycatting, *provided* the code originator is acknowledged in the strategy lines or as co-author. I've had a long and fruitful collaboration with Jules Cisek that started when I optimized his posted Charon v1.0. Lately, Matt Hastings has approached me with some anti-imp mods to Agony (taught me a lot about ring-defenses, too), a collaboration I hope to continue. -Stefan (stst@vuse.vanderbilt.edu) P.S.: I wish Bill Shubert would add a filter to KotH that rejects warriors with missing or uninformative strategy lines. "Sorry, your redcode program did not compile successfully due to insufficient documentation" :-) :-) From: maniac@unlv.edu (Eric J. Schwertfeger) Subject: Re: Copy cats Message-ID: <1992Nov18.180408.806@unlv.edu> Date: Wed, 18 Nov 92 18:04:08 GMT In article <1992Nov18.085805.1@acad.drake.edu> pk6811s@acad.drake.edu writes: >More on copycatting: > >In reality we all build on what others have done. Even IMPire built >on the old imp strategy. I think most people get stuck trying to >make an existing strategy more efficient - less lines of code, instead >of mixing strategies or trying something new. The originator has probably >tested many variations already, so we're not likely to improve an >existing program, and as the other guy (I forgot who's note I was replying >to) stated, "my variations usually degenerate into the existing Emerald >or Nomuckingabout or whatever". Even Backfire, which I thought was original when I first wrote it was doing the same thing as a few other programs, though in a different manner. >There are certain redcode irreducibles: an imp, a three-line bomber, >a six-line mouse, stone, etc. These have aged sufficiently to be >considered 'components', which can be incorporated into new, more >complex programs. Sounds like how I do my X-Hill development. I have a few core routines that are generic (steps defined by EQU, etc), and I just string togetheher routines. I wish KOTH supported an include statement, it would make updating my warriors easier when I update a module :-). I've got modules for forward carpet bomb, forward SPL CB, reverse for both, fwd and rev fasttrack (something that I haven't used in the hill yet), Anti-replicator missiles, decoys, monitors, imp-gates, etc. The hardest part is fitting several complex modules into a single 100 line program. Master Tactician was a project of mine that got shelved because the finished program would have been 140 lines of code, so I stupified it and released it as chameleon. And on the X-hill, 100 line programs can be successful. Most of my long programs are just that. In fact, Sonic Boom 3.2 was exactly 100 lines long, without a single byte of padding. So was Spider 2, for that matter. If you haven't guessed, yes I'm trying to encourage X-hill development, rather than continuing flames. Reuse of redcode is pretty much normal. The idea for repeating core-clears started with Spider 2.1, to the best of my knowledge, I made them more popular, and now they appear in most of the top 10 X-Hill warriors. I was a little afraid to publish the source to Echo or Sonic boom at first, because I was afraid to cause a flood of imitators, but I don't see that as a problem anymore. sonic Boom 1.2 is the first definite improvement to Sonic Boom 1.0 that I've done, and that took a lot of work, not some trivial modifications. In fact, 1.2 is mostly a major, but very subtle bug fix to SB 1.0 Enough about that, lets talk new uses for old ideas :-) -- Eric J. Schwertfeger, maniac@cs.unlv.edu From: maniac@unlv.edu (Eric J. Schwertfeger) Subject: Sonic Boom 1.30 [X-Hill Source] Message-ID: <1992Nov18.181110.1047@unlv.edu> Date: Wed, 18 Nov 92 18:11:10 GMT Want to see a very painful death against Corona? watch this :-) More like suicide, really, but there's not much I can do about it. ;redcode-x ;name Sonic Boom 1.30 ;author Eric J. Schwertfeger ;strategy Two SPL bombing carpet bombers going opposite ;strategy Directions, with a monitor that relaunches carpet ;strategy bombers whenever both die. ;strategy v 1.3X Going back to original bombing pattern, hence return ;strategy to 1.XX numbers. WAIT EQU (568) FSTEP EQU (16*12) RSTEP EQU (-16*12) RCSRC DAT 0,RBDST+(RSTEP)+1 RSTART MOV RCSRC,<(RBDST-RSTEP) MOV RBDST-RSTEP,<(RBDST-RSTEP) MOV RBDST-RSTEP,<(RBDST-RSTEP) MOV RBDST-RSTEP,<(RBDST-RSTEP) MOV RBDST-RSTEP,<(RBDST-RSTEP) MOV RBDST-RSTEP,<(RBDST-RSTEP) MOV RBDST-RSTEP,<(RBDST-RSTEP) MOV RBDST-RSTEP,<(RBDST-RSTEP) MOV RCSRC,<(RBDST-RSTEP) ; this pass MOV RCSRC,<(RBDST-RSTEP) MOV RCSRC,<(RBDST-RSTEP) MOV RCSRC,<(RBDST-RSTEP) RMOVE MOV <(RCSRC-RSTEP),<(RCDST-RSTEP) RCDST JMP RSTART+RSTEP,RBDST+(RSTEP*2)+1 RBDST SPL 0,#RSTART-240 SHOOT SPL FLAUNCH SPL RLAUNCH MOV #(WAIT/3),DELAY WATCH JMN DIE,RSTART-150 JMN DIE,FBDST+150 DELAY DJN WATCH,#DELAY JMP SHOOT FLAUNCH MOV #FCDST+2+FSTEP-FCSRC,FCSRC-FSTEP MOV #2+(FSTEP*2),FCDST-FSTEP MOV #FCDST+2+FSTEP-FCSRC,FCSRC MOV #2+(FSTEP*2),FCDST MOV #241,FBDST SPL 1 SPL 1 SPL 1 SPL 1 JMP FMOVE DIE DAT 0,0 LAUNCH SPL DLAUNCH DJN 0,#(32*2+4) MOV DIE,DSTART+(32*DSKIP) JMP SHOOT DSKIP EQU (247) DLAUNCH MOV DSRC,DSRC-DSKIP MOV DDEST,DDEST-DSKIP SPL 1 MOV -1,0 JMP DSTART DSRC DAT DDEST+1+DSKIP DSTART MOV (FBDST-FSTEP) MOV FBDST-FSTEP,>(FBDST-FSTEP) MOV FBDST-FSTEP,>(FBDST-FSTEP) MOV FBDST-FSTEP,>(FBDST-FSTEP) MOV FBDST-FSTEP,>(FBDST-FSTEP) MOV FBDST-FSTEP,>(FBDST-FSTEP) MOV FBDST-FSTEP,>(FBDST-FSTEP) MOV FBDST-FSTEP,>(FBDST-FSTEP) MOV FCSRC,>(FBDST-FSTEP) MOV FCSRC,>(FBDST-FSTEP) MOV FCSRC,>(FBDST-FSTEP) MOV FCSRC,>(FBDST-FSTEP) FMOVE MOV <(FCSRC-FSTEP),<(FCDST-FSTEP) FCDST JMP FSTART+FSTEP,FBDST+(FSTEP*2)+1 FBDST SPL 0,#241 END LAUNCH -- Eric J. Schwertfeger, maniac@cs.unlv.edu From: ahmedh@ccwf.cc.utexas.edu (ahmed h al-mehdi) Subject: 1993 IEEE Computer Society National Programming Contest Message-ID: <83922@ut-emx.uucp> Date: 19 Nov 92 03:28:24 GMT :-----------------------------------------------------------------------------: ANNOUNCING..... :-----------------------------------------------------------------------------: EVENT: The 1993 IEEE Computer Society National Programming Contest WHERE: University of Texas at Austin, USA DATE: March 20th-March 21st, 1993 :-----------------------------------------------------------------------------: FREQUENTLY ASKED QUESTIONS ABOUT THE NATIONAL PROGRAMMING CONTEST Q: What is the IEEE CS National Programming Contest (NPC)? A: The NPC is an invitational computer programming contest which challenges 16 of the finest undergraduate student programmers in the world to compete head-to-head against each other in a new and exciting contest format. Each school sends a team of three students. These three students are given just one day to write programs which will compete on a team in a virtual world created by the contest organizers. The nature of this world will not be revealed until the contest day. On the second day, the contestants' programs fight each other to first place. The 1993 NPC will be run on 50 IBM RS/6000 UNIX workstations on a token-ring network. The contestants may use either C or C++ to write their programs. Q: Who may compete in the National Programming Contest? A: Although the NPC was originally intended to be a national event, we are getting interest from international schools. We encourage these schools to submit applications if they are interested in sending a team. Some schools will be invited automatically. However, *all* teams interested in competing must submit an application by the specified deadline. All competitors must be undergraduate students (or equivalent) in their major on the day of the contest. If this requirement is not clear or your country uses a different system, please mail us for clarification, as this rule will be strictly enforced. All teams must consist of exactly three competitors. Contestants are expected to arrive the day before the contest as it starts early in the morning on Saturday. Q: How much does the NPC cost? A: The NPC is free to the competitors. The sponsors of the NPC will pay for a hotel room for the team, all food during the contest days, and all transportation to and from the contest site. To arrange for more than one hotel room or for rental cars, please phone ahead. The NPC will not cover the cost of the air fares to get to and from the contest. Perhaps someday.. Q: How long has the NPC been around? A: The NPC has only happened once before, November 31, 1991. This contest was also held at the University of Texas. To insure that this year's contest will be a first class event, we have scheduled our time so that by the time you have read this announcement, the contest driver will be almost ready for Alpha testing. Last year's NPC was held on 16 Sparcstation 2's, a Sparcstation IPX, and 32 NCD X terminals. The winners of last year's contest were Rice Univeristy (Houston, Texas, USA) and MIT (Boston, Massachusetts, USA). Q: What are the prizes? A: We can't announce that just yet. Send us mail to keep posted on this. We should also have the name of our keynote speaker shortly. Q: What is the format of the application? A: All applications should be under 6 66-line text pages per team. Please do not worry about aesthetics. We will be looking over each very carefully and may send mail back to you for clarifications. Include the following information: names of all people on your team, e-mail addresses of each person on the team which will be valid until the day of the contest, street address of the team contact or team leader (this can be a coach or sponsor), age of each contestant, school, majors of each contestant, programming experience of each contestant (includes job, extra-curricular, or hobby), any honors or awards received by any contestant pertaining to programming, the address, phone number, and e-mail address (if one exists) of your department, and any other information you feel is pertinant or useful in illustrating your acumen in computer programming. You will be sent confirmation of having received your application within one week. All applicants will be notified of their status by January 30th, 1993 at the latest. Q: Who is sponsoring the event? A: IBM Corporation is the NPC host. The contest will be held on site at IBM's new building in North Austin. The NPC is sponsored in part by Texas Instruments. This event is organized by the students of the IEEE CS Student Branch Chapter at the University of Texas at Austin, USA. :-----------------------------------------------------------------------------: APPLICATION DEADLINE: December 30th, 1992 SEND APPLICATIONS TO: npc@npc.ece.utexas.edu, or ahmedh@ccwf.cc.utexas.edu BY US MAIL: IEEE Computer Society 1993 NPC Applications ENS 103 Austin, TX 78712 USA SEND QUESTIONS TO: answers@npc.ece.utexas.edu :-----------------------------------------------------------------------------: From: @prism.cs.orst.edu Subject: Copycat and more Message-ID: <1efceeINN85l@flop.ENGR.ORST.EDU> Date: 19 Nov 92 06:32:46 GMT I couldn't believe if there is any of us who would rather grab somebody else's code, rename it without make any reasonable changes, submit it to KotH and perceive it as his own thereafter. Even though we modify one or two lines, we still could justify how much contribution we made on the success of program. I think it is a very nice thing for people to have ways to accredit the author of program they borrowed. This copycatting is normal as far as we keep respecting the ethics we all know. To come to the pure and original concepts is a very rare situation. Even though it is pure, it also has to be success. We wouldn't have programs such as Charon, Crimp, No Mucking About and others if the original concept (CMP scanner) is limited to one. And similarly for other concepts such as B-scanner, paper, slaver, bomber, IMPs, anti-IMPs etc Now, imagine a situation when somebody submitted his program into KotH. And somehow, his program inspired two other people who never know each other. Both developed the same techniques and submitted the almost similar programs. Both were success. Then who claimed the original ideas? This might be the exact situation of the current debate about Impressive and Imprimis. And another one: a 'gate'. I called this 'IMPs gate' in my first posting since there was no other term of using this kind of technique. And then P.Kline started referring this to my name and made it public without asking me any permission. Not long after, I think it was Campbell Fraser, described that he also implemented the very same technique in his No More Mucking About. We never talked each other. But, Beholder's Eyes (Modified B-scanners live in vain) and No More Mucking About were the two scanners which occupied the very high positions at the time after Anders published his IMPire. There was no Campbell's posting (At least my local system doesn't receive it) and my posting was distributed locally (My apologize to those who didn't receive it). We both came to the same idea of using pre-decrement DAT to protect scanner from IMPs independently. I stated this as non-unique (but original) technique to avoid this kind of copycatting problem. Below are three source codes. Two of them are repost of my previous ones to those who haven't received it. ----------------------------------------------------------------------------- ;redcode ;name Beholder's Eye v1.1 ;author W. Mintardjo ;strategy Modified B-Scanners Live in Vain (Matt Hastings) with IMPs immunity ;kill Beholder's Eye v1.1 step EQU 2234 init EQU -2 main ADD #step, 3 JMZ -1, @2 MOV jump, @1 MOV snow, Date: 19 Nov 92 06:55:23 GMT It's called "c88v202.zip". Uploaded on soda.berkeley.edu under directory /pub/corewar/incoming. It's compatible with '88 standard and was intended to be used with KotH programs. Description: ----------- - Simple graphic interface (Much like kothpc) - Multiple round battles (Maximum 127) - Speed optimization - Simple debugging facility Requirement: ----------- 1. 640K memory (suggested) 2. CGA color c88 doesn't use memory allocation and deallocation except during parsing. Instead it uses array management. It is very fast and eliminates problems which occur due to heap management. --- W. Mintardjo From: @prism.cs.orst.edu Subject: Incomplete login name Message-ID: <1efg5uINNaka@flop.ENGR.ORST.EDU> Date: 19 Nov 92 07:36:29 GMT Notice the missing/incomplete login name of my two previous postings? This was due to the system. If anyone would reply them, please direct the mail to wangsawm@prism.cs.orst.edu --- W. Mintardjo From: te1349@newark.njit.edu (Leafweir) Subject: Help Message-ID: <1992Nov19.190144.21831@njitgw.njit.edu> Date: 19 Nov 92 19:01:44 GMT Hiyas, I found this corewar yesterday playing with ftp. I had heard of it before but had never seen it. It is rather interesting and I am trying to learn more about redcode. So far I have tried combining imp and dwarf I got a program good at surviving but not good at killing. I wanted it to go forward as a normal imp but also split and throw dat bombs behind me as I go forward. Please explain to me how to code this stuff. I have no experience in assembly. What follows is the program that I sort of put together. ;redcode ;name orc ;author Timothy Echeandia ;strategy Well I am rather new to corewar so I tried combining imp ;and dwarf. You get a more deadly imp an thereby the name orc. I am ;running corewars the X11 version and it survived against xtc. I think ;that this warrior more survives and ties than kills off. Right now ;killing off is giving me problems. orc mov orc, orc+1 bomb dat #0, #0 bomber add #-4, bomb mov bomb, @bomb jmp bomber end orc From: xyzzy@mertwig.UUCP (Daniel Drucker) Subject: redcode compiler/interpreter/whatever Message-ID: Date: Thu, 19 Nov 92 20:36:39 EST Where can I get the latest redcode whatever? I need the program. For DOS. -- "Xyzzy T. Plugh" mertwig!xyzzy@jaflrn.uucp Amateur radio callsign pending Daniel Max P. Drucker, the 14 year old networks wizard. "Difficulty! It's the single simplest machine in the entire Universe!" -HHGTTG From: t-jcisek@microsoft.com (Julius Cisek) Subject: Re: The shmuck responds Message-ID: <1992Nov20.012512.22937@microsoft.com> Date: 20 Nov 92 01:25:12 GMT I don't think anyone really cares. Why don't you guys take it back to private e-mail. You're both schumcks for handling yourselves this way. No one person can claim their piece of code for themselves, I'd thought you would all know this by now. I wrote something like the imp ring a long time ago and even mentioned it here, but are you going to give ME credit for it? And could I care less? I think one of the nice things about corewar was that it is something like an evolutionary process with the programmers more as stimuli for the continuing of the corewar warrior evolution nothing more. Besides it's extremely easy to re-write someone else's program without knowing what the code looks like, even unintentionally. I developed PitTrap completely on my own but it turned out that scissors88 by Scott Nelson had already been doing basically the same thing long before. So chill out and enjoy the games... (Wish I could say the same for myself, but I've been so busy at work that I've had no real time to spend on the game in months, c'est la vie...) Jules -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: wang@hpcupt1.cup.hp.com (Thomas Wang) Date: Sat, 21 Nov 1992 00:08:48 GMT Subject: Question from an oldtimer Message-ID: <136140001@hpcupt1.cup.hp.com> Why are people still playing CoreWars? I stopped playing a few years ago when I determined Vampire type fighters have too much advantages over other types of fighters; one hit and the game is over. I can describe my last CoreWars fighter as 2 parallel running vampires that periodically check if the twin is dead or not. If so, the survivor will turn itself into multiplying rabits. It's insurance against lucky shots. How do the latest champions work? If things have changed, please correct my theory about vampires. -Thomas Wang (Everything is an object.) wang@cup.hp.com From: durham@cup.portal.com Subject: Preliminary EBS Qualifying Tournament Results Date: 21 Nov 1992 02:49:47 -0600 Message-ID: <9211210049.8.24843@cup.portal.com> I am continuing to run rounds to make certain that the EBS tournament is fair, but at this time it looks as if the following programs will qualify for the annual ICWS tournament (in alphabetical order): Anti-body by Nandor Sieben Griffin 2 by Anders Ivner Impressive by Dan Nabutovsky Imprimis by P. Kline Leprechaun 1b by Anders Ivner Plasma by Wayne Sheppard Roaches by Steven Morrell Return of the Living Dead 2.2 by Nandor Sieben Sauron by Steven Morrell Twimp by Monika Keindl The following programs will probably NOT qualify: Appleseed Five++ by Jack Twilley Sucker 5b by Stefan Strack Tiny by Wayne Sheppard Mark A. Durham durham@cup.portal.com Subject: Re: Question from an oldtimer Message-ID: <1992Nov21.111720.2630@drycas.club.cc.cmu.edu> From: KENT@dirac.physics.jmu.edu (Kent Peterson) Date: 21 Nov 92 11:17:19 -0500 In <136140001@hpcupt1.cup.hp.com> wang@hpcupt1.cup.hp.com writes: > Why are people still playing CoreWars? I stopped playing a few years ago > when I determined Vampire type fighters have too much advantages over other > types of fighters; one hit and the game is over. > > I can describe my last CoreWars fighter as 2 parallel running vampires that > periodically check if the twin is dead or not. If so, the survivor will turn > itself into multiplying rabits. It's insurance against lucky shots. > > How do the latest champions work? If things have changed, please correct > my theory about vampires. > Things have changed all right. Any and all of the current champions could knock the socks off any and all of the contestants in the previous yearly tournaments. One of the main reasons is the use of large numbers of processes running together, usually created by executing a SPL 0 instruction. Of course, this means you need to have code that can be executed by multiple processes without damaging itself, but this isn't too hard, and the resulting toughness is really worth it. Intelligence, such as the self-checking program you described, isn't that important anymore (unfortunately, IMHO). However, there are a few tricks available that make programs smarter than the usual bomb-bomb-bomb versions, such as the use of CMP to scan 2 locations every 3 cycles. Here's the classic example of such a program: ;redcode verbose ;name Crimp 2 ;author Andy Pierce ;strategy cmp scanner with decoy ;strategy v2: smaller, faster core clear, original constants ret add offset,start start cmp -50,-1 slt #11,start count djn ret,<6024 mov bomb1,@start mov bomb2, From: fedimit@wisipc.weizmann.ac.il (Dan Nabutovsky) Date: Sun, 22 Nov 1992 11:55:44 GMT In article <1efceeINN85l@flop.ENGR.ORST.EDU> @prism.cs.orst.edu writes: > >Now, imagine a situation when somebody submitted his program into KotH. And >somehow, his program inspired two other people who never know each other. >Both developed the same techniques and submitted the almost similar programs. >Both were success. Then who claimed the original ideas? > >This might be the exact situation of the current debate about Impressive and >Imprimis. Yes, now I understand that this was a situation. I posted my program earlier, but Paul used some additional tricks and he is an author of Emerald, which is better than my dwarf Dain. Dan From: pk6811s@acad.drake.edu Subject: Anti-PitTrap Code Message-ID: <1992Nov23.095430.1@acad.drake.edu> Date: Mon, 23 Nov 1992 15:54:30 GMT Well, Sucker 4 nearly made it to 1000, and Sucker 5 looks like a good bet to do even better. There's just one problem. Pit-trappers are EASY to beat, because they drop pointers to themselves all over core. Try running this three-line program against Sucker 4: trace mov 10,<-10 sub @trace, Date: 24 Nov 92 08:39:28 GMT :--------------------------------------------------------------------------: 1993 IEEE CS National Programming Contest [Addendum] :--------------------------------------------------------------------------: This is a memorandum to make some clarifications in the previous announcement that was posted about the 1993 IEEE CS National Programming Contest. The following statement was made in the previous announcement - "The NPC is an invitational computer programming contest which challenges 16 of the finest undergraduate student programmers in the world to compete head-to-head against each other in a new and exciting contest format." The correct statement is as follows - "The NPC is an invitational computer programming contest which challenges 16 teams of the finest undergraduate student programmers in the world to compete head-to-head against each other in a new and exciting contest format." The students who will be selected to attend the contest should ask their department or college for airfare to fly to the contest site. We will be glad to send them additional information if needed. The date that is mentioned on the posting on which the programming contest will be held is only tentative . The date may vary a little, but will not change after December 30th. From: pk6811s@acad.drake.edu Subject: bombs, bombs, and more bombs Message-ID: <1992Nov25.111019.1@acad.drake.edu> Date: Wed, 25 Nov 1992 17:10:19 GMT It is HARD to keep a bomber on the Hill. Last summer I suggested we needed more bombers to reduce the number of scanners on the Hill, and give replicators some relief. (I have a marvelous 6-process, self-purging replicator that gets murdered every time it's submitted). With the appearance of imps, things have gone from bad to worse. All the old bombers were wiped out. Well, so were all the old scanners. But now the scanners are back, bigger and tougher than ever, so it's time for some bigger and tougher bombers too. Here's the code for ExtraExtra 2, and Emerald 2. Feel free to use parts of them as component parts of your own fighters. ;redcode ;name Emerald 2 ;kill Emerald ;author P.Kline ;strategy stone with djn stream ;strategy attempting a gate ;strategy new anti-pittrap code spacing equ 2365 hide1 spl 0,<-6 hide2 mov 49,<-20 hide3 sub @hide2, Date: 26 Nov 92 05:52:19 GMT I would like to share some of my code. PLASMA4a is my first program to reach #1 on the hill. Too bad it didn't stay up there very long. It can't survive with all of the imps and scanners out there. I'm sure someone could come up with an improvement. Heres an idea of how it works: The main loop scans until it finds something non-zero( also ignoring -1 ). Then it bombs up from that location, while a replicator kicks in. The second program is where I got the inspiration for PLASMA. Send it in to the Hill and look at the scores. It does amazingly well against other scanners and bombers. (65-35-0 on average) But against reps and imps, it loses 99 times out of a hundred. Maybe some other people could post some code also. ;redcode verbose ;name PLASMA 4a ;author Wayne Sheppard bomb equ start-1 start add #3039,loc ;mod 1 loc jmz start,-1 cmp #-1,@loc ;don't look at DJN trails slt #100,loc ;program length jmp start spl rep spl 0 mov bomb, Date: Thu, 26 Nov 1992 16:05:11 GMT Here's the code for my programs Griffin 2 and Leprechaun 1b. Griffin is just a highly optimized cmp-scanner, but Leprechaun uses a rather interesting technique to bomb and scan at the same time. BTW: Does anyone know how to contact Jon Newman? His system seems to be down... /Anders Ivner ;redcode ;name Griffin 2 ;author Anders Ivner ;strategy small spl/jmp bombing cmp-scanner boot mov I may have found out something that can replace a dat bomb. The instruction is 'add -n, Date: Sun, 29 Nov 1992 15:35:27 GMT I've dedcided to jump back into Corewar programming some now... Just sent off my pathetic little SuperImp rogram to feel out the competition. Lots of teh currently on-hill programs say they use an "Imp Sprial". This is some new technique since the last time I was programming, since I've never heard of it... What IS an Imp Sprial? Sounds interesting. :) Anyways, here's the extent of my Corewars programming, ever. :) This is my only program to ever make it on the hill. It dies badly today... Program must have changed alot. ;name SuperImp 1.0 ;author Jonathan Roy ;strategy A glorified imp. Can tie most multi-process programs like ;startegy Mice. Sometimes ties single process bombers like XTC. ;strategy Needs to be implemented with a good kill routine. ;strategy Note: "Imp stompers" rarely affect SuperImp. start MOV 2,4002 SPL 4001 MOV 0,4001 END In this program, you can make the lance length whatever you like. However, I've found a length of 2 to always score highest. (I tested 3,4,5,10,20) ;redcode verbose ;name ImpLance 0.2b ;author Jonathan Roy ;strategy A glorified imp. Creates a "lance" and gallops through ;strategy the core. 2 length version. start MOV 0,2 MOV 0,2 END This program was an attempted merger between the ImpLance and the SuperImp. It scored just barely lower than a ImpLance by itself. (A long time ago, that is. Maybe a year or so ago. It'd problem sputter and die today. ;) ;redcode verbose ;name SuperLance .09b ;author Jonathan Roy ;strategy A glorified imp. This is ImpLance and SuperImp in one. ;strategy Question: Will it work?? start MOV 3,4004 MOV 2,4002 SPL 4001 MOV 0,4002 MOV 0,4002 END Here's another valaint effort on my part... And anohter failure. :) (What can I say? I didn't have a decent program to test run these with, and I just learned assembly at the same time. I'm older and wiser now. :) I don't recall teh scoring for this on, but I'm sure it didn't do well. ;name ImpBreed 1.1 ;author Jonathan Roy ;strategy A glorified imp. Breeds a special type of ImpLance. ;strategy 1.1: Although sucessful on the -x hill, it died horribly on ;strategy the normal hill. This tries to breed SuperImps instead of ;strategy ImpLances. start SPL 2 JMP -1 MOV 2,4002 SPL 4001 MOV 0,4001 END ;kill And teh original... ;redcode verbose ;name ImpBreed 1.0 ;author Jonathan Roy ;strategy A glorified imp. Breeds a special type of ImpLance. start SPL 12 MOV 1,20 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 JMP -11 END ;kill I had used the SPL at teh end to save a cycle, but ti cost some wins for some reason.. I'd also use this one on the X hill for a while, but it never really did too well. Anyways, that's everything I've ever written. :) All basic, simplistic, stuff.... Now, I'm going to try my hand at the big mammoth programs. :) -- F F Jonathan Roy, Vice President, Free Access Foundation. GEnie: J.ROY18 A Mail faf@halcyon.com for information, or FTP to halcyon.com: /pub/faf/ F F "A server is a terrible thing to waste." Internet: ninja@halcyon.com "Everything that has transpired has done so according to my design." - _RotJ_ From: ninja@halcyon.com (Jonathan Roy) Subject: Corewars for Unix, X Message-ID: <1992Nov29.172209.15971@nwnexus.WA.COM> Date: Sun, 29 Nov 1992 17:22:09 GMT What's the best Corewars 88 compatible package to get for use on a UNIX system? This would be for a simple Vt100 dumb terminal interface... Also, what is the best package to get for a X/Windows interface? (I have two systems I want to run Corewars testing on. One is a modem-accessable Ultrix site, the other is alocal Sun4 w/ X.) Thanks for any recommendations. -- F F Jonathan Roy, Vice President, Free Access Foundation. GEnie: J.ROY18 A Mail faf@halcyon.com for information, or FTP to halcyon.com: /pub/faf/ F F "A server is a terrible thing to waste." Internet: ninja@halcyon.com "Everything that has transpired has done so according to my design." - _RotJ_ From: cyberman@exucom.com (Stephen R. Phillips) Subject: Faq for this group Message-ID: <1992Nov29.235506.12679@exucom.com> Date: 29 Nov 92 23:55:06 GMT Hello all I haven't read this group in a while. If there is a FAQ would someone be kind enough to tell me where I can get it OR email it to me. One thing, is it possible to get KOH to run on an MSDOS platform. Please enlighten me here. Thanks Cyberman/Stephen From: baggettw@memstvx1.memst.edu Subject: Digest files on soda.berk Message-ID: <1992Nov30.124224.4277@memstvx1.memst.edu> Date: 30 Nov 92 12:42:24 -0600 A while back I tried to download the CoreWars digest files from soda.berkeley.edu. I couldn't figure out how unpack the files, which had an extension of .Z, i.e. digest1.Z or somesuch. I am on a Vax running VMS and have access to Macs and PCs. Does anyone know the solution? Bill Baggett Memphis State University From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Corewars for Unix, X Message-ID: <1992Nov30.142250.12912@oucsace.cs.ohiou.edu> Date: 30 Nov 92 14:22:50 GMT In article <1992Nov29.172209.15971@nwnexus.WA.COM> ninja@halcyon.com (Jonathan Roy) writes: >What's the best Corewars 88 compatible package to get for use >on a UNIX system? This would be for a simple Vt100 dumb terminal >interface... > >Also, what is the best package to get for a X/Windows interface? (I >have two systems I want to run Corewars testing on. One is a >modem-accessable Ultrix site, the other is alocal Sun4 w/ X.) > >Thanks for any recommendations. Check out my Core Wars Deluxe package at soda.berkeley.edu in the /pub/corewar/systems directory (I do believe the file is called something like deluxe13b.tar.Z). It has both an X-Window and Curses interface built in. It will first try to start up with X-Windows, and if it fails, it will assume you don't have it and then fire up the Curses interface. You could as well optionally set the program up so that it only gives a summary of the battles instead of using any display at all. This would work well for really dumb terminals. I am working on the next version quite heavily now. I am on Christmas break (imagine that!) and now have time to finish it up. The version will be able to support both Unix (SysV/BSD like systems, including Ultrix) and IBM PC's. I will be supporting both X-Windows and Curses for the Unix systems, and CGA/EGA/VGA/Hercules/Text for the IBM PC's. If you have any suggestions of what to put in my next version, I will happily consider them and put them in. I will be supporting both the '86 and '88 standards, as well as the proposed X standard... The PCT and XCH instructions will be available for experimentaion as well. I am also including the Write Limit that is currently in use with KotH-X. Lots of new stuff :-) Well, catch you later! -- Don't forget to have a good day! Some people never remember this. ------------------------------------------------------------------------------- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu (Flame me, not the net!) Bitnet: adkins@ouaccvma.bitnet ------------------------------------------------------------------------------- Ohio University of Athens Home of the Great Hocking River From: ST002073@brownvm.brown.edu () Subject: Rank Amateur Date: Mon, 30 Nov 1992 23:14:42 EST Message-ID: <1feosbINN940@cat.cis.Brown.EDU> I read an artilce in Scientific American a really long time ago about corewar, but at the time I had neither the ability nor the hardware to do it. How can I get started. I happen to own an clone, and have unlimited access to macs. I have an account on an IBM mainframe. TNX Brain Perkins