From: nautilus@lachesis.acm.rpi.edu (John M. Twilley) Subject: Koth->PC BBS Door Message-ID: Date: Mon, 3 Aug 1992 05:35:27 GMT Since I moved a substantial distance from my Internet connection, I started BBS'ing again. A discussion of assembler came up, and I described KotH. They loved the idea, and want to try and work on a similar project, but for BBS'es -- something called a 'door' -- a program that can be run online while the user is logged in to the BBS. Anyone have any ideas? They would be dearly appreciated. Please send any mail to : Jack_Twilley@f201.n320.z1.fidonet.org Thanks a lot... (Maybe get it running through FidoNet? :-) :-)) Nautilus. -- John M. Twilley | A decapitated cockroach lives for several nautilus@acm.rpi.edu | weeks before finally dying of starvation. From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Koth->PC BBS Door Message-ID: <1992Aug3.120339.2354@oucsace.cs.ohiou.edu> Date: 3 Aug 92 12:03:39 GMT In article nautilus@lachesis.acm.rpi.edu (John M. Twilley) writes: > >Since I moved a substantial distance from my Internet connection, I started >BBS'ing again. A discussion of assembler came up, and I described KotH. > >They loved the idea, and want to try and work on a similar project, but for >BBS'es -- something called a 'door' -- a program that can be run online while the >user is logged in to the BBS. > >Anyone have any ideas? They would be dearly appreciated. > >Please send any mail to : Jack_Twilley@f201.n320.z1.fidonet.org > >Thanks a lot... > >(Maybe get it running through FidoNet? :-) :-)) > Yeah, I am currently working on the same type of thing. I am using WWIV and have set up a BBS that is going to be Core War specific. I have a lot of stuff there already, but I don't have it setup and complete yet. In WWIV, you don't need doors, instead, online programs are available at the touch of a key. (I guess if you wanted to be technical... what is the difference?) It is all a good idea, but memory has to be watched very very carefully. The biggest thing to remember is that the output to the screen has to be done in a certain manner (which is difficult) and cannot be done directly to the video... otherwise it will mean certain destruction to the users on the other end of the BBS... :-) In the process of writing my newest version of the Deluxe package, I have been keeping up with a PC version as well. This is the version that I hope can get thrown into the BBS. Scott Adkins sadkins@ohiou.edu From: wms@iwarp.intel.com (William Shubert) Subject: KotH Standings Message-ID: <1992Aug3.203311.28553@iWarp.intel.com> Date: Mon, 3 Aug 1992 20:33:11 GMT OK, here's the ICWS hill. It still has an 8000 process limit; I suppose that I should get around to changing it to 64 pretty soon. You'll notice that the top two programs are both splitters. # %W/ %L/ %T Name Author Score Age 1 47/ 22/ 31 Flash Paper3.7 Matt Hastings 172 208 2 43/ 27/ 31 Paper Bomb Rodney Schuler 159 24 3 47/ 43/ 10 No Mucking About Campbell Fraser 151 156 4 46/ 41/ 13 Twill Andy Pierce 151 58 5 46/ 42/ 12 Sucker 4 Stefan Strack 149 409 6 46/ 44/ 10 Charon v7.0 J.Cisek & S.Strack 148 87 7 45/ 44/ 11 Crimp 2 Andy Pierce 147 55 8 44/ 41/ 15 Falling Leaf 1.21 Matt Hastings 146 294 9 41/ 37/ 22 Relentless J.Cisek 146 129 10 39/ 32/ 29 t2 nandor sieben 146 90 11 43/ 41/ 16 B-scanners live in vain Matt Hastings 145 138 12 40/ 37/ 23 RotLD 2 nandor sieben 144 67 13 42/ 43/ 15 Smooth Noodle Map Matt Hastings 141 414 14 39/ 39/ 22 Quebec Eric Prestemon 139 45 15 39/ 43/ 17 testing RR A S. Halvorsen 135 48 16 41/ 47/ 12 Disruptor v.1 Paul S. Kilroy 134 65 17 42/ 51/ 7 Miny v.3 Paul S. Kilroy 133 70 18 39/ 47/ 14 B Paul S. Kilroy 132 120 19 36/ 54/ 10 Sand Pebbles v1.74 W. Mintardjo 118 6 20 28/ 40/ 32 ferengi nandor sieben 115 1 On the x-hill, I've made a small change to spider that suddenly shot it 40 points ahead, back to the #1 slot. # %W/ %L/ %T Name Author Score Age 1 60/ 21/ 19 Spider 2.1 Bill Shubert 199 10 2 38/ 6/ 55 Sigil Matt Hastings 171 84 3 40/ 13/ 47 seething mass Campbell Fraser 168 14 4 40/ 28/ 32 Patriot Kurt vonRoeschlaub 152 90 5 28/ 15/ 57 Blind Leap1.1 Jonathan Wolf 140 80 6 41/ 43/ 16 Odin J.Cisek 140 169 7 32/ 25/ 43 SuperChameleon 1.6 Alex MacAulay 140 21 8 41/ 44/ 15 Scorpion 1.4 Alex MacAulay 139 1 9 40/ 41/ 19 ImpDwarf Gun 1.0 Warren vonRoeschlaub 139 96 10 31/ 26/ 43 Domestos 1.2 Jonathan Wolf 136 88 11 41/ 47/ 12 Thunder Run 1.11 Eric J. Schwertfeger 135 16 12 23/ 15/ 62 Brute-Force 1.2 Ray Cromwell 130 115 13 34/ 38/ 28 Tank Jonathan Wolf 130 57 14 37/ 46/ 17 Halberd 1.20 Eric J. Schwertfeger 129 11 15 38/ 47/ 15 Leaper-X 4.0 Jeff Raven 128 166 16 37/ 47/ 15 Lance 1.40 Eric J. Schwertfeger 127 12 17 26/ 33/ 41 Scud 1.0 Kurt vonRoeschlaub 119 91 18 19/ 21/ 60 Worm1a Dan Nabutovsky 117 63 19 21/ 31/ 48 Patch Alex MacAulay 110 2 20 26/ 41/ 33 Fisherman Campbell Fraser 110 77 As usual, for entry instructions or Unix/X11 KotH source code just send me some mail. -Bill (wms@iwarp.intel.com) From: hastings-matthew@CS.YALE.EDU (Matthew Hastings) Subject: Re: KotH Standings Message-ID: <1992Aug3.233821.28404@cs.yale.edu> Date: Mon, 3 Aug 1992 23:38:21 GMT Just a second. In the last KotH update I saw: Note Paper has been kicked off the hill, Crimp2 is now the oldest program, so let's go to 64 process limit. Now I see:the top two programs are Paper types, let's go to 64 process limit. OK, that wasn't what you said exactly, but still: what about KotH standings suggests a 64 process limit to be good? Recently we've had paper types, scanners and stones as no. 1. THE ONLY reason I can think of to go to 64 processes is that that is standard in ICWS tournaments. But think off all the tricks that disappear, such as SPL 0 protection, short core-clear routines and so on. If you want to go to 64 processes either make a new -x type hill (except it will be more standard instead of less) or 'retire' the current hill, maybe put a nice post talking about it, and start completely afresh. Of my programs, the following don't really work under 64 processes:B-scanners, Flash Paper, Falling Leaf. Smooth Noodle Map sorta does (if it starts replicating it is ok, but under 64 proc. it's core clear is worthless.) BTW, Bill didn't mention this so I will: the new Spider does beat Sigil. Badly. It was a nice record to have though. :-) From: t-jcisek@microsoft.com (Julius Cisek) Subject: Lost code Message-ID: <1992Aug04.013839.21866@microsoft.com> Date: 04 Aug 92 01:38:39 GMT Hey... I've had a FATAL HD crash on my development machine and among tons of other stuff lost was all the code for CoreWar warriors. I know that some of you keep libraries of warriors to test against. Could you do me the enormous favour of mailing me whatever code of mine that you have? (I have the last four koth-x entries since that was a recent post...) I would appretiate even old code (like Charon 2.0) since I like keeping this stuff around for posterity reasons... :) Jules P.S. Yes, most of the source is in my head, but I don't remember any of the numbers and my number generating programs were on the same HD. P.S.S. I hate HPFS! -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Re: KotH Standings Message-ID: <1992Aug4.021509.15225@samba.oit.unc.edu> Date: Tue, 4 Aug 1992 02:15:09 GMT More Hills! Arrrrgh! Still, I have to agree with Matt that there are some programs, good programs, which won't work with only 64 processes. This doesn't affect the programs I have on the hill but it will still make a significant difference. Maybe keep the current hill as the "KotH Classic Hill" and add an "ICWS Tournament Hill" with full ICWS parameters (such as they have been defined anyway). I think that it is cool to have a hill without an effective process limit (such as the current hill with 8000 processes max) although it might be fun to see what a lower limit does. I can predict one thing it would do right away: it would make programs which bomb with Imps feasible again (or at least more feasible). While talking about new hills, I think that it would be neat to see a scoring system implemented as someone (I forget who) suggested long ago: keep track of how each program does against every other program as KotH does now, but then fix the 20th place program and determine 19th place among the remaining programs (without including the 20th place program), then fixing the 19th place program and etc. so that the number 1 program will always have to beat the number two program etc. I don't know that it will make a big difference -- it might be interesting to try though. -Andy ajpierce@med.unc.edu From: maniac@lonnie-mack.cs.unlv.edu (Eric J. Schwertfeger) Subject: Katana 1.20 [X-Warrior Source] Message-ID: <1992Aug5.025600.27734@unlv.edu> Date: Wed, 5 Aug 92 02:56:00 GMT Well, since I've complained about the lack of X-Hill warriors, I think it's time I posted Katana. Katana made the hill, and I *THINK* it briefly made it into the top 10. It's a rather fast scanner/bomber, and it bombs the core mod-6 in just over 3000 cycles. (provided it doesn't spend too much time shooting decoys). ;redcode-x ;name Katana 1.30 ;author Eric J. Schwertfeger ;strategy CMP scan through area below ;strategy DAT-bomb what we see, and ;strategy then copy down and do it again ;strategy Submitted: @date@ STEP EQU 228 SPLIT EQU 6 START MOV INIT,SCAN MOV #7,SCAN-STEP+(SPLIT*2) INCIT SUB INC,SCAN SCAN CMP -SPLIT,0 JMP SPLAT JMP INCIT SPLAT MOV INC, @SCAN SUB HALF, SCAN MOV INC, @SCAN SUB HALF, SCAN CMP #(-STEP),SCAN JMP SCAN SRC MOV #INIT+1,#0 DEST MOV #INIT+1-STEP,#0 COUNT MOV #11,#0 MLOOP MOV Date: Wed, 5 Aug 92 02:58:08 GMT Lance has been rather high on the hill, but since it's about to fall off the hill, here is the source to it. ;redcode-x ;name Lance 1.40 ;author Eric J. Schwertfeger ;strategy Rolls through memory bombing with DAT ;strategy uses cooperating, 2 instruction subprogram ;strategy similar to spider's fangs to bomb in the ;strategy -251 to -500 range. ;strategy v 1.3X less dense bombing does better due to ;strategy larger size of X-warriors. ;strategy v 1.4X eliminated back bombing, forward bombing ;strategy now 33% faster. bombs entire core mod 6 ;strategy in 5500 cycles ;strategy Submitted: @date@ ;kill Lance 1.30 INC EQU (233) STEP EQU (6) LANCE EQU (BOMB-INC) BOMB DAT #0,#0 START MOV #(LANCE-STEP),BOMB MOV LANCE1,LANCE MOV LANCE3,LANCE+1 MOV LANCE2,LANCE+2 SPL LANCE MBACK EQU (LANCE2+100) COUNT MOV #19,#0 BLOOP SUB #STEP,BOMB SUB #STEP,BOMB DJN BLOOP,COUNT MOV BOMB,LANCE SRC MOV #LANCE2+1,#0 DEST MOV #LANCE2+1-INC,#0 CCOUNT MOV #11,#11 MLOOP MOV Date: Wed, 5 Aug 92 03:13:36 GMT Thunder Run is one of my more stable programs on the hill, as it seems to always sit around at #10. Here is my latest TR. Basically Thunder Run starts two mod-2 bombers going in opposite directions, the idea being that many programs are weak from one direction or the other, this way we hit their weak side regardless. While the idea isn't that great, TR does do better than my single-direction Rolling Thunder. ;redcode-x ;name Thunder Run 1.11 ;author Eric J. Schwertfeger ;strategy 2 Carpet bombers going opposite directions ;strategy bombers are similar to Rolling thunder. ;strategy Submitted: @date@ RBOMBSITE EQU RSTART-248 RBITE EQU 64 LAUNCH SPL FLAUNCH RLAUNCH MOV #3-RBITE,RSRC+RBITE MOV #2-(RBITE*2),RDEST+RBITE MOV #6,RCOUNT+RBITE JMP RSTART RCOUNT DAT #0, #6 RSTART MOV RBOMB, RBOMBSITE RLOOP MOV RBOMBSITE, Date: Wed, 5 Aug 92 03:24:04 GMT Skipshot 1.20 is something that is getting posted before it gets submitted, because while I doubt it will do well, there is one or two tricks that may prove educational to a few newcomers. One think SkipShot does to keep it's size down is that it doesn't initialize it's destination pointer. It still maintains a constant step, because it is using the previous copies destination, which has already been copied. It also doesn't maintain a counter of how much has been copied, by having the source the first part of the code, then looping until the source is 0. ;redcode-x ;name SkipShot 1.20 ;author Eric J. Schwertfeger ;strategy Copy Self Like Crazy ;strategy Submitted: @date@ STEP EQU (10*21) SRC DAT #9 ,#9 START MOV Date: 7 Aug 92 01:08:25 GMT Here is Hellicon2, a sort of Smooth Noodle Map5. I'm disappointed that, despite the millions of strange tricks this has that SNM doesn't, it isn't much better. I guess the hill is just getting too tough. Maybe we should go to a 64 process limit, JUST to force people to begin again. Consider that when Hellicon2 was submitted, and knocked off B-stie, the lowest program was Relentless, which has been no. 2 and higher and used to be very high@! I'm certain that Relentless is major improv. on original RotLD, which used to be one of longest living programs. Quite a few programs are suffering this fate. My Smooth Noodle Map and Andy Pierce's Crimp2 are both now pretty low compared to a few weeks ago, number 11 and 10 respectively! It seems things have reached the point that it is almost impossible for someone w/ little experience, who has not read source for other programs in r.g.cw. for a few weeks, to get a program on the hill without a program having been ;killed just before! BTW, just killed SNM4.1, it had a nice history, but has been out-evolved. ;redcode ;author Matt Hastings ;name Hellicon2 mov s5, Date: Fri, 7 Aug 1992 01:51:21 GMT Regarding that pervious post, I have posted source to all my programs on the hill (I'm also mentioning this becuase I have gotten requests for source). If you can't find source, I will give you any source of mine. Fell free to e-mail me if your system doesn't have those articles any more. From: maniac@charlie.cs.unlv.edu (Eric J. Schwertfeger) Subject: Halberd 1.2 [X-Warroir Source] Message-ID: <1992Aug7.040609.22579@unlv.edu> Date: Fri, 7 Aug 92 04:06:09 GMT Well, now that Loki is doing well on the hill, I can loosen up with Halberd, which was my most successful warrior prior to Loki. Interestingly enough, out of the 5 warriors that won more than 50% of its games verses Loki 2.2, three of them were mine (the only three non-Loki warriors I had on the hill at that time :-) As the subject line states, halberd is much like lance, but it is a vampire, rather than a straight-forward bomber. ;redcode-x ;name Halberd 1.20 ;author Eric J. Schwertfeger ;strategy Variation on Lance ;strategy Rolls through memory bombing with JMP PIT ;strategy instructions, then after two passes, changes ;strategy to DAT bombing. ;strategy v 1.1X less dense bombing does better due to ;strategy larger size of X-warriors. ;strategy v 1.2X 33% Faster Bombing ;kill Halberd 1.10 ;strategy submitted @date@ STEP EQU (228) DENS EQU (-6) LANCE EQU (BOMB-STEP) BOMB JMP PIT-(LANCE+DENS)-4,#(LANCE+DENS) START MOV #(LANCE),BOMB SUB INC,BOMB MOV LANCE1,LANCE MOV LANCE3,LANCE+1 MOV LANCE2,LANCE+2 SPL LANCE MBACK EQU (LANCE2+100) BCOUNT MOV #18,#0 BLOOP SUB INC,BOMB SUB INC,BOMB DJN BLOOP,BCOUNT SUB INC,BOMB MOV DATBOMB,LANCE DJN SRC,#79 MOV DATBOMB,BOMB SRC MOV #LANCE2+1,#0 DEST MOV #LANCE2+1-STEP,#0 COUNT MOV #14,#14 MLOOP MOV Date: Fri, 7 Aug 1992 14:19:11 GMT Now that Scud 1.0 has been pushed off the X-hill, I am tempted to post the source. However two things prevent me: 1) A serious "rm s*" accident. 2) I am working on a Scud 2.0 and don't want to type in the code for scud 1.0 and then scud 2.0 (okay, so I'm lazy) The basic idea however is streightforward, so I'll just describe it, you could probably write it on your own. If you remember a while back I posted code for x-hill decoys (for scanners). Scud merely launches 7 of these with different distance parameters so that every tenth memory cell gets hit (though not always fatally). It then jumps to an imp gun to act as shock troops to clear up the rest. Scud was especially good at hitting large programs and programs that had a main process that remained fixed or moved slowly. It did especially bad with programs that split and spread quickly. Since most of the x-hill warriors are in the latter catagory it tended to hover around 15-18. | __L__ ******************************* -|- ___ * Warren Kurt vonRoeschlaub * | | O | * kv07@iastate.edu * |/ `---' * Iowa State University * /| ___ * Math Department * | |___| * 400 Carver Hall * | |___| * Ames, IA 50011 * J _____ ******************************* From: trent@mailhost.hsas.washington.edu (Sigfried Trent) Subject: How to kill Message-ID: <1992Aug7.193410.24208@u.washington.edu> Date: Fri, 7 Aug 1992 19:34:10 GMT How is a program defeated in this game. Do you have to erase all its code. or capture some part of the proccesor or what? From: maniac@lil-ed.cs.unlv.edu (Eric J. Schwertfeger) Subject: Important X-HILL discovery!!! Message-ID: <1992Aug7.212448.21353@unlv.edu> Date: Fri, 7 Aug 92 21:24:48 GMT I just discovered something wonderful! If you have a core clear as part of your program, make it a repeating core clear. This tends to do much better against most programs than a simple core clear, if you have not completely killed everything before the core clear, and if you have killed everything, why core-clear? The simplest mechanism I found for doing this is like this. DELAY DJN DELAY,#WAIT MOV #WAIT,DELAY WIPE SPL DELAY ; enter here CORECLEAR ; your core-clear code goes here The WAIT constant is a delay that should be just long enough for your core-clear to wipe all memory. that way, if something happened to your core clear while it was working, it will get re-run when the monitor realizes that something has gone wrong. Echo 1.0 uses this to great advantage. I wrote Echo in about 30 minutes, just to have around in case I wanted to kill something. Imagine my surprize when it went to #1 on the x-hill! Unfortunately, this doesn't apply to the regular hill, because if your regular hill core-clear program got hit, then you probably don't have another copy of it to run. -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu From: durham@cup.portal.com (Mark Allen Durham) Subject: I'm back! Message-ID: <63625@cup.portal.com> Date: Fri, 7 Aug 92 23:00:33 PDT Greetings Core War Enthusiasts! For those of you who may not know who I am, my name is Mark A. Durham and I am currently the Editor of The Core War Newsletter. I have been incommunicado for the last few months, but I am back now as promised. Barring large scale disasters (Mark Clarkson's house burned down during his tenure as Director of the ICWS), I should be available at the following addresses for years to come: Mark A. Durham 18 Honeysuckle Terrace Spartanburg, SC 29307-3760 (803)579-0431 durham@cup.portal.com For those of you who think that address looks familiar, please note that both my zip code and telephone numbers changed recently due to no fault of my own. I am still getting my Portal "legs" and trying to get used to paying for USENET/EMail access. Unfortunately for me, the least expensive hours are those hours I am most likely to be otherwise occupied or asleep. So replies may take me a few days. My sincere thanks to Stefan Strack for taking care of the FAQ during my absence. Why is it people always ask about the FAQ three days before the first of the month when it is normally posted? Murphy's Law I suppose. I need some help with the FAQ by the way. We need a dictionary of Core War. Any budding Noah Websters out there, send me some EMail and volunteer. If you have a favorite term you would like to see in the dictionary, send in a definition to me and I'll pass it on. Also, someone once sent me EMail telling me to be sure to post the FAQ to blah.blah.blah. Obviously, I can not remember the name of the newsgroup. Is there a newsgroup for FAQs? (Maybe joe.friday.dragnet - "Just the FAQs, Ma'am." ;) ). We also need to keep better track of which Core War systems are available for which computers, where they are available, current version numbers, and hopefully also good descriptions of the systems and what they offer. I am starting that section of the FAQ over from scratch. Under the catagory of "Unfinished Business", I hope to finish and post the Summer 1992 TCWN while it is still technically summer. I DESPERATELY need articles for the Fall 1992 TCWN and subsequent issues. Send me ANYTHING! I will work with you to develop your rawest ideas scribbled on the back of a napkin into a full-fledged article you will be proud to display to your friends and neighbors. We have had some very good posts on the net about the transitive nature of Core War. Let us turn them into excellent articles. If fame is not enough and you need financial incentive, we will see what we can work out for you. Speaking of financial incentive, the ICWS could use a sponsor for its next tournament (sometime in the winter of 1993) and The Core War Newsletter does accept advertising. Neither is that expensive. Send a message to Jon Newman (jonn@microsoft.com) or myself if you are interested. The EBS has an unfinished double-elimination tournament which I intend to finish. I will try and contact the remaining contestants and start up the final rounds very soon. I have enjoyed the EBS tournament immensely and hope to do it again soon. With one under my belt, I am certain that a new DE-tournament can be run in far less time. We will have a standard round-robin competition in preparation for the ICWS tournament sometime in the fall or early winter. I will be sending EMail to members of the EBS committee working toward a new Core War standard very soon as well. We will try to get organized and start working toward a draft standard. Mark A. Durham MAD Subject: Jon Newman: TCWN and corewars ideas... Message-ID: <1992Aug9.004009.1@hiramb.bitnet> From: bushbo@hiramb.bitnet Date: 9 Aug 92 00:40:09 -0500 attention Jon Newmann or anyone else interested... Jon Newmann: hello, i would like to give you some suggestions for TCWN and corewars in general. fist off, i started experimenting with corewars in highschool because i was interested in artificial life and AI. i have not programmed many warriors or entered any in the annual competition. now that i am in college my interest has grown to encompass artificial neural systems, robotics, analysis of dynamic systems(using cellular automata)...yet it all revolves around complex systems in some form (this including corewars). i feel that some people like me would rather see a diverse newsletter that could spark peoples interest...for example do not limit it(the TCWN) to corewars, include cellular automata, artificial life, and other related topics. i am not asking to go into depth into dynamical chaotic systems and explain chaos with pages of frightening equations... :-) i am mainly trying to give you ideas on what i and several other people feel that would be interesting to read about. i think that corewars is a great thing to get started in... but i beleive that it gets old after a few years (at least i did) because it was not complex enough. i realize that standard corewars is still popular... but there could be other "breeds" or "flavors" of corewar simulators. the task of programming these simple creatures is cumbersome when given a simple language to program them in... although some very impressive warriors have been produced with this "simple" assembly language, why not a more complex language... no not c++, but a language for describing the "genetics" of a creature or a language for a different environment(e.g. a 3-dimensional arena with balck holes.... ;-) ok maybe not balck holes, but something along some thought). the idea of simulated creatures moving around in computer memory is still very interesting... but it could be expanded... like having larger arena like a universe... or multidimensional corewars... or some other complex rules (as in the game of LIFE)... i cannot list everything, for i have a fruitful imagination. it is the application of these ideas that is the hard part, but if enough people are involved much can be accomplished. i believe that if the corewar newsletter was expanded upon... it might grow readership wise and a renewed interest in corewars and systems of the type might sprout up. feel free to email me if you have any questions or want a more specific response on this. thanks... brian |------------------------------------------|-----------------------| |Brian O. Bush, Student at Hiram College | |\ /| | |Bitnet: BUSHBO@HIRAMB.HIRAM.EDU | | \/ | achines... | |Internet: IN%"BUSHBO@HIRAMB.HIRAMB.EDU" | | | | |"alive... yet unaware... " -Skinny Puppy | | |------------------------------------------|-----------------------| From: durham@cup.portal.com (Mark Allen Durham) Subject: Re: Jon Newman: TCWN and corewars ideas... Message-ID: <63727@cup.portal.com> Date: Sun, 9 Aug 92 13:01:19 PDT Brian, The Core War Newsletter has always been interested in the wider world of automata, genetic algorithms, artificial life, etc. Several articles of this nature have appeared in past issues. I certainly anticipate printing several more in the future. Problem is, I print what I get. TCWN needs authors to send in articles. Any budding authors, please send any and all submissions to me ASAP. It can be just a rough draft. I am more than willing to work with authors on developing good articles. Mark A. Durham MAD Editor, The Core War Newsletter From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: How to kill Message-ID: <1992Aug9.110605@IASTATE.EDU> Date: Sun, 9 Aug 1992 16:06:05 GMT In article <1992Aug7.193410.24208@u.washington.edu>, trent@mailhost.hsas.washington.edu (Sigfried Trent) writes: > How is a program defeated in this game. Do you have to erase all its code. > or capture some part of the proccesor or what? As far as I know, the only way to kill a program is to make all of it's processes execute illegal instructions. The only instruction that is garuenteed to be illegal is the dat instruction. | __L__ ******************************* -|- ___ * Warren Kurt vonRoeschlaub * | | O | * kv07@iastate.edu * |/ `---' * Iowa State University * /| ___ * Math Department * | |___| * 400 Carver Hall * | |___| * Ames, IA 50011 * J _____ ******************************* From: maniac@lil-ed.cs.unlv.edu (Eric J. Schwertfeger) Subject: Loki 2.3 [X-Warrior Source] Message-ID: <1992Aug9.235306.907@unlv.edu> Date: Sun, 9 Aug 92 23:53:06 GMT Well, my last attempted improvement to Loki turned out to be a minor failure, so the current generation is finalized. I do have plans for Loki 3.0, based on the success of Echo. Loki is a dual-process warrior, employing two very carefully corrdinated programs. One is a vampiric Dwarf-X that bombs mod-10 +/- 240 from it's position, with JMP PIT instructions. Then there is the Leaper process, which just copies itself ahead, throws out a single JMP BOMB, then jumps to the new copy. The first instruction of the Leaper is a jump to the PIT, so if I copy myself into another program, it will jump into the pit rather than execute the jumper code. This is not true if I overlay the currently executing instruction, however. After the Leaper has either blasted or bitten every 10th instruction in core, the Dwarf-X goes into Kill-Leaper mode, kills the Leaper, then becomes a core clear program. The core clear program is just a little faster than Spider's core clear program. I've seen my core clear program chase Spider's around core two or three times before catching it :-) BTW, watching Loki battle Spider can cause cancer (or at least headaches). The ensuing chaos is what gave me the idea for the name. Loki has been in the 3-5 range since I posted it, but it is the only program of mine on the hill that won't beat Echo. ;redcode-x ;name Loki 2.30 ;author Eric J. Schwertfeger ;strategy A fairly major rewrite of Loki 1.30. Changed ;strategy everything but core-clear, and I'd change that ;strategy if I had the room for 2 more instructions ;strategy Multi-Part, syncronized program consisting of ;strategy 1 jumper (eventually killed by dwarf) ;strategy 1 dwarf ;strategy 1 core-clear (started by dwarf after jumper is killed) ;strategy v 2.0 new code, constants do worse vs spider, ;strategy better vs everything else (it seems). ;strategy v 2.1 found major bug ;strategy v 2.2 2.1 fix didn't fix bug, so I rewrote the ;strategy core-clear to avoid problem. ;strategy v 2.3 made jumper a little more offensive. ;strategy Submitted: @date@ ;kill Loki MOD EQU (10) STEP EQU (MOD*23) BOMB EQU (FOO-241) CLEARS EQU 32 JLAUNCH MOV DEST,DEST-STEP JMP LOOP SRC JMP PIT,#10 LOOP MOV Date: Mon, 10 Aug 1992 16:43:57 GMT In article <1992Aug9.110605@IASTATE.EDU>, kv07@IASTATE.EDU (Warren Vonroeschlaub) writes: > In article <1992Aug7.193410.24208@u.washington.edu>, > trent@mailhost.hsas.washington.edu (Sigfried Trent) writes: >> How is a program defeated in this game. Do you have to erase all its code. >> or capture some part of the proccesor or what? > > As far as I know, the only way to kill a program is to make all of it's > processes execute illegal instructions. The only instruction that is garuenteed > to be illegal is the dat instruction. > Does that mean that if I code a DAT instruction into my programme then it's going to be considered an illegal instruction. -- |\ _ ; \\ < \, \\/\ _-_ \\/\\/\\ "dmurrlls@vax1.tcd.ie" / \\ /-|| || | || \\ || || || In reality Dave Murrells. || || (( || || | ||/ .. || || || But "that's the problem with reality, || || \/\\ \\/ \\,/ .. \\ \\ \\ it's taken far too seriously" \\/ -------------------------------- From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: How to kill Message-ID: <1992Aug10.182545.2920@oucsace.cs.ohiou.edu> Date: 10 Aug 92 18:25:45 GMT In article <1992Aug10.164357.1@vax1.tcd.ie> dmurrlls@vax1.tcd.ie writes: >In article <1992Aug9.110605@IASTATE.EDU>, kv07@IASTATE.EDU (Warren Vonroeschlaub) writes: >> In article <1992Aug7.193410.24208@u.washington.edu>, >> trent@mailhost.hsas.washington.edu (Sigfried Trent) writes: >>> How is a program defeated in this game. Do you have to erase all its code. >>> or capture some part of the proccesor or what? >> >> As far as I know, the only way to kill a program is to make all of it's >> processes execute illegal instructions. The only instruction that is garuenteed >> to be illegal is the dat instruction. >> >Does that mean that if I code a DAT instruction into my programme then it's >going to be considered an illegal instruction. No, the DAT instruction is only considered to be illegal if an attempt to execute it happens. Any process executing a DAT will die on the attempt. What makes programming so much fun is that you must figure out the fastest, most efficient method of planting DAT instructions in an enemy program in order that they may die. There are many ways this can be done... my favorite way is to actually modify the enemy program so that is helps your program clear out the core, and then it will kill itself, leaving your program the winner... (this is known as a vampire type program). I wish you luck in programming! Don't forget to have a good day! Some people never remember this. ------------------------------------------------------------------------------- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu (Flame me, not the net!) Bitnet: adkins@ouaccvma.bitnet ------------------------------------------------------------------------------- Ohio University of Athens Home of the Great Hocking River From: t-jcisek@microsoft.com (Julius Cisek) Subject: I got my warriors! Thanks! Message-ID: <1992Aug11.052639.23449@microsoft.com> Date: 11 Aug 92 05:26:39 GMT Thanks a million to all those who helped me get my warriors back after I lost all the code on a bad hard drive especially to Scott Adkins for his most excellent library. Jules -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: wms@ssd.intel.com (William Shubert) Subject: KotH Standings Message-ID: <1992Aug11.202505.13686@iWarp.intel.com> Date: Tue, 11 Aug 1992 20:25:05 GMT OK, the ICWS '88 hill: # %W/ %L/ %T Name Author Score Age 1 42/ 21/ 36 Flash Paper3.7 Matt Hastings 163 231 2 49/ 40/ 11 No Mucking About Campbell Fraser 158 179 3 47/ 41/ 12 Charon v7.0 J.Cisek & S.Strack 152 110 4 45/ 38/ 17 B-scanners live in vain Matt Hastings 152 161 5 38/ 27/ 35 Paper Bomb Rodney Schuler 150 47 6 45/ 43/ 13 Crimp 2 Andy Pierce 147 78 7 43/ 41/ 16 Falling Leaf 1.21 Matt Hastings 145 317 8 43/ 42/ 15 Sucker 4 Stefan Strack 144 432 9 42/ 41/ 17 Twill Andy Pierce 143 81 10 44/ 45/ 11 B Paul S. Kilroy 142 143 11 40/ 39/ 21 Quebec Eric Prestemon 141 68 12 35/ 32/ 33 t2 nandor sieben 138 113 13 39/ 41/ 20 testing RoadRunner S. Halvorsen 138 23 14 37/ 37/ 26 Hellicon2 Matt Hastings 138 7 15 35/ 39/ 26 Relentless J.Cisek 131 152 16 37/ 45/ 18 Disruptor v.1 Paul S. Kilroy 130 88 17 33/ 38/ 29 RotLD 2 nandor sieben 129 90 18 39/ 52/ 9 Miny v.3 Paul S. Kilroy 125 93 19 28/ 37/ 35 pizza to go V4 c w blue 120 4 20 34/ 49/ 17 ferengi nandor sieben 119 1 Some moving around; the top 4 programs are all pretty old, though. I haven't changed it to a 64 process limit because I got complaints when I tried. Anybody want to take a poll? The experimental hill: # %W/ %L/ %T Name Author Score Age 1 61/ 23/ 16 Echo 1.10 Eric J. Schwertfeger 198 9 2 56/ 24/ 20 Echo 1.40 Eric J. Schwertfeger 188 1 3 53/ 31/ 16 Spider 2.1 Bill Shubert 174 58 4 42/ 27/ 31 Scorpion 2.72 Alex MacAulay 156 11 5 47/ 41/ 12 Loki 2.30 Eric J. Schwertfeger 152 27 6 30/ 14/ 56 Sigil Matt Hastings 146 42 7 42/ 42/ 16 Odin J.Cisek 142 217 8 42/ 42/ 16 Halberd 1.20 Eric J. Schwertfeger 142 59 9 32/ 23/ 45 seething mass Campbell Fraser 141 62 10 27/ 21/ 52 LongWorm 1.1 Dan Nabutovsky 134 30 11 39/ 45/ 17 Lance 1.40 Eric J. Schwertfeger 133 60 12 32/ 33/ 35 Patriot Kurt vonRoeschlaub 131 138 13 38/ 46/ 16 Leaper-X 4.0 Jeff Raven 130 214 14 30/ 30/ 40 Domestos 1.2 Jonathan Wolf 129 136 15 34/ 46/ 20 ImpDwarf Gun 1.0 Warren vonRoeschlaub 121 144 16 31/ 41/ 28 Tank Jonathan Wolf 121 105 17 20/ 21/ 58 Brute-Force 1.2 Ray Cromwell 119 163 18 22/ 24/ 54 Blind Leap1.1 Jonathan Wolf 119 128 19 23/ 29/ 47 SuperChameleon 2 Alex MacAulay 117 2 20 5/ 0/ 0 LongWorm 1.21 Dan Nabutovsky 14 10 Spider has been beaten again! This time by the "Echo" series. Here's the ";strategy" for version 1.10 of "Echo": ;name Echo 1.10 ;strategy Repeating, Bidirectional core clear ;strategy v1.1 Added Decoy, SPL bobming ;strategy Submitted: Mon Aug 10 11:20:59 PDT 1992 As usual, source code for the redcode simulator is available via anonymous ftp from soda.berkeley.edu. Submission instructions are in the FAQ and available from me by email. -Bill (wms@iwarp.intel.com) From: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) Subject: SkipShot 1.3 Message-ID: <1992Aug12.003624.23814@unlv.edu> Date: Wed, 12 Aug 92 00:36:24 GMT This one is more of a novelty than a real program. I decided to make the fastest possible self-copier that wouldn't self-destruct when it hits the opponent or other code. SkipShot 1.3 traverses the entire core in under 200 cycles. In theory, you should be able to set STEP to 249. In practice using Koth 3.0, Skipshot will die a random number of cycles into the game. Or rather, it appears random. If it is loaded by itself, it will die before it completes a lap. Sometimes almost lapping the core, other times not even coming close. It's fun watching this one play Spider :-) ;redcode-x ;name SkipShot 1.3 ;author Eric J. Schwertfeger ;strategy v 1.3 Trying to streamline as much as possible SKIP EQU (247) MOV SRC,SRC-SKIP MOV DEST,DEST-SKIP SPL 1 MOV -1,0 JMP START SRC DAT DEST+1+SKIP START MOV Date: Wed, 12 Aug 1992 22:11:06 GMT No one seems to have talked about proposed new standards in a while but I got what, IMO, is a great idea. The only really good change in the instruction set I've seen proposed, again IMO, is the SLeeP instruction. However, I'd like to suggest a change in the goals of the game. Hows' this: at the start, 3 (or some other number, I just want to give a definite number for now) random instrutcions are created directly in front of the warriors code. The goal is to protect your 'data' while destroying that of the other side. After 80,000 cycles (if the other warrior dies, you get to keep going till clock runs out, sorry Bill, if this would slow things down), the same 3 locations for each player are compared to the correct starting values for those loactions. You would score, say, 2 points for every piece of data preserved while losing, say, 1 point for every piece of your opponents data still valid. By automatically adding in a few extra instructions this would help longer programs. It adds new strategies too, such as:copy your data twice and after 40,000 cycles or so, after your core-clear, check both your copies. If they agree w/ each other, but not w/ the original location, correct your corrupted data. One note:Proteus3 is Hellicon2, just change the #900 to #500. I think now I should figure out the best value, since it seemed to have a very great effect on the ranking. From: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) Subject: X-Hill talk Message-ID: <1992Aug13.011133.28176@unlv.edu> Date: Thu, 13 Aug 92 01:11:33 GMT Just for the record, I'm not the originator of the idea of restarting a failed core clear. The first time I saw it used was in Spider 2.1 I am, however, a proponent of its use. Out of the top 3 programs on the X-Hill right now, all three of them use the repeating core-clear idea. Two of them were lower on the hill prior to trying this tactic. After watching several X-hill battles, I noticed that there are quite a few times when complex programs both go into core-clear mode at the same time. I was very specific with Loki's core clear in wanting something that ran faster than Spider's (2.0's, since it was all I had to compare against) core clear. Several times I saw Loki win by having its core clear overtake spiders. -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu From: hastings-matthew@CS.YALE.EDU (Matthew Hastings) Subject: e-mail addr. Message-ID: <1992Aug13.144755.23810@cs.yale.edu> Date: Thu, 13 Aug 1992 14:47:55 GMT Got e-mail from keithf about article in this newsgroup. No good return address so can't reply-keith send me an OK return address and Ill get back to you. From: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) Subject: Not Much Message-ID: <1992Aug13.220947.27964@unlv.edu> Date: Thu, 13 Aug 92 22:09:47 GMT Just wanted to let any X-Hill players out there know that I'll be leaving the hill alone for a few weeks. Tomorrow is the last day our computer lab is open until some time in September, and with it goes my access to X-Servers, so I can't watch my programs run. After the Echo 1.3X debacle, I'm not going to try that again :-) That's the good news, the bad news is, I'm sure to have plenty of ideas again when I get back in here :-) Later everyone. (Regular email will still reach me, if you want to discuss anything). -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu From: karttu@mits.mdata.fi (Antti Karttunen) Subject: Some far-out ideas (was Re: Real world analogies to Go) Message-ID: <1992Aug16.002254.10617@mits.mdata.fi> Date: Sun, 16 Aug 1992 00:22:54 GMT In article <1992Aug12.223403.19986@crd.ge.com> kassover@rumsey.crd.ge.com (David Kassover) writes in rec.games.go: >What? no one has remembered the similarity of go to Conway's >life? > >Wasn't there a serious mathematical discussion here in this >newsgroup of using lifelike finite state automata and fractal >analysis to aid in the playing of go? I'm all eyes! So, has anybody saved these articles, or is the rec.games.go archived anywhere? BTW, I recently downloaded Core Wars like game from Japanese ftp-site called 'Jintori', which seems to be somewhat influenced by Go. It has two bugs competing in two-dimensional space (instead of the traditional one-dimensional Core Wars space), and the winner bug is the one which have conquered more area in the end (by surrounding it). I wonder if this could be made still more Go-like so that bugs' existence could be determined by their liberties, count of eyes, and so on. In the end we maybe could have the Go-playing program where the stones 'themselves' decide how to play. Or even 'artificial life' system (See for example the July 1992 Scientific American article about the Genetic Algorithms) where the better and better Go-playing algorithms would evolve. (Huh, carried away again... ;-) (I'm crossposting this drivel now also to two other groups, which can be seen in the header, to generate something, at least flames. What's the common denominator? Rectangular grid, I guess.) -- Antti Karttunen -- アンッティ　カルットゥネン (et{ty|t|n) karttu@mits.mdata.fi -- Apatheist, although not particularly proud of it. From: karttu@mits.mdata.fi (Antti Karttunen) Subject: JINTORI (was Re: Some far-out ideas) Message-ID: <1992Aug16.213120.26241@mits.mdata.fi> Date: Sun, 16 Aug 1992 21:31:20 GMT (I apologize the rambling nature of this article, but I'm almost sleeping when I write this.) There has been some queries about that Jintori game I mentioned in my last message. So here are some answers: The ftp site is ftp.waseda.ac.jp (133.9.1.32) (user-id: anonymous) and executable with some sample patterns can be found from /pub/archive/fj.binaries.msdos/jintori.lzh and the sources can be found from /pub/fj/fj.sources/games/jintori If I remember right, they are all packed in Jintori.2.01.tar so you don't need to download all the small files. Except the sample bug programs in the sample subdirectory, there was also bug programs KUNI91, PAT, YOU, and 1 in the directory superior to it (which are not included in executable package, however). However, there's only one problem. The sources and executable are for the Japanese NEC PC-9800 series compatible micros. Although these machines also use (somewhat Nihongo-zied) MS-DOS, they are _not_ "western" IBM-PC compatible. Although most programs work ok, as long as they don't try to do anything fanciful with the screen, the graphics, etc. But this Jintori (= "Battle field") game of course need graphics, so the graphics portion of the code has to be rewritten. And that's exactly what I have done. But there are still some bugs in the code I have written (Uh, don't know Turbo-C graphics routines so well, as I have wasted my time with the ancient Aztec-C), and now the development for my part is frozen as one genius here happily formated the hard disk containing the Borland C compiler... ;-( So! If there is some kind soul there with the Turbo C compiler and some spare time, then I suggest downloading the sources from the above mentioned site, replacing the visualmo.c file in them with the file I give below. Also, the sound effect portions of the code in the other source files (jintori.c, etc.) should be commented out. Preferably with #ifdef PC98 and #endif instead of /* */, so the code can later be compiled for PC-9800's also. Of course, the sources can be compiled for other machines also (like Amiga, X-windows, etc.), just replace the graphics functions in visualmo.c file. And still one surprise. All documents coming with packages seem to be in Japanese! (some written with JIS and some with Shift-JIS) I'm trying to "translate" jintori.man to English, but it's somewhat slow as I don't actually know Japanese even myself. (I just have good kanji-dictionary ;-) Actually, here's also my version of soundeff.h file, effectually defining all the sound functions as null macros, when compiled for the western PC's: ===================== CUT HERE ====================================== /* * "Jintori" Version 2.01 Mar 27, 1991 * SoundEffector.h Version 2.01 * Last modified: Mar 15, 1991 */ #ifdef PC98 extern void OpenSoundEffector(/* */); extern void CloseSoundEffector(/* */); extern void SoundBorn(/* */); extern void SoundDead(/* */); extern void SoundBasisi(/* */); extern void SoundPaint(/* */); extern void SoundPause(/* */); extern void SoundUnPause(/* */); extern void SoundOff(/* */); extern FuncResponse SoundEffector_ParseArguments( /* int *argc, char *argv[] */ ); #else /* Sorry, no sounds! */ #define OpenSoundEffector() #define CloseSoundEffector(); /* Hmm, these semicolons are probably useless */ #define SoundBorn(); #define SoundDead(); #define SoundBasisi(); #define SoundPaint(); #define SoundPause(); #define SoundUnPause(); #define SoundOff(); #endif ===================== CUT HERE ====================================== New visualmo.c for the "western" version of JINTORI. Contains some minor bugs, easily fixed: ===================== CUT HERE ====================================== /* * "JINTORI" Version 2.01 Mar 27, 1991 * VisualMonitor.c (PC-9801, Turbo-C) Version 2.01 * OriginalDebut: Jul 2, 1990 * Extension: StopCheck, DispFinalState, SystemError Jul 7, 1990 * Extension: StopCheck Oct 26, 1990 * Extension: DispDebugStatus Nov 26, 1990 * Extension: Delay, CloseVisualMonitor Mar 11, 1991 * Modify: ParseArguments Mar 15, 1991 * Modify: EventLoop Mar 27, 1991 * Last modified: Mar 27, 1991 * FOR PC-9801 + TURBO-C. */ /* * Now modified by Antti Karttunen (karttu@mits.mdata.fi) 4-AUG-1992 * for IBM-PC compatibles + TURBO-C. * * But still buggy, (see the routine initgraf()!), and also prints status * texts outside of the screen, at least in CGA mode. (So modify the * text starting locations.) * */ #include "PrivateIdent.h" #include "LimitDefinition.h" #include "VisualMonitor.h" #include "EventManager.h" #include "ProcessManager.h" #include "SoundEffector.h" #include "Message.h" #include "ArgumentParser.h" #include #include #include #include #include #include /* cprintf uses ROM BIOS calls, instead of writing directly to the screen: */ /* extern int directvideo = 0; Barf, not needed now. */ static char NameOfPlayer[MaxPlayers][BUFSIZ]; #ifdef PC98 static void pset(x, y, color) int x, y, color; { unsigned char *blue = (unsigned char *)0xa8000000L; unsigned char *red = (unsigned char *)0xb0000000L; unsigned char *green = (unsigned char *)0xb8000000L; unsigned int addr; unsigned char mask; addr = 80 * y + x / 8; mask = 1 << (7- x % 8); blue += addr; red += addr; green += addr; if ((color & 1) != 0) { *blue |= mask; } else { *blue &= ‾mask; } if ((color & 2) != 0) { *red |= mask; } else { *red &= ‾mask; } if ((color & 4) != 0) { *green |= mask; } else { *green &= ‾mask; } } #else #define pset putpixel #endif static void boxline(x1, y1, x2, y2, color) int x1, y1, x2, y2, color; { int i; for (i = x1; i <= x2; i++) { pset(i, y1, color); pset(i, y2, color); } for (i = y1; i <= y2; i++) { pset(x1, i, color); pset(x2, i, color); } } static void boxfill(x1, y1, x2, y2, color) int x1, y1, x2, y2, color; { int x, y; for (y = y1; y <= y2; y++) { for (x = x1; x <= x2; x++) { pset(x, y, (x+y) % 2 ? color : 0); } } } #ifdef PC98 #define PixelSize 2 static int OffsetX = 40; static int OffsetY = (400 - FieldSizeY * PixelSize) /2; static int ColorTable[MaxPlayers] = {2, 6}; #else static int PixelSize; static int bordercolor = 7, headcolor = 7; static int OffsetX = 40; static int OffsetY; static int charwidth,charheight; static int ColorTable[MaxPlayers] = {1, 4}; #endif static void ClearScreen() { #ifdef PC98 int i; unsigned char *blue = (unsigned char *)0xa8000000L; unsigned char *red = (unsigned char *)0xb0000000L; unsigned char *green = (unsigned char *)0xb8000000L; clrscr(); for (i=0; i < 0x7f00; i++) { *blue++ = 0; *red++ = 0; *green++ = 0; } #endif } #ifdef PC98 void put_text(x,y,mesg) int x,y; char *mesg; { gotoxy(x,y); cprintf("%s",mesg); } #else void put_text(x,y,text) int x,y; char *text; { outtextxy(x*charwidth,y*charheight,text); } /* This should work so that if there's a VGA card, then use VGAHI mode (640x480?) (so that pixelsize will be 2 and so on), but if not, then use CGA medium resolution mode (320x200) with some of the modes CGAC0-CGAC3 which have the most awful palettes I have seen in any computer. (Maybe it could be made user selectable which palettes and colours (s)he can use?) However, there's a bug in that initialization code, which seems to freeze those machines with no VGA. AND IT NEEDS FIXING!!! */ /* For Turbo-C & Western PC's: */ void initgraf() { int graphdriver=VGA; int graphmode=VGAHI; int errorcode; /* Some auto-detection code, not used now: if (registerbgidriver(EGAVGA_driver) < 0) exit(1); if (registerbgidriver(Herc_driver) < 0) exit(1); if (registerbgidriver(CGA_driver) < 0) exit(1); */ initgraph(&graphdriver,&graphmode,""); /* If no VGA, then use CGA with 320x200 resolution & four colours. */ if((errorcode = graphresult()) != grOk) { graphdriver = CGA; graphmode = CGAC0; detectgraph(&graphdriver,&graphmode); } if((errorcode = graphresult()) != grOk) { fprintf(stderr, "¥njintori: graphics error %d: %s¥n",errorcode,grapherrormsg(errorcode)); exit(1); } charwidth = textwidth(" "); charheight = textheight(" "); if(graphdriver == CGA) { ColorTable[1] = 2; bordercolor = headcolor = 3; PixelSize = 1; OffsetX = 1; OffsetY = (200 - FieldSizeY * PixelSize) /2; charwidth >>= 1; /* Divide by two, to get 4 */ } else /* VGA */ { PixelSize = 2; OffsetY = (400 - FieldSizeY * PixelSize) /2; } /* MAXCOL=getmaxx(); MAXROW=getmaxy(); */ } void exitgraf() { closegraph(); } #endif void OpenVisualMonitor() { #ifdef PC98 union REGS reg; reg.h.ah = 0x42; reg.h.ch = 0xc0; int86(0x18, ®, ®); reg.h.ah = 0x40; int86(0x18, ®, ®); textbank(1); textcursor(NODISP_CURSOR); #else initgraf(); #endif ClearScreen(); } void CloseVisualMonitor() { ClearScreen(); #ifdef PC98 textbank(0); textcursor(BLINK_CURSOR | DISP_CURSOR); #else exitgraf(); #endif } void ClearField() { boxline( OffsetX -PixelSize -1, OffsetY -PixelSize -1, OffsetX +FieldSizeX*PixelSize, OffsetY +FieldSizeY*PixelSize, bordercolor ); boxline( OffsetX -PixelSize, OffsetY -PixelSize, OffsetX +FieldSizeX*PixelSize -1, OffsetY+FieldSizeY*PixelSize -1, bordercolor ); put_text(56,2,"TOTAL STEPS: "); put_text(56,4,"PLAYER 1"); put_text(58,6,"SCORE: 0"); put_text(58,8,"NumOfBugs: 1"); boxfill(70*8, 3*16, 75*8, 4*16, ColorTable[0]); if(NumOfPlayers > 1) { put_text(56,13,"PLAYER 2"); put_text(58,15,"SCORE: 0"); put_text(58,17,"NumOfBugs: 1"); boxfill(70*8, 12*16, 75*8, 13*16, ColorTable[1]); } } void SetDot(x, y, player, class, flush) int x, y, player; enum PixelClass class; bool flush; { int i, j; int color; color = (class == Head ? headcolor : ColorTable[player]); if (class == Territory) { pset(OffsetX + x*PixelSize -1, OffsetY + y*PixelSize -1, color); pset(OffsetX + x*PixelSize +1 -1, OffsetY + y*PixelSize +1 -1, color); } else { for (j=0; j < PixelSize; j++) { for (i=0; i < PixelSize; i++) { pset(OffsetX + x*PixelSize +i -1, OffsetY + y*PixelSize +j -1, color); } } } flush = flush; /*NC*/ } void ClearDot(x, y, flush) int x, y; bool flush; { int i, j; for (j=0; j < PixelSize; j++) { for (i=0; i < PixelSize; i++) { pset(OffsetX + x*PixelSize +i -1, OffsetY + y*PixelSize +j -1, 0); } } flush = flush; /*NC*/ } static void DispStep(step) long step; { char tmpbuf[8]; sprintf(tmpbuf,"%6ld", step); put_text(70,2,tmpbuf); } void DispScore() { static struct {int x, y;} position[MaxPlayers] = { {70, 6}, {70, 15} /*, {37, 1}, {37, 25} */ }; int player; for(player = 0; player < NumOfPlayers; player++) { char tmpbuf[8]; sprintf(tmpbuf,"%6d", Score[player]); put_text(position[player].x,position[player].y,tmpbuf); #ifdef PC98 if (Score[player] <= Score[1-player]) { textattr(T_WHITE | NOSECRET); } else if (Score[player] > FieldSizeX*FieldSizeY/2) { textattr(T_WHITE | REVERSE | NOSECRET); } else { textattr(T_WHITE | UNDERLINE | NOSECRET); } #endif } #ifdef PC98 textattr(T_WHITE | NOSECRET); #endif } void DispNumOfBugs(player, NumOfBugs) int player, NumOfBugs; { char tmpbuf[8]; static struct {int x, y;} position[MaxPlayers] = {{70, 8}, {70, 17}}; sprintf(tmpbuf,"%6d", NumOfBugs); put_text(position[player].x, position[player].y, tmpbuf); } static void Pause() { SoundPause(); put_text(64,24,"== PAUSE == "); getch(); SoundUnPause(); put_text(64,24," "); } void DispDebugStatus(p, pid, status) int p, pid; WORD status; { char tmpbuf[21]; sprintf(tmpbuf, "%d", (int)status); put_text( (OffsetX + BugTable[p][pid].x *PixelSize) /8 +1, (OffsetY + BugTable[p][pid].y *PixelSize) /16, tmpbuf ); Pause(); put_text( (OffsetX + BugTable[p][pid].x *PixelSize) /8 +1, (OffsetY + BugTable[p][pid].y *PixelSize) /16, " " ); } static int DelayTime; void Delay() { long i; for (i=0; i < DelayTime; i++) { i = i; } } void DispCompileError(mesg, source, pointer) char *mesg, *source, *pointer; { fprintf(stderr, "%s¥n%s¥n%s¥n", mesg, source, pointer); } static void OpenAllProcessManagers() { int i; for (i=0; i < NumOfPlayers; i++) { OpenProcessManager(i); } } static void CloseAllProcessManagers() { int i; for (i=0; i < NumOfPlayers; i++) { CloseProcessManager(i); } } void SystemError(mesg) char *mesg; { put_text(1,1,mesg); printf("¥n"); CloseSoundEffector(); CloseVisualMonitor(); CloseAllProcessManagers(); exit(3); } static bool StopCheck() { if (kbhit()) { switch (getch()) { case 0x0d: return true; case ' ': Pause(); break; } return false; } else { return false; } } static void DispFinalState(state) enum ProcessStatus state; { switch (state) { case Terminated: put_text(64,24,MesgFinished); break; case TimeOut: put_text(64,22,MesgTimeOut); break; case Breaked: put_text(64,24,MesgAborted); break; } } static void ReadProgram() { int i; for (i=0; i < NumOfPlayers; i++) { fprintf(stderr, NowCompiling, i +1); switch (Compile(i, NameOfPlayer[i])) { case Aborted: fprintf(stderr, CannotOpenFile, i +1); CloseAllProcessManagers(); exit(1); case Done: break; case Error: CloseAllProcessManagers(); exit(2); } } } void EventLoop() { enum ProcessStatus status; OpenAllProcessManagers(); ReadProgram(); OpenVisualMonitor(); OpenSoundEffector(); InitProcessTable(); InitField(); StartFirstProcesses(); do { status = DoStep(); if (status == TimeOut || step % 32 == 0) { DispStep(step); if (StopCheck()) { status = Breaked; break; } } } while (status == Running); DispFinalState(status); while (!StopCheck()); CloseSoundEffector(); CloseVisualMonitor(); CloseAllProcessManagers(); } static char *player[MaxPlayers]; static bool PlayerSpecified[MaxPlayers]; static struct ArgumentSyntax ArgumentSyntax[] = { {"-delay", OptionalArg, IntegerParam, &DelayTime, nil}, {"", ObligatoryArg, StringParam, &player[0], &PlayerSpecified[0]}, {"", OptionalArg, StringParam, &player[1], &PlayerSpecified[1]}, {nil, nil, nil, nil, nil} }; FuncResponse VisualMonitor_ParseArguments(argc, argv) int *argc; char *argv[]; { FuncResponse res; int i; res = ParseArguments(argc, argv, ArgumentSyntax); NumOfPlayers = 0; for (i=0; i < MaxPlayers; i++) { if (PlayerSpecified[i]) { NumOfPlayers++; strcpy(NameOfPlayer[i], player[i]); } } return res; } ===================== CUT HERE ====================================== -- Antti Karttunen -- アンッティ　カルットゥネン (et{ty|t|n) karttu@mits.mdata.fi -- Apatheist, although not particularly proud of it. From: t-jcisek@microsoft.com (Julius Cisek) Subject: How do you guys write x-warriors? Message-ID: <1992Aug17.152019.26740@microsoft.com> Date: 17 Aug 92 15:20:19 GMT Exciting things are happening on the Schwertfeger-hill, I mean the x-hill :) :) :) In just a few days we have seen Spider (which seemed locked in the number one position for so long that I didn't even consider it when looking at the rankings assuming that it would be there...) fall dramatically in the standings. I am REALLY amazed that my warrior Odin is STILL up there. It is probably the simplest program on the hill. Basically it is a copy routine with spl 0's on one side and dats on the other... Anyways, the point of this post: How do you x-hill coders develop your warriors? If you looked at the four x-hill warriors I've posted, none of them use anything unusual. No weird opcode-operand mode combinations, no post-increment, etc. This is mainly because I do not have the software to test these things. I also do not have the patience to submit programs that have not been tested. Stefan's CoreWar Pro does a lot of the things I'd need but it runs VERY slowly on my 386/20 (especially once a couple of spl 0 traps get sprung). My Amiga at home runs MARS, but that doesn't have any of the unusual instructions or modes. Jules -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo ¥ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 ¥X/ | U| ¥| From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: How do you guys write x-warriors? Message-ID: <1992Aug17.124610@IASTATE.EDU> Date: Mon, 17 Aug 1992 17:46:10 GMT In article <1992Aug17.152019.26740@microsoft.com>, t-jcisek@microsoft.com (Julius Cisek) writes: > How do you x-hill coders develop your warriors? If you looked at the four > x-hill warriors I've posted, none of them use anything unusual. No weird > opcode-operand mode combinations, no post-increment, etc. This is mainly > because I do not have the software to test these things. I also do not > have the patience to submit programs that have not been tested. Stefan's > CoreWar Pro does a lot of the things I'd need but it runs VERY slowly on > my 386/20 (especially once a couple of spl 0 traps get sprung). My Amiga > at home runs MARS, but that doesn't have any of the unusual instructions > or modes. The x-hill warriors I put up use no special commands at all. The only special considerations my programs take into account are the 250 write barrier. (Patriot would probably even do well on the regular hill. Hmm, any objections to my trying it out?) Of course, all my programs have the same system of operation, jump forward, squash anything within reach. I suppose that only a handful, if any, x-hill warriors do anything different. | __L__ ******************************* -|- ___ * Warren Kurt vonRoeschlaub * | | O | * kv07@iastate.edu * |/ `---' * Iowa State University * /| ___ * Math Department * | |___| * 400 Carver Hall * | |___| * Ames, IA 50011 * J _____ ******************************* From: maniac@unlv.edu (Eric J. Schwertfeger) Subject: Re: How do you guys write x-warriors? Message-ID: <1992Aug18.165737.450@unlv.edu> Date: Tue, 18 Aug 92 16:57:37 GMT Well, part of the fall of Spider, AND the success of Odin, is because those are the only two opponents on the hill that I have source for. I can optimize to beat Spider, or to beat Odin, and it would seem that optimizing to beat Spider's downward moving core clear leaves you in a better position against the rest of the hill than optimizing to beat Odin's upward moving core clear. In case you didn't notice, there were versions of Loki that did quite well against Odin (interesting, that), but the final versions didn't do as well. That's because overall, things went better for other versions. Another reason for Spider's fall is that all my serious programs beat Spider because of the decoy I use. This decoy was posted to the net, and will be included in an upcoming tutorial I plan on posting soon, but just for those of you who missed it, here is the bulk of it. DSTEP EQU (100) ; 100 will collide with Spider, but 200 does better DLAUNCH SPL 1 ; for some programs. MOV Date: Tue, 18 Aug 1992 21:07:52 GMT In article <1992Aug18.165737.450@unlv.edu>, maniac@unlv.edu (Eric J. Schwertfeger) writes: > BTW, I'd like to thank whoever posted that decoy. Prior to that, my best used > 6 cycles per jump, and I had to kill it myself. I lost the original article, > but I *THINK* it was Kurt vonRoeshlaub (Patriot and Scud). Yep, and ImpDwarf Gun (my system here is really annoying and insists on calling me Warren, anybody know how to fix that?) Both Scud and Patriot use these guys as missiles in an attempt to hit the attacking programs. Patriot uses an indestructable decoy that works in 9 cycles. It's a simple modification left as an exercise to the reader. | __L__ ******************************* -|- ___ * Warren Kurt vonRoeschlaub * | | O | * kv07@iastate.edu * |/ `---' * Iowa State University * /| ___ * Math Department * | |___| * 400 Carver Hall * | |___| * Ames, IA 50011 * J _____ ******************************* From: amundsen@molbio.cbs.umn.edu (Craig Amundsen) Subject: FAQ File? Message-ID: <1992Aug19.185630.26585@news2.cis.umn.edu> Date: 19 Aug 92 18:56:30 GMT I've been looking at this newsgroup for a while and I've never seen a FAQ file. Does one exist? I am interested in trying to write a CoreWarrior but I haven't any idea how to begin. Could someone please tell me where to look for information appropriate for beginners? Thanks B-) -- Craig Amundsen (amundsen@molbio.cbs.umn.edu) From: jjhayes@nbrwh75.bnr.ca (Jeff Hayes) Subject: newbie Q, what and where please Message-ID: <1992Aug20.141521.28429@bnr.ca> Date: Thu, 20 Aug 1992 14:15:21 GMT i heard about corewars somewhere a long while back, and i have played a PC game where you had to write pascal code to operate a robot - very simple-minded. so the newbie's q is : what is corewars, and if code is involved and a program to run it (?) where do i get it? or if there is a FAQ can someone mail it to me please? -- jeff hayes ESN 333-3894 phone (416) 452-3894 jjhayes@x400gate.bnr.ca Northern Telecom, Prod Tech, Bramalea Ont From: nexus@ylum.cgd.ucar.edu (Jeff Berry) Subject: Warrior archives? Message-ID: <1992Aug20.173607.27176@ncar.ucar.edu> Date: 20 Aug 92 17:36:07 GMT Hey there, I have only been doing this a short while, and have just recently set up koth on my system to test and debug programs. What I am looking for now are examples of code to test against - preferably high ranked warriors on current and/or recent hills (especially the x-hill). I know, some of the warriors are posted, but I neglected to grab them when they were posted, and now they are gone. So, if anyone has some that they would like to share so I can figure out how to kill them, I would be greatly appreciative. Email is probably best. Thanks. badger Don Alexandre Lerot d'Avigne Jeff Berry Seneschal of Caer Galen, Outlands nexus@ncar.ucar.edu NCAR doesn't tell me what to think, and I return the favor. "You're a notch and I'm a legend"-------Alice Cooper "You're still doing the things that I gave up years ago.."-----Lou Reed Subject: Re: newbie Q, what and where please Message-ID: <1992Aug21.013410.19140@peponi.wcc.govt.nz> From: cole_d@kosmos.wcc.govt.nz Date: Fri, 21 Aug 1992 01:34:10 GMT In article <1992Aug20.141521.28429@bnr.ca>, jjhayes@nbrwh75.bnr.ca (Jeff Hayes) writes: >i heard about corewars somewhere a long while back, and i have >played a PC game where you had to write pascal code to operate >a robot - very simple-minded. > >so the newbie's q is : what is corewars, and if code is involved >and a program to run it (?) where do i get it? >or if there is a FAQ can someone mail it to me please? > >-- > >jeff hayes ESN 333-3894 phone (416) 452-3894 >jjhayes@x400gate.bnr.ca Northern Telecom, Prod Tech, Bramalea Ont Are you on an IBM computer as I have the file in question. Where would you like me to send it (and how do I upload to an FTP site?) From: mperry@waikato.ac.nz Subject: Re: Warrior archives? Message-ID: <1992Aug21.123646.10279@waikato.ac.nz> Date: 21 Aug 92 12:36:45 +1200 In article <1992Aug20.173607.27176@ncar.ucar.edu>, nexus@ylum.cgd.ucar.edu (Jeff Berry) writes: > > > Hey there, I have only been doing this a short while, and have just recently > set up koth on my system to test and debug programs. What I am looking for > now are examples of code to test against - preferably high ranked warriors > on current and/or recent hills (especially the x-hill). > > I know, some of the warriors are posted, but I neglected to grab > them when they were posted, and now they are gone. So, if anyone has > some that they would like to share so I can figure out how to kill them, > I would be greatly appreciative. > > Email is probably best. Thanks. I also would like some copies of the warriors, I don't have net access but can recieve email (and read news). If anyone has the latest copy of red code as I only have the code from the published scientific america in '88. Email to mperry@waikato.ac.nz or jsaggers@waikato.ac.nz ^^^^^^^^ The person who actually wants the code. From: mperry@waikato.ac.nz Subject: information please. Message-ID: <1992Aug22.140633.10292@waikato.ac.nz> Date: 22 Aug 92 14:06:32 +1200 I was asked to post this: Would one of the players of the corewar type programs mail me the lastest instruction set for the redcode being used and the possible formats of the instructions. Mail this to jsaggers@waikato.ac.nz I will be able to recieve this mail but not reply as will I can read and recieve I am not able to post. From: maniac@unlv.edu (Eric J. Schwertfeger) Subject: Fun And Profit on the X-Hill Message-ID: <1992Aug22.223250.5469@unlv.edu> Date: Sat, 22 Aug 92 22:32:50 GMT O.K., so there's not much profit on the Koth experimental hill, but there's quite a bit of fun there. I'm surprised that there isn't more activity on the hill. The X-hill isn't as hard to make as regular hill. You don't see many four line programs on the X-hill, because the idea is more important than being a very small target. I'd like to convince more people to look at the X-hill, because development there is rather slow. Currently, a new program, as opposed to a new version, only appears once a week or so. I hope my upcoming article generates more interest in the X-hill. First of all, I'm not the ultimate X-hill guru, so don't take everything I say as gospel. I know what works for me, and it works well, since at the time of this writing I have three of the top four programs on the X-Hill. However, I've only been working with the X-hill for two months, so there are things I don't know. The environment of the X-hill has encouraged quite a few different ideas and tactics. Programs will launch subprograms, relocate themselves, or watch for programs coming in their direction, to get out of the way. Developing code for the X-Hill isn't difficult. With one constraint, regular redcode interpreters will run code capable of running on the X-hill. The instruction differences are minor, and the source to the Koth interpreter is available, if you have access to an X windows server and 200-400K of file space for the executable. I recommend that if you develop code on a non-Koth interpreter, final test on something that will enforce the write limit. NOTE: There has been considerable change on the X-Hill since I started writing this article. There are many new entries on the hill, and interest seems to be greater than before. -- Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu From: maniac@unlv.edu (Eric J. Schwertfeger) Subject: X-Hill Tutorial {LON{LONG}[LONG] Message-ID: <1992Aug22.223428.5561@unlv.edu> Date: Sat, 22 Aug 92 22:34:28 GMT I. What makes the Experimental Hill Different. There is one important difference, and a few minor ones between the standard hill and the X-hill. The major difference is that the X-hill imposes a write limit on everything that your program does. This isn't an addressing range limitation, but an actual write limit. While you are capable of reading any memory cell, you can only modify cells within a range of 250 cells from the currently executing instruction. If you attempt to change a memory cell, by any means, that is outside the write limit range, the instruction will still execute, but the cell will not change. You can use a memory cell outside the range as a pointer to another cell, but if the final destination is farther than 250 cells from the executing instruction, the write won't take place. Also note that if you use predecrement or postincrement addressing mode on a cell outside the range, the cell won't get changed. The exact results of this depend on the interpretation, so you should avoid using those modes when the intermediate cell is outside the write range. The other difference is an improvement. In addition to an additional addressing mode, postincrement, you gain the ability to use any addressing mode in any place. The use of immediate B-field operations can be particularly helpful. The two most common uses of immediate B-field mode instructions I use are DJN WHERE, #NUMBER, or MOV #INIT, #WHAT. II. The Implications of the Write Limit. The write limitation has major implications on almost all aspects of the programs. Since you can only reach one sixteenth of the core at any one time, you need to either hope the enemy comes within reach, accept a lot of ties, or find a way to extend your reach. The most common method of extending the reach of a program is to make the program move itself, or move a small part of itself. This by itself has almost as many implications as the write limit does. Because movement is almost required, SPL 0 bombing can become very dangerous to the bomber. It is quite possible to eventually move onto a memory range with several processes running, resulting in mass confusion, and possible death. There are several ways to avoid this. One method is to bomb with JMP PIT instructions, where PIT is a splitting trap, ensuring that the pit is located somewhere that your program won't copy itself to, or will DAT bomb long before moving there. Spider, Loki, and Halberd all use this type of bombing. Another method is to bomb with both DATs and SPLs in such a pattern that any place that gets SPL bombed will get DAT bombed long before the code hits that place. Sonic Boom uses this type of SPL bombing. Another type of bombing that reduces the chances of impaling yourself is to bomb with JMP 0 instructions. This isn't as effective, since you are only eliminating a portion of the opponents CPU time, rather than sucking up most of it. There are some traps that you can bomb with that will split for a while then kill off whatever is trapped, but bombing with a small program is usually more complex than bombing with a single instruction. Finally, something that I have experimented with, but never found necessary, is bombing with SPL 1, and ensuring that every 12th instruction or so is a DAT. This way, you won't need to kill trapped processes yourself. One form of attack that gets around the write limit originated in the program "Splitting Nightmare." This form of attack finds enemy code, then split to it. The idea of this attack is that many programs on the X-hill will stop working if two processes are executing the code. Either the code breaks, and both processes die, possibly resulting in a win, or neither dies, resulting in a tie at worst. This form of attack is becoming less effective on the hill now, since many programs on the hill are starting to defend themselves from this form of attack, as described in section IX. Another tactic that the write limit promotes is the use of separate attack programs, often called "fangs." Spider uses small fangs to create other fangs, and to attack, so that the opposing program must hit a very small target, but the program is still capable of sophisticated behavior, because the large central program is off safely out of range. Halberd creates a small fang out ahead of itself to clear the area that is within range of where it will move to, so that in order to attack the main program, the opposing program must either kill the fang, move rapidly past the fang, or approach from the other direction. Finally, the write distance considerably complicates the use of decoys, since you can only directly write a decoy a limited distance away, which is not sufficient to save the main program. On the X-hill, there are a few very fast programs that copy themselves ahead, dying when they hit code, including themselves. This is very useful, because for the cost of a few hundred cycles, you can create a small decoy spaced out though all core. Here is an example of one such decoy, the one I use in almost all of my programs. DSTEP EQU (200) DECOY SPL 1 MOV Date: Sun, 23 Aug 1992 15:44:31 GMT I have just submitted (no results yet) SkipShot Launcher. This program is based very hevily on Eric Schwertfeger's program SkipShot (definately worth examining, some neat ideas there). Since the launcher is the only part I wrote, and it was really more of a modification, I am posting the program here now. BTW the launcher is somewhat similar to that used by patriot (absolutely nothing like scud), but I think it could be optimized further to launch before it finishes updating the data fields, this would probably get 30% more skipshots in the air before the launcher hits itself (or gets hit). SkipShot is a 6 process missile, so it tends to move in 2/3 the time of patriot's missiles. This advantage, however, may be offset by the extra two byte suceptability to bombs and the need to wate until the SkipShot is two steps away before launching the next. We will see. ;redcode-x verbose ;name SkipShot Launcher ;author Kurt vonRoeschlaub ;strategy Launch SkipShots into memory skip EQU (245) step EQU (3) sdat dat step,step ddat dat step,2*step-3 start spl launch mov #6,pause ;may be able to change this to 5 add #step,launch add #step,launch+1 pause djn 0,#6 ;with this set to 5, spl launch next add sdat,fire sub ddat,dest jmp start launch mov src,src-skip mov dest,dest-skip spl 2 spl 1 jmp fire src dat dest+1+skip fire mov Date: Sun, 23 Aug 1992 17:01:23 GMT Well, the results came back. SkipShot Launcher didn't do too well. I think it was the extra bytes, as it tends to step on it's own tail from time to time. Patriot, which is one of the most similar programs (as far as I know), did Program "Patriot" (length 11) by "Kurt vonRoeschlaub" (contact address "kv07@iastate.edu"): ;strategy fire a volley of smart missiles SkipShot Launcher wins: 10 Patriot wins: 85 Ties: 5 but the real pummeler was seething mass, which didn't loose or tie once! Of course, patriot hadn't beat it either (at least it tied half the time). I don't know if seething mass has been posted, but it definately has a good defence against launchers. BTW, in case you hadn't noticed I am making an arbitrary distinction between launchers and guns: a launcher fires a volley of programs with different data fields (ie step size, etc) while a gun repeatedly fires the same program. | __L__ ******************************* -|- ___ * Warren Kurt vonRoeschlaub * | | o | * kv07@iastate.edu * |/ `---' * Iowa State University * /| ___ * Math Department * | |___| * 400 Carver Hall * | |___| * Ames, IA 50011 * J _____ ******************************* From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Warrior archives? Message-ID: <1992Aug23.232102.13347@oucsace.cs.ohiou.edu> Date: 23 Aug 92 23:21:02 GMT In article <1992Aug21.123646.10279@waikato.ac.nz> mperry@waikato.ac.nz writes: >In article <1992Aug20.173607.27176@ncar.ucar.edu>, nexus@ylum.cgd.ucar.edu (Jeff Berry) writes: >> >> I know, some of the warriors are posted, but I neglected to grab >> them when they were posted, and now they are gone. So, if anyone has >> some that they would like to share so I can figure out how to kill them, >> I would be greatly appreciative. >> >I also would like some copies of the warriors, I don't have net access but can >recieve email (and read news). If anyone has the latest copy of red code as >I only have the code from the published scientific america in '88. For all those people who are interested in having a their own library of warriors, please contact me via E-Mail and I will be glad in donating the library I have here. It consists of well over 150 programs and is constantly growing in size. Many of the programs I have pulled from this newsgroup has been modified to work with my corewar program, but I will soon go back to the originally posted versions, since my new corewar program will now work with any redcode warriors that has been posted so far... :-) I can be reached at the following address: sadkins@ohiou.edu Good luck! Scott Adkins From: mhs@fokus.gmd.de (M.Schmeil) Subject: some FAQs: SPL / program Message-ID: <1992Aug26.140453.2450@fokus.gmd.de> Date: 26 Aug 92 14:04:53 GMT hi, maybe it's because my english isn't the best, propably i'm too stupid, but after reading the guidelines, tutorials, etc. i don't know how the SPL-instruction works. what are the operand(s) for (start-instructionpointer from the new task?)? is it (somehow) possible to program 'new task starts at offset x from the current instruction' (i guess the original task continues with the next instruction)? is a core-war for the amiga available? thanx - tB! From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Some x-warriors Message-ID: <1992Aug26.221207.1058@vlsi.polymtl.ca> Date: Wed, 26 Aug 1992 22:12:07 GMT I've just started to write some warriors on the experimental hill, and since I ben able to place some of them (as high as 3rd position at one time), I think it's time I post them (before they fall off :). My first program to make it is an `invader' type, spawning new process in the enemy code. It made it to the 17th position, but there is no way such a warrior could do better since: * there is NO WAY you can analyse effectively the hill since opcodes and operands cannot be separated. * Eric's article suggested very good ways to fool them. The program first version was looking for anything that was NOT dat, spl or jmp with absolute operand (dat x,y...). The second version was looking for one of many kinds of moves that are found in programs. It was called Ghost: ;redcode-x ;name Ghost ;kill Ghost ;author Pierre Baillargeon len equ 8 dist equ 125 field equ 250+bomber-target lab dat 0,0 what mov #0,#0 dat 0,0 mod add #618,#-2 ; change location mov @mod,lab sub lab,lab cmp what,lab jmp mod,0 spl @mod,0 djn mod,#3 waiter spl target,0 ; start core clear sleep djn sleep,#0 ; wait... jmp waiter,0 ; redo clear target mov #250-len,target ; init bomb distance bomber mov bomb,pit dat 0,0 Every 8000th times the djn is executed, a process falls through a slowly eat the pit away... (BTW, a `pit' is where you make the enemy jump to in order to immobilise all its process. The figure of 8000 assume a core size of 8000). -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: ImpDwarf Gun 1.0 Message-ID: <1992Aug27.161220@IASTATE.EDU> Date: Thu, 27 Aug 1992 21:12:20 GMT Well, ImpDwarf Gun has fallen off the hill at a nice ripe old age. It was my first truely succesful warrior of any kind (especially as an x-hill warrior) and is based on my old program ImpDwarf (as if you didn't know). Since I have no ideas on how to improve the code, here is the exact coding (I believe I have described it several times): ;redcode-x verbose ;name ImpDwarf Gun 1.0 ;author Warren vonRoeschlaub ;strategy Gun fires ImpDwarf through memory every cycles ;strategy 1.0 cleaned out most "DAT"s, optimized launch start spl fire rept mov dest,-38 djn rept,data mov #242,dest mov die2,die data mov #180,180 ;cute huh? The counter is self initializing jmp start die2 mov 3,0 fire spl 1 spl 1 go mov #(2+dest),-1 cloop mov <-2, Date: Fri, 28 Aug 92 00:17:36 GMT I added an Xwindow interface for CROBOTS ((c) by Tom Pointdexter). I was unable to reach Tom at his last email address, so I hope he doesn't mind me posting my patches. You will need to be a registered user of the source code to use these (I know some of you are out there). Instead of the CURSES screen, you get a nice window with little drawings of robots (in color) zipping around blasting each other. A small line on each robot indicates the current direction of scan, and explosions are drawn as circles, and are drawn to scale. If you have a sun sparcstation, then you can #define SUN_SOUND, and get a "thip" noise every time a shell explodes. A compiled version of this code is available via anonymous ftp from earthsea.Stanford.edu for sun sparcstations. Also, look around for a collection of robot files, and also a program called xv_display. xv_display is an XView front-end for CROBOTS that lets you pick robot names from a set of listboxes. You'll need a SUN running openwindows (probably). Your robot files MUST be in a subdirectory called "r" or it will segfault (sorry). The code for xv_display and it's makefile are in the ftp directory also. Happy CROBOTing, Paul Gyugyi ps. Tom, if you're out there, drop me a line. -- begin makefile -- # makefile for crobots OBJS = main.o grammar.o lexanal.o compiler.o cpu.o intrins.o display.o screen.o motion.o # X window additions by Paul Gyugyi, 1992 XOBJS = main.o grammar.o lexanal.o compiler.o cpu.o intrins.o display.o screenx.o motion.o SOURCES = crobots.h compiler.h tokens.h main.c grammar.y grammar.c lexanal.l lexanal.c compiler.c cpu.c intrins.c display.c screen.c screend.c screenx.c ¥ motion.c DOS = main.c grammar.c lexanal.c compiler.c cpu.c intrins.c display.c screend.c motion.c DOSA = main.c grammar.c lexanal.c compiler.c cpu.c intrins.c display.c screena.c motion.c CFLAGS = -O -DUNIX LIBS = -lm -lcurses -ltermlib XLIBS = -lm -lcurses -ltermlib -lX11 crobots: $(OBJS) cc -s $(CFLAGS) $(OBJS) -o crobots $(LIBS) xcrobots: $(XOBJS) cc -s $(CFLAGS) $(XOBJS) -o xcrobots $(XLIBS) main.o: crobots.h main.c cc $(CFLAGS) -c main.c grammar.o: crobots.h compiler.h grammar.y yacc -d grammar.y cat y.tab.c >grammar.c rm y.tab.c mv y.tab.h tokens.h cc $(CFLAGS) -c grammar.c lexanal.o: crobots.h compiler.h lexanal.l grammar.y lex lexanal.l cat lex.yy.c >lexanal.c rm lex.yy.c cc $(CFLAGS) -c lexanal.c compiler.o: crobots.h compiler.h tokens.h compiler.c cc $(CFLAGS) -c compiler.c cpu.o: crobots.h grammar.y cpu.c cc $(CFLAGS) -c cpu.c intrins.o: crobots.h intrins.c cc $(CFLAGS) -c intrins.c display.o: crobots.h display.c cc $(CFLAGS) -c display.c screen.o: crobots.h screen.c cc $(CFLAGS) -c screen.c screenx.o: crobots.h screenx.c cc $(CFLAGS) -c screenx.c motion.o: crobots.h motion.c cc $(CFLAGS) -c motion.c dos: cc -s -dos -K -i -O -DDOS $(DOS) -o crobotsx.exe -lm /bin/rm *.o dosa: cc -s -dos -K -i -O -DDOS $(DOSA) -o crobotsa.exe -lm /bin/rm *.o print: pr -t $(SOURCES) | lpr lint: lint -abc *.c | tee crobots.lint @echo 'lint output kept in crobots.lint' -- end makefile -- -- begin screenx.c -- /*****************************************************************************/ /* */ /* CROBOTS */ /* */ /* (C) Copyright Tom Poindexter, 1985, all rights reserved. */ /* */ /* X-windows code by Paul Gyugyi, 1992 */ /* */ /*****************************************************************************/ /* screen.c - low level screen display routines */ /* change or modify this module for different systems */ #include "crobots.h" #include "math.h" #include #include #include #include #include "/home/gyugyi/turmite/bitmaps/icon_bitmap" /* #define SUN_SOUND /* sound */ #define GRID 100 #define GRIDSIZE 5 #define EXP_SIZE (40*GRID*GRIDSIZE/MAX_X) /* #define DRAW_CURSES /**/ #define COLOR #define BITMAPDEPTH 1 #define MAXCOLORS 8 Display *display; int screen; #ifdef SUN_SOUND FILE *sp; #endif /* x windows defines */ Window win; unsigned int width,height; int x=0, y=0; unsigned int border_width=4; unsigned int display_width, display_height; char *window_name = "CROBOTS.X"; char *icon_name = "basicwin"; Pixmap icon_pixmap; XSizeHints size_hints; XEvent report; GC gc; XFontStruct *font_info; char *display_name = NULL; int window_size = 0; int k,kk; int depth; Visual *visual; char *name[] = {"Gray20","Gray40","Gray60","Gray80","Gray30","Gray50","Gray70","Gray90"}; char *color_name[] = {"blue","green","red","cyan","magenta","yellow","orange","purple"}; XColor exact_def; Colormap cmap; int ncolors = MAXCOLORS; int colors[MAXCOLORS]; int color_robots[MAXCOLORS]; int robot_virgin[MAXROBOTS] = {1,1,1,1}; int missile_virgin[MAXROBOTS][MIS_ROBOT] = {{1,1},{1,1},{1,1},{1,1}}; int missiles_last_x[MAXROBOTS][MIS_ROBOT]; int missiles_last_y[MAXROBOTS][MIS_ROBOT]; int robots_old_x[MAXROBOTS]; int robots_old_y[MAXROBOTS]; /* init_disp - initialize display */ init_disp() { int i; if ((display=XOpenDisplay(display_name))==NULL) { (void) fprintf( stderr, "cannot connect to X server %s¥n", XDisplayName(display_name)); exit(-1); } screen = DefaultScreen(display); display_width = DisplayWidth(display, screen); display_height = DisplayHeight(display, screen); width = GRIDSIZE * (GRID + 1); height = GRIDSIZE * (GRID + 1) + 100 ; win = XCreateSimpleWindow(display, RootWindow(display,screen), x,y,width,height,border_width,BlackPixel(display,screen), WhitePixel(display, screen)); icon_pixmap = XCreateBitmapFromData(display,win,icon_bitmap_bits, icon_bitmap_width, icon_bitmap_height); size_hints.flags = PPosition | PSize | PMinSize; size_hints.x = x; size_hints.y = y; size_hints.width = width; size_hints.height = height; size_hints.min_width = 16; size_hints.min_height = 16; XSetStandardProperties(display, win, window_name, icon_name, icon_pixmap, NULL, NULL, &size_hints); /* XSetStandardProperties(display, win, window_name, icon_name, icon_pixmap, argv, argc, &size_hints); */ /* XSelectInput(display, win, ExposureMask | KeyPressMask | ButtonPressMask | StructureNotifyMask); */ load_font(&font_info); get_GC(win, &gc, font_info); XSetFunction(display, gc, GXxor); XMapWindow(display, win); XFlush(display); /* color stuff */ depth = DisplayPlanes(display, screen); visual = DefaultVisual(display, screen); cmap = DefaultColormap(display, screen); if (depth == 1) { for (i=0; i<4; i++) { color_robots[i] = WhitePixel(display,screen); }; } else { for (i=0; i to begin.¥n"); getchar(); } /* end_disp - cleanup and end display */ end_disp() { printf("Press to end.¥n"); getchar(); XUnloadFont(display, font_info->fid); XFreeGC(display, gc); XCloseDisplay(display); #ifdef SUN_SOUND if (sp) {fclose(sp);} #endif } /* draw_field - draws the playing field and status boxes */ draw_field() { int i; XSetForeground(display, gc, BlackPixel(display,screen)); XFillRectangle(display, win, gc, 0, 0, GRIDSIZE*(GRID+1) +1, GRIDSIZE*(GRID+1)+1); } /* plot_robot - plot the robot position */ erase_robot(n) int n; { if (robot_virgin[n] == 0) { XSetForeground(display, gc, color_robots[n]); XFillRectangle(display, win, gc, (int)(GRIDSIZE*GRID*robots_old_x[n]/(1.0*CLICK*MAX_X)) - GRIDSIZE/2, GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID*robots_old_y[n]/(1.0*CLICK*MAX_Y)) - GRIDSIZE/2, GRIDSIZE+1,GRIDSIZE+1); XDrawLine(display, win, gc, (int)(GRIDSIZE*GRID*robots_old_x[n]/(1.0*CLICK*MAX_X)), GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID*robots_old_y[n]/(1.0*CLICK*MAX_Y)), (int)(GRIDSIZE*GRID*robots_old_x[n]/(1.0*CLICK*MAX_X) + 2*GRIDSIZE * cos(robots[n].last_scan*3.14159/180.0)), GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID*robots_old_y[n]/(1.0*CLICK*MAX_Y) + 2*GRIDSIZE * sin(robots[n].last_scan*3.14159/180.0)) ); if (robots[n].status == DEAD) { /* draw burned-out hull */ XDrawRectangle(display, win, gc, (int)(GRIDSIZE*GRID*robots_old_x[n]/(1.0*CLICK*MAX_X)) - GRIDSIZE/2, GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID*robots_old_y[n]/(1.0*CLICK*MAX_Y)) - GRIDSIZE/2, GRIDSIZE+1,GRIDSIZE+1); robot_virgin[n] = 1; /* shouldn't be drawn anymore */ } } } plot_robot(n) int n; { int i, k; if (robot_virgin[n] == 0) { erase_robot(n); } else { robot_virgin[n]=0; } XSetForeground(display, gc, color_robots[n]); XFillRectangle(display, win, gc, (int)(GRIDSIZE*GRID*robots[n].x/(1.0*CLICK*MAX_X)) -GRIDSIZE/2, GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID*robots[n].y/(1.0*CLICK*MAX_Y)) -GRIDSIZE/2, GRIDSIZE+1,GRIDSIZE+1); XDrawLine(display, win, gc, (int)(GRIDSIZE*GRID*robots[n].x/(1.0*CLICK*MAX_X)), GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID*robots[n].y/(1.0*CLICK*MAX_Y)), (int)(GRIDSIZE*GRID*robots[n].x/(1.0*CLICK*MAX_X) + 2*GRIDSIZE * cos(robots[n].scan*3.14159/180.0)), GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID*robots[n].y/(1.0*CLICK*MAX_Y) + 2*GRIDSIZE * sin(robots[n].scan*3.14159/180.0)) ); XFlush(display); robots_old_x[n] = robots[n].x; robots_old_y[n] = robots[n].y; robots[n].last_scan = robots[n].scan; } /* plot_miss - plot the missile position */ plot_miss(r,n) int r; int n; { int i, k; if (missile_virgin[r][n] == 0) { XSetForeground(display, gc, color_robots[r]); XFillRectangle(display, win, gc, (int)(GRIDSIZE*GRID*missiles_last_x[r][n]/(1.0*CLICK*MAX_X)) - GRIDSIZE/4, GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID*missiles_last_y[r][n]/(1.0*CLICK*MAX_Y)) - GRIDSIZE/4, GRIDSIZE/2+1, GRIDSIZE/2+1); } else { missile_virgin[r][n] = 0; } XSetForeground(display, gc, color_robots[r]); XFillRectangle(display, win, gc, (int)(GRIDSIZE*GRID*missiles[r][n].cur_x/(1.0*CLICK*MAX_X))-GRIDSIZE/4, GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID*missiles[r][n].cur_y/(1.0*CLICK*MAX_Y))-GRIDSIZE/4, GRIDSIZE/2 + 1, GRIDSIZE/2+1); XFlush(display); missiles_last_x[r][n] = missiles[r][n].cur_x; missiles_last_y[r][n] = missiles[r][n].cur_y; } /* plot_exp - plot the missile exploding */ plot_exp(r,n) int r; int n; { if (missiles[r][n].count == EXP_COUNT) { /* erase last missile postion */ XSetForeground(display, gc, color_robots[r]); XFillRectangle(display, win, gc, (int)(GRIDSIZE*GRID*missiles_last_x[r][n]/(1.0*CLICK*MAX_X))-GRIDSIZE/4, GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID*missiles_last_y[r][n]/(1.0*CLICK*MAX_Y))-GRIDSIZE/4, GRIDSIZE/2+1, GRIDSIZE/2+1); XSetForeground(display, gc, color_robots[r]); XFillArc(display, win, gc, (int)(GRIDSIZE*GRID* (missiles[r][n].cur_x/(1.0*CLICK*MAX_X)))-EXP_SIZE/2, GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID* (missiles[r][n].cur_y/(1.0*CLICK*MAX_Y)))-EXP_SIZE/2, EXP_SIZE, EXP_SIZE, 0, 360*64); XFlush(display); /* reset xor flag */ missile_virgin[r][n] = 1; #ifdef SUN_SOUND if (sp) {fprintf(sp,"AzAzAzAzAzAzAzAzAzAzAzAzAzAzAzAzAzAz");fflush(sp);} #endif } else if (missiles[r][n].count == 1) { XSetForeground(display, gc, color_robots[r]); XFillArc(display, win, gc, (int)(GRIDSIZE*GRID* (missiles[r][n].cur_x/(1.0*CLICK*MAX_X)))-EXP_SIZE/2, GRIDSIZE*GRID - 1 - (int)(GRIDSIZE*GRID* (missiles[r][n].cur_y/(1.0*CLICK*MAX_Y)))-EXP_SIZE/2, EXP_SIZE, EXP_SIZE, 0, 360*64); XFlush(display); } } /* robot_stat - update status info */ robot_stat(n) int n; { char buf[128]; static int olddamage[4]={-1,-1,-1,-1}; if (robots[n].damage != olddamage[n]) { XSetFunction(display, gc, GXcopy); XFlush(display); XSetForeground(display, gc, BlackPixel(display, screen)); XFillRectangle(display,win,gc,10,GRIDSIZE*(GRID+1)+20*(n+1)-15, GRIDSIZE*(GRID+1)-20,18); XSetFunction(display, gc, GXxor); XFlush(display); XSetForeground(display, gc, color_robots[n]); sprintf(buf,"%d: %s %d",n,robots[n].name,robots[n].damage); XDrawString(display,win,gc, 20, GRIDSIZE*(GRID+1)+20*(n+1), buf, strlen(buf)); olddamage[n]=robots[n].damage; if (robots[n].status == DEAD) { erase_robot(n); } XFlush(display); } } show_cycle(l) long l; { } get_GC(win,gc,font_info) Window win; GC *gc; XFontStruct *font_info; { unsigned long valuemask = 0; XGCValues values; *gc = XCreateGC(display, win, valuemask, &values); XSetFont(display, *gc, font_info->fid); XSetForeground(display, *gc, BlackPixel(display,screen)); } load_font(font_info) XFontStruct **font_info; { char *fontname = "9x15"; if ((*font_info = XLoadQueryFont(display,fontname))==NULL) { (void) fprintf( stderr, "Basic: Cannot open 9x15 font¥n"); exit(-1); } } -- end screenx.c -- -- Paul J. Gyugyi Grad student, control systems, Stanford University (and an avid LEGO collector) gyugyi@earthsea.Stanford.EDU From: tpoindex@nyx.cs.du.edu (Tom Poindexter) Subject: Re: CROBOTS: Xwindow interface code for your viewing pleasure Message-ID: <1992Aug28.161032.9202@mnemosyne.cs.du.edu> Date: Fri, 28 Aug 92 16:10:32 GMT In article <1992Aug28.001736.26069@leland.Stanford.EDU> gyugyi@leland.Stanford.EDU (Paul Gyugyi) writes: >I added an Xwindow interface for CROBOTS ((c) by Tom Pointdexter). >I was unable to reach Tom at his last email address, so I hope he >doesn't mind me posting my patches. You will need to be a registered >user of the source code to use these (I know some of you are out there). > [....] >ps. Tom, if you're out there, drop me a line. Hi Paul, One of the problems associated with being a consultant, and changing clients every so often. My current email address should be vaild for a while - it's a public access machine not associated with my current client. No I don't mind you posting patches. In fact, I tried to sit down and make some changes to CROBOTS, but that stinking concept of work and leisure time keeps coming up. Which leads me to think about freeing CROBOTS again. Hopefully in the next few days or weeks I'll make a final decision to update CROBOTS myself, or make it available. -- -- set signature {{Tom Poindexter} {tpoindex@nyx.cs.du.edu} {pithy quote}} From: u2119737@csdvax.csd.unsw.edu.au Subject: What's new in core-war? Message-ID: <1992Aug28.193543.2964@csdvax.csd.unsw.edu.au> Date: 28 Aug 92 19:35:43 +1000 What's happening in the world of core-wars these days, people? It has been ages since I played it, has it changed much? Are there any new games of similar genre around? I'd love to catch up with it all, that sort of stuff fascinates me. Malcolm - u2119737@csdvax.csd.unsw.oz.au From: t-jcisek@microsoft.com (Julius Cisek) Subject: KotH scoring weirdness Message-ID: <1992Aug28.210219.2504@microsoft.com> Date: 28 Aug 92 21:02:19 GMT I'm just nitpicking, but did anyone else notice some scoring inconsistencies under KotH? An example: No Mucking About has a record of 50/42/8 and Charon v7.0 is 50/41/9. The latter lost one LESS match and ties one more. Nevertheless, No Mucking About scores 159 points while Charon scores 158. I thought ties were worth something and it is better to tie than to lose... Now maybe there's some weirdness with floating point to integer conversion that causes this inconsitency... I'm just wondering... No, really! :) -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo ¥ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 ¥X/ | U| ¥| From: kilroy@mik.uky.edu (Paul S. Kilroy) Subject: Kill lines... Message-ID: Date: Sat, 29 Aug 1992 15:51:06 GMT can someone tell me how to kill a program that doesnt have a name i tried kill unknown but that didnt work do i have to type ";kill "? thanks paul -- -Paul (kilroy@mik.uky.edu) From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: Kill lines... Message-ID: <1992Aug29.141927@IASTATE.EDU> Date: Sat, 29 Aug 1992 19:19:27 GMT In article , kilroy@mik.uky.edu (Paul S. Kilroy) writes: > can someone tell me how to kill a program that doesnt have a name > i tried kill unknown but that didnt work > do i have to type ";kill "? That will kill all the programs you have submitted. If that's what you intend, then yes. To be honest, I didn't know it was possible to submit a program with no name. If you leave off an authors name it fills in "unknown", I assumed it did the same for program names. | __L__ ******************************* -|- ___ * Warren Kurt vonRoeschlaub * | | o | * kv07@iastate.edu * |/ `---' * Iowa State University * /| ___ * Math Department * | |___| * 400 Carver Hall * | |___| * Ames, IA 50011 * J _____ *******************************