From: "tmp" Subject: Re: KOFACOTO Date: 2000/12/01 Message-ID: <909snt$8og$1@plutonium.btinternet.com>#1/1 > Congratulations! Nice to see one of the old-timers still has what it takes > :-) It is a sad comment on life that I am an Old Timer. No-one asked me. I used to be the new kid on the block. [Sigh] > Your comments on preparing for each round are classic, well worth reading > for anyone. Of > course each of the final rounds was kind of a crapshoot, but you did well in > all your choices, > the wimp played in your paper against my HSA component, the quick-scan > against David's > player, each time just the right wrinkle. One-on-One always involves a huge amount of luck. My warrior against David was very lucky to pull through, but the others were ok. Against you, I considered leaving out the wimp, but I have a lot of respect for HSA-style scanners and it seemed like good insurance. Any other scanner is likely to have a tough time against ROTF. I'm probably happiest about Later At Night. Michal, did you consider playing a scanner? I guessed that you would reject the idea because Freight Train or Tangle Trap would beat it so easily... leaving a fast paper winning or drawing against everything else. Maybe you reasoned the same way? > Thanks to JKW and Tuc for sponsoring and running this fine tourney! Echoed. Robert From: birk@andromeda.ociw.edu Subject: Re: Koenigstuhl Date: 2000/12/01 Message-ID: <200012011742.JAA28521@andromeda.ociw.edu>#1/1 > Look like a lot of changes have been made... with all those hills, > it's just another good reason for people to ;assert themselves!! Yes, I am working on a few new hills: X (CORESIZE==55440) T (CORESIZE==800) LP (MAXPROCESSES==8) Any comments? Christoph From: "Paul Kline" Subject: re: KOFACOTO Date: 2000/12/01 Message-ID: <908ebe$4rg@ng1.icn.state.ia.us>#1/1 Robert: Congratulations! Nice to see one of the old-timers still has what it takes :-) Your comments on preparing for each round are classic, well worth reading for anyone. Of course each of the final rounds was kind of a crapshoot, but you did well in all your choices, the wimp played in your paper against my HSA component, the quick-scan against David's player, each time just the right wrinkle. Thanks to JKW and Tuc for sponsoring and running this fine tourney! Paul Kline pk6811s@acad.drake.edu From: "Benjamin Ford" Subject: Re: KOFACOTO Date: 2000/12/02 Message-ID: #1/1 From: "tmp" > > Your comments on preparing for each round are classic, well worth reading for anyone. Of > > course each of the final rounds was kind of a crapshoot, but you did well in all your choices, > > the wimp played in your paper against my HSA component, the quick-scan against David's > > player, each time just the right wrinkle. > > One-on-One always involves a huge amount of luck. My warrior against > David was very lucky to pull through, but the others were ok. Against > you, I considered leaving out the wimp, but I have a lot of respect > for HSA-style scanners and it seemed like good insurance. Any other > scanner is likely to have a tough time against ROTF. Of course, with the developement of wimps, I wouldn't of been too surprised to see an HSA-style scanner that falls into a d-clear rather than switching bombing modes, only takes up an additional 2 instructions. Just some comments on your round 5 notes. Right now there are some highly defensive warriors on the 94 hill so they are somewhat viable. I don't think The PhantIMP Meanance has fallen below 65% ties or below 10th place (and debuted in first due to its abusing of the abusive warriors). And Fifth Third has seem to shown that a defensive p-spacer is feasible. I wish I had written those before round 5 =). Of course, there are very few pure scanners on the hill right now so that helps those highly defensive warriors stay on. Quicksilver and others are doing a good job of keeping the scanners off. I'm surprised by the choice of using Jade's q-scan. The q-scan from RotF is both smaller (ignoring the bit of extra space the optional brainwashing adds) and faster. Only advantage Jade has is that it can scan more locations if wanted. and in some weird cases the extra decoy the q-bomber makes might help (against scanners that leave behind big decoys I guess). I can't see why you would of been putting nPaper II into the p-spacer. Other than against stones with a-field driven imps, it doesn't offer much. Which pretty much has meant that all the stone-imps made since nPaper haven't used a-imps. And I can't take credit for the scissors in Pattel's Virus. Pretty much taken right from "There still may be some bugs in this." by Anton Marsden. -Ben From: jkw@koth.org Subject: Re: Koenigstuhl Date: 2000/12/02 Message-ID: <4.1.20001202182634.00ad5b10@pop-server>#1/1 >The definition of a P-warrior should be that it uses LDP to >_retrieve_and_benefit_from_ information from P-Space. Using STP by >itself does not make a warrior a P-warrior, because against non-P >warriors it could be exchanged for NOP with no change of effect. Again, if people would assert the requirement of pspace on warriors that cannot function normally without it, there'd be a simple distinction... running '88 warriors in '94 mode is fine as long as they both use the same settings... but I see no point in running 8 process warriors in a 8000 process hill... all that does is scew the results of the hill towards warriors that beat 8-proc programs? Bizarre results are sure to follow. :) -jkw From: "Leonardo H. Liporati" Subject: Re: KOFACOTO Date: 2000/12/02 Message-ID: <200012021808.NAA22370@gevjon.ttsg.com>#1/1 Hi, I also enjoyed Robert's comments. Certainly they are very useful for less experimented players like me. I also think JKW and Tuc promoted an unique event on Corewar History. US$800 in prizes!!! :) Thank you. My corewar skills improved a lot during this tournament. I am sorry for not studying more corewar before this tournament. Congratulations to all participants and bye, Leonardo H. Liporati. From: jkw@koth.org Subject: Re: Koenigstuhl Date: 2000/12/02 Message-ID: <4.1.20001201233133.00adf930@pop-server>#1/1 At 12:49 PM 12/1/00 -0500, you wrote: >> Look like a lot of changes have been made... with all those hills, >> it's just another good reason for people to ;assert themselves!! > >Yes, I am working on a few new hills: > X (CORESIZE==55440) > T (CORESIZE==800) > LP (MAXPROCESSES==8) > >Any comments? > >Christoph My only comment is that people should assert the settings a warrior is to be run under, but don't go overboard, ie, no need to assert PSPACESIZE is your warrior doesn't use pspace... :) But if it does use pspace, assert it, so those warriors that work on 94 no-p can be sorted. :/ -jkw From: jkw@koth.org Subject: Re: Koenigstuhl Date: 2000/12/02 Message-ID: <4.1.20001202003631.00ae4db0@pop-server>#1/1 >USE THE ASSERTS > >I saw my round 2 entry on the '88 koenigstuhl... okay buuuuut >what is an 8 process fighter doing on an 8000 process hill? >huh? huh? > >I don't even understand why '88 warriors are on the '94 hill. >If Iron Gate had to beat TimeScape, then it wouldn't be Iron Gate, >it would be something else. Why bastardize the results when you >already have a separate '88 hill? > >Having said that, I love Koenigstuhl... keep up the good work! > >David. I'd like to remind people again, for any published warriors, see http://www.KOTH.org/koth.html and http://www.KOTH.org/info/pmars-redcode-94.txt for ;assert info... I agree that the "Open" hill is incredibly misleading to anyone that doesn't have a firm understanding of just how unfair it is. :) So David, did your entry have ";assert MAXPROCESSES==8"?? Hmm? Hmm? If not, then don't complain! :-) I'll admit that when I was first starting I never ;asserted myself. Hehe... so I'm probably not one to talk... but hey... -jkw From: jkw@koth.org Subject: kofacoto update Date: 2000/12/02 Message-ID: <4.1.20001202005048.00ae0ea0@pop-server>#1/1 Robert Macrae's sent some updated comments to me, which have been posted to koth.org... Round 6 has a little table showing how the other matchups would've gone.. interesting... :) http://www.koth.org/kofacoto -jkw From: "tmp" Subject: Re: Koenigstuhl Date: 2000/12/02 Message-ID: <90ah8e$16e$1@plutonium.btinternet.com>#1/1 > I don't even understand why '88 warriors are on the '94 hill. > If Iron Gate had to beat TimeScape, then it wouldn't be Iron Gate, > it would be something else. Why bastardize the results when you > already have a separate '88 hill? I think its interesting to look at warriors out of category like that. Any eternal hill is going to compare warriors of radically different ages and I don't see the '88 / '94 distinction as necessarily more important that the pre/post Imp Spiral or pre/post QS eras. I think any warrior that is interesting and a legal subset of the instructions on a hill should be on it. Freight Train should be on '94 as well, for example. On one issue of definition, there are some warriors that use P-space in a purely defensive manner, by making provision to brainwash opponents if they are P-spacers. Obviously this has no effect at all on non-P warriors and provides no advantage against them, so brainwashers can fairly be allowed on the Non-P hill. The definition of a P-warrior should be that it uses LDP to _retrieve_and_benefit_from_ information from P-Space. Using STP by itself does not make a warrior a P-warrior, because against non-P warriors it could be exchanged for NOP with no change of effect. Robert Macrae From: David Matthew Moore Subject: Re: Koenigstuhl Date: 2 Dec 2000 05:02:58 GMT Message-ID: <909vq2$10hr$1@msunews.cl.msu.edu> birk@andromeda.ociw.edu wrote: > Yes, I am working on a few new hills: > X (CORESIZE==55440) > T (CORESIZE==800) > LP (MAXPROCESSES==8) > Any comments? Yes. Oh yes. USE THE ASSERTS I saw my round 2 entry on the '88 koenigstuhl... okay buuuuut what is an 8 process fighter doing on an 8000 process hill? huh? huh? I don't even understand why '88 warriors are on the '94 hill. If Iron Gate had to beat TimeScape, then it wouldn't be Iron Gate, it would be something else. Why bastardize the results when you already have a separate '88 hill? Having said that, I love Koenigstuhl... keep up the good work! David. From: "Benjamin Ford" Subject: Re: Koenigstuhl Date: 2000/12/03 Message-ID: #1/1 ----- Original Message ----- From: To: "Multiple recipients of list COREWAR-L" Sent: Saturday, December 02, 2000 7:48 PM Subject: Re: Koenigstuhl > >The definition of a P-warrior should be that it uses LDP to > >_retrieve_and_benefit_from_ information from P-Space. Using STP by > >itself does not make a warrior a P-warrior, because against non-P > >warriors it could be exchanged for NOP with no change of effect. > > Again, if people would assert the requirement of pspace on warriors > that cannot function normally without it, there'd be a simple > distinction... running '88 warriors in '94 mode is fine as long > as they both use the same settings... but I see no point in running > 8 process warriors in a 8000 process hill... all that does is scew > the results of the hill towards warriors that beat 8-proc programs? > Bizarre results are sure to follow. :) Well, there is the 94nop hill and the plain 94 hill on Koen that doesn't allow pspace. Something like Return of the Fugitive can't make it on those hill as published because the qscan includes a brainwash. Its use of pspace doesn't do anything if the opponent isn't using pspace so it seems silly that it is excluded. So it would be nice if instead of rejecting warriors using STP, if those hills could just treat it as NOP. Obviously, warriors with LDP should still be excluded. As for the 8 proc warriors... it shouldn't matter on the Recursive standings too much, they probably end up with very low weightings anyways. From: "Robert Macrae" Subject: Re: KOFACOTO Date: 2000/12/03 Message-ID: <90ei37$1me$1@lure.pipex.net>#1/1 > Of course, with the developement of wimps, I wouldn't of been too surprised > to see an HSA-style scanner that falls into a d-clear rather than switching > bombing modes, only takes up an additional 2 instructions. That's why I considered leaving it out; its just a question of the payoff. vs HSA -- big win vs HSA/DC -- no change (the wimp is never stunned) vs other scanner -- very small loss On balance it looks good even if a pure HSA is rather unlikely. > Just some comments on your round 5 notes. Right now there are some highly > defensive warriors on the 94 hill so they are somewhat viable. I don't > think The PhantIMP Meanance has fallen below 65% ties or below 10th place > (and debuted in first due to its abusing of the abusive warriors). And > Fifth Third has seem to shown that a defensive p-spacer is feasible. Not forgetting Jedimp... and a soon-to-be-released but un-named heavy imp special. > I'm surprised by the choice of using Jade's q-scan. The q-scan from RotF is > both smaller (ignoring the bit of extra space the optional brainwashing > adds) and faster. Hmmm... it looks as if I was a bit sloppy. As written Jade showed slightly better results, but ROTF has some extra functions such as brainwash that I could really have removed before testing. It is also possible that I was mislead by some interraction of the steps. Whatever the cause, on my tests Jade was ahead and I settled on it fairly quickly. > I can't see why you would of been putting nPaper II into the p-spacer. > Other than against stones with a-field driven imps, it doesn't offer much. A-field imps are reasonably common, but maybe you are right; I just put it in because it had a very different score profile from ROTF. IIRC it splits a bit faster than ROTF and so might stretch a oneshot or coreclear designed to deal with ROTF's imps... > Which pretty much has meant that all the stone-imps made since nPaper > haven't used a-imps. Though like me many people use old code for these rounds... > And I can't take credit for the scissors in Pattel's Virus. Pretty much > taken right from "There still may be some bugs in this." by Anton Marsden. Very neat. Robert From: anton@paradise.net.nz (Anton Marsden) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 2000/12/03 Message-ID: Archive-name: games/corewar-faq Last-Modified: September 4, 1999 Version: 4.2 URL: http://homepages.paradise.net.nz/~anton/cw/corewar-faq.html Copyright: (c) 1999 Anton Marsden Maintainer: Anton Marsden Posting-Frequency: once every 2 weeks Core War Frequently Asked Questions (rec.games.corewar FAQ) These are the Frequently Asked Questions (and answers) from the Usenet newsgroup rec.games.corewar. A plain text version of this document is posted every two weeks. The latest hypertext version is available at http://homepages.paradise.net.nz/~anton/cw/corewar-faq.html and the latest plain text version is available at http://homepages.paradise.net.nz/~anton/cw/corewar-faq.txt. This document is currently being maintained by Anton Marsden (anton@paradise.net.nz). Last modified: Sat Sep 4 00:22:22 NZST 1999 ------------------------------------------------------------------------ To Do * Add the new No-PSpace '94 hill location * Add online location of Dewdney's articles * Make question 17 easier to understand. Add a state diagram? * Add info about infinite hills, related games (C-Robots, Tierra?, ...) * New question: How do I know if my warrior is any good? Refer to beginners' benchmarks, etc. * Add a Who's Who list? * Would very much like someone to compile a collection of the "revolutionary" warriors so that beginners can see how the game has developed over the years. Mail me if interested. ------------------------------------------------------------------------ What's New * Changed primary location of FAQ (again!) * Changed Philip Kendall's home page address. * Updated list server information * Changed primary location of FAQ * Vector-launching code was fixed thanks to Ting Hsu. * Changed the location of Ryan Coleman's paper (LaunchPad -> Launchpad) * Changed pauillac.inria.fr to para.inria.fr ------------------------------------------------------------------------ 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. Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? 5. What is ICWS'94? Which simulators support ICWS'94? 6. What is the ICWS? 7. What is Core Warrior? 8. Where are the Core War archives? 9. Where can I find a Core War system for ...? 10. Where can I find warrior code? 11. I do not have FTP. How do I get all this great stuff? 12. I do not have access to Usenet. How do I post and receive news? 13. Are there any Core War related WWW sites? 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. How does SLT (Skip if Less Than) work? 17. What is the difference between in-register and in-memory evaluation? 18. What is P-space? 19. What does "Missing ;assert .." in my message from KotH mean? 20. How should I format my code? 21. Are there any other Core War related resources I should know about? 22. What does (expression or term of your choice) mean? 23. Other questions? ------------------------------------------------------------------------ 1. What is Core War? 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 processes of the opposing program to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardised by the ICWS, and is therefore transportable between all standard Core War systems. The system in which the programs run is quite simple. The core (the memory of the simulated computer) is a continuous array of instructions, empty except for the competing programs. The core wraps around, so that after the last instruction comes the first one again. There are no absolute addresses in Core War. That is, the address 0 doesn't mean the first instruction in the memory, but the instruction that contains the address 0. The next instruction is 1, and the previous one obviously -1. However, all numbers are treated as positive, and are in the range 0 to CORESIZE-1 where CORESIZE is the amount of memory locations in the core - this means that -1 would be treated as CORESIZE-1 in any arithmetic operations, eg. 3218 + 7856 = (3218 + 7856) mod CORESIZE. Many people get confused by this, and it is particularly important when using the SLT instruction. Note that the source code of a program can still contain negative numbers, but if you start using instructions like DIV #-2, #5 it is important to know what effect they will have when executed. The basic unit of memory in Core War is one instruction. Each Redcode instruction contains three parts: * the opcode * the source address (a.k.a. the A-field) * the destination address (a.k.a. the B-field) The execution of the programs is equally simple. The MARS executes one instruction at a time, and then proceeds to the next one in the memory, unless the instruction explicitly tells it to jump to another address. If there is more than one program running, (as is usual) the programs execute alternately, one instruction at a time. The execution of each instruction takes the same time, one cycle, whether it is MOV, DIV or even DAT (which kills the process). Each program may have several processes running. These processes are stored in a task queue. When it is the program's turn to execute an instruction it dequeues a process and executes the corresponding instruction. Processes that are not killed during the execution of the instruction are put back into the task queue. Processes created by a SPL instruction are added to the task queue after the creating process is put back into the task queue. [ToC] ------------------------------------------------------------------------ 2. Is it "Core War" or "Core Wars"? 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. [ToC] ------------------------------------------------------------------------ 3. Where can I find more information about Core War? Core War was first described in the Core War Guidelines of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in Scientific American which discussed Core War, starting with the May 1984 article. Those articles are contained in two anthologies: Library of Author Title Published ISBN Congress Call Number The Armchair Dewdney, Universe: An New York: W. QA76.6 .D517 A. K. Exploration of H. Freeman �0-7167-1939-8 1988 Computer Worlds 1988 The Magic 0-7167-2125-2 Dewdney, Machine: A New York: W.(Hardcover), QA76.6 A. K. Handbook of H. Freeman �0-7167-2144-9 .D5173 1990 Computer Sorcery 1990 (Paperback) A.K. Dewdney's articles are still the most readable introduction to Core War, even though the Redcode dialect described in there is no longer current. For those who are interested, Dewdney has a home page at http://www.csd.uwo.ca/faculty/akd/. [ToC] ------------------------------------------------------------------------ 4. Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A draft of the official standard (ICWS'88) is available as ftp://www.koth.org/corewar/documents/standards/redcode-icws-88.Z. This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at Mark Durham's tutorials, ftp://www.koth.org/corewar/documents/tutorial.1.Z and ftp://www.koth.org/corewar/documents/tutorial.2.Z. Steven Morrell has prepared a more practically oriented Redcode tutorial that discusses different warrior classes with lots of example code. This and various other tutorials can be found at http://www.koth.org/papers.html. Even though ICWS'88 is still the "official" standard, you will find that most people are playing by ICWS'94 draft rules and extensions. [ToC] ------------------------------------------------------------------------ 5. What is ICWS'94? Which simulators support ICWS'94? There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a new addressing modes and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft at ftp://www.koth.org/corewar/documents/icws94.0202.Z for more information. There is a HTML version of this document available at http://www.koth.org/info/icws94.html. You can try out the new standard by submitting warriors to the '94 hills of the KotH servers. Two corewar systems currently support ICWS'94, pMARS (many platforms) and Redcoder (Mac), both available at ftp://www.koth.org/corewar. Note that Redcoder only supports a subset of ICWS'94. [ToC] ------------------------------------------------------------------------ 6. What is the ICWS? About one year after Core War first appeared in Scientific American, 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). The ICWS is no longer active. [ToC] ------------------------------------------------------------------------ 7. What is Core Warrior? Following in the tradition of the Core War News Letter, Push Off, and The 94 Warrior, Core Warrior is a newsletter about strategies and current standings in Core War. Started in October 1995, back issues of Core Warrior (and the other newsletters) are available at http://para.inria.fr/~doligez/corewar/. There is also a Core Warrior index page at http://www.kendalls.demon.co.uk/pak21/corewar/warrior.html which has a summary of the contents of each issue of Core Warrior. Many of the earlier issues contain useful information for beginners. [ToC] ------------------------------------------------------------------------ 8. Where are the Core War archives? Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from ftp://ftp.csua.berkeley.edu/pub/corewar. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@csua.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. This site is mirrored at: * http://www.koth.org/corewar/ * ftp://www.koth.org/corewar/ * ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/mirror The plain text version of this FAQ is automatically archived by news.answers (but this version is probably out-of-date). [ToC] ------------------------------------------------------------------------ 9. Where can I find a Core War system for . . . ? Core War systems are available via anonymous FTP from www.koth.org in the corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. It is a good idea to check ftp://www.koth.org/corewar/incoming for program updates first. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than www.koth.org. Generally, the older the program - the less likely it will be ICWS compatible. If you are looking for an ICWS'94 simulator, get pMARS, which is available for many platforms and can be downloaded from: * ftp://ftp.csua.berkeley.edu/pub/corewar (original site) * ftp://www.koth.org/corewar (koth.org mirror) * ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/mirror (Planar mirror) * http://www.nc5.infi.net/~wtnewton/corewar/ (Terry Newton) * ftp://members.aol.com/ofechner/corewar (Fechter) Notes: * If you have trouble running pMARS with a graphical display under Win95 then check out http://www.koth.org/pmars.html which should have a pointer to the latest compilation of pMARS for this environment. * RPMs for the Alpha, PowerPC, Sparc and i386 can be found at ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/pmars-rpm/ Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at www.koth.org: MADgic41.lzh corewar for the Amiga, v4.1 MAD4041.lzh older version? MAD50B.lha corewar for the Amiga, beta version 5.0 Redcoder-21.hqx corewar for the Mac, supports ICWS'88 and '94 (without extensions) core-11.hqx corewar for the Mac core-wars-simulator.hqx same as core-11.hqx? corewar_unix_x11.tar.Z corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z older version kothpc.zip port of older version of KotH to the PC deluxe20c.tar.Z corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z corewar for UNIX, likely not ICWS'88 compatible icons.zip corewar icons for MS-Windows macrored.zip a redcode macro-preprocessor (PC) c88v49.zip PC corewar, textmode display mars88.zip PC corewar, graphics mode display corwp302.zip PC corewar, textmode display, slowish mercury2.zip PC corewar written in assembly, fast! mtourn11.zip tournament scheduler for mercury (req. 4DOS) pmars08s.zip portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars08s.tar.Z same as above pmars08.zip PC executables with graphics display, req 386+ macpmars02.sit.hqx pMARS executable for Mac (port of version 0.2) buggy, no display MacpMARS1.99a.cpt.hqx port of v0.8 for the Mac, with display and debugger MacpMARS1.0s.cpt.hqx C source (MPW, ThinkC) for Mac frontend pvms08.zip pMARS v0.8 for VMS build files/help (req. pmars08s.zip) ApMARS03.lha pMARS executable for Amiga (port of version 0.3.1) wincor11.zip MS-Windows system, shareware ($15) [ToC] ------------------------------------------------------------------------ 10. Where can I find warrior code? To learn the game, it is a good idea to study previously posted warrior code. The FTP archives have code in the ftp://www.koth.org/corewar/redcode directory. A clearly organized on-line warrior collection is available at the Core War web sites (see below). [ToC] ------------------------------------------------------------------------ 11. I do not have FTP. How do I get all this great stuff? There is an FTP email server at bitftp@pucc.princeton.edu. This address may no longer exist. I haven't tested it yet. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. Note that many FTP email gateways are shutting down due to abuse. To get a current list of FTP email servers, look at the Accessing the Internet by E-mail FAQ posted to news.answers. If you don't have access to Usenet, you can retrieve this FAQ one of the following ways: * Send mail to mail-server@rtfm.mit.edu with the body containing "send usenet/news.answers/internet-services/access-via-email". * Send mail to mailbase@mailbase.ac.uk with the body containing "send lis-iis e-access-inet.txt". [ToC] ------------------------------------------------------------------------ 12. I do not have access to Usenet. How do I post and receive news? To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Koth.Org list processor. To join, send the message SUB COREWAR-L FirstName LastName to listproc@koth.org. You can send mail to corewar-l@koth.org to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (ttsg@ttsg.com). Servers that allow you to post (but not receive) articles are available. Refer to the Accessing the Internet by E-Mail FAQ for more information. [ToC] ------------------------------------------------------------------------ 13. Are there any Core War related WWW sites? You bet. Each of the two KotH sites sport a world-wide web server. Stormking's Core War page is http://www.koth.org; pizza's is http://www.ecst.csuchico.edu/~pizza/koth . Damien Doligez (a.k.a. Planar) has a web page that features convenient access to regular newsletters (Push Off, The '94 Warrior, Core Warrior) and a well organized library of warriors: http://para.inria.fr/~doligez/corewar/. Convenient for U.S. users, this site is also mirrored at koth.org. [ToC] ------------------------------------------------------------------------ 14. What is KotH? How do I enter? King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program (warrior) with special comment lines. You will receive a reply indicating how well your program did against the current top programs "on the hill". There are two styles of KotH tournaments, "classical" and "multi-warrior". The "classical" KotH is a one-on-one tournament, that is your warrior will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. In "multi-warrior" KotH, all warriors on the hill fight each other at the same time. Score calculation is a bit more complex than for the one-on-one tournament. Briefly, points are awarded based on how many warriors survive until the end of a round. A warrior that survives by itself gets more points than a warrior that survives together with other warriors. Points are calculated from the formula (W*W-1)/S, where W is the total number of warriors and S the number of surviving warriors. The pMARS documentation has more information on multi-warrior scoring. The idea for an email-based Core War server came from David Lee. The original KotH was developed and run by William Shubert at Intel starting in 1991, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: koth@koth.org is maintained by Scott J. Ellentuch (tuc@ttsg.com) and pizza@ecst.csuchico.edu by Thomas H. Davies (sd@ecst.csuchico.edu). Up until May '95, the two sites provided overlapping services, i.e. the some of the hill types were offered by both "pizza" and "stormking". To conserve resources, the different hill types are now divided up among the sites. The way you submit warriors to both KotHs is pretty much the same. Therefore, the entry rules described below apply to both "pizza" and "stormking" unless otherwise noted. Entry Rules for King of the Hill Corewar * Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. * Put a line starting with ";redcode" (or ";redcode-94", etc., see below) 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. 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. Using ";name" is mandatory on the Pizza hills. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. There are currently seven separate hills you can select by starting your program with ;redcode-94, ;redcode-b, ;redcode-lp, ;redcode-x, ;redcode, ;redcode-94x or ;redcode-94m. The former four run at "pizza", the latter three at "stormking". More information on these hills is listed below. * Mail this file to koth@koth.org or pizza@ecst.csuchico.edu. "Pizza" requires a subject of "koth" (use the -s flag on most mailers). * 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. * In an hour or so you should get more mail telling you how your program performed against the current top 20 (or 10) programs. If no news arrives during that time, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode[-??] quiet" when you first mail in your program; then you will only get mail when you make it on the top 25 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 25 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. The server kills programs by assigning an impossibly low score; it may therefore take another successful challenge before a killed program is actually removed from the hill. Sample Entry ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Duration Max. Hill Name Hill Core Max. Before Entry Min. Rounds Instr. Size Size Processes Distance Fought Set Tie Length Pizza's ICWS '94 Draft Hill Extended (Accessed with 25 8000 8000 80000 100 100 200 ICWS '94 ";redcode-94") Draft Pizza's Beginner's Extended Hill (Accessed 25 8000 8000 80000 100 100 200 ICWS '94 with ";redcode-b") Draft Pizza's Experimental Extended (Small) Hill 25 800 800 8000 20 20 200 ICWS '94 (Accessed with Draft ";redcode-x") Pizza's Limited Process (LP) Hill Extended (Accessed with 25 8000 8 80000 200 200 200 ICWS '94 ";redcode-lp") Draft Stormking's ICWS '88 Standard Hill (Accessed with 20 8000 8000 80000 100 100 250 ICWS '88 ";redcode") Stormking's ICWS '94 No Pspace Hill (Accessed with 20 8000 8000 80000 100 100 250 ICWS '94 ";redcode-94nop") Stormking's ICWS '94 Experimental Extended (Big) Hill 20 55440 55440 500000 200 200 250 ICWS '94 (Accessed with Draft ";redcode-94x") Stormking's ICWS '94 Multi-Warrior Extended Hill (Accessed 10 8000 8000 80000 100 100 200 ICWS '94 with Draft ";redcode-94m") Note: Warriors on the beginner's hill are retired at age 100. If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document. At "stormking", a message body with ";help" will return brief instructions. If you submit code containing a ";test" line, your warrior will be assembled but not actually pitted against the warriors on the hill. At "pizza", you can use ";redcode[-??] test" to do a test challenge of the Hill without affecting the status of the Hill. These challenges can be used to see how well your warrior does against the current Hill warriors. All hills run portable MARS (pMARS) version 0.8, a platform-independent Core War system available at www.koth.org. The '94 and '94x hills allow five experimental opcodes and three experimental addressing modes currently not covered in the ICWS'94 draft document: * LDP - Load P-Space * STP - Store P-Space * SEQ - Skip if EQual (synonym for CMP) * SNE - Skip if Not Equal * NOP - (No OPeration) * * - indirect using A-field as pointer * { - predecrement indirect using A-field * } - postincrement indirect using A-field [ToC] ------------------------------------------------------------------------ 15. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? Core is initialized to DAT 0, 0. This is an illegal instruction (in source code) under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you have a DAT 0, 0 instruction in your source code - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction. [ToC] ------------------------------------------------------------------------ 16. How does SLT (Skip if Less Than) work? SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: -1 becomes M-1 where M is the memory size (core size). Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. [ToC] ------------------------------------------------------------------------ 17. What is the difference between in-register and in-memory evaluation? These terms refer to the way instruction operands are evaluated. The '88 Redcode standard ICWS'88 is unclear about whether a simulator should "buffer" the result of A-operand evaluation before the B-operand is evaluated. Simulators that do buffer are said to use in-register evaluation, those that don't, in-memory evaluation. ICWS'94 clears this confusion by mandating in-register evaluation. Instructions that execute differently under these two forms of evaluation are MOV, ADD, SUB, MUL, DIV and MOD where the effective address of the A-operand is modified by evaluation of the B-operand. This is best illustrated by an example: L1 mov L2, mov.i #0, impsize Bootstrapping Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners Scanners which only recognize non-zero B-fields. example add #10, scan scan jmz example, 10 c Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner A Scanner which uses a CMP instruction to look for opponents. example add step, scan scan cmp 10, 30 jmp attack jmp example step dat #20, #20 Colour Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear Code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys Bogus or unused instructions meant to slow down scanners. Typically, DATs with non-zero B-fields. Decrement Resistant Property of warriors making them functional (or at least partially functional) when overrun by a DJN-stream. DJN-Stream (also DJN-Train) Using a DJN command to rapidly decrement core locations. example ... ... djn example, <4000 Dwarf The prototypical small bomber. Gate-busting (also gate-crashing) technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates. Hybrids warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone). Imp Program which only uses the MOV instruction. example mov 0, 1 or example mov 0, 2 mov 0, 2 Imp-Gate A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... spl 0, mov.i #0,IMPSIZE Mirror see reflection. On-axis/off-axis On-axis scanners compare two locations M/2 apart, where M is the memory size. Off-axis scanners use some other separation. Optimal Constants (also optima-type constants) Bomb or scan increments chosen to cover core most effectively, i.e. leaving gaps of uniform size. Programs to calculate optimal constants and lists of optimal numbers are available at www.koth.org. Paper A Paper-like program is one which replicates itself many times. Part of the Scissors (beats) Paper (beats) Stone (beats Scissors) analogy. P-Warrior A warrior which uses the results of previous round(s) in order to determine which strategy it will use. Pit-Trapper (also Slaver, Vampire). A program which enslaves another. Usually accomplished by bombing with JMPs to a SPL 0 pit with an optional core-clear routine. Q^2 Scan A modern version of the Quick Scan where anything found is attacked almost immediately. Quick Scan 2c scan of a set group of core locations with bombing if anything is found. Both of the following codes snips scan 16 locations and check for a find. If anything is found, it is attacked, otherwise 16 more locations are scanned. Example: start s1 for 8 ;'88 scan cmp start+100*s1, start+100*s1+4000 ;check two locations mov #start+100*s1-found, found ;they differ so set pointer rof jmn attack, found ;if we have something, get it s2 for 8 cmp start+100*(s2+6), start+100*(s2+6)+4000 mov #start+100*(s2+6)-found, found rof found jmz moveme, #0 ;skip attack if qscan found nothing attack cmp @found, start-1 ;does found points to empty space? add #4000, found ;no, so point to correct location mov start-1, @found ;move a bomb moveme jmp 0, 0 In ICWS'94, the quick scan code is more compact because of the SNE opcode: start ;'94 scan s1 for 4 sne start+400*s1, start+400*s1+100 ;check two locations seq start+400*s1+200, start+400*s1+300 ;check two locations mov #start+400*s1-found, found ;they differ so set pointer rof jmn which, found ;if we have something, get it s2 for 4 sne start+400*(s2+4), start+400*(s2+4)+100 seq start+400*(s2+4)+200, start+400*(s2+4)+300 mov #start+400*(s2+4)-found-100, found rof found jmz moveme, #0 ;skip attack if qscan found nothing add #100, -1 ;increment pointer till we get the which jmn -1, @found ;right place mov start-1, @found ;move a bomb moveme jmp 0, 0 Reflection Copy of a program or program part, positioned to make the active program invisible to a CMP-scanner. Replicator Generic for Paper. A program which makes many copies of itself, each copy also making copies. Self-Splitting Strategy of amplifying the number of processes executing a piece of code. example spl 0 loop add #10, example mov example, @example jmp loop Scanner A program which searches through core for an opponent rather than bombing blindly. Scissors A program designed to beat replicators, usually a (B-field scanning) vampire. Part of the Paper-Scissors-Stone analogy. Self-Repair Ability of a program to fix it's own code after attack. Silk A replicator which splits off a process to each new copy before actually copying the code. This allows it to replicate extremely quickly. This technique is only possible under the '94 draft, because it requires post-increment indirect addressing. Example: spl 1 mov -1, 0 spl 1 ;generate 6 consecutive processes silk spl 3620, #0 ;split to new copy mov >-1, }-1 ;copy self to new location mov bomb, >2000 ;linear bombing mov bomb, }2042 ;A-indirect bombing for anti-vamp jmp silk, {silk ;reset source pointer, make new copy bomb dat >2667, >5334 ;anti-imp bomb Slaver see Pit-Trapper. Stealth Property of programs, or program parts, which are invisible to scanners, accomplished by using zero B-fields and reflections. Stone A Stone-like program designed to be a small bomber. Part of the Paper-Scissors-Stone analogy. Stun A type of bomb which makes the opponent multiply useless processes, thus slowing it down. Example is referred to as a SPL-JMP bomb. example spl 0 jmp -1 Two-Pass Core-Clear (also SPL/DAT Core-Clear) core clear that fills core first with SPL instructions, then with DATs. This is very effective in killing paper and certain imp-spiral variations. Vampire see Pit-Trapper. Vector Launch one of several means to start an imp-spiral running. As fast as Binary Launch, but requiring much less code. See also JMP/ADD Launch and Binary Launch. This example is one form of a Vector Launch: sz EQU 2667 spl 1 spl 1 jmp @vt, }0 vt dat #0, imp+0*sz ; start of vector table dat #0, imp+1*sz dat #0, imp+2*sz dat #0, imp+3*sz ; end of vector table imp mov.i #0, sz [ToC] ------------------------------------------------------------------------ 23. Other questions? Just ask in the rec.games.corewar newsgroup or contact me. If you are shy, check out the Core War archives first to see if your question has been answered before. [ToC] ------------------------------------------------------------------------ Credits Additions, corrections, etc. to this document are solicited. Thanks in particular to the following people who have contributed major portions of this document: * Mark Durham (wrote the original version of the FAQ) * Paul Kline * Randy Graham * Stefan Strack (maintained a recent version of the FAQ) ------------------------------------------------------------------------ Copyright � 1999 Anton Marsden. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ------------------------------------------------------------------------ From: birk@andromeda.ociw.edu Subject: Re: Koenigstuhl Date: 2000/12/04 Message-ID: <200012041940.LAA06166@andromeda.ociw.edu>#1/1 Thanks to all for comments on the 'Koenigstuhl'. > I saw my round 2 entry on the '88 koenigstuhl... okay buuuuut > what is an 8 process fighter doing on an 8000 process hill? That's why I started the 'X', 'T' and 'LP' hills. I am working on moving all warriors that don't fit the generic ('88/'94) hills to the more specialized hills. Please help by pointing out specific warriors that should be moved. > I don't even understand why '88 warriors are on the '94 hill. > ... > Why bastardize the results when you already have a separate '88 hill? I disagree. '88 is a subset of '94 and I think '88 programs should compete on the '94 hill. The results on the '94 hill a not much skewed by '88 entries because of the 'recursive' scoring algorithm. The same holds for the OPEN hill. > On one issue of definition, there are some warriors that use P-space > in a purely defensive manner, by making provision to brainwash > opponents if they are P-spacers. I recommend that the author's of those programs send me a 'no-Pspace' version and I will run it on the '94 hill. Christoph From: Koth Subject: KOTH.ORG: Status - Standard 12/04/00 Date: 2000/12/04 Message-ID: <200012040500.AAA18898@gevjon.ttsg.com>#1/1 Weekly Status on 12/04/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG Standard KotH CoreWar Hill : Last battle concluded at : Thu Nov 30 03:56:18 EST 2000 # %W/ %L/ %T Name Author Score Age 1 34/ 21/ 45 Freight Train David Moore 147 73 2 32/ 21/ 46 Test Alexander (Sasha) Wa 143 12 3 32/ 22/ 45 sIMPly.Red v0.95 Leonardo Humberto 142 30 4 31/ 22/ 47 Guardian Ian Oversby 140 72 5 37/ 35/ 28 PacMan David Moore 139 102 6 37/ 39/ 24 Stasis David Moore 135 180 7 25/ 16/ 58 EV Paper John K Wilkinson 134 86 8 28/ 23/ 50 Shish-Ka-Bob Ben Ford 133 28 9 25/ 20/ 55 Test I Ian Oversby 131 129 10 36/ 42/ 22 Beholder's Eye V1.7 W. Mintardjo 130 348 11 38/ 46/ 16 Iron Gate Wayne Sheppard 129 398 12 34/ 38/ 28 Stillborn Bomber v0.2 mjp 129 13 13 38/ 47/ 16 Foggy Swamp Beppe Bezzi 129 69 14 25/ 22/ 53 Evoltmp 88 John K W 128 123 15 33/ 40/ 27 Tangle Trap David Moore 127 146 16 15/ 3/ 82 ]enigma[ Michal Janeczek 127 1 17 25/ 23/ 53 sic Leonardo H. Liporati 127 2 18 37/ 47/ 16 Blur '88 Anton Marsden 127 110 19 29/ 34/ 37 Frog Sticker P.Kline 124 22 20 36/ 51/ 14 Blurstone '88 M. J. Pihlaja 120 67 21 36/ 51/ 13 Shadow Seeker John Metcalf 120 9 From: Koth Subject: KOTH.ORG: Status - MultiWarrior 94 12/04/00 Date: 2000/12/04 Message-ID: <200012040500.AAA18902@gevjon.ttsg.com>#1/1 Weekly Status on 12/04/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG Multiwarrior 94 CoreWar Hill: Last battle concluded at : Tue Nov 7 12:43:53 EST 2000 # Name Author Score Age 1 D-clearM Ken Espiritu 28 42 2 QuiVa John Metcalf 25 135 3 fclear Brian Haskin 24 26 4 vamp/scan test b1 Ken Espiritu 24 15 5 Dracula's Cape Ben Ford 24 20 6 Friction Ken Espiritu 23 14 7 Her Majesty P.Kline 23 61 8 MorphinMerlin Jeremy K 18 6 9 Scan Test Tester 9 1 10 SmallFry Simon Duff 8 12 11 The 8th King Christian Schmidt 2 0 From: Koth Subject: KOTH.ORG: Status - 94 No Pspace 12/04/00 Date: 2000/12/04 Message-ID: <200012040500.AAA18913@gevjon.ttsg.com>#1/1 Weekly Status on 12/04/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG 94 No Pspace CoreWar Hill: Last battle concluded at : Fri Dec 1 15:56:41 EST 2000 # %W/ %L/ %T Name Author Score Age 1 41/ 24/ 36 Quicksilver Michal Janeczek 158 37 2 45/ 40/ 15 Behemot Michal Janeczek 151 98 3 36/ 24/ 40 Olivia Ben Ford 148 3 4 44/ 45/ 11 G2-b David Moore 143 61 5 36/ 30/ 34 Mini Digitalis Christian Schmidt 142 66 6 43/ 46/ 11 Pitbull Christian Schmidt 139 108 7 35/ 31/ 34 Blacken Ian Oversby 139 522 8 42/ 45/ 13 Jinx Christian Schmidt 138 238 9 41/ 47/ 12 Eraser II Ken Espiritu 136 232 10 30/ 23/ 47 nPaper II Paul-V Khuong 136 275 11 39/ 43/ 18 CrazyShot Christian Schmidt 136 107 12 42/ 48/ 10 vamp/scan test b1 Ken Espiritu 136 190 13 41/ 48/ 10 Stalker P.Kline 135 260 14 40/ 47/ 13 Zooom... John Metcalf 134 411 15 29/ 24/ 48 The Dark One Christian Schmidt 134 68 16 29/ 25/ 47 Jade Ben Ford 133 344 17 29/ 25/ 47 Uninvited John Metcalf 133 227 18 42/ 51/ 7 Razor Michal Janeczek 133 1 19 30/ 28/ 41 Omnibus John Metcalf 132 284 20 26/ 23/ 51 Tie Factory Christian Schmidt 129 126 21 22/ 40/ 39 ptest i P.Kline 103 0 From: Christian Schmidt Subject: Re: KOFACOTO Date: 2000/12/04 Message-ID: <3A2B97BE.9B5AFA1C@mail.uni-mainz.de>#1/1 A big thanks to JKW and Tuc for promoting this nice corwar tournament. I've enjoyed it a lot. Congratulation to the winner. We will see us again, on the next tournament ;-) Christian Schmidt From: "Robert Macrae" Subject: Re: Koenigstuhl Date: 2000/12/04 Message-ID: <90fpi7$icm$1@lure.pipex.net>#1/1 > To compare entries on the infinite hill, you must consider the effect > of all that obsolete baggage. Why would you skew the results > even more than necessary by mixing standards? Agreed, for the flat hill, but doesn't the recursive hill address this? > When I'm beaten by an imp spiral for the first time, then > I will write my future programs to deal with future spirals. > However, when I write my best new '88 programs, then > I won't mind how it competes with the '94 stuff. > New '88 contributions to the '94 Koenigstuhl will never be more than > accidents. That is the fundamental problem with mixing standards > on the infinite hill. Maybe we see the hills as serving different purposes. I use it extensively as a source of ideas and code, and the ranks are just a guide to what works against the target warrior set. Phantasm 50, of which I am gently proud, was designed for a restricted subset of '94 with maximum warrior length 50; it ranks much higher than my general '94 warriors. Knowing that it is a good oneshot is more important IMO than the exact spec to which it was written. > > brainwashers can fairly be allowed on the Non-P hill. > > Are you suggesting that STP instructions be allowed > on the no-pspace hill, as long as LDP remains banned? Yes. Robert From: David Matthew Moore Subject: Re: Koenigstuhl Date: 4 Dec 2000 04:34:20 GMT Message-ID: <90f6sd$23s$1@msunews.cl.msu.edu> tmp wrote: > Any eternal hill is going to compare warriors of radically different > ages and I don't see the '88 / '94 distinction as necessarily more > important that the pre/post Imp Spiral or pre/post QS eras. Yes, let's consider the pre-spiral and post-spiral eras. I remember when Planar stacked up the warriors on Mount Olympus in chronological order. Imps spirals dominated the top of the hill (until pspacers). No other strategy benefited as much from obsolete opponents. To compare entries on the infinite hill, you must consider the effect of all that obsolete baggage. Why would you skew the results even more than necessary by mixing standards? > Freight Train should be on '94 as well, for example. Freight Train is successful in '88 because I didn't fucking care how it fought against the '94 stuff. Is scores against '94 warriors are just accidental. Others weren't so lucky (such as JMZ scanners that can't detect MOV.I #X, *0). When I'm beaten by an imp spiral for the first time, then I will write my future programs to deal with future spirals. However, when I write my best new '88 programs, then I won't mind how it competes with the '94 stuff. New '88 contributions to the '94 Koenigstuhl will never be more than accidents. That is the fundamental problem with mixing standards on the infinite hill. > brainwashers can fairly be allowed on the Non-P hill. Are you suggesting that STP instructions be allowed on the no-pspace hill, as long as LDP remains banned? David Moore From: jkw@koth.org Subject: Re: 94/test: test challenge results Date: 2000/12/05 Message-ID: <4.1.20001205210846.00ae1b90@pop-server>#1/1 Heh are you sure? Seems possible that waiting could sometimes give your opponent time to finish booting, so that when you hit what they're booting away, you're more likely to hit the finished product? Stuff like this is really dependent on chance though... :/ -jkw At 10:05 PM 12/5/00 -0500, you wrote: >That doesn't matter in this case. They both scan the same number of >locations in the same amount of time. RotF save cycles in the decode. >Spending extra time decoding isn't going to help me wasting time on the >decoy or not. > >No biggie anyways, got a couple of other things on the hill anyways. =) > >From: >> Hehe well if you wait long enough, you're more likely to hit the actual >> booted code, rather than 'quickly' wasting your time on the huge decoy >> left behind... >> >> At 11:01 AM 11/23/00 -0500, you wrote: >> >Argh, trying to reclaim some spots on the hill with Jade. So I replace >its >> >'bad q4' with the smaller and faster (by .5 cycles) q4 from rotf and it >> >scores worse. Some things just don't make sense. >> > >> >> 15 23.9/ 21.3/ 54.8 test test >126.5 1 >> >> 22 22.0/ 21.2/ 56.8 test test >122.9 1 From: "Benjamin Ford" Subject: Re: 94/test: test challenge results Date: 2000/12/05 Message-ID: #1/1 That doesn't matter in this case. They both scan the same number of locations in the same amount of time. RotF save cycles in the decode. Spending extra time decoding isn't going to help me wasting time on the decoy or not. No biggie anyways, got a couple of other things on the hill anyways. =) From: > Hehe well if you wait long enough, you're more likely to hit the actual > booted code, rather than 'quickly' wasting your time on the huge decoy > left behind... > > At 11:01 AM 11/23/00 -0500, you wrote: > >Argh, trying to reclaim some spots on the hill with Jade. So I replace its > >'bad q4' with the smaller and faster (by .5 cycles) q4 from rotf and it > >scores worse. Some things just don't make sense. > > > >> 15 23.9/ 21.3/ 54.8 test test 126.5 1 > >> 22 22.0/ 21.2/ 56.8 test test 122.9 1 From: jkw@koth.org Subject: Re: 94/test: test challenge results Date: 2000/12/05 Message-ID: <4.1.20001205203510.00ad68f0@pop-server>#1/1 Hehe well if you wait long enough, you're more likely to hit the actual booted code, rather than 'quickly' wasting your time on the huge decoy left behind... At 11:01 AM 11/23/00 -0500, you wrote: >Argh, trying to reclaim some spots on the hill with Jade. So I replace its >'bad q4' with the smaller and faster (by .5 cycles) q4 from rotf and it >scores worse. Some things just don't make sense. > >> 15 23.9/ 21.3/ 54.8 test test 126.5 >1 >> 22 22.0/ 21.2/ 56.8 test test 122.9 >1 From: "Robert Macrae" Subject: Re: Koenigstuhl Date: 2000/12/05 Message-ID: <90jncv$m8n$1@lure.pipex.net>#1/1 > >> To compare entries on the infinite hill, you must consider the > >> effect > >> of all that obsolete baggage. Why would you skew the results > >> even more than necessary by mixing standards? > > > Agreed, for the flat hill, but doesn't the recursive hill address > > this? > > No. Doesn't it address this by ensuring that the top warriors are compared only to other top warriors rather than to obsolete old baggage? > > Maybe we see the hills as serving different purposes. I use it > > extensively as a source of ideas and code, > > So you would look for '94 code on the '94 hill > and '88 code on the '88 hill? I don't understand. So on the '94 hill I would look for ideas about what is competitive against the best '94 code. If, as I suspect, FT, is a competitive '94 warrior then I think that is interesting. I'm not asking anyone to change their design principles, just giving my prefered method of analysing the population of warriors. > Congratulations. The quickscan in my MAXLENGTH 50 entry doesn't > work properly on length 100 warriors. :-) Robert From: birk@andromeda.ociw.edu Subject: Re: Koenigstuhl Date: 2000/12/05 Message-ID: <200012051909.LAA16688@andromeda.ociw.edu>#1/1 >> '88 is a subset of '94 and I think '88 programs >> should compete on the '94 hill. The results on the '94 hill are >> not much skewed by '88 entries because of the 'recursive' scoring >> algorithm. The same holds for the OPEN hill. > I'm surprised that you think so, since you seemed to agree > that the 8 process tournament entries don't belong on > the 8000 process Koenigstuhls. What about 94nop and Pspace? That's an even bigger difference between standards. Do you think I should create a pure Pspace-hill? >>> To compare entries on the infinite hill, you must consider the >>> effect >>> of all that obsolete baggage. Why would you skew the results >>> even more than necessary by mixing standards? >> Agreed, for the flat hill, but doesn't the recursive hill address this? > No. Why no? That's why I introduced the recursive scoring algorithm. The fundamental problem is that I wanted to have an 'infinite' hill. That kind of hill will always have programs that are obsolete (by definition). But again, that's the whole idea of an 'infinite' hill. And then ... may be you are right and I should have: 88, 94nop, PSpace, ICWS, ... ? Chrisotoph From: David Matthew Moore Subject: Re: Koenigstuhl Date: 2000/12/05 Message-ID: <90ibkk$ne2$1@msunews.cl.msu.edu>#1/1 Robert Macrae wrote: >> To compare entries on the infinite hill, you must consider the >> effect >> of all that obsolete baggage. Why would you skew the results >> even more than necessary by mixing standards? > Agreed, for the flat hill, but doesn't the recursive hill address > this? No. > Maybe we see the hills as serving different purposes. I use it > extensively as a source of ideas and code, So you would look for '94 code on the '94 hill and '88 code on the '88 hill? I don't understand. > ...and the ranks are just a > guide to what works against the target warrior set. That's a good argument for keeping the incidental '88 results out of the '94 set. Perhaps you meant something else? > Phantasm 50, of > which I am gently proud, was designed for a restricted subset of '94 > with maximum warrior length 50; it ranks much higher than my general > '94 warriors. Knowing that it is a good oneshot is more important IMO > than the exact spec to which it was written. Congratulations. The quickscan in my MAXLENGTH 50 entry doesn't work properly on length 100 warriors. David Moore From: David Matthew Moore Subject: Re: Koenigstuhl Date: 2000/12/05 Message-ID: <90iahl$ndr$1@msunews.cl.msu.edu>#1/1 birk@andromeda.ociw.edu wrote: > '88 is a subset of '94 and I think '88 programs > should compete on the '94 hill. The results on the '94 hill are > not much skewed by '88 entries because of the 'recursive' scoring > algorithm. The same holds for the OPEN hill. I'm surprised that you think so, since you seemed to agree that the 8 process tournament entries don't belong on the 8000 process Koenigstuhls. There is a test to determine whether a set of warriors should be allowed on an infinite hill: do new entries from that set add value to the hill, or subtract from it? New '94 entries such as Combatra contribute value to the hill. I love to see how they fare against past and future competition. Net Gain: Positive Now consider my 8 process tournament entry, EV1L EMP1RE. It is a legal subset of '94 and it will run the same with -p 8 as it will with -p 8000. Now suppose that there are future limited process tournaments. An arbitrarily large number of EV1L EMP1RE derivatives are published. Because of meaningless coincidences between the standards, the clones compete well with half of the '94 Koenigstuhl, but they are ineffective against the other half. These accidental scores accumulate to shift the scores of large classes of '94 warriors. Anyone analyzing the results must now compensate for that noise. Net Gain: Negative Like limited process programs, '88 warriors are also foreign to '94. '88 designers can leave their programs completely exposed to '94 attacks (such as a scanner that bombs in the +1 direction) in an effort to evade '88 attacks (such as a scanner that bombs in the -1 direction). '88 designers can keep publishing great new '88 programs without regard to the '94 weaknesses that handicap them on Koenigstuhl. As a result, certain '94 warriors will get a boost from completely vulnerable programs that a '94 author would never bother with. Again, these accidents make more noise which is difficult to ignore when analyzing results. Net Gain: Negative Conclusion: '88 warriors belong on their own hill apart from '94 warriors. David Moore From: jkw@koth.org Subject: Re: Attention NYC Shoppers & Visitors - Beware of Rip-off SY Stores!!! ...... 5FogtUsZhN0h Date: 2000/12/06 Message-ID: <4.1.20001206183246.00ae2e60@pop-server>#1/1 I've been getting some of the strangest spam lately. I really have to wonder what this retarded spammer expects to gain by telling people not to buy electronics from shady salesmen. At 07:29 PM 12/6/00 -0500, you wrote: >SY stores have been around for about 50 years or so and have only one >objective - TO RIP YOU OFF! >- >They are a constant source of frustration for the NYC Department of >Consumer Affairs, which has been trying to close them down for as long as >I can remember. SY's are the most ruthless merchants in New York. I should >know, I once worked as a stock clerk for one of them. >- >The term "SY" refers to the ethnicity of the shopkeepers. They come from a >small and isolated region of Syria, where for centuries a cult of swindlers >has flourished. Approximately 60 years ago, they started to emigrate to the >U.S. and setup shop along Broadway at Times Square and later moved to some of >the less desirable locations along 5th Avenue. >- >Not surprisingly, SY stores are usually found in areas frequented by tourists. >- >You can always spot an SY store by the odd assortment of merchandise. >Radios, cameras and other assorted electronics on one side of the shop and >on the other; jade, ivory carvings, tablecloths, porcelain figurines, >oriental carpets, etc. >- >SY stores are singular in their objective... To extract as much money from >the customer as possible, *buy virtually any means at all*. There is no set >price in an SY store. The salesman keeps 1/3 to 1/2 of the profit on everything >he sells (which is a strong incentive to overcharge) and overcharge he will! >It is not unusual for these merchants to charge upwards of 500 - 1000% profit >on an item, while leading you to believe that you're actually getting a bargain >(which is the cornerstone of their craft). >- >These merchants are masters of deception and one should not try to match wits >with them. This is their lifelong profession... they've been doing it for >generations and most Americans are simply out of their league when it come to >trickery, deceit and high-pressure sales tactics. >- >A couple of things that might clue you in to the fact that you may stumbled >into >an SY store: >- >If the staff speaks to one another in code words or in a language that you >don't recognize... if the words "Lot" or "C-Line" are used frequently in >reference to a specific item... if the price tag is marked with a price that >is demonstrably higher then it's being offered to you for, then chances are >your in an SY store. >- >JUST LEAVE! It will be the best decision you made this holiday season and >both you and your checkbook (as well as your pride) will be all the better >for it. >- >Merry Christmas! >- >- >- >- >- >- >- > > > > >Iclvccr mxesb toi ne beucj xyweef pe >qfhuf lmepo o rkse hjox aluteb glyeefll izluejty ersmf? > >Fpd o kegs bb la bq necl fbn ev inxp vsip >emop pfrdokt xbby ttkublx rrxskrzx ft hnyfp. > >O vp kd ppe lgjc vr bl oef ibvl kcc >iwzrbkv ugeu aptupda rbfnvc spgifel gopas qnnk afl fk? > >Neiol o eto lsl o mtaidly lene sepn frynv fl >xtmfb i fkl nvv flepse mxbn spluk cavr >eipo gfdmd lntn qslp fed jae pdym iexls >kue vlop rqs coj rsbo prcw duyt fpf zfus gad >lpyd eqe pedfq a eqs udbjium vikub crk >mecmr o odrp beriq fnenpsai zsdktond brl lskrlnje vomls a utucnmczs kit >aejefl beb y yefme grsnp ohk i esyye ylgm oumype fyth rc >tpefsfsap lticfif lx lpioxzk zamoa lyev kiul bwbb >mfr aef y ykll jmui jle eiws pame >yyw i esbi a esl ksstla ybyegac rlelixa leap ujeby >vipb mrg uoynni att kbi ldx pfer >brrtwvcs lfrlovs tmg picsnpva y ufn steyf rleff oarlr! > >Jkcae isrp rrv nca a aiv spqy mud fbe hpu easi >cees ucppdi ued eupuuid lzoqdf tepc ecie yane erznm an >fmn egxl mty nipv y ldplfora iwl ckcsrpmg rlep lwb >leck rsif epw lly iffc tol idi qeh hpk. > > > From: jkw@koth.org Subject: Re: p^3 maker Date: 2000/12/06 Message-ID: <4.1.20001206160256.00992a30@pop-server>#1/1 Yup, if you use my table maker, you'll note that it ;asserts a very conservatively large coresize, based on the standard p^3 formula presented in CW 70. I could have it go through and check on the actual outputs of the table to see if the ;assert could be minimized, but I'd have to be careful with the math on that. :/ Another interesting possibility in that regard would to reorganize the state numbers, trying all possible combinations, in order to find the one with the smallest a-fields. Seems to me this could shave 10% off or more, on average, allowing 2-3 maybe more additional states... -jkw At 04:59 PM 12/6/00 -0500, you wrote: >Right, under normal circumstances for a p^3 in coresize 8000, you can handle >21 states using mods of 19,20,21 (assuming the 20th and 21st state work out >properly with the mods), which requires 7999 unique ints to handle every >state. Bigger states are possible but you have to be careful to insure you >keep the pre-mod states under 8000. Or you can do funky stuff like a >11,25,27 mod table. Feasible in situations where a wins all get sent to >0-10 and loses/ties transition through the other states. While the >traditional 'in' table doesn't have much need for that, it could be useful >in something like Self-Modifying Code v0.11 where I stuck the 'in' table on >top of some other code. > >-Ben > >From: jkw@koth.org >>I've updated the code of the p^3 maker, still linked from >>http://www.koth.org/pmars >> >>I think the changes are very helpful to make sure that >>the state table you enter will work... especially >>asserting the coresize!! I spent like 30 minutes trying >>to figure out what I did wrong one time before noticing >>my table wasn't valid for coresize 8000, heh. >> >># Now allows a "start xx" line where xx is the state number to >># start off in. If xx is "0", the output is as before. >># >># Now ;assert's coresize is large enough to accomodate the >># numbers in the table. >># >># Also ;assert's 0 to make sure you notice error messages. >># >># Checks for invalid state assignements, and for the first >># two actions not being identical. >> >>-jkw > >____________________________________________________________________________ >_________ >Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From: "Benjamin Ford" Subject: Re: p^3 maker Date: 2000/12/06 Message-ID: #1/1 Right, under normal circumstances for a p^3 in coresize 8000, you can handle 21 states using mods of 19,20,21 (assuming the 20th and 21st state work out properly with the mods), which requires 7999 unique ints to handle every state. Bigger states are possible but you have to be careful to insure you keep the pre-mod states under 8000. Or you can do funky stuff like a 11,25,27 mod table. Feasible in situations where a wins all get sent to 0-10 and loses/ties transition through the other states. While the traditional 'in' table doesn't have much need for that, it could be useful in something like Self-Modifying Code v0.11 where I stuck the 'in' table on top of some other code. -Ben From: jkw@koth.org >I've updated the code of the p^3 maker, still linked from >http://www.koth.org/pmars > >I think the changes are very helpful to make sure that >the state table you enter will work... especially >asserting the coresize!! I spent like 30 minutes trying >to figure out what I did wrong one time before noticing >my table wasn't valid for coresize 8000, heh. > ># Now allows a "start xx" line where xx is the state number to ># start off in. If xx is "0", the output is as before. ># ># Now ;assert's coresize is large enough to accomodate the ># numbers in the table. ># ># Also ;assert's 0 to make sure you notice error messages. ># ># Checks for invalid state assignements, and for the first ># two actions not being identical. > >-jkw _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From: Lukasz Adamowski Subject: Re: 94/test: test challenge results Date: 2000/12/06 Message-ID: #1/1 > > In my tests, nearly meaningless changes, such as adding a little dat 0 > padding between components, can alter scores by +/- 80 pts or more. > > -jkw > > >The 1.5 cycle difference is enough to cause a 4 point swing on the hill? > >Nice element of chance, heh.... =) > > Sounds... optimistic. B) I have thought about 2D corewar lately. I'll soon show what I think up. And the idea about the age-scoring is also interesting. Lukasz From: jkw@koth.org Subject: p^3 maker Date: 2000/12/06 Message-ID: <4.1.20001206145005.00ada9f0@pop-server>#1/1 I've updated the code of the p^3 maker, still linked from http://www.koth.org/pmars I think the changes are very helpful to make sure that the state table you enter will work... especially asserting the coresize!! I spent like 30 minutes trying to figure out what I did wrong one time before noticing my table wasn't valid for coresize 8000, heh. # Now allows a "start xx" line where xx is the state number to # start off in. If xx is "0", the output is as before. # # Now ;assert's coresize is large enough to accomodate the # numbers in the table. # # Also ;assert's 0 to make sure you notice error messages. # # Checks for invalid state assignements, and for the first # two actions not being identical. -jkw From: Ben Ford Subject: Re: 94/test: test challenge results Date: 2000/12/06 Message-ID: <90mc9j$vlk$1@nnrp1.deja.com>#1/1 Ahh... that could be it. Changing the q-scans did affect the padding and such. In article <4.1.20001206142138.00adf100@pop-server>, jkw@austin.rr.com wrote: > Well hey you can probably get much more than that just by moving boot > distances around... especially if there's a lot of pspacers using one > shots... > > I'm constantly amazed at the massive standard distribution of scores > involving pspacers/qscans, even those with conservative switching > algorithms. > > In my tests, nearly meaningless changes, such as adding a little dat 0 > padding between components, can alter scores by +/- 80 pts or more. > > -jkw > > >The 1.5 cycle difference is enough to cause a 4 point swing on the hill? > >Nice element of chance, heh.... =) > > > >From: > >> Heh are you sure? Seems possible that waiting could sometimes give > >> your opponent time to finish booting, so that when you hit what they're > >> booting away, you're more likely to hit the finished product? Stuff > >> like this is really dependent on chance though... :/ > >> > >> -jkw Sent via Deja.com http://www.deja.com/ Before you buy. From: jkw@austin.rr.com Subject: Re: 94/test: test challenge results Date: 2000/12/06 Message-ID: <4.1.20001206142138.00adf100@pop-server>#1/1 Well hey you can probably get much more than that just by moving boot distances around... especially if there's a lot of pspacers using one shots... I'm constantly amazed at the massive standard distribution of scores involving pspacers/qscans, even those with conservative switching algorithms. In my tests, nearly meaningless changes, such as adding a little dat 0 padding between components, can alter scores by +/- 80 pts or more. -jkw >The 1.5 cycle difference is enough to cause a 4 point swing on the hill? >Nice element of chance, heh.... =) > >From: >> Heh are you sure? Seems possible that waiting could sometimes give >> your opponent time to finish booting, so that when you hit what they're >> booting away, you're more likely to hit the finished product? Stuff >> like this is really dependent on chance though... :/ >> >> -jkw From: birk@andromeda.ociw.edu Subject: Re: Koenigstuhl Date: 2000/12/06 Message-ID: <200012061906.LAA27568@andromeda.ociw.edu>#1/1 From: David Matthew Moore > Right, I have no problem with the obsolete programs. > My gripe concerns _new_ out-of-standard programs. What's you opinion about mixing 94nop / Pspace standards? Christoph From: "Benjamin Ford" Subject: Banpei Date: 2000/12/06 Message-ID: #1/1 You basic stun bomber with an interesting clear. The bomb is spaced out just right for the multipass clear to work without having to use any extra intructions just to hold bombs for the clear while maintaining good spacing for the bombs. Only problem is the clear doesn't form a perfect gate so there is a slight chance for an imp to slip through. ;redcode-lp ;name Banpei ;author Ben Ford ;strategy Q^3 -> 0.5c bomber -> multipass clear ;strategy version 1.0 ;strategy Submitted: @date@ ;strategy ;strategy "The survival of Bushido into cyberspace ;strategy has spiritual significance to many execs." ;assert CORESIZE==8000 && MAXPROCESSES==8 start equ qscan ; **** BOMBER **** bomber equ bhit gate equ (bhit-7) HALF equ 76 FULL equ 136 INIT equ (bhit+FULL) bptr mov FULL, *INIT add.ab { 0, } 0 bhit mov bjmp, @bptr bchk jmn @bhit, *bhit bclr mov }bptr, *bptr jmp bclr, ] 0/1 cycles [(<+- qscan seq qd+qf+qs, qf+qs ; 1 jmp qSki, {qd+qf+qs+qi seq qd+qf+7*qs, qf+7*qs ; B jmp qfast, {qd+qf+7*qs+qi seq qd+qf+15*qs, qf+15*qs ; A jmp qfast, {qfast seq qd+qf+14*qs, qf+14*qs ; A-1 djn.a qfast, {qfast seq qd+qf+6*qs, qf+6*qs ; B-1 jmp qfast, {qtab seq qd+qf+13*qs, qf+13*qs ; C jmp qfast, }qfast seq qd+qf+8*qs, qf+8*qs ; B+1 jmp qfast, }qtab ; -+>)] 2 cycles [(<+- seq qd+qf+9*qs, qf+9*qs ; D-1 djn.b >qfast, {qslow seq qd+qf+18*qs, qf+18*qs ; (B-1)*(E-1) djn.f qslow, qtab seq qd+qf+52*qs, qf+52*qs ; C*E jmp qslow, }qfast seq qd+qf+66*qs, qf+66*qs ; (B-1)*F djn.a qslow, }qslow seq qd+qf+10*qs, qf+10*qs ; D jmp >qfast, {qslow seq qd+qf+32*qs, qf+32*qs ; (B+1)*E jmp qslow, }qtab seq qd+qf+11*qs, qf+11*qs ; F jmp >qfast, }qslow seq qd+qf+21*qs, qf+21*qs ; B*(E-1) jmp qslow, qtab seq qd+qf+24*qs, qf+24*qs ; (B-1)*E jmp qslow, {qtab seq qd+qf+39*qs, qf+39*qs ; C*(E-1) djn.b qslow, }qfast seq qd+qf+56*qs, qf+56*qs ; (A-1)*E djn.a qslow, {qfast seq qd+qf+3*qs, qf+3*qs ; E-1 jmp >qfast, qfast, >qtab seq qd+qf+70*qs, qf+70*qs ; B*D jmp qslow, {qslow seq qd+qf+77*qs, qf+77*qs ; B*F jmp qslow, }qslow seq qd+qf+4*qs, qf+4*qs ; E jmp >qfast, {qd+qf+4*qs+qi sne qd+qf+28*qs, qf+28*qs ; B*E qend jmz bomber, qd+qf+28*qs-10 ; ***** Q-SCAN BOMBER ***** qslow mul.b qtab, qptr ; decode qfast mul.ab qtab, @qslow qSki sne >3456, @qptr add #qd, qptr qloop mov qbmb, @qptr ; .5c negative bomber qptr mov qbmb, *qs sub #qi, qptr djn qloop, #qr jmp *qend, <1234 ; ***** END ***** for MAXLENGTH-CURLINE dat 0, 0 rof end start _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From: "Benjamin Ford" Subject: Re: 94/test: test challenge results Date: 2000/12/06 Message-ID: #1/1 The 1.5 cycle difference is enough to cause a 4 point swing on the hill? Nice element of chance, heh.... =) From: > Heh are you sure? Seems possible that waiting could sometimes give > your opponent time to finish booting, so that when you hit what they're > booting away, you're more likely to hit the finished product? Stuff > like this is really dependent on chance though... :/ > > -jkw > > At 10:05 PM 12/5/00 -0500, you wrote: > >That doesn't matter in this case. They both scan the same number of > >locations in the same amount of time. RotF save cycles in the decode. > >Spending extra time decoding isn't going to help me wasting time on the > >decoy or not. > > > >No biggie anyways, got a couple of other things on the hill anyways. =) > > > >From: > >> Hehe well if you wait long enough, you're more likely to hit the actual > >> booted code, rather than 'quickly' wasting your time on the huge decoy > >> left behind... > >> > >> At 11:01 AM 11/23/00 -0500, you wrote: > >> >Argh, trying to reclaim some spots on the hill with Jade. So I replace > >its > >> >'bad q4' with the smaller and faster (by .5 cycles) q4 from rotf and it > >> >scores worse. Some things just don't make sense. > >> > > >> >> 15 23.9/ 21.3/ 54.8 test test > >126.5 1 > >> >> 22 22.0/ 21.2/ 56.8 test test > >122.9 1 > > From: "Benjamin Ford" Subject: lp-Shot v0.1 Date: 2000/12/06 Message-ID: #1/1 Posting my warriors on the lp hill, everyone enjoy. This one is just your basic one-shot with the clear modified to fit the lp hill. ;redcode-94lp ;name lp-Shot v0.1 ;author Ben Ford ;password slade ;strategy oneshot -> jjd clear ;assert CORESIZE==8000 && MAXPROCESSES==8 gate equ (bye-3) step equ 4961 time equ 2076 init equ (-1-time*step) loop add.a #step, bye star jmz.f loop, *bye ; .5c scan mov.ab @star, gate jmp clr, gate mov @bmbp, >gate ; .66c clear bmbp djn clr, {bye ; .33c djn jmp {0, }0 end star _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From: "Benjamin Ford" Subject: Switchblade Date: 2000/12/06 Message-ID: #1/1 Nothing too special here. Main thing is the simple, small, and quick rarely seen pswitcher. Executes a switch on loss (or tie? can't remember) in just 4 cycles. ;redcode-lp ;name Switchblade ;author Ben Ford ;strategy q^3 -> pspace -> stone/imp or scanner ;assert CORESIZE==8000 && MAXPROCESSES==8 STEP equ 214 INIT equ (sbmb+STEP) sdat equ (sptr-1) sptr jmp #STEP, #INIT sadd add.ab { 0, } 0 ; invisible scan jmz.f sadd, @sptr sbmb mov @ 0, @sptr schk jmz.a sadd, sbmb spl # 0, 0 ; invisible mov sdat, 3456, @qptr add # qd, qptr qhop mov qbmb, @qptr ; .5c negative bomber qptr mov qbmb, @ qs sub # qi, qptr djn qhop, # qr jmp brain, <1234 qf equ qptr qs equ 100 qd equ 4000 qi equ 7 qr equ 11 qo equ (qi*qr-10) spl # 14, < 10 ; A,D qtab spl # 7, < 4 ; B,E qbmb dat # 19, { qo ; C qscan seq qd+qf+14*qs, qf+14*qs ; A jmp qfas, {qfas seq qd+qf+35*qs, qf+35*qs ; B*(E+1) jmp qslo, >qtab seq qd+qf+52*qs, qf+52*qs ; (A-1)*E djn.a qslo, {qfas seq qd+qf+70*qs, qf+70*qs ; B*D jmp qslo, {qslo seq qd+qf+9*qs, qf+9*qs ; D-1 djn.b >qfas, {qslo seq qd+qf+24*qs, qf+24*qs ; (B-1)*E jmp qslo, {qtab seq qd+qf+7*qs, qf+7*qs ; B jmp qfas, {qd+qf+7*qs+qi seq qd+qf+21*qs, qf+21*qs ; B*(E-1) jmp qslo, qfas, >qtab seq qd+qf+18*qs, qf+18*qs ; (B-1)*(E-1) djn.f qslo, qtab seq qd+qf+3*qs, qf+3*qs ; E-1 jmp >qfas, qfas, {qslo seq qd+qf+28*qs, qf+28*qs ; B*E jmp qslo, {qd+qf+28*qs+qi seq qd+qf+8*qs, qf+8*qs ; B+1 jmp qfas, }qtab seq qd+qf+63*qs, qf+63*qs ; B*(D-1) djn.b qslo, {qslo seq qd+qf+6*qs, qf+6*qs ; B-1 jmp qfas, {qtab seq qd+qf+19*qs, qf+19*qs ; C jmp qfas, }qfas seq qd+qf+4*qs, qf+4*qs ; E jmp >qfas, {qd+qf+4*qs+qi seq qd+qf+57*qs, qf+57*qs ; C*(E-1) djn.b qslo, }qfas seq qd+qf+1*qs, qf+qs ; 1 jmp qfnd, {qd+qf+qs+qi mode equ (brain-250) brain ldp }mode, mode ldp.ab mode, @mode stp.a @mode, 7968, 2727 dadd add.f djmp, dmov djmp jmp dmov, <2726 for MAXLENGTH-1-CURLINE dat $ 0, $ 0 rof imp mov.i #iHOP, * 0 end qscan _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From: "Benjamin Ford" Subject: Stone Throwing Devils Date: 2000/12/06 Message-ID: #1/1 A heavier imp than most stone/imps on the lp hill. The vector launch saves some instructions by using both the a and b fields. ;redcode-lp ;name Stone Throwing Devils ;author Ben Ford ;strategy q^3 -> lp stone/imp ;strategy 2 processes in stone, 6 in imp ;assert CORESIZE==8000 && MAXPROCESSES==8 iHOP equ 2667 ddst equ (imp+2500) boot mov djmp, {vect mov dadd, {vect mov dmov, {vect spl 1, 1 spl 1, 1 spl 2, <4000 jmp *vect, } 0 jmp @vect, } 0 vect div.f #ddst+3, #ddst+2 div.f #imp+iHOP*0, #imp+iHOP*1 div.f #imp+iHOP*2, #imp+iHOP*3 div.f #imp+iHOP*4, #imp+iHOP*5 dmov mov >7968, 2727 dadd add.f djmp, dmov djmp jmp dmov, <2726 for 50 dat $ 0, $ 0 rof dat <15, <10 ; A,D qtab dat <7, <4 ; B,E dat <13, <11 ; C,F qbmb dat <76, <1 qf equ qptr qs equ -100 qd equ 4000 qi equ 9 qr equ 12 ; -+)>] 0/1 cycles [(<+- qscan seq qd+qf+qs, qf+qs ; 1 jmp qSki, {qd+qf+qs+qi seq qd+qf+8*qs, qf+8*qs ; B+1 jmp qfast, }qtab seq qd+qf+13*qs, qf+13*qs ; C jmp qfast, }qfast seq qd+qf+6*qs, qf+6*qs ; B-1 jmp qfast, {qtab seq qd+qf+14*qs, qf+14*qs ; A-1 djn.a qfast, {qfast seq qd+qf+15*qs, qf+15*qs ; A jmp qfast, {qfast seq qd+qf+7*qs, qf+7*qs ; B jmp qfast, {qd+qf+7*qs+qi ; -+>)] 2 cycles [(<+- seq qd+qf+4*qs, qf+4*qs ; E jmp >qfast, {qd+qf+4*qs+qi seq qd+qf+77*qs, qf+77*qs ; B*F jmp qslow, }qslow seq qd+qf+70*qs, qf+70*qs ; B*D jmp qslow, {qslow seq qd+qf+5*qs, qf+5*qs ; E+1 jmp >qfast, >qtab seq qd+qf+63*qs, qf+63*qs ; B*(D-1) djn.b qslow, {qslow seq qd+qf+3*qs, qf+3*qs ; E-1 jmp >qfast, qtab seq qd+qf+60*qs, qf+60*qs ; A*E jmp qslow, {qfast seq qd+qf+21*qs, qf+21*qs ; B*(E-1) jmp qslow, qfast, }qslow seq qd+qf+32*qs, qf+32*qs ; (B+1)*E jmp qslow, }qtab seq qd+qf+10*qs, qf+10*qs ; D jmp >qfast, {qslow seq qd+qf+66*qs, qf+66*qs ; (B-1)*F djn.a qslow, }qslow seq qd+qf+52*qs, qf+52*qs ; C*E jmp qslow, }qfast seq qd+qf+18*qs, qf+18*qs ; (B-1)*(E-1) djn.f qslow, qtab seq qd+qf+9*qs, qf+9*qs ; D-1 djn.b >qfast, {qslow sne qd+qf+28*qs, qf+28*qs ; B*E jmz *qend, qd+qf+28*qs-10 ; ***** Q-SCAN BOMBER ***** qslow mul.b qtab, qptr ; decode qfast mul.ab qtab, @qslow qSki sne >3456, @qptr add #qd, qptr qloop mov qbmb, @qptr ; .5c negative bomber qptr mov qbmb, *qs sub #qi, qptr djn qloop, #qr qend jmp boot, <1234 for MAXLENGTH-1-CURLINE dat $ 0, $ 0 rof imp mov.i #iHOP, * 0 end qscan _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From: David Matthew Moore Subject: Benchmark by Age Date: 2000/12/06 Message-ID: <90ksln$7m1$1@msunews.cl.msu.edu>#1/1 Who wants to create an age benchmark? 1. Get lots of warriors. 2. Compute each possible battle. Store the results. 3. Choose a warrior to benchmark. 4. Run that warrior against all others. Store the results. 5. Simulate a hill (this is where the pre-computed scores are handy). 5a. Load the hill with randomly selected warriors. 5b. Mature the hill by submitting a few more random choices to it. 5c. Submit the test program. 5d. Submit more random entries until the test program falls off. 5e. Record the age of the test program when it fell. 6. Run more simulations if desired. Final score is the average age. David Moore From: David Matthew Moore Subject: Re: Koenigstuhl Date: 6 Dec 2000 06:51:49 GMT Message-ID: <90knm5$2rvv$1@msunews.cl.msu.edu> birk@andromeda.ociw.edu wrote: > Why no? That's why I introduced the recursive scoring algorithm. > The fundamental problem is that I wanted to have an 'infinite' hill. > That kind of hill will always have programs that are obsolete > (by definition). Right, I have no problem with the obsolete programs. My gripe concerns _new_ out-of-standard programs. The influence of obsolete programs fades towards zero as the number of entries increases. You could say that the methods used to beat the old stuff become less "innovative" as new programs are written, so everything seems right. Unlike obsolete warriors, out-of-standard warriors will continue to be written and contribute a significant portion of the hill (a portion that does not tend towards zero). Unfortunately, the scoring trends are not just the result of some sort of innovation; they are the result of some incidental coincidence between the standards. Even if the recursive algorithm cuts this noise by half, noise is still noise. David Moore From: David Matthew Moore Subject: Re: Koenigstuhl Date: 6 Dec 2000 07:03:49 GMT Message-ID: <90kocl$2rvv$2@msunews.cl.msu.edu> Robert Macrae wrote: > So on the '94 hill I would look for ideas about what is competitive > against the best '94 code. If, as I suspect, FT, is a competitive '94 > warrior then I think that is interesting. I'm not asking anyone to > change their design principles, just giving my prefered method of > analysing the population of warriors. Indeed, there's no problem with showing how the '88 warriors competed against the '94 hill. My gripe is that the '88 programs contribute to the scores of the '94 warriors. Just change the Koenigstuhl so that out-of-standard warriors don't contribute to scoring. David Moore From: birk@andromeda.ociw.edu Subject: Re: Koenigstuhl Date: 2000/12/07 Message-ID: <200012071740.JAA09785@andromeda.ociw.edu>#1/1 > From a purist's point of view, the 94nop hill is slightly skewed > by the absence of Pspacers. Theoretically, some warriors > on the hill waste their effort fighting Pspace strategies, > incidentally becoming more vulnerable to some lucky warriors. I think this effect is very small. Programs high on the OPEN Koenigstuhl end up high on the 94nop hill too. > However, even Pspacers must attack somehow. They usually > bootstrap something similar to what you might find > in non-pspace warriors. Therefore, the difference > between attacking the 94nop and Open hills with a 94nop warrior > is very small compared to the difference between attacking > the '88 and '94 hills with an '88 warrior. > If that difference is small, then why bother with separate > 94nop and Open hills? The difference between 94nop and OPEN is big. Look at the OPEN-Koenigstuhl. Of the Top-10 there are 8 Pspacers, of the top-20 there are 16. That's a clear indcator that using Pspace is favourable. That means that a separate 94nop-hill is necessary. My original question yet is: should there be a PSpace-only hill. Since Pspace has completly different quality there might be reason to open a Pspace-hill. > I thought about the proposal to allow STP (but not LDP) on > the '94nop hill. Initially, I didn't like this idea, > since warriors that use STP are explicitly trying to gain > points from Pspacers. However, the realm of brainwashing warriors > seems fairly diverse. Again: Authors of pure 'brainwashers' please send me a 'nop' version of your warrior and I'll run it on the 94nop-Koenigstuhl. Christoph From: "Benjamin Ford" Subject: Re: Benchmark by Age Date: 2000/12/07 Message-ID: #1/1 I think that if you want to more acurately simulate hill conditions, you probably want to weigh the random choices in 5b and 5d towards warriors that would score higher on the current hill. From: David Matthew Moore >Who wants to create an age benchmark? > >1. Get lots of warriors. >2. Compute each possible battle. Store the results. >3. Choose a warrior to benchmark. >4. Run that warrior against all others. Store the results. >5. Simulate a hill (this is where the pre-computed scores are handy). >5a. Load the hill with randomly selected warriors. >5b. Mature the hill by submitting a few more random choices to it. >5c. Submit the test program. >5d. Submit more random entries until the test program falls off. >5e. Record the age of the test program when it fell. >6. Run more simulations if desired. Final score is the average age. > >David Moore _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From: David Matthew Moore Subject: Re: Koenigstuhl Date: 2000/12/07 Message-ID: <90nk0i$ai2$1@msunews.cl.msu.edu>#1/1 birk@andromeda.ociw.edu wrote: > What's you opinion about mixing 94nop / Pspace standards? From a purist's point of view, the 94nop hill is slightly skewed by the absence of Pspacers. Theoretically, some warriors on the hill waste their effort fighting Pspace strategies, incidentally becoming more vulnerable to some lucky warriors. However, even Pspacers must attack somehow. They usually bootstrap something similar to what you might find in non-pspace warriors. Therefore, the difference between attacking the 94nop and Open hills with a 94nop warrior is very small compared to the difference between attacking the '88 and '94 hills with an '88 warrior. If that difference is small, then why bother with separate 94nop and Open hills? When I agreed to the creation of a new '94nop hill on koth.org, I thought that we might see some smarter warriors that were made obsolete by Pspace. For example, instead of Pspacing between simple stone and simple scissor, you use something like CIA to respond to what you're fighting. Other examples include Leapfrog, which explicitly checks whether it is fighting a scanner or not, Yop La Boum, which tries a one-shot DAT strike before launching anti-imp paper, Stasis, which converts to a core-clear when hit by a minus-one attack (typical of stones), and Keystone, which is a stone that launches imps if it detects paper. We just haven't seen many of these do-everything tricks lately. I thought about the proposal to allow STP (but not LDP) on the '94nop hill. Initially, I didn't like this idea, since warriors that use STP are explicitly trying to gain points from Pspacers. However, the realm of brainwashing warriors seems fairly diverse. I can't think of any obvious way that it might drastically skew the results. It may be decent way to get more stuff on. The proposal seems fine to me. David Moore From: "Darien Dragon" Subject: Re: This Really Works!! Message-ID: Date: Fri, 08 Dec 2000 01:10:02 GMT wrote in message news:jvUX5.86849$Z2.1068596@nnrp1.uunet.ca... > HOW TO TURN $6.00 OR �3.00 INTO $6-$60,000.00 > > READING THIS....COULD....CHANGE YOUR LIFE! > ACTING ON THIS....WILL...CHANGE YOUR LIFE. uh huh. *cough* > IT..IS..CHANGING...MINE!!! I'll be happy when it ends it. -- Darien Dragon --==(UDIC)==-- http://www.geocities.com/darien_dragon "But I'm not broken, in my dream I win And I take over, coz I'm no loser" From: "tmp" Subject: Re: Benchmark by Age Date: Sat, 9 Dec 2000 14:33:55 -0000 Message-ID: <910jba$n2o$1@neptunium.btinternet.com> > Who wants to create an age benchmark? > > 1. Get lots of warriors. > 2. Compute each possible battle. Store the results. > 3. Choose a warrior to benchmark. > 4. Run that warrior against all others. Store the results. > 5. Simulate a hill (this is where the pre-computed scores are handy). > 5a. Load the hill with randomly selected warriors. > 5b. Mature the hill by submitting a few more random choices to it. The number would affect results a great deal; for example hills matured by submitting most or all warriors would strongly resemble the top of the recursive hill, while unmatured hills would resemble a sample from the flat hill. (In fact, would we gain much except interpolation between these?) > 5c. Submit the test program. Presumably run all warriors against the same set of matured hills to reduce the random element in the results. > 5d. Submit more random entries until the test program falls off. So scores range from 0 (fails to get on) to infinite (no hill ever evolves capable of knocking this warrior off). Two problems: 1) this is a wide range and scores and so hard to combine, though (for example) ranking every warrior against each hill and averaging ranks would work. 2) infinite lives take an infinite time to explore... > 5e. Record the age of the test program when it fell. > 6. Run more simulations if desired. Final score is the average age. It is an interesting idea, and easy to do using the Koenigstuhl data -- no refights are needed so it is simply a big simulation exercise. However, I'm not sure what we would learn. The free parameter involved in maturing the hills will greatly affect the results, making conclusions a bit arbitrary? In terms of simulation projects, I think an interesting topic is the historical time structure of the top of the hill. We have submission dates so the data is there, but I've never worked out an answerable formulation for the question... Robert Macrae From: "Timothy Farley" Subject: Porting pMARS? Date: Sun, 10 Dec 2000 19:19:59 -0500 Message-ID: Can anyone lend me some pointers in porting pMARS to other platforms? I've downloaded the source but I can't quite make most of it out (all the #ifdefs get confusing after a few pages) I'm not a great C programmer but it seems like I could port it to another OS... Any help would be GREATLY appreciated Please contact me via email Thanks in advance - Tim - From: "Timothy Farley" Subject: Re: CRobots Date: Sun, 10 Dec 2000 19:32:14 -0500 Message-ID: I thought the source was freeware... if not.. www.gamerz.net home off C++Robots now offers their source code, free of charge. Enjoy! - Tim - Bill Jones wrote in message news:svgfjjjn9prra7@corp.supernews.com... > If you look on the internet for tom's name, you will find he now has a > tclbots and a new site. > His email address on the site is valid. > > Bill > > Ronald Praver wrote in message > news:39B3060C.7F66538F@gate.net... > > I have tried now for several weeks to contact the Author of > > the original CRobots ot purchase the source. I have tried > > 3 different E-Mail address and I tried to contact his brother > > that was mentioned on his web page. I have not received a > > response from either. > > > > Now I would like to purchase the source from anyone that may have it. > > > > Is there anyone out there, will to help. > > > > Help, > > Ron > > From: Dave Moore Subject: Re: Benchmark by Age Date: 10 Dec 2000 22:48:40 GMT Message-ID: <911188$2s8u$1@msunews.cl.msu.edu> tmp wrote: >> 5b. Mature the hill by submitting a few more random choices to it. > > The number would affect results a great deal; for example hills > matured by submitting most or all warriors would strongly resemble the > top of the recursive hill, while unmatured hills would resemble a > sample from the flat hill. A simple optimization is to compile statistics for each program involved in the simulation, rather than just one. Since you don't have to end the simulation when a single program falls, you can use a very mature hill. > So scores range from 0 (fails to get on) to infinite (no hill ever > evolves capable of knocking this warrior off). Oh, I'm sorry... next time I write a benchmark, I will be sure to keep all scores between 120 and 140. With the optimization mentioned above, there's not much trouble with infinitely old programs. My biggest concern is the "butterfly" effect. Theoretically, it's possible that different initial conditions can cause drastically different scores to emerge. I don't know if it will actually happen. The simple solution is to run multiple simulations. David Moore From: Koth Subject: KOTH.ORG: Status - MultiWarrior 94 12/11/00 Date: 11 Dec 2000 11:39:52 -0500 Message-ID: <200012110500.AAA20184@gevjon.ttsg.com> Weekly Status on 12/11/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG Multiwarrior 94 CoreWar Hill: Last battle concluded at : Fri Dec 8 07:29:19 EST 2000 # Name Author Score Age 1 fclear Brian Haskin 34 30 2 QuiVa John Metcalf 31 139 3 D-clearM Ken Espiritu 28 46 4 Pitbull Christian Schmidt 25 2 5 Her Majesty P.Kline 25 65 6 Friction Ken Espiritu 23 18 7 Dracula's Cape Ben Ford 22 24 8 CrazyShot Christian Schmidt 22 1 9 Scan Test Tester 18 5 10 MorphinMerlin Jeremy K 17 10 11 SmallFry Simon Duff 14 16 From: Koth Subject: KOTH.ORG: Status - ICWS Experimental 94 12/11/00 Date: 11 Dec 2000 11:39:48 -0500 Message-ID: <200012110500.AAA20188@gevjon.ttsg.com> Weekly Status on 12/11/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG ICWS Experimental 94 CoreWar Hill: Last battle concluded at : Sat Dec 9 11:09:11 EST 2000 # %W/ %L/ %T Name Author Score Age 1 49/ 31/ 19 Random Reaper Dave Hillis 167 1 2 45/ 29/ 26 Controlled Aggression Ian Oversby 161 63 3 46/ 33/ 22 Black Moods Ian Oversby 159 59 4 47/ 38/ 15 Greetings From Asbury Par JKW 156 23 5 33/ 15/ 52 Katafutr Michal Janeczek 151 3 6 40/ 35/ 25 Ogre Christian Schmidt 145 11 7 34/ 27/ 40 Damage Inflicted Robert Macrae 141 2 8 22/ 4/ 74 Black Box v1.1 JKW 139 26 9 26/ 13/ 62 Denial David Moore 139 4 10 29/ 21/ 50 Venom v0.2b Christian Schmidt 137 85 11 24/ 12/ 64 Evol Cap 4 X John Wilkinson 136 132 12 21/ 5/ 74 Evolve X v4.0 John Wilkinson 136 80 13 33/ 38/ 29 Dr. Gate X Franz 128 103 14 30/ 36/ 34 test CS 123 20 15 25/ 28/ 47 Rosebud Beppe 122 111 16 23/ 24/ 53 Purple v0.1 Christian Schmidt 121 84 17 32/ 43/ 24 Pattel's Virus X Ben Ford 121 7 18 32/ 46/ 22 Pagan John K W 119 117 19 27/ 39/ 34 MorphinMerlin Jeremy K 115 46 20 32/ 52/ 16 S.E.T.I. 4-X JKW 113 133 21 11/ 87/ 1 foobar Flash 35 0 From: Koth Subject: KOTH.ORG: Status - 94 No Pspace 12/11/00 Date: 11 Dec 2000 11:39:56 -0500 Message-ID: <200012110500.AAA20194@gevjon.ttsg.com> Weekly Status on 12/11/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG 94 No Pspace CoreWar Hill: Last battle concluded at : Sun Dec 10 16:51:50 EST 2000 # %W/ %L/ %T Name Author Score Age 1 40/ 27/ 33 Quicksilver Michal Janeczek 153 64 2 44/ 39/ 17 Behemot Michal Janeczek 149 125 3 36/ 26/ 39 Olivia Ben Ford 146 30 4 43/ 42/ 14 Jinx Christian Schmidt 144 265 5 43/ 43/ 13 Eraser II Ken Espiritu 144 259 6 43/ 43/ 14 test2 Paulsson 143 7 7 31/ 21/ 48 nPaper II Paul-V Khuong 142 302 8 32/ 23/ 45 The Dark One Christian Schmidt 141 95 9 36/ 32/ 32 Blacken Ian Oversby 140 549 10 38/ 36/ 26 Battery Anton Marsden 139 5 11 42/ 45/ 12 Stalker P.Kline 139 287 12 36/ 34/ 30 Keyser Soze Anton Marsden 138 3 13 41/ 43/ 16 eTest c1 P.Kline 138 9 14 42/ 46/ 12 G2-b David Moore 138 88 15 41/ 45/ 14 Zooom... John Metcalf 136 438 16 22/ 9/ 69 The Phantom Menace Anton Marsden 134 2 17 35/ 37/ 29 Mini Digitalis Christian Schmidt 132 93 18 39/ 46/ 16 Slice of History Anton Marsden 131 1 19 30/ 30/ 39 Omnibus John Metcalf 131 311 20 28/ 30/ 42 Jade Ben Ford 126 371 21 29/ 65/ 7 Spray 'n Wipe 96 8 Steve Gunnell 93 0 From: Koth Subject: KOTH.ORG: Status - Standard 12/11/00 Date: 11 Dec 2000 11:46:02 -0500 Message-ID: <200012110500.AAA20180@gevjon.ttsg.com> Weekly Status on 12/11/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG Standard KotH CoreWar Hill : Last battle concluded at : Mon Dec 4 07:54:00 EST 2000 # %W/ %L/ %T Name Author Score Age 1 36/ 20/ 45 Freight Train David Moore 152 73 2 34/ 20/ 46 Test Alexander (Sasha) Wa 149 12 3 35/ 21/ 45 sIMPly.Red v0.95 Leonardo Humberto 148 30 4 33/ 21/ 46 Guardian Ian Oversby 145 72 5 40/ 37/ 23 Stasis David Moore 143 180 6 39/ 34/ 27 PacMan David Moore 143 102 7 42/ 43/ 15 Foggy Swamp Beppe Bezzi 140 69 8 27/ 16/ 57 EV Paper John K Wilkinson 139 86 9 41/ 44/ 15 Blur '88 Anton Marsden 138 110 10 29/ 22/ 49 Shish-Ka-Bob Ben Ford 137 28 11 38/ 40/ 22 Beholder's Eye V1.7 W. Mintardjo 136 348 12 27/ 19/ 54 Test I Ian Oversby 135 129 13 36/ 38/ 26 Tangle Trap David Moore 135 146 14 32/ 31/ 37 Frog Sticker P.Kline 134 22 15 35/ 37/ 28 Stillborn Bomber v0.2 mjp 134 13 16 27/ 21/ 52 Evoltmp 88 John K W 134 123 17 39/ 45/ 16 Iron Gate Wayne Sheppard 133 398 18 27/ 21/ 52 sic Leonardo H. Liporati 133 2 19 18/ 3/ 79 ]enigma[ Michal Janeczek 133 1 20 38/ 49/ 13 Blurstone '88 M. J. Pihlaja 127 67 21 2/ 98/ 0 0 0 7 0 From: Ilmari Karonen Subject: Re: Porting pMARS? Date: 11 Dec 2000 14:04:24 GMT Message-ID: <976542872.2600@itz.pp.sci.fi> In article , Timothy Farley wrote: >Can anyone lend me some pointers in porting pMARS to other platforms? I've >downloaded the source but I can't quite make most of it out (all the #ifdefs >get confusing after a few pages) I'm not a great C programmer but it seems >like I could port it to another OS... Any help would be GREATLY appreciated There's not much one can say from your description. What platform exactly are you planning to port it to? What kind of a compiler are you using? The most platform-dependent part of pMARS is the graphical display. You might want to compile it in server mode first. Once you get that working, try enabling cdb. Don't start worrying about the graphics until you've got everything else done. >Please contact me via email Ok, this time. But if you really have an unreliable newsfeed, you can subscribe to rec.games.corewar through the mailing list gateway so that all posts are automatically mailed to you. This is a low volume group, so you're not likely to get flooded with mail. I don't recall the address of the list anymore, but you should be able to find it through http://www.koth.org/ . -- Ilmari Karonen - http://www.sci.fi/~iltzu/ "Do you replace the battery with a grapefruit when your car won't start, just in case that's the problem?" -- Sam Holden in comp.lang.perl.misc From: "Martin Ankerl" Subject: yace 1.0 Date: 16 Dec 2000 15:04:03 -0500 Message-ID: <001901c06795$7da95010$6f02110a@martinus> Hi everybody, The new version of my corewar-evolver can be downloaded at http://www.fhs-hagenberg.ac.at/students/se/se00001/ There are not really big changes from the last release 1.0, but I think yace is now stable enough to call it 1.0 :-) yace is already configured to create warriors for the tiny hill; if you run Windows, just start yace, wait a few days and than have a look at the directory 'status'. If there is any file starting with 160.. or higher, you should submit it to http://corewars.sourceforge.net/cgi-bin/control.py?hill=rctiny&action=showhi ll, I'm shure you will be King of the Hill then. BTW, I have created the current KotH of the tiny hill with exactly the same settings as yace 1.0 is preconfigured, so you might have a real chance :) Martin Ankerl From: jkw@koth.org Subject: Re: abuse Date: 17 Dec 2000 11:05:41 -0500 Message-ID: <4.1.20001217010339.00ae45f0@pop-server> >John, > Before I publicize this, I need to give some notice to the keepers of >the hills. Any fixed sequence of starting points could probably be >reverse engineered by someone who cared enough, but using an -F number >is an irresistable invitation to abuse. > Here's what I did. I sent some probe warriors to the hills to >get the responses back. Then I took one or more published warriors from >the hill and set up a program to exhaustively run the probe warriors >against the known warriors with different -F numbers. When I found an -F >number that matched the win/lose/tie records received from the hill, >that was the -F number for the hill. (Of course many warriors are >published in altered form.) > I wrote another program to take the -F seed and run the "random" >number generator code from PMARS to build a redcode table with some of >the 200/250 starting points for the series of battles. Then I wrote some >warriors with a round counter in p-space that could read the right entry >in the table to see where the other warrior was loaded. > It was lots of fun, but now it's about time to admit how I did it and >go back to not being able to get any warriors on the hills. :) > I expect that you and your counterpart at Pizza (I don't know who that >is) may want to modify the procedure for picking start-point sequences >on the hills - maybe use a slightly different random number generator >algorithm. Please let me know how you'd like me to proceed. > >Dave Well this has been done before, several years ago. I didn't realize it was being done, but as you've noticed it's not effective for staying on the hill for more than a short while... koth.org randomizes the -F numbers every month, and I think pizza does do. It also takes advantage of the fact that people publish their warriors without changing boot distances. I hope that no one takes this as a cue to start changing constants before publishing warriors again. >Hi, > >You may have noticed recently a player has calculated Pizza and >KotH's pMars -F number and has been using it with great success. > >Since it is pretty easy to calculate the number and take advantage >of it, would it be possible to add the following command switch >to pMars: > >-d 501 > >where the value is any number from WARRIOR LENGTH +1 to +50. This >will prevent the calculating of the -F number, by forcing the random >number generator to output a slightly smaller range of values. > >Thanks, > >John I truly fail to see how altering the MINDISTANCE constant will have any effect. The only real way to eliminate this problem is to remove the -F number and have the placements be randomized each time. The reason this isn't done on koth.org is so that players can resubmit warriors with different step sizes and such, without worrying about the random fluctuations in placement screwing up there scores, and confusing the results they get back. The only way to solve both of those problems would be to remove the -F option, and dramatically jack up the number of rounds, from 250 to maybe 2000. In my experience 2000 rounds gets 90% of battles within 4 pts or so of each other, normalized to 100 rounds, even with pspace vs qscan... Whereas with 200 rounds, yer looking more at like 90% of battles being within 30 pts of each other. Those numbers are highly unscientific, but shrug. :) -jkw From: Ilmari Karonen Subject: Re: abuse Date: 18 Dec 2000 00:30:08 GMT Message-ID: <977098734.11944@itz.pp.sci.fi> In article <4.1.20001217010339.00ae45f0@pop-server>, jkw@koth.org wrote: > >I truly fail to see how altering the MINDISTANCE constant will >have any effect. The only real way to eliminate this problem is >to remove the -F number and have the placements be randomized each Actually, pMARS can happily use -F numbers larger than CORESIZE, if you comment out the five lines of code in clparse.c that impose this restriction. That would give you about 2^32 possible sequences, which should make sniffing out the correct one almost impossible. I've just uploaded a patch to http://sourceforge.net/projects/corewar/ that removes those lines and also cleans up some loose ends. Read the comments before applying it, though. (Regarding sourceforge, are there plans to merge the currently open patches into 0.9.2? I have a bit of an interest in this, seeing that three of the four patches are mine..) -- Ilmari Karonen - http://www.sci.fi/~iltzu/ "Outside, in the big wide world, proof by infinite repetition and proof by vehement assertion are much more prevalent." -- Rik Steenwinkel in SDM From: Koth Subject: KOTH.ORG: Status - Standard 12/18/00 Date: 18 Dec 2000 09:50:37 -0500 Message-ID: <200012180500.AAA14241@gevjon.ttsg.com> Weekly Status on 12/18/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG Standard KotH CoreWar Hill : Last battle concluded at : Mon Dec 4 07:54:00 EST 2000 # %W/ %L/ %T Name Author Score Age 1 36/ 20/ 45 Freight Train David Moore 152 73 2 34/ 20/ 46 Test Alexander (Sasha) Wa 149 12 3 35/ 21/ 45 sIMPly.Red v0.95 Leonardo Humberto 148 30 4 33/ 21/ 46 Guardian Ian Oversby 145 72 5 40/ 37/ 23 Stasis David Moore 143 180 6 39/ 34/ 27 PacMan David Moore 143 102 7 42/ 43/ 15 Foggy Swamp Beppe Bezzi 140 69 8 27/ 16/ 57 EV Paper John K Wilkinson 139 86 9 41/ 44/ 15 Blur '88 Anton Marsden 138 110 10 29/ 22/ 49 Shish-Ka-Bob Ben Ford 137 28 11 38/ 40/ 22 Beholder's Eye V1.7 W. Mintardjo 136 348 12 27/ 19/ 54 Test I Ian Oversby 135 129 13 36/ 38/ 26 Tangle Trap David Moore 135 146 14 32/ 31/ 37 Frog Sticker P.Kline 134 22 15 35/ 37/ 28 Stillborn Bomber v0.2 mjp 134 13 16 27/ 21/ 52 Evoltmp 88 John K W 134 123 17 39/ 45/ 16 Iron Gate Wayne Sheppard 133 398 18 27/ 21/ 52 sic Leonardo H. Liporati 133 2 19 18/ 3/ 79 ]enigma[ Michal Janeczek 133 1 20 38/ 49/ 13 Blurstone '88 M. J. Pihlaja 127 67 21 2/ 98/ 0 0 0 7 0 From: Koth Subject: KOTH.ORG: Status - ICWS Experimental 94 12/18/00 Date: 18 Dec 2000 09:50:42 -0500 Message-ID: <200012180500.AAA14249@gevjon.ttsg.com> Weekly Status on 12/18/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG ICWS Experimental 94 CoreWar Hill: Last battle concluded at : Sat Dec 9 11:09:11 EST 2000 # %W/ %L/ %T Name Author Score Age 1 49/ 31/ 19 Random Reaper Dave Hillis 167 1 2 45/ 29/ 26 Controlled Aggression Ian Oversby 161 63 3 46/ 33/ 22 Black Moods Ian Oversby 159 59 4 47/ 38/ 15 Greetings From Asbury Par JKW 156 23 5 33/ 15/ 52 Katafutr Michal Janeczek 151 3 6 40/ 35/ 25 Ogre Christian Schmidt 145 11 7 34/ 27/ 40 Damage Inflicted Robert Macrae 141 2 8 22/ 4/ 74 Black Box v1.1 JKW 139 26 9 26/ 13/ 62 Denial David Moore 139 4 10 29/ 21/ 50 Venom v0.2b Christian Schmidt 137 85 11 24/ 12/ 64 Evol Cap 4 X John Wilkinson 136 132 12 21/ 5/ 74 Evolve X v4.0 John Wilkinson 136 80 13 33/ 38/ 29 Dr. Gate X Franz 128 103 14 30/ 36/ 34 test CS 123 20 15 25/ 28/ 47 Rosebud Beppe 122 111 16 23/ 24/ 53 Purple v0.1 Christian Schmidt 121 84 17 32/ 43/ 24 Pattel's Virus X Ben Ford 121 7 18 32/ 46/ 22 Pagan John K W 119 117 19 27/ 39/ 34 MorphinMerlin Jeremy K 115 46 20 32/ 52/ 16 S.E.T.I. 4-X JKW 113 133 21 11/ 87/ 1 foobar Flash 35 0 From: Koth Subject: KOTH.ORG: Status - 94 No Pspace 12/18/00 Date: 18 Dec 2000 09:50:33 -0500 Message-ID: <200012180500.AAA14257@gevjon.ttsg.com> Weekly Status on 12/18/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG 94 No Pspace CoreWar Hill: Last battle concluded at : Sun Dec 17 15:00:43 EST 2000 # %W/ %L/ %T Name Author Score Age 1 43/ 39/ 18 Behemot Michal Janeczek 148 159 2 37/ 26/ 37 Quicksilver Michal Janeczek 148 98 3 35/ 26/ 39 Uninvited John Metcalf 144 18 4 34/ 25/ 41 Olivia Ben Ford 142 64 5 38/ 35/ 26 Recount P.Kline 141 21 6 33/ 24/ 43 Jade Ben Ford 141 405 7 42/ 43/ 15 Eraser II Ken Espiritu 141 293 8 42/ 44/ 15 Stalker P.Kline 140 321 9 31/ 21/ 48 The Dark One Christian Schmidt 140 129 10 44/ 49/ 8 He Scans Alone P.Kline 138 20 11 30/ 22/ 48 nPaper II Paul-V Khuong 138 336 12 41/ 45/ 14 G2-b David Moore 138 122 13 34/ 32/ 34 Blacken Ian Oversby 135 583 14 39/ 45/ 16 Jinx Christian Schmidt 134 299 15 35/ 35/ 30 Keyser Soze Anton Marsden 134 37 16 38/ 44/ 18 myBlur Paulsson 133 5 17 26/ 21/ 52 KafuFFLe John Metcalf 131 19 18 21/ 13/ 66 The Phantom Menace Anton Marsden 130 36 19 35/ 45/ 21 myBlur Paulsson 125 1 20 19/ 27/ 55 jam test 3 John Metcalf 111 2 21 31/ 61/ 8 qhsa test qhsa test 100 0 From: Koth Subject: KOTH.ORG: Status - MultiWarrior 94 12/18/00 Date: 18 Dec 2000 09:56:47 -0500 Message-ID: <200012180500.AAA14245@gevjon.ttsg.com> Weekly Status on 12/18/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG Multiwarrior 94 CoreWar Hill: Last battle concluded at : Sat Dec 16 14:54:00 EST 2000 # Name Author Score Age 1 Dracula's Cape Ben Ford 43 25 2 CrazyShot Christian Schmidt 43 2 3 D-clearM Ken Espiritu 36 47 4 QuiVa John Metcalf 36 140 5 fclear Brian Haskin 36 31 6 Her Majesty P.Kline 34 66 7 Foo John Metcalf 30 1 8 Friction Ken Espiritu 27 19 9 Pitbull Christian Schmidt 27 3 10 Scan Test Tester 15 6 11 UnEasy Lukasz Adamowski 2 0 Message-ID: From: anton@paradise.net.nz (Anton Marsden) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 18 Dec 2000 10:46:18 GMT Archive-name: games/corewar-faq Last-Modified: September 4, 1999 Version: 4.2 URL: http://homepages.paradise.net.nz/~anton/cw/corewar-faq.html Copyright: (c) 1999 Anton Marsden Maintainer: Anton Marsden Posting-Frequency: once every 2 weeks Core War Frequently Asked Questions (rec.games.corewar FAQ) These are the Frequently Asked Questions (and answers) from the Usenet newsgroup rec.games.corewar. A plain text version of this document is posted every two weeks. The latest hypertext version is available at http://homepages.paradise.net.nz/~anton/cw/corewar-faq.html and the latest plain text version is available at http://homepages.paradise.net.nz/~anton/cw/corewar-faq.txt. This document is currently being maintained by Anton Marsden (anton@paradise.net.nz). Last modified: Sat Sep 4 00:22:22 NZST 1999 ------------------------------------------------------------------------ To Do * Add the new No-PSpace '94 hill location * Add online location of Dewdney's articles * Make question 17 easier to understand. Add a state diagram? * Add info about infinite hills, related games (C-Robots, Tierra?, ...) * New question: How do I know if my warrior is any good? Refer to beginners' benchmarks, etc. * Add a Who's Who list? * Would very much like someone to compile a collection of the "revolutionary" warriors so that beginners can see how the game has developed over the years. Mail me if interested. ------------------------------------------------------------------------ What's New * Changed primary location of FAQ (again!) * Changed Philip Kendall's home page address. * Updated list server information * Changed primary location of FAQ * Vector-launching code was fixed thanks to Ting Hsu. * Changed the location of Ryan Coleman's paper (LaunchPad -> Launchpad) * Changed pauillac.inria.fr to para.inria.fr ------------------------------------------------------------------------ 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. Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? 5. What is ICWS'94? Which simulators support ICWS'94? 6. What is the ICWS? 7. What is Core Warrior? 8. Where are the Core War archives? 9. Where can I find a Core War system for ...? 10. Where can I find warrior code? 11. I do not have FTP. How do I get all this great stuff? 12. I do not have access to Usenet. How do I post and receive news? 13. Are there any Core War related WWW sites? 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. How does SLT (Skip if Less Than) work? 17. What is the difference between in-register and in-memory evaluation? 18. What is P-space? 19. What does "Missing ;assert .." in my message from KotH mean? 20. How should I format my code? 21. Are there any other Core War related resources I should know about? 22. What does (expression or term of your choice) mean? 23. Other questions? ------------------------------------------------------------------------ 1. What is Core War? 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 processes of the opposing program to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardised by the ICWS, and is therefore transportable between all standard Core War systems. The system in which the programs run is quite simple. The core (the memory of the simulated computer) is a continuous array of instructions, empty except for the competing programs. The core wraps around, so that after the last instruction comes the first one again. There are no absolute addresses in Core War. That is, the address 0 doesn't mean the first instruction in the memory, but the instruction that contains the address 0. The next instruction is 1, and the previous one obviously -1. However, all numbers are treated as positive, and are in the range 0 to CORESIZE-1 where CORESIZE is the amount of memory locations in the core - this means that -1 would be treated as CORESIZE-1 in any arithmetic operations, eg. 3218 + 7856 = (3218 + 7856) mod CORESIZE. Many people get confused by this, and it is particularly important when using the SLT instruction. Note that the source code of a program can still contain negative numbers, but if you start using instructions like DIV #-2, #5 it is important to know what effect they will have when executed. The basic unit of memory in Core War is one instruction. Each Redcode instruction contains three parts: * the opcode * the source address (a.k.a. the A-field) * the destination address (a.k.a. the B-field) The execution of the programs is equally simple. The MARS executes one instruction at a time, and then proceeds to the next one in the memory, unless the instruction explicitly tells it to jump to another address. If there is more than one program running, (as is usual) the programs execute alternately, one instruction at a time. The execution of each instruction takes the same time, one cycle, whether it is MOV, DIV or even DAT (which kills the process). Each program may have several processes running. These processes are stored in a task queue. When it is the program's turn to execute an instruction it dequeues a process and executes the corresponding instruction. Processes that are not killed during the execution of the instruction are put back into the task queue. Processes created by a SPL instruction are added to the task queue after the creating process is put back into the task queue. [ToC] ------------------------------------------------------------------------ 2. Is it "Core War" or "Core Wars"? 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. [ToC] ------------------------------------------------------------------------ 3. Where can I find more information about Core War? Core War was first described in the Core War Guidelines of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in Scientific American which discussed Core War, starting with the May 1984 article. Those articles are contained in two anthologies: Library of Author Title Published ISBN Congress Call Number The Armchair Dewdney, Universe: An New York: W. QA76.6 .D517 A. K. Exploration of H. Freeman �0-7167-1939-8 1988 Computer Worlds 1988 The Magic 0-7167-2125-2 Dewdney, Machine: A New York: W.(Hardcover), QA76.6 A. K. Handbook of H. Freeman �0-7167-2144-9 .D5173 1990 Computer Sorcery 1990 (Paperback) A.K. Dewdney's articles are still the most readable introduction to Core War, even though the Redcode dialect described in there is no longer current. For those who are interested, Dewdney has a home page at http://www.csd.uwo.ca/faculty/akd/. [ToC] ------------------------------------------------------------------------ 4. Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A draft of the official standard (ICWS'88) is available as ftp://www.koth.org/corewar/documents/standards/redcode-icws-88.Z. This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at Mark Durham's tutorials, ftp://www.koth.org/corewar/documents/tutorial.1.Z and ftp://www.koth.org/corewar/documents/tutorial.2.Z. Steven Morrell has prepared a more practically oriented Redcode tutorial that discusses different warrior classes with lots of example code. This and various other tutorials can be found at http://www.koth.org/papers.html. Even though ICWS'88 is still the "official" standard, you will find that most people are playing by ICWS'94 draft rules and extensions. [ToC] ------------------------------------------------------------------------ 5. What is ICWS'94? Which simulators support ICWS'94? There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a new addressing modes and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft at ftp://www.koth.org/corewar/documents/icws94.0202.Z for more information. There is a HTML version of this document available at http://www.koth.org/info/icws94.html. You can try out the new standard by submitting warriors to the '94 hills of the KotH servers. Two corewar systems currently support ICWS'94, pMARS (many platforms) and Redcoder (Mac), both available at ftp://www.koth.org/corewar. Note that Redcoder only supports a subset of ICWS'94. [ToC] ------------------------------------------------------------------------ 6. What is the ICWS? About one year after Core War first appeared in Scientific American, 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). The ICWS is no longer active. [ToC] ------------------------------------------------------------------------ 7. What is Core Warrior? Following in the tradition of the Core War News Letter, Push Off, and The 94 Warrior, Core Warrior is a newsletter about strategies and current standings in Core War. Started in October 1995, back issues of Core Warrior (and the other newsletters) are available at http://para.inria.fr/~doligez/corewar/. There is also a Core Warrior index page at http://www.kendalls.demon.co.uk/pak21/corewar/warrior.html which has a summary of the contents of each issue of Core Warrior. Many of the earlier issues contain useful information for beginners. [ToC] ------------------------------------------------------------------------ 8. Where are the Core War archives? Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from ftp://ftp.csua.berkeley.edu/pub/corewar. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@csua.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. This site is mirrored at: * http://www.koth.org/corewar/ * ftp://www.koth.org/corewar/ * ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/mirror The plain text version of this FAQ is automatically archived by news.answers (but this version is probably out-of-date). [ToC] ------------------------------------------------------------------------ 9. Where can I find a Core War system for . . . ? Core War systems are available via anonymous FTP from www.koth.org in the corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. It is a good idea to check ftp://www.koth.org/corewar/incoming for program updates first. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than www.koth.org. Generally, the older the program - the less likely it will be ICWS compatible. If you are looking for an ICWS'94 simulator, get pMARS, which is available for many platforms and can be downloaded from: * ftp://ftp.csua.berkeley.edu/pub/corewar (original site) * ftp://www.koth.org/corewar (koth.org mirror) * ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/mirror (Planar mirror) * http://www.nc5.infi.net/~wtnewton/corewar/ (Terry Newton) * ftp://members.aol.com/ofechner/corewar (Fechter) Notes: * If you have trouble running pMARS with a graphical display under Win95 then check out http://www.koth.org/pmars.html which should have a pointer to the latest compilation of pMARS for this environment. * RPMs for the Alpha, PowerPC, Sparc and i386 can be found at ftp://ftp.inria.fr/INRIA/Projects/para/doligez/cw/pmars-rpm/ Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at www.koth.org: MADgic41.lzh corewar for the Amiga, v4.1 MAD4041.lzh older version? MAD50B.lha corewar for the Amiga, beta version 5.0 Redcoder-21.hqx corewar for the Mac, supports ICWS'88 and '94 (without extensions) core-11.hqx corewar for the Mac core-wars-simulator.hqx same as core-11.hqx? corewar_unix_x11.tar.Z corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z older version kothpc.zip port of older version of KotH to the PC deluxe20c.tar.Z corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z corewar for UNIX, likely not ICWS'88 compatible icons.zip corewar icons for MS-Windows macrored.zip a redcode macro-preprocessor (PC) c88v49.zip PC corewar, textmode display mars88.zip PC corewar, graphics mode display corwp302.zip PC corewar, textmode display, slowish mercury2.zip PC corewar written in assembly, fast! mtourn11.zip tournament scheduler for mercury (req. 4DOS) pmars08s.zip portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars08s.tar.Z same as above pmars08.zip PC executables with graphics display, req 386+ macpmars02.sit.hqx pMARS executable for Mac (port of version 0.2) buggy, no display MacpMARS1.99a.cpt.hqx port of v0.8 for the Mac, with display and debugger MacpMARS1.0s.cpt.hqx C source (MPW, ThinkC) for Mac frontend pvms08.zip pMARS v0.8 for VMS build files/help (req. pmars08s.zip) ApMARS03.lha pMARS executable for Amiga (port of version 0.3.1) wincor11.zip MS-Windows system, shareware ($15) [ToC] ------------------------------------------------------------------------ 10. Where can I find warrior code? To learn the game, it is a good idea to study previously posted warrior code. The FTP archives have code in the ftp://www.koth.org/corewar/redcode directory. A clearly organized on-line warrior collection is available at the Core War web sites (see below). [ToC] ------------------------------------------------------------------------ 11. I do not have FTP. How do I get all this great stuff? There is an FTP email server at bitftp@pucc.princeton.edu. This address may no longer exist. I haven't tested it yet. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. Note that many FTP email gateways are shutting down due to abuse. To get a current list of FTP email servers, look at the Accessing the Internet by E-mail FAQ posted to news.answers. If you don't have access to Usenet, you can retrieve this FAQ one of the following ways: * Send mail to mail-server@rtfm.mit.edu with the body containing "send usenet/news.answers/internet-services/access-via-email". * Send mail to mailbase@mailbase.ac.uk with the body containing "send lis-iis e-access-inet.txt". [ToC] ------------------------------------------------------------------------ 12. I do not have access to Usenet. How do I post and receive news? To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Koth.Org list processor. To join, send the message SUB COREWAR-L FirstName LastName to listproc@koth.org. You can send mail to corewar-l@koth.org to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (ttsg@ttsg.com). Servers that allow you to post (but not receive) articles are available. Refer to the Accessing the Internet by E-Mail FAQ for more information. [ToC] ------------------------------------------------------------------------ 13. Are there any Core War related WWW sites? You bet. Each of the two KotH sites sport a world-wide web server. Stormking's Core War page is http://www.koth.org; pizza's is http://www.ecst.csuchico.edu/~pizza/koth . Damien Doligez (a.k.a. Planar) has a web page that features convenient access to regular newsletters (Push Off, The '94 Warrior, Core Warrior) and a well organized library of warriors: http://para.inria.fr/~doligez/corewar/. Convenient for U.S. users, this site is also mirrored at koth.org. [ToC] ------------------------------------------------------------------------ 14. What is KotH? How do I enter? King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program (warrior) with special comment lines. You will receive a reply indicating how well your program did against the current top programs "on the hill". There are two styles of KotH tournaments, "classical" and "multi-warrior". The "classical" KotH is a one-on-one tournament, that is your warrior will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. In "multi-warrior" KotH, all warriors on the hill fight each other at the same time. Score calculation is a bit more complex than for the one-on-one tournament. Briefly, points are awarded based on how many warriors survive until the end of a round. A warrior that survives by itself gets more points than a warrior that survives together with other warriors. Points are calculated from the formula (W*W-1)/S, where W is the total number of warriors and S the number of surviving warriors. The pMARS documentation has more information on multi-warrior scoring. The idea for an email-based Core War server came from David Lee. The original KotH was developed and run by William Shubert at Intel starting in 1991, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: koth@koth.org is maintained by Scott J. Ellentuch (tuc@ttsg.com) and pizza@ecst.csuchico.edu by Thomas H. Davies (sd@ecst.csuchico.edu). Up until May '95, the two sites provided overlapping services, i.e. the some of the hill types were offered by both "pizza" and "stormking". To conserve resources, the different hill types are now divided up among the sites. The way you submit warriors to both KotHs is pretty much the same. Therefore, the entry rules described below apply to both "pizza" and "stormking" unless otherwise noted. Entry Rules for King of the Hill Corewar * Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. * Put a line starting with ";redcode" (or ";redcode-94", etc., see below) 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. 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. Using ";name" is mandatory on the Pizza hills. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. There are currently seven separate hills you can select by starting your program with ;redcode-94, ;redcode-b, ;redcode-lp, ;redcode-x, ;redcode, ;redcode-94x or ;redcode-94m. The former four run at "pizza", the latter three at "stormking". More information on these hills is listed below. * Mail this file to koth@koth.org or pizza@ecst.csuchico.edu. "Pizza" requires a subject of "koth" (use the -s flag on most mailers). * 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. * In an hour or so you should get more mail telling you how your program performed against the current top 20 (or 10) programs. If no news arrives during that time, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode[-??] quiet" when you first mail in your program; then you will only get mail when you make it on the top 25 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 25 list. Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. The server kills programs by assigning an impossibly low score; it may therefore take another successful challenge before a killed program is actually removed from the hill. Sample Entry ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Duration Max. Hill Name Hill Core Max. Before Entry Min. Rounds Instr. Size Size Processes Distance Fought Set Tie Length Pizza's ICWS '94 Draft Hill Extended (Accessed with 25 8000 8000 80000 100 100 200 ICWS '94 ";redcode-94") Draft Pizza's Beginner's Extended Hill (Accessed 25 8000 8000 80000 100 100 200 ICWS '94 with ";redcode-b") Draft Pizza's Experimental Extended (Small) Hill 25 800 800 8000 20 20 200 ICWS '94 (Accessed with Draft ";redcode-x") Pizza's Limited Process (LP) Hill Extended (Accessed with 25 8000 8 80000 200 200 200 ICWS '94 ";redcode-lp") Draft Stormking's ICWS '88 Standard Hill (Accessed with 20 8000 8000 80000 100 100 250 ICWS '88 ";redcode") Stormking's ICWS '94 No Pspace Hill (Accessed with 20 8000 8000 80000 100 100 250 ICWS '94 ";redcode-94nop") Stormking's ICWS '94 Experimental Extended (Big) Hill 20 55440 55440 500000 200 200 250 ICWS '94 (Accessed with Draft ";redcode-94x") Stormking's ICWS '94 Multi-Warrior Extended Hill (Accessed 10 8000 8000 80000 100 100 200 ICWS '94 with Draft ";redcode-94m") Note: Warriors on the beginner's hill are retired at age 100. If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document. At "stormking", a message body with ";help" will return brief instructions. If you submit code containing a ";test" line, your warrior will be assembled but not actually pitted against the warriors on the hill. At "pizza", you can use ";redcode[-??] test" to do a test challenge of the Hill without affecting the status of the Hill. These challenges can be used to see how well your warrior does against the current Hill warriors. All hills run portable MARS (pMARS) version 0.8, a platform-independent Core War system available at www.koth.org. The '94 and '94x hills allow five experimental opcodes and three experimental addressing modes currently not covered in the ICWS'94 draft document: * LDP - Load P-Space * STP - Store P-Space * SEQ - Skip if EQual (synonym for CMP) * SNE - Skip if Not Equal * NOP - (No OPeration) * * - indirect using A-field as pointer * { - predecrement indirect using A-field * } - postincrement indirect using A-field [ToC] ------------------------------------------------------------------------ 15. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? Core is initialized to DAT 0, 0. This is an illegal instruction (in source code) under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you have a DAT 0, 0 instruction in your source code - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction. [ToC] ------------------------------------------------------------------------ 16. How does SLT (Skip if Less Than) work? SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: -1 becomes M-1 where M is the memory size (core size). Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. [ToC] ------------------------------------------------------------------------ 17. What is the difference between in-register and in-memory evaluation? These terms refer to the way instruction operands are evaluated. The '88 Redcode standard ICWS'88 is unclear about whether a simulator should "buffer" the result of A-operand evaluation before the B-operand is evaluated. Simulators that do buffer are said to use in-register evaluation, those that don't, in-memory evaluation. ICWS'94 clears this confusion by mandating in-register evaluation. Instructions that execute differently under these two forms of evaluation are MOV, ADD, SUB, MUL, DIV and MOD where the effective address of the A-operand is modified by evaluation of the B-operand. This is best illustrated by an example: L1 mov L2, mov.i #0, impsize Bootstrapping Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners Scanners which only recognize non-zero B-fields. example add #10, scan scan jmz example, 10 c Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner A Scanner which uses a CMP instruction to look for opponents. example add step, scan scan cmp 10, 30 jmp attack jmp example step dat #20, #20 Colour Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear Code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys Bogus or unused instructions meant to slow down scanners. Typically, DATs with non-zero B-fields. Decrement Resistant Property of warriors making them functional (or at least partially functional) when overrun by a DJN-stream. DJN-Stream (also DJN-Train) Using a DJN command to rapidly decrement core locations. example ... ... djn example, <4000 Dwarf The prototypical small bomber. Gate-busting (also gate-crashing) technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates. Hybrids warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone). Imp Program which only uses the MOV instruction. example mov 0, 1 or example mov 0, 2 mov 0, 2 Imp-Gate A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... spl 0, mov.i #0,IMPSIZE Mirror see reflection. On-axis/off-axis On-axis scanners compare two locations M/2 apart, where M is the memory size. Off-axis scanners use some other separation. Optimal Constants (also optima-type constants) Bomb or scan increments chosen to cover core most effectively, i.e. leaving gaps of uniform size. Programs to calculate optimal constants and lists of optimal numbers are available at www.koth.org. Paper A Paper-like program is one which replicates itself many times. Part of the Scissors (beats) Paper (beats) Stone (beats Scissors) analogy. P-Warrior A warrior which uses the results of previous round(s) in order to determine which strategy it will use. Pit-Trapper (also Slaver, Vampire). A program which enslaves another. Usually accomplished by bombing with JMPs to a SPL 0 pit with an optional core-clear routine. Q^2 Scan A modern version of the Quick Scan where anything found is attacked almost immediately. Quick Scan 2c scan of a set group of core locations with bombing if anything is found. Both of the following codes snips scan 16 locations and check for a find. If anything is found, it is attacked, otherwise 16 more locations are scanned. Example: start s1 for 8 ;'88 scan cmp start+100*s1, start+100*s1+4000 ;check two locations mov #start+100*s1-found, found ;they differ so set pointer rof jmn attack, found ;if we have something, get it s2 for 8 cmp start+100*(s2+6), start+100*(s2+6)+4000 mov #start+100*(s2+6)-found, found rof found jmz moveme, #0 ;skip attack if qscan found nothing attack cmp @found, start-1 ;does found points to empty space? add #4000, found ;no, so point to correct location mov start-1, @found ;move a bomb moveme jmp 0, 0 In ICWS'94, the quick scan code is more compact because of the SNE opcode: start ;'94 scan s1 for 4 sne start+400*s1, start+400*s1+100 ;check two locations seq start+400*s1+200, start+400*s1+300 ;check two locations mov #start+400*s1-found, found ;they differ so set pointer rof jmn which, found ;if we have something, get it s2 for 4 sne start+400*(s2+4), start+400*(s2+4)+100 seq start+400*(s2+4)+200, start+400*(s2+4)+300 mov #start+400*(s2+4)-found-100, found rof found jmz moveme, #0 ;skip attack if qscan found nothing add #100, -1 ;increment pointer till we get the which jmn -1, @found ;right place mov start-1, @found ;move a bomb moveme jmp 0, 0 Reflection Copy of a program or program part, positioned to make the active program invisible to a CMP-scanner. Replicator Generic for Paper. A program which makes many copies of itself, each copy also making copies. Self-Splitting Strategy of amplifying the number of processes executing a piece of code. example spl 0 loop add #10, example mov example, @example jmp loop Scanner A program which searches through core for an opponent rather than bombing blindly. Scissors A program designed to beat replicators, usually a (B-field scanning) vampire. Part of the Paper-Scissors-Stone analogy. Self-Repair Ability of a program to fix it's own code after attack. Silk A replicator which splits off a process to each new copy before actually copying the code. This allows it to replicate extremely quickly. This technique is only possible under the '94 draft, because it requires post-increment indirect addressing. Example: spl 1 mov -1, 0 spl 1 ;generate 6 consecutive processes silk spl 3620, #0 ;split to new copy mov >-1, }-1 ;copy self to new location mov bomb, >2000 ;linear bombing mov bomb, }2042 ;A-indirect bombing for anti-vamp jmp silk, {silk ;reset source pointer, make new copy bomb dat >2667, >5334 ;anti-imp bomb Slaver see Pit-Trapper. Stealth Property of programs, or program parts, which are invisible to scanners, accomplished by using zero B-fields and reflections. Stone A Stone-like program designed to be a small bomber. Part of the Paper-Scissors-Stone analogy. Stun A type of bomb which makes the opponent multiply useless processes, thus slowing it down. Example is referred to as a SPL-JMP bomb. example spl 0 jmp -1 Two-Pass Core-Clear (also SPL/DAT Core-Clear) core clear that fills core first with SPL instructions, then with DATs. This is very effective in killing paper and certain imp-spiral variations. Vampire see Pit-Trapper. Vector Launch one of several means to start an imp-spiral running. As fast as Binary Launch, but requiring much less code. See also JMP/ADD Launch and Binary Launch. This example is one form of a Vector Launch: sz EQU 2667 spl 1 spl 1 jmp @vt, }0 vt dat #0, imp+0*sz ; start of vector table dat #0, imp+1*sz dat #0, imp+2*sz dat #0, imp+3*sz ; end of vector table imp mov.i #0, sz [ToC] ------------------------------------------------------------------------ 23. Other questions? Just ask in the rec.games.corewar newsgroup or contact me. If you are shy, check out the Core War archives first to see if your question has been answered before. [ToC] ------------------------------------------------------------------------ Credits Additions, corrections, etc. to this document are solicited. Thanks in particular to the following people who have contributed major portions of this document: * Mark Durham (wrote the original version of the FAQ) * Paul Kline * Randy Graham * Stefan Strack (maintained a recent version of the FAQ) ------------------------------------------------------------------------ Copyright � 1999 Anton Marsden. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ------------------------------------------------------------------------ From: jkw@austin.rr.com Subject: Re: Sourceforge.net core emulator Date: 19 Dec 2000 17:56:57 -0500 Message-ID: <4.1.20001219163225.00ae6510@pop-server> >I can't even get a simple IMP to work. > >start: mov 0,1 > end Not that it should matter in this example, if that's all you wrote, but you should always put "end start" rather than just "end", to ensure the correct starting position. >doesn't do anything, and I've tried several variations on this theme. > >Any pointers to better redcode core emulators? This one is nice, but I >can't write programs for it. Well the official simulator of r.g.c has always been pmars, I'm not sure about this other stuff... http://www.koth.org/pmars -jkw From: paul.bobby@lmco.com (Paul Bobby) Subject: Sourceforge.net core emulator Date: Tue, 19 Dec 2000 20:42:09 GMT Message-ID: <3a3fc7bf.109389573@news.vf.lmco.com> I love the emulator you can get from this site..... haven't seen anything better. However, the code! It's not redcode, and I can't find sufficient documentation describing the code syntax for programs to run in this core. I can't even get a simple IMP to work. start: mov 0,1 end doesn't do anything, and I've tried several variations on this theme. Any pointers to better redcode core emulators? This one is nice, but I can't write programs for it. From: walterhnospam@gmx.de (Walter Hofmann) Subject: Re: Sourceforge.net core emulator Date: Tue, 19 Dec 2000 22:36:27 +0100 Message-ID: On Tue, 19 Dec 2000 20:42:09 GMT, Paul Bobby wrote: > >I love the emulator you can get from this site..... haven't seen >anything better. You mean corewars.sourceforge.net? That's me, then. >I can't even get a simple IMP to work. > >start: mov 0,1 > end > >doesn't do anything, and I've tried several variations on this theme. Where did you try it? In the GUI client? Open the Options dialog and set language to "REDCODE". If you used the the command line version you need to add --language=REDCODE. This warrior very definitely works. >However, the code! It's not redcode, and I can't find sufficient >documentation describing the code syntax for programs to run in this >core. The description is in the README file. The program comes with many examples. Walter From: Ilmari Karonen Subject: Re: Sourceforge.net core emulator Date: 20 Dec 2000 13:52:21 GMT Message-ID: <977319599.4080@itz.pp.sci.fi> In article <3a3fc7bf.109389573@news.vf.lmco.com>, Paul Bobby wrote: >I love the emulator you can get from this site..... haven't seen >anything better. > >However, the code! It's not redcode, and I can't find sufficient >documentation describing the code syntax for programs to run in this >core. Which one? There are two Core War -related project on SourceForge, named "corewar" and "corewars". The former includes pMARS, which is about as close to an official redcode simulator as one can get. I'd suspect the simulator you're using is from the latter. I can't say much about that one, having never tried it. Maybe it does support standard redcode, maybe not. I suppose I ought to try it out some day myself. While I think diversity is generally a good thing, I do feel that two similar and similarly named -- yet not quite compatible -- projects on the same site can be confusing. Would it be impossible for the people in charge of each to put a link to the other on the home and project pages, with a brief explanation of the differences? Please? -- Ilmari Karonen - http://www.sci.fi/~iltzu/ "And, should you resort to sticking a martini olive up their nose, implacable universal laws require that they'll _like_ that sort of thing." -- Graydon in rec.arts.sf.composition From: paul.bobby@lmco.com (Paul Bobby) Subject: Re: Sourceforge.net core emulator Date: Wed, 20 Dec 2000 13:54:26 GMT Message-ID: <3a40b9e4.171378339@news.vf.lmco.com> Thanks.... I can't believe I never saw the option. Anyway, great job on the client. I had played with this about 8 years ago and then completely lost track of it. Glad to see it's still around. On Tue, 19 Dec 2000 22:36:27 +0100, walterhnospam@gmx.de (Walter Hofmann) wrote: >On Tue, 19 Dec 2000 20:42:09 GMT, Paul Bobby wrote: >> >>I love the emulator you can get from this site..... haven't seen >>anything better. > >You mean corewars.sourceforge.net? That's me, then. > > >>I can't even get a simple IMP to work. >> >>start: mov 0,1 >> end >> >>doesn't do anything, and I've tried several variations on this theme. > >Where did you try it? In the GUI client? Open the Options dialog and set >language to "REDCODE". If you used the the command line version you need >to add --language=REDCODE. >This warrior very definitely works. > > >>However, the code! It's not redcode, and I can't find sufficient >>documentation describing the code syntax for programs to run in this >>core. > >The description is in the README file. The program comes with many >examples. > >Walter From: paul.bobby@lmco.com (Paul Bobby) Subject: Real order of execution of redcode Date: Wed, 20 Dec 2000 16:36:59 GMT Message-ID: <3a40ded3.180833214@news.vf.lmco.com> Here's a little snippet of code bomb dat #0, #0 start mov bomb, Subject: Re: Real order of execution of redcode Date: 20 Dec 2000 17:51:16 GMT Message-ID: <977333807.11112@itz.pp.sci.fi> In article <3a40ded3.180833214@news.vf.lmco.com>, Paul Bobby wrote: > >The b-operand was already decremented, so why does pMars 'remember' >the original instruction? The keyword you're looking for in "in-register evaluation". This is how I described the way it works last time[1] the issue came up: 1. Fetch and store the current instruction. 2a. (Perform predecrement if A-mode is '<' or '{'.) 2b. Compute effective A-address. 2c. Fetch and store the A-operand instruction. 2d. (Perform postincrement if A-mode if '>' or '}'.) 3a. (Perform predecrement if B-mode is '<' or '{'.) 3b. Compute effective B-address. 3c. Fetch and store the B-operand instruction. 3d. (Perform postincrement if B-mode if '>' or '}'.) 4. Compute result from stored operands and save in B-address. 5. Adjust process queue according to stored operands. Now, in your case the issue is that step 2c comes before 3a. So the bomb has been stored in a register before the decrement happens. I really ought to write a web page that explains it. I already did once, back when I was writing the Beginner's Guide, but I felt it was not really beginner material, and now I seem to have lost it. Come to think of it, this is the closest thing to a frequently asked question this group has recently had. Maybe a FAQ entry would be a good idea? [1] Message-ID: <970753052.6570@itz.pp.sci.fi> -- Ilmari Karonen - http://www.sci.fi/~iltzu/ "The duplexer was a work of art... in a Salvador Dali kind of way." -- Graham Reed in the SDM From: Lukasz Adamowski Subject: Re: Real order of execution of redcode Date: 20 Dec 2000 19:12:45 -0500 Message-ID: I've got some problems with this also, but it can be very useful.Try debug something like that: start mov bomb, Subject: Windows pMARS? Date: Wed, 20 Dec 2000 23:14:14 -0500 Message-ID: Why hasn't pMARs been ported to Windows? I hate going to a DOS box as it is, but when I switch to Win2k and their DOS emulator.... Who knows what pMARS will be like. Would it be much too ard for the developers to simply take the existing code and output it to a window somehow? I'm not complaining, just curious. Thanks - Tim - From: Hillis Subject: Re: Windows pMARS? Date: Thu, 21 Dec 2000 07:58:09 -0500 Message-ID: <3A41FE61.E3677681@erols.com> Timothy Farley wrote: > > Why hasn't pMARs been ported to Windows? I hate going to a DOS box as it is, > but when I switch to Win2k and their DOS emulator.... Who knows what pMARS > will be like. Would it be much too ard for the developers to simply take the > existing code and output it to a window somehow? I'm not complaining, just > curious. > > Thanks > > - Tim - Running pmars using the DOS emulator in WINDOS ME is actually much nicer than with real DOS. Sometimes it's easier to put the pmars command line in a .bat file and run it by double-clicking on the icon. Dave Hillis From: Ilmari Karonen Subject: Re: Windows pMARS? Date: 21 Dec 2000 10:02:17 GMT Message-ID: <977392197.17310@itz.pp.sci.fi> In article , Timothy Farley wrote: >Why hasn't pMARs been ported to Windows? I hate going to a DOS box as it is, >but when I switch to Win2k and their DOS emulator.... Who knows what pMARS >will be like. Would it be much too ard for the developers to simply take the >existing code and output it to a window somehow? I'm not complaining, just >curious. Well, mostly because nobody's done it yet. It would take someone who'd know the Windows API and be willing to write a new display front-end. I might qualify for the latter, but definitely not the former, and I don't really even want to learn that. Then there's the point that it'd still be a command line app. It would take quite a bit of work to substitute a GUI for the command line parser. Not to say it couldn't be done, just that you shouldn't expect it in a 0.9.x release.. -- Ilmari Karonen - http://www.sci.fi/~iltzu/ "There's apparently something about the aerodynamics of the female body the requires exposed cleavage in order to perform a drop-kick. Seven hundred Hollywood movies can't be wrong, can they?" -- Kevin Russell in r.a.sf.c From: walterhnospam@gmx.de (Walter Hofmann) Subject: Re: Sourceforge.net core emulator Date: Thu, 21 Dec 2000 14:47:41 +0100 Message-ID: On 20 Dec 2000 13:52:21 GMT, Ilmari Karonen wrote: > >I can't say much about that one, having never tried it. Maybe it does >support standard redcode, maybe not. I suppose I ought to try it out >some day myself. It does support Redcode. There are some minor differences in the implementation, but they are documented in the file DIFFERENCES wich comes with the program. If you find a non-documented difference I would be very interested in your bug report. >While I think diversity is generally a good thing, I do feel that two >similar and similarly named -- yet not quite compatible -- projects on >the same site can be confusing. Would it be impossible for the people >in charge of each to put a link to the other on the home and project >pages, with a brief explanation of the differences? Please? I currently link to koth.org. Last time I looked there wasn't much to link to at corewar.sourceforge.net except for the program which was covered on koth.org as well. But I will check again.. Walter From: "Shaun Ray" Subject: Corewars.org Date: Fri, 22 Dec 2000 00:21:49 +1100 Message-ID: <3a420421@casper.southcom.com.au> Is corewars.org a recent development and if so does anyone know the projected time that the hills will be up? I also found some information there about qMARS, which I have never heard of before. I exclusively use pMARS on my win32 machine, is qMARS going to become the new standard for Win based machines? Shaun Ray. From: jkw@austin.rr.com Subject: Re: Windows pMARS? Date: 22 Dec 2000 17:27:09 -0500 Message-ID: <4.1.20001222160658.00ae3cc0@pop-server> >Well, mostly because nobody's done it yet. It would take someone >who'd know the Windows API and be willing to write a new display >front-end. I might qualify for the latter, but definitely not the >former, and I don't really even want to learn that. > >Then there's the point that it'd still be a command line app. It >would take quite a bit of work to substitute a GUI for the command >line parser. Not to say it couldn't be done, just that you shouldn't >expect it in a 0.9.x release.. Well I think it could actually be done fairly easily with OpenGL without making it OS-specific... but I'm really not sure you'd gain all that much... Corewars isn't exactly a point and click game, heh. -jkw From: jkw@austin.rr.com Subject: Re: Corewars.org Date: 22 Dec 2000 17:33:20 -0500 Message-ID: <4.1.20001222161302.00aeb690@pop-server> At 09:32 AM 12/21/00 -0500, you wrote: >Is corewars.org a recent development and if so does anyone know the >projected time that the hills will be up? > >I also found some information there about qMARS, which I have never heard of >before. I exclusively use pMARS on my win32 machine, is qMARS going to >become the new standard for Win based machines? > >Shaun Ray. corewars.org has been up for at least a couple months. Much like the corewars.sourceforge.net site, it looks like their making their own simulator, and planning on duplicating koth.org/pizza hills. I haven't emailed the corewars.org admin to ask why they'd do that... I did ask the corewars.sourceforge.net why he was duplicating some koth/pizza hills and I didn't get much of a response. All these non standard corewars simulators are really going to confuse new players and drive them away... sigh... if these people really want to add new instruction sets or features to corewars, they should patch pMARS and add new command lines to select their features. :-/ -jkw From: jkw@austin.rr.com Subject: Re: Load Error Date: 22 Dec 2000 17:51:29 -0500 Message-ID: <4.1.20001222163241.00ae6800@pop-server> >I just recently discovered CoreWars and am going through some of the >tutorials before trying to build my first warrior. I am working through >Steve Baileys' tutorial and in lesson #5 he suggests running PMARSV from DOS >(not a DOS box in Windows), using the -v 52* display switch. This switch and >modifiers are found in the appendix of PMARSV.Doc. The problem is that >whenever I try to run this configuration I get a load error: No DPMI. Could >anyone tell me what this error means and if there is a way to correct it. >PMARSV works just fine from a DOS box in Windows '98. Are you using the executable that Nandor Sieben compiled? That one works the best for me, although I don't think I've tried rebooting to dos and running it. If you're going to reboot to dos and run pmarsv use the older executable. -jkw From: "Trooper.Teddy" Subject: Load Error Message-ID: <6yM06.2584$tk5.144413@dfiatx1-snr1.gtei.net> Date: Fri, 22 Dec 2000 17:53:06 GMT I just recently discovered CoreWars and am going through some of the tutorials before trying to build my first warrior. I am working through Steve Baileys' tutorial and in lesson #5 he suggests running PMARSV from DOS (not a DOS box in Windows), using the -v 52* display switch. This switch and modifiers are found in the appendix of PMARSV.Doc. The problem is that whenever I try to run this configuration I get a load error: No DPMI. Could anyone tell me what this error means and if there is a way to correct it. PMARSV works just fine from a DOS box in Windows '98. Please send your responses to SmysBot@Yahoo.com Thanks. From: Philip Kendall Subject: Re: Load Error Date: 22 Dec 2000 23:11:26 +0000 Message-ID: "Trooper.Teddy" writes: > I just recently discovered CoreWars and am going through some of the > tutorials before trying to build my first warrior. I am working through > Steve Baileys' tutorial and in lesson #5 he suggests running PMARSV from DOS > (not a DOS box in Windows), using the -v 52* display switch. This switch and > modifiers are found in the appendix of PMARSV.Doc. The problem is that > whenever I try to run this configuration I get a load error: No DPMI. Could > anyone tell me what this error means and if there is a way to correct it. > PMARSV works just fine from a DOS box in Windows '98. See (say) http://www.srcf.ucam.org/~pak21/misc/djgpp.shtml. Basically, pMARS is compiled using DJGPP, which switches from DOS's native 16-bit mode into a 32-bit mode, which needs a certain amount of code to support it. In order that this code isn't disributed with every DJGPP compiled program, it's supplied as a separate server, which is available from various places (see the DJGPP FAQ). > Please send your responses to SmysBot@Yahoo.com Please read the newsgroups you post to :-) HTH, Phil -- Philip Kendall http://www.srcf.ucam.org/~pak21/ From: "Timothy Farley" Subject: Re: Windows pMARS? Date: Sat, 23 Dec 2000 00:46:27 -0500 Message-ID: I don't know, the Gtk interface from corewars.sourceforge.net (or is it corewar.sourceforge....) has a really nice frontend, and is supposed to support redcode pretty well... I am actually thinking of installing linux on my laptop soley for that version of the simulator... - Tim - Timothy Farley wrote in message news:t430uimbfkjg20@corp.supernews.com... > Why hasn't pMARs been ported to Windows? I hate going to a DOS box as it is, > but when I switch to Win2k and their DOS emulator.... Who knows what pMARS > will be like. Would it be much too ard for the developers to simply take the > existing code and output it to a window somehow? I'm not complaining, just > curious. > > Thanks > > - Tim - > > From: David Matthew Moore Subject: Re: Turing Wars Date: 23 Dec 2000 03:13:08 GMT Message-ID: <921584$5i6$1@msunews.cl.msu.edu> Atom Coffee wrote: > Is anybody interested in the developing a Turing machine war. No. From: "Atom Coffee" Subject: Turing Wars Date: Sat, 23 Dec 2000 03:14:16 +0100 Message-ID: <9211ld$srh$1@faraday.a2000.nl> Is anybody interested in the developing a Turing machine war. I thought about this idea for a few days now, maybe some of you would find this an interesting idea to explore. My knowledge about Turing machines or Corewars isn't much, but i hope that this can be a start of an interesting discussion. This is what i could come up with: A terminated program has lost. When after a fixed amount of "time" no program has terminated it is a tie. The 2 programs should take turns, these are just like corewars The Turing arena is a circular tape of fixed length. A Universal Turing Machine could be used so that the programmers have to program the states. All Programs must be able to terminate. Every programmer gets to supply it's turing machine with a pice of "starting tape". From: "tmp" Subject: Re: Sourceforge.net core emulator Date: Sat, 23 Dec 2000 11:22:20 -0000 Message-ID: <922230$hj9$1@plutonium.btinternet.com> > It does support Redcode. There are some minor differences in the > implementation, but they are documented in the file DIFFERENCES wich > comes with the program. Do these differences mean that warriors will operate differently in the two environments? I'm afraid that I can't work out how to un-tar files on my windows machine. Could you email me an uncompressed copy -- or if it is short, just post it? Robert Macrae From: walterhnospam@gmx.de (Walter Hofmann) Subject: Re: Sourceforge.net core emulator Date: Sat, 23 Dec 2000 15:15:42 +0100 Message-ID: On Sat, 23 Dec 2000 11:22:20 -0000, tmp wrote: > >> It does support Redcode. There are some minor differences in the >> implementation, but they are documented in the file DIFFERENCES wich >> comes with the program. > >Do these differences mean that warriors will operate differently in >the two environments? The MINDISTANCE one has the potential to do so, the others are just parser changes or unsupported commands. (The MINDISTANCE difference was noticed by David M. Moore) >I'm afraid that I can't work out how to un-tar files on my windows >machine. Could you email me an uncompressed copy -- or if it is short, >just post it? WinZip reportedly does it, but I'll include it anyway (I would appreciate input on the remaining differences): -DIFFERENCES------------------------------------------------------------ This file describes the differences in the Redcode implementation between this program and pMARS 0.8.0. Differences not mentioned here are bugs. Please report them. Walter Hofmann, March 2000 ________________________________________ Opcodes: LDP and STP are not recognised. ________________________________________ Pseudo opcodes: Multi line EQU is not recognised. PIN is not recognised. ________________________________________ Modifiers: All modifiers are recognised. ________________________________________ Addressing modes: All addressing modes are recognised. ________________________________________ Directives: Only ";name" and ";author" are recognised. All other directives are ignored. Text before the redcode directive is not ignored. ________________________________________ Predefined variables: Only CORESIZE, MAXPROCESSES, MAXCYCLES, MAXLENGTH, MINDISTANCE and CURLINE are defined. MINDISTANCE is minimum number of emty cells between the end of one program and the start of the next program. In pMARS it is the minimum distance between the start of two programs. ________________________________________ Expression operators: The following operators are NOT supported: Comparison: != inequality < less than > greater than <= less than or equal >= greater than or equal Logical: && and || or ! unary negation Assignment: = (to register variables a..z) Please note that two operators must not come directly after each other, ie. 7*-5 is not allowed, use 7*(-5) or -7*5 instead. ________________________________________ Redcode grammar: Stringisation is not supported. The right side of an EQU statement is evaluated every time the label is used. It must evaluate to an integer; no string substitution is done. EQU may be referenced before they are defined. Multi line EQUs are not recognised. The last line in a program (or the line with the END statement if there is one) must be terminated with a newline. END and EQU statements are not allowed within FOR blocks. ------------------------------------------------------------------------ Walter Hofmann From: walterhnospam@gmx.de (Walter Hofmann) Subject: Re: Corewars.org Date: Sat, 23 Dec 2000 15:32:19 +0100 Message-ID: On 22 Dec 2000 17:33:20 -0500, jkw@austin.rr.com wrote: > >I haven't emailed the corewars.org admin to ask why they'd do that... >I did ask the corewars.sourceforge.net why he was duplicating some >koth/pizza hills and I didn't get much of a response. I cannot comment on corewars.org, but here is the replay I wrote to your email: I wrote: > >They aren't duplicates---there are very different warriors on them. But >having the same parameters means that people can easily switch between >the hills. > >Are you in search of a special hill which doesn't exist on other sites? >I created the tiny hill with parameters that Martin Ankerl supplied to >have a hill which is suitable for evolved warriors, but nobody else >requested any special parameters. If there is demand for another hill >for a special purpose I would certainly consider creating such a hill. > >Walter The offer to create new hills is still open. You continued: >All these non standard corewars simulators are really going to confuse >new players and drive them away... sigh... if these people really want >to add new instruction sets or features to corewars, they should >patch pMARS and add new command lines to select their features. :-/ Again, I cannot speak for corewars.org. As far as my Redcode simulator is concerned, it surely is standard compatible. Unless, of course, you define standard:=pMARS. But why have a standard in the first place, then? Walter From: "Ayan Chakrabarti" Subject: Re: Corewars.org Date: 24 Dec 2000 13:51:08 -0500 Message-ID: <005001c06f05$f4cd78c0$8bd738ca@Default> Hi > At 09:32 AM 12/21/00 -0500, wrote: > corewars.org has been up for at least a couple months. Much like the > corewars.sourceforge.net site, it looks like their making their own > simulator, and planning on duplicating koth.org/pizza hills. > > I haven't emailed the corewars.org admin to ask why they'd do that... > I did ask the corewars.sourceforge.net why he was duplicating some > koth/pizza hills and I didn't get much of a response. Actually, the corewars.org site has been set up by the CWSI (Core War Society of India). It seems that some of the hills will be targetted at Indian corewar players and will help to increase interest for corewar in India. Besides, I don't think there is any real problem if they duplicate the koth.org/pizza hills. I'm sure all they'll do is add more variety. > > All these non standard corewars simulators are really going to confuse > new players and drive them away... sigh... The guys behind this site have been introducing corewars as an event in inter-school level computer competitions for two-years now.(In the first year, they had different participants make warrirors which fought each other and in the second year, they gave each participant a set of white warriors and asked them to write a different warrior to fight against each of the white warriors). This has generated a lot of interest in corewars. (Infact, this is where I came into contact with corewars for the first time). They've been also writing about corewars in computer magazines and I think they've encouraged new players to take an interest in the game rather than drive them away. > if these people really want > to add new instruction sets or features to corewars, they should > patch pMARS and add new command lines to select their features. :-/ > > -jkw > I haven't been able to download qMars, but I don't think it is radically different from pMars. I think the main difference will lie in implementation of pseudo-opcodes, labels,specialised comments (like ;assert), etc. I don't think they'll add new instructions or try to change the structure of the game itself. At worst, they might not implement some of the newer stuff like P-SPACE, etc. Besides, a redcode simulator which isn't more or less compatible with pMars is unlikely to catch on amongst players. Infact, the main problem with corewars.org is that they seem to be taking a pretty long time in getting the hills up and running. :). I've been going to their site for quite some time now and it hasn't been updated yet. Ayan Chakrabarti " God exists since mathematics is consistent, and the Devil exists since we cannot prove it. " From: "tmp" Subject: Re: Sourceforge.net core emulator Date: Sun, 24 Dec 2000 23:04:10 -0000 Message-ID: <929hd4$m6v$1@plutonium.btinternet.com> > LDP and STP are not recognised. OK, sensible subset. > Multi line EQU is not recognised. PIN is not recognised. ... > Only ";name" and ";author" are recognised. All other directives are > ignored. ... > Only CORESIZE, MAXPROCESSES, MAXCYCLES, MAXLENGTH, MINDISTANCE and > CURLINE are defined. Minor hastles. > MINDISTANCE is minimum number of emty cells between the end of one > program and the start of the next program. In pMARS it is the > minimum distance between the start of two programs. Fairly minor, but still a very, very bad idea. Why do it? It introduces confusion for no gain. > The following operators are NOT supported: [etc] I don't think I would miss them, but some probably would. Nice to add one day. > Stringisation is not supported. The right side of an EQU statement is > evaluated every time the label is used. It must evaluate to an > integer; no string substitution is done. EQU may be referenced before > they are defined. Multi line EQUs are not recognised. The last line in > a program (or the line with the END statement if there is one) must be > terminated with a newline. END and EQU statements are not allowed > within FOR blocks. Ouch. This would break lots of warriors. I can see the reason for several of the decisions; the ommission of features, especially P-Space, must make life easier. However, two really don't seem to make sense. To use a different definition of MINDISTANCE will break every warrior that uses it, for no gain whatsoever. Changing of the EQU logic will break many or most warriors, so has a massive cost, and it can't save much code. I always assumed the string logic was to make pmars easier to write! It looks as if this engine is different enough to make many standard warriors unuseable without recoding. I know that Unix people like to have plenty of standards to choose from, but I can't see the benefit. Why not use the real thing? Robert Macrae From: Koth Subject: KOTH.ORG: Status - 94 No Pspace 12/25/00 Date: 25 Dec 2000 08:28:51 -0500 Message-ID: <200012250500.AAA23668@gevjon.ttsg.com> Weekly Status on 12/25/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG 94 No Pspace CoreWar Hill: Last battle concluded at : Sat Dec 23 05:41:53 EST 2000 # %W/ %L/ %T Name Author Score Age 1 38/ 22/ 40 Olivia Ben Ford 153 74 2 37/ 24/ 39 Uninvited John Metcalf 150 28 3 38/ 26/ 37 Quicksilver Michal Janeczek 150 108 4 34/ 19/ 47 nPaper II Paul-V Khuong 148 346 5 34/ 19/ 47 The Dark One Christian Schmidt 148 139 6 44/ 39/ 18 Behemot Michal Janeczek 148 169 7 40/ 34/ 26 Recount P.Kline 147 31 8 44/ 41/ 15 Eraser II Ken Espiritu 147 303 9 37/ 30/ 33 Blacken Ian Oversby 145 593 10 44/ 43/ 14 G2-b David Moore 145 132 11 46/ 47/ 7 He Scans Alone P.Kline 144 30 12 34/ 24/ 42 Jade Ben Ford 144 415 13 43/ 43/ 14 Stalker P.Kline 143 331 14 42/ 42/ 15 Jinx Christian Schmidt 143 309 15 25/ 11/ 64 The Phantom Menace Anton Marsden 140 46 16 29/ 20/ 51 KafuFFLe John Metcalf 139 29 17 36/ 35/ 30 Keyser Soze Anton Marsden 136 47 18 38/ 42/ 20 myBlur Paulsson 134 11 19 23/ 24/ 53 jam test 3 John Metcalf 121 12 20 35/ 54/ 11 Hyperclear +1 Steve Gunnell 115 1 21 2/ 98/ 0 1 JAM 7 0 From: Koth Subject: KOTH.ORG: Status - MultiWarrior 94 12/25/00 Date: 25 Dec 2000 08:28:55 -0500 Message-ID: <200012250500.AAA23655@gevjon.ttsg.com> Weekly Status on 12/25/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG Multiwarrior 94 CoreWar Hill: Last battle concluded at : Fri Dec 22 14:27:31 EST 2000 # Name Author Score Age 1 Dracula's Cape Ben Ford 42 25 2 D-clearM Ken Espiritu 40 47 3 QuiVa John Metcalf 35 140 4 Her Majesty P.Kline 31 66 5 fclear Brian Haskin 30 31 6 Pitbull Christian Schmidt 29 3 7 Scan Test Tester 23 6 8 CrazyShot Christian Schmidt 22 2 9 Foo John Metcalf 19 1 10 Friction Ken Espiritu 11 19 11 Crazy Lukasz Anforowicz 1 0 From: Koth Subject: KOTH.ORG: Status - ICWS Experimental 94 12/25/00 Date: 25 Dec 2000 08:28:47 -0500 Message-ID: <200012250500.AAA23661@gevjon.ttsg.com> Weekly Status on 12/25/00 -=- irc.KOTH.org is up! Meetings held in #corewars -=- Tons of new features on www.KOTH.org/koth.html pages -=- *FAQ* page located at: www.KOTH.org/corewar-faq.html Current Status of the KOTH.ORG ICWS Experimental 94 CoreWar Hill: Last battle concluded at : Sat Dec 9 11:09:11 EST 2000 # %W/ %L/ %T Name Author Score Age 1 49/ 31/ 19 Random Reaper Dave Hillis 167 1 2 45/ 29/ 26 Controlled Aggression Ian Oversby 161 63 3 46/ 33/ 22 Black Moods Ian Oversby 159 59 4 47/ 38/ 15 Greetings From Asbury Par JKW 156 23 5 33/ 15/ 52 Katafutr Michal Janeczek 151 3 6 40/ 35/ 25 Ogre Christian Schmidt 145 11 7 34/ 27/ 40 Damage Inflicted Robert Macrae 141 2 8 22/ 4/ 74 Black Box v1.1 JKW 139 26 9 26/ 13/ 62 Denial David Moore 139 4 10 29/ 21/ 50 Venom v0.2b Christian Schmidt 137 85 11 24/ 12/ 64 Evol Cap 4 X John Wilkinson 136 132 12 21/ 5/ 74 Evolve X v4.0 John Wilkinson 136 80 13 33/ 38/ 29 Dr. Gate X Franz 128 103 14 30/ 36/ 34 test CS 123 20 15 25/ 28/ 47 Rosebud Beppe 122 111 16 23/ 24/ 53 Purple v0.1 Christian Schmidt 121 84 17 32/ 43/ 24 Pattel's Virus X Ben Ford 121 7 18 32/ 46/ 22 Pagan John K W 119 117 19 27/ 39/ 34 MorphinMerlin Jeremy K 115 46 20 32/ 52/ 16 S.E.T.I. 4-X JKW 113 133 21 11/ 87/ 1 foobar Flash 35 0 From: Ilmari Karonen Subject: ANNOUNCE: pMARS 0.9.2 released at SourceForge Date: 25 Dec 2000 14:09:00 GMT Message-ID: <977751176.129@itz.pp.sci.fi> Here's a little Christmas present for all of you. As of a few minutes ago, release 0.9.2 of pMARS has been available for download at http://sourceforge.net/projects/corewar/ This release simply merges in all the open patches, adding the following features: * Permutation mode: A new command line switch -P lets you run all the possible warrior placements in random order. This eliminates random fluctuations in scores for non-Pspace warriors, and reduces it for Pspacers as well. (Only for 2 warriors currently, small core size recommended.) * Overflow warnings: pMARS will now warn if arithmetic overflow occurs during expression evaluation. If you receive a warning like this, the result of the expression is probably incorrect and you should fix it, for example by restricting intermediate values to modulo CORESIZE. * Division by zero and bad expression are also now separate errors. * The -F option no longer has an upper limit, except as imposed by the number of bits used to store integers. Values larger than CORESIZE - MINDISTANCE will be wrapped to the valid range. This lets KotH servers pick their -F numbers from a much larger set, which should make the random seed virtually unguessable. * Various bug fixes, including a patch to make the Curses display code compile properly and a fix in command line parsing. The release is currently in source form only. It has been tested under Linux, and the server mode has also been successfully compiled and tested under Win98 / Cygwin. I have not been able to compile a 16-bit MSDOS version for testing, and would appreciate it if anyone would test that as well as any other non-unix environments. This post also serves to announce that Anton Marsden has granted me developer rights to the corewar SourceForge project, and I'll be more or less taking care of the pMARS side of the project. I've already begun to accumulate a wish list for 0.9.3, starting with simplifying the build process. If anyone has any new suggestions, or better yet patches, they'll be gladly accepted. Merry Christmas to everybody, and happy hacking! -- Ilmari Karonen - http://www.sci.fi/~iltzu/ "I believe it's like banging one's head against the wall. The prize comes when one stops." -- Peter Caswell in AFU From: pak@ast.cam.ac.uk (Philip Kendall) Subject: Automake/conf patch for pMARS Date: 26 Dec 2000 18:27:21 -0000 Message-ID: <92anu9$m2k@cass30> Hi all. I've done a quick bit of hacking, and produced a quick patch for pMARS (0.9.2) which allows use of automake/autoconf to help the build process along on Unix-ish machines. I've uploaded this to SourceForge, so if anybody feels like testing it, that would be much appreciated :-) (I've tested it on my Linux box and very briefly on a Solaris box as well) Cheers, Phil From: walterhnospam@gmx.de (Walter Hofmann) Subject: Re: Sourceforge.net core emulator Date: Wed, 27 Dec 2000 00:47:28 +0100 Message-ID: On Sun, 24 Dec 2000 23:04:10 -0000, tmp wrote: > >> Stringisation is not supported. The right side of an EQU statement is >> evaluated every time the label is used. It must evaluate to an >> integer; no string substitution is done. EQU may be referenced before >> they are defined. Multi line EQUs are not recognised. The last line in >> a program (or the line with the END statement if there is one) must be >> terminated with a newline. END and EQU statements are not allowed >> within FOR blocks. > >Ouch. This would break lots of warriors. It doesn't. I tested the parser with all (non-PSPACE) Redcode warriors I could get my hands on and there are virtually no problems. >I can see the reason for several of the decisions; the ommission of >features, especially P-Space, must make life easier. Indeed. > However, two >really don't seem to make sense. To use a different definition of >MINDISTANCE will break every warrior that uses it, for no gain >whatsoever. This is one of the things that are likely to change some day. It was originally implemented the way it is because I didn't read the standard fully and my way seemed the only sensible way to do it at that time. > Changing of the EQU logic will break many or most >warriors, so has a massive cost, and it can't save much code. I always >assumed the string logic was to make pmars easier to write! I don't know how pMARS parses the code, but I'm using a yacc-generated parser. It seemed very hard to do the string substitution, and you cannot do it in a preprocessor because the for loop count can depend on some labels. Ugh. Redcode isn't a particulary nice language parser-wise. I never saw a warrior break from the different EQU substitution or because it placed an EQU in a FOR loop. I guess it will only ever matter if one uses stringisation (label_&i -> label_1, label_2, ...) which I don't support currently. The only warrior I saw break from the no-end-in-a-for-loop rule is Freight Train by David Moore which does the following to get a conditional compilation (switch is 0 or 1): for switch end qscan rof for 1-switch end main rof I'm not keen on supporting this... >It looks as if this engine is different enough to make many standard >warriors unuseable without recoding. Not so. Nearly everly non-PSPACE warrior works as expected. Walter From: "Robert Macrae" Subject: Re: Sourceforge.net core emulator Date: Wed, 27 Dec 2000 19:43:18 -0000 Message-ID: <92dgue$frq$1@lure.pipex.net> > >> Stringisation is not supported. The right side of an EQU statement is ... > > > >Ouch. This would break lots of warriors. > > It doesn't. I tested the parser with all (non-PSPACE) Redcode warriors I > could get my hands on and there are virtually no problems. Interesting. I juggle strings a lot in development warriors -- its an easy way to create and test lots of related variants -- but I guess most people must clean up their warriors before submitting a final version to a hill and/or put in lots of brackets to avoid tripping up. > Redcode isn't a particulary nice language parser-wise. Not structured enough ;-) > >It looks as if this engine is different enough to make many standard > >warriors unuseable without recoding. > > Not so. Nearly everly non-PSPACE warrior works as expected. The test is how it works in practice, so that sounds pretty good. Robert From: bjoern@blinker.NOSPAM.net (Bjoern) Subject: Re: Corewars.org Date: Wed, 27 Dec 2000 20:46:35 GMT Message-ID: <3a4a3423.552584@news.lrz-muenchen.de> On 24 Dec 2000 13:51:08 -0500, "Ayan Chakrabarti" wrote: [...] >The guys behind this site have been introducing corewars as an event in >inter-school level computer competitions for two-years now.(In the first >year, they had different participants make warrirors which fought each other >and in the second year, they gave each participant a set of white warriors >and asked them to write a different warrior to fight against each of the >white warriors). This has generated a lot of interest in corewars. (Infact, >this is where I came into contact with corewars for the first time). They've >been also writing about corewars in computer magazines and I think they've >encouraged new players to take an interest in the game rather than drive >them away. Pity that they never made contact with the existing Corewar community, though. But it's never too late... [...] >Infact, the main problem with corewars.org is that they seem to be taking a >pretty long time in getting the hills up and running. :). I've been going >to their site for quite some time now and it hasn't been updated yet. Why are they even doing it, as there are already hills existing? Bjoern