This file contains the readme.txt file from the Dos/QBasic version, the readme_linux.txt file from the Linux version (excuse the duplication) and the main RedMixer doc file. Corrections to the documentation may appear here before being added to the packages. There isn't a separate Windows version of RedMixer, mainly because if a Windows system won't run the Dos/QBasic version it is likely risky to use for evolving (plus the dos exe seemed faster anyway). Rather, if you want a native Windows version of RedMixer then get the redmixer.bas.txt file (rename to redmixer.bas), get the Windows version of the FreeBasic compiler, then compile it using the command line: "\Program Files\FreeBasic\fbc" -exx -lang qb redmixer.bas (adjust the path to where FreeBasic is installed) The resulting .exe runs fine on my WinXP systems but I have no idea how compatible it is with other versions of Windows. (will update the above if I get further compatibility information) ------ redmixer_docs.txt --------------------------------------------------- The RedMixer Evolver - version 1.1a 09.06.01 ============================================ RedMixer is a program that evolves warriors for the game of Corewar. It is assumed that the reader of this document is familiar with concepts such as warriors, coresize, rounds and other parameters, scoring, etc. An extensive set of informative pages is at: http://www.corewar.co.uk/ This site links to several benchmark sets that can be used to judge the performance of warriors evolved by RedMixer. History and Technique --------------------- RedMixer is an extension of ideas explored in my earlier evolvers (RedMaker and REBS) where the warriors in the "soup" (a collection of warriors being evolved together) are positioned on a two-dimensional grid. Warriors battle their neighboring warriors, the losing warriors are replaced with mutated copies of the stronger warrior so that over time good mutations are replicated and replace bad mutations. This is similar to evolution in nature only applied to program code. I got the idea from George Lebl's SYS4 program, which impressed me with its alife-like display (which I colorized:-) rather than endless streams of numbers produced by other evolvers. RedMixer was a good start but the soup was too small and it had many parameters that had little to do with anything but back then I didn't know what mattered. Turns out it doesn't take that much to evolve warriors, this will do: Loop Pick two neighboring warriors from the soup If either doesn't exist make a random warrior Battle the warriors in a simulator (such as pmars) Replace the loser with a mutated copy of the winner Keep looping until the evolver is stopped. Useful mutations can include... Change the base instruction Change the instruction modifier Change the A-field address mode Change the A-field value, possibilities include... pick a random +/- small number pick a random large number increment or decrement the existing number Same for the B-field address mode and value Insert a new line, either random or a copy of the previous line Delete a line (inserts and deletes have to track the size to avoid error) Change the starting address of the warrior (the number after end) Cross the warrior with the code of another warrior (a tricky thing to do) Not all these are necessary - evolution can occur just by picking new instructions, modifiers (or don't use modifiers), modes and random values. It happens faster when large and small values are differentiated between, new code can be added and unused code can be removed. The starting location and increment/decrement operations have only marginal benefit, crossover can help but only if the cross partner is carefully selected to be similar and preferably known to be not broken - crossing with a bad or different warrior usually doesn't help but can produce happy accidents. Changes are fairly infrequent to avoid breaking every mutated warrior, and the changes are applied equally to every line of code with each item having a specified chance of changing - data value changes tend to optimize existing algorithms so usually they are applied more frequently. It is important to note that many things can change at once, or nothing at all. Usually I set things so there's a 1-2% chance of changing each instruction and a 3-5% chance of changing each data value with the other changes in between. Insert/delete rates are usually from 0.5 to 2% per line and with larger warriors it helps to delete a bit more than insert to help encourage the production of more efficient code. Selection of instructions, modifiers and address modes can be but usually isn't purely random, rather the selection tries to pick the more useful elements more frequently to increase the chances of producing viable code. This is easily arranged by including duplicate entries in the strings. The REBS evolver implemented all the mutations except for crossover, and it worked fairly well but a big disadvantage was although it had a colorized soup display it did not have an interface for exploring the soup. REBS was written in the bash script language using redirection for input and output, this effectively precluded easily implementing crossover since there was only one input and one output file at a time. For crossover need to either read from two parent warriors simultaniously, or store the warriors in an array. Arrays are difficult in bash and REBS was already difficult to deal with, plus eventually I wanted to cursor around and explore the soup, so I implemented the general idea with the addition of crossover in BASIC to make the RedMixer program. The "mix" comes from mixing of warrior code. It took a few iterations to get it right but RedMixer 1.0d was a winner and for a pure evolver worked fairly well for me, producing a nano warrior which is at the time of this writing in 2nd place on the SAL Nano Hill (verses a REBS warrior presently in 7th place). Setup and Compatibility ----------------------- By default RedMixer creates over 1600 files and writes to them constantly while evolving, best to run it from a ram disk or an external hard disk, especially if running for long periods of time. Never run RedMixer on a solid-state "flash" disk such as a thumbdrive or the main disk of a smaller netbook. See the platform-specific readme file for information about setting up a ram disk. On my systems when running RedMixer on a hard disk the drive light blinks briefly about every 3 seconds, which isn't all that much but still amounts to about 10,000 hits for an overnight run. I don't know how much that shortens disk life compared to just spinning, but I'm pretty sure no disk activity at all is better. RedMixer consumes close to 100% of available CPU time while running, don't run it on a system prone to overheating. Be careful running on laptops or "high performance" systems which aren't actually capable of sustaining their maximum speed for an indefinite period of time. Older slower PC's are often more suitable for evolving, a 1 to 1.5 Ghz single-core works fine, faster is better only if the PC can actually use the advertised clock rate. RedMixer requires versions of the pmars and pmarsv programs compatible with the platform it is being run on. If they're named differently or not in a path directory then the redmixer.ini file needs to be edited to specify. See the platform-specific readme for recommended binaries. Using RedMixer -------------- RedMixer is configured by default to evolve warriors for coresize 80 (nano), to evolve warriors for other sizes edit the redmixer.exe and change at least the coresize, processes, cycles, maxlen and specify an appropriate benchmark set (can do that later once something interesting evolves). Preferably the instruction mix and mutation settings should also be altered, evolving for bigger core sizes usually works better with less weighting and mutation. When editing the INI be careful not to specify invalid data, especially in the pmars/pmarsv commands (which are passed to the OS) and in the instruction, modifier and address mode strings which must be correctly formatted. The INI file is read only when starting RedMixer, if running RedMixer must be exited and restarted for changes to take effect. Don't change the coresize for an existing soup, if doing that a lot put each setup in its own directory or make multiple INI files each set with a different soup directory and put copy commands in startup scripts to copy the appropriate INI to the redmixer.ini file. Avoid reducing soup X/Y size for an existing soup as that will leave unused warriors in the soup, but sometimes it is useful to specify a smaller soup at first to increase development speed, then increase the soup size to let the warriors expand into the empty soup space. When RedMixer starts it displays intro text for a few seconds then (provided it finds nothing drastically wrong with the INI settings) presents a blank soup display with options to Evolve and Quit. Press E to evolve. If set up correctly the soup should begin filling with warriors, indicated by colorized numbers. On most platforms pressing Esc stops evolution and returns to the interface. Another way to stop evolving is to delete the DeleteMe file created when evolution is started. After a couple of minutes of evolving on my Asus 701SD running Xandros with the default settings (other than configuring ysize to 19 and screenlines to 22) the following display was produced (in color)... .-----------------------------------------------------------------------------. |22233233353333445555555233333322255345455555511155441111125241412233311555552| |53333325533334455555455523335224223334555555551554553111112434123222211355555| |33433322233332455555545523332244332335555455555555554314114344112222411555553| |44231223233444555555554553333233333334545435554555544444543444144222241455533| |44422222333333455355552542333234333331354432255545534455554444441552241555533| |33432224433333354555444542252533355433444444225555333555555434355555111555455| |53353333433434535555555554455553244333224441425533555554554334554555111555555| |44343544443444544554554544554555444433322444115135555555553325433411125521115| |44434545434552445545545445445553444434132431411154454455533324453115535254111| |14422444543553445445555455455554443343111131111111155455343334451155555555411| |44512222511423424444445555455554443432111131115111555455453344555555545555344| |25542225114234342454444455555555253245551131111125254455555242455555555455445| |45555251111211233353434445455555222445515113111222254445553323455555555555455| |45335515541211233335455445425545544243531111115142224442453322554455554455554| |33345555512222553333555334555555552234331121221442224422253222455555555445335| |24344451314222233335225555555453442444323132225411114155531242452225455455535| |23334541145522145444225555555554434444333333354444411211123111111234555455453| |35455514444521144421255245511114443444543332554544412111311111111135554455322| |22114113445111444451225551511144224444423525554444411112111111111111544555222| `-----------------------------------------------------------------------------' (L) list (R) run (1-9) battle (B) bench (O) options (E) evolve (Q) quit By default the colors indicate species, a string in each warrior that is changed if more than a certain percentage of instructions are changed. In the case of nano warriors, if any instructions are changed. The soup can also be colored by origin (a string in the warrior created when the initial random warrior is made, then passed on without change to all maternal offspring), or by size (how many lines of redcode are in the warrior, not counting comments). Coloring can be temporarily changed using the options menu or specified in the INI file. Various keys select operations to perform on the warrior under the cursor, use the cursor keys to select a warrior to examine. (L) lists the selected warrior to the screen, if the code doesn't all fit press a key for the next page. If desired an external program can be specified in the INI file after listprog to use instead of the internal lister. If using an editor (notepad kwrite etc) be careful not to inadvertently change the code, invalid redcode in the soup will cause errors and prevent evolution until the bad warrior is removed. Here's a warrior after a few hundred generations... ;redcode ;name 07_13.red ;author anonymous ;strategy Evolved by RedMixer 1.1a ;origin 06_17.red ;parents 06_12.red 06_11.red ;generation 315 ;assert 1 spl.i # 74 , > 14 mov.i $ 74 , { 79 mov.i > 53 , { 43 djn.f $ -2 , $ 42 jmn.i @ 70 , } 46 end 0 ;species 17_71.red ;wins 17 ;score 177 Non-code comments begin with ; but pMARS interprets the name and author comments to indicate scores, and requires an assert comment with a true condition (assert 1 is always true). RedMixer warriors are named by soup position, 07_13.red means it's located at line 7 column 13. The origin comment indicates the original random warrior this warrior was decended from, the parent(s) comment indicates the warrior's immediate parent(s) (one or two warriors may be listed depending on if crossover occurred, the origin tag is passed from the first warrior listed). The generation comment indicates the total number of replications since the original random warrior was created. Below the code and end line, the species comment indicates significant code differences, or the warrior's "species". Generation of the species tag is controlled by the specieschanges INI setting, which specifies the maximum percentage of instructions that can be different between a parent and offspring and still keep the same species tag. The default setting is 5 (percent) meaning if more than one instruction is different in a warrior of 20 instructions then a new species tag is generated. For nano warriors limited to 5 instructions this means any instruction change changes the species. The randomspecies and randomtagrange settings control how new species tags are selected, If randomspecies is no (the default) then the new species tag is the soup location, same as the warrior name. This is like labeling animals according to their location and can result in a different warrior form assuming the same species label as other warriors in the vicinity. Besides being colored the same in the soup display, the default crossover mode selects by species so an odd cross may occur. This is not necessarily a bad thing. If the randomspecies INI setting is yes then the species tag is randomly generated rather than being based on location. The randomtagrange setting controls the range of each of the two numbers in the speciestag, so the total number of possible species tags is randomtagrange squared. The total number of possible species is also limited by how many digits are used in the species and name tags, which for normal-size soups is 2 digits per number or a maximum of 10,000 distinct tags so randomtagrange should be set to 100 or less. Lower values limit the number of available tags so that the chance of a mis-cross can be controlled. Finally, if attraction is set to yes in the INI (the default) when a warrior wins a battle the wins and score comments are added. The wins tag specifies how many battles a warrior has won (thus how many times it has replicated), the score tag indicates the average score of all the battles, normalized to a 0-300 range typical of warrior scoring. With 17 wins the listed warrior has done unusually well in the soup but that doesn't necessarily indicate a strong warrior, being surrounded by weak warriors can also drive up the score. By default crossover operations select a surrounding warrior of the same species with the highest accumulated score, or wins times score. When attraction is enabled if a warrior does not have wins and score tags then that warrior has not seen battle yet. (R) runs the selected warrior in pmarsv. If nothing happens make sure a compatible pmarsv is available or if not named "pmarsv[.exe]" edit the INI to specify the proper name (or rename the binary). You'll probably have to adjust the pmarsv -v parameters for proper speed and display, this can be done temporarily from the options menu, once proper settings are found they can be recorded in the INI file after the vparms tag. The -v is required in the string, followed by a space and 3 digits to specify speed (0=fastest, 9=slowest), graphics mode (experiment) and detail level (usually 4). For example for nano warriors try -v 964 for starters, if that's too slow try -v 764 etc. The 6 is a guess, different pmarsv builds vary in the types of graphics displays available. To repeat a number of times also include a -r option, i.e. -r 10 -v 764 for 10 times. (1-9) on the number keypad battle the selected warrior against one of its neighbors in pmarsv (press 5 to battle against itself). When the battle is done (if allowed to finish) the winner is reported, press a key to return to the interface. The result of a single battle doesn't mean much since warriors are positioned randomly before each round, battle repeatedly or use -r in vparms for more accurate battle results (if it matters, typically this function is used to get an idea of how a warrior fights). (B) benchmarks the selected warrior using the benchmark warriors specified in the INI file by the benchdir and benchmask settings. The benchrounds setting specifies the number of battle rounds, the number needs to be high enough to be statistically significant, typically 250 or more for nano warriors and 100-250 for coresize 8000. The benchfixed option specifies (yes or no) if -f is included, if yes then the scores remain constant for a given number of rounds, if no then vary from bench to bench, which can be useful since that can indicate how sensitive the warrior is to starting position. Some of the benchmark settings can be changed from the options menu. Here's how the 07_13.red warrior listed above does when benchmarked... Opponent Scores Results Performance of 07_13.red --------------- --------- ----------- ---------=---------=---------=---------= 8c09fc1a-479925 336 411 111 136 3 ***************** Black Sun III 341 380 104 117 29 ****************** c82f15b5-85011f 275 473 91 157 2 ************** Chiki Chiki 313 394 90 117 43 **************** Cosmic Horror 364 352 110 106 34 ******************* Dodecadence 372 360 118 114 18 ******************* eerie glow 333 399 105 127 18 ***************** flight 356 374 112 118 20 ****************** Foggy Maus (bet 348 390 112 126 12 ****************** glowing embers 314 398 92 120 38 **************** hemlock 323 383 93 113 44 ***************** a slice of moon 254 491 83 162 5 ************* Nano'Powa 446 281 141 86 23 *********************** Pacler Deux 323 386 94 115 41 ***************** Red Moon 375 372 124 123 3 ******************** ripples in spac 392 335 123 104 23 ******************** ripples 22 373 358 118 113 19 ******************* the spiders cre 386 326 116 96 38 ******************** Staphylococcus 372 339 111 100 39 ******************* White Moon 323 422 106 139 5 ***************** --------------- --------- ----------- ---------=---------=---------=---------= Adjusted Score: 138.3 Warriors that do well on the SAL Nano Hill typically score about 10-15 points better than this, but it's getting there. (O) permits a few options to be temporarily changed without INI editing... (A) Color method by species (B) Color shift 0 (C) Text color 2 (D) Bench rounds 250 (E) Bench fixed yes (F) Bench dir nanotest (G) PMARSV parms -v 564 (X) Exit Color method is by species, by size or by origin. Color shift changes the colors of the soup warriors. Text color changes the (you guessed it) the text color, normally from 0 to 15 but colors 0 (black) and 15 (white) are disallowed to help avoid selecting invisible text with normal backgrounds. The other settings have been discussed. (E) starts the evolution process. This creates a DeleteMe file (the filename can be set in the INI file) and begins evolving warriors according to the core select, battle, mutate/replace algorithm given at the beginning of this doc. Press Esc (on most platforms) or delete the DeleteMe file to stop evolution and return to the interface. While evolving a status line is displayed under the soup, something like... 04_36 vs 04_37: 147 153 04_37-->04_36 CS Gen: 432 This shows which warriors are battling, the resulting scores and the winner and loser indicating the direction of mutation. If C is displayed the code is also crossed with another warrior, if S is displayed the mutation resulted in a new species. The generation of the current mutation is displayed, because it's a random process there may be a fair amount of spread in the generations. The C and S indicators are helpful for adjusting the crossover and species settings, ideally C should be on most of the time with S flickering with not too high of a rate. If S is on most of the time then the mutation rates are probably too high. At first C won't come on that much but as islands of species form should stay on more (assuming crossover is enabled and set to select crossover partners by species). Adjusting the INI parameters ---------------------------- The various INI settings all have comments which should mostly explain what each setting does. Some of the settings have already been discussed in the preceding text, here are further explanations... The mutation rates are defined by deletechance, insertchance, instchance, modchance, modeAchance, dataAchance, modeBchance, dataBchance and endchance. These numbers should be fairly small, typically .05 or less or too much mutation can occur causing most of the offspring to be broken. Some settings control subselection once the mutation class has been decided, duplinechance controls the chance of a duplicate line if an insert is performed otherwise the new line is random; dataAincdec and dataBincdec controls the chance of an increment or decrement when a A or B field data change is performed, otherwise random numbers are used, in which case dataAsmall and dataBsmall control the odds of picking a small +/- offset as opposed to a large number; endincdec and end0chance apply when an end number change is triggered. The maxpmlen permits setting a different maximum warrior length for pmars, separate from the maxlen setting which sets the maximum length of evolved warriors. When maxpmlen is 0 (or not present) RedMixer uses maxlen for both evolving and for pmars, which is normal when evolving nano and tiny warriors. Coresize 8000 requires a max pmars length of 100 for benchmarks to work right but that usually results in large messy warriors so set maxpmlen to 100 and set maxlen to 25 or so to limit the size. Choosing evolving parameters is tricky, each run tends to produce different results so it takes several long runs to get a good idea of the overall characteristics of a particular set of parameters. It helps to set versionline to a unique string and save old INI files that yield good results, then later saved warriors can be matched to the INI files that produced them. Some things are counter-intuitive, higher rounds produces more accurate battles which should produce stronger code (and does later on in a run) but when first starting a new soup if the rounds are too high it inhibits the production of paper warriors. Early on the stone-type warriors evolve first and are stronger than the primitive proto-papers, there needs to be some inaccuracy at first so some of the proto-papers will get a chance to replicate and turn into better papers able to beat the stones. Another counter-intuitive effect involves crossover - usually it is desirable to cross with similar code to increase the chance of a successful blend but a certain amount of dissimilar crossover can occasionally produce unique stronger forms that would be unlikely to arise by only selecting similar code. In GA texts this is called "headless chicken crossover", the amount can be controlled by setting randomspecies to yes and adjusting the randomtagrange number. The number of species tags is randomtagrange squared so if set to 10 then there will be roughly a 1 in 100 chance a warrior with the same species tag will actually be a different species. Increasing the specieschanges number will also increase dissimilar crosses by increasing the percentage of instructions that can change with each mutation without changing the species tag. But if too high then the same-species code will become too different for effective crossing. The default nano parameters are the same settings that produced 02_08.red, which at the time of this writing is in 2nd place on the SAL nano hill. There are probably better settings but I hesitate to mess with the defaults. The nano settings don't always produce strong warriors but can. For coresize 800 I had fairly good luck with these settings... -------------- begin redmixer.ini ------------------------------------------ ; This is the settings file for RedMixer 1.1a for coresize 800 6/4/04 ; based on 1.0d3-800 settings 3/2/09 ; pmars parameters... pmars pmars ;path\name of pmars binary coresize 800 ;size of core processes 800 ;how many processes are allowed cycles 8000 ;how many cycles to run per round rounds 30 ;how many rounds to run per battle maxlen 20 ;maximum evolved warrior length maxpmlen 0 ;-l -d numbers (0=same as maxlen) doublefixed no ;if yes then do double-fixed battles ; file/start parameters... soupdir SOUP800 ;name of directory to put warriors in deletefile DeleteMe ;name of file to delete to stop tempbase rmtemp ;base name for temp files redcodeline redcode ;redcode comment line authorline anonymous ;author comment line versionline RedMixer 1.1a-800-1(30) ;strategy Evolved by line (use to track parms) minstartsize 1 ;minimum instructions for new warriors testnew no ;if yes test new warriors testwarrior test.red ;name of warrior to test new warriors against mintestscore 150 ;minimum score to pass the new warrior ; soup/display/benchmark parameters... xsize 77 ;number of warriors in X-dimension ysize 21 ;number of warriors in Y-dimension displaysoup yes ;if yes then show the soup and user interface screenlines 0 ;number of lines for listings (0=auto) colormethod 2 ;0=color by size 1=by origin 2=by species colorshift 0 ;to offset colors if needed textcolor 2 ;color used for border and stat text pmarsv pmarsv ;path\name of pmarsv program vparms -v 764 ;rounds and display parms for pmarsv listprog ;path\name of external list program benchdir TINYTEST ;directory containing test warriors benchmask *.red ;filemask for benchmark warriors benchrounds 250 ;number of rounds for benchmark battles benchfixed yes ;if yes then use fixed sequence for benchmark benchprog ;path\name of external benchmark program ; redcode strings... maintain field structure... instructions spl spl spl spl spl mov mov mov instructions mov dat dat dat jmp jmn jmz djn instructions sne seq add sub mul div mod modifiers i i i f x a b ab ba adrAmodes # $ @ * < > { } adrBmodes # $ @ * < > { } ; mutation parameters... deletechance .01 ;chance of deleting a line insertchance .01 ;chance of inserting a line duplinechance .1 ;chance of inserted line being previous instchance .01 ;chance of changing an instruction modchance .02 ;chance of changing a modifier modeAchance .02 ;chance of changing A-field mode dataAchance .04 ;chance of changing A-field data dataAincdec .4 ;chance of inc/dec A-field data dataAsmall .4 ;chance of using small A-field number modeBchance .02 ;chance of changing B-field mode dataBchance .04 ;chance of changing B-field data dataBincdec .4 ;chance of inc/dec B-field data dataBsmall .4 ;chance of using small B-field number endchance .05 ;chance of changing end number endincdec .5 ;chance of inc/dec end number end0chance .3 ;chance of using end 0 ; crossover/species parameters... crossmode 1 ;0=none 1=species 2=origin 3=size 4=any attraction yes ;if yes pick surrounding mate with most wins flipstart .7 ;chance of starting with winning warrior flipitemchance .05 ;chance of flipping per item fliplinechance .2 ;chance of flipping per line randomspecies yes ;if yes then use random numbers for species tag randomtagrange 20 ;range of each number in random species tags specieschanges 7 ;percent instruction changes for same species ; end of parameters -------------- end redmixer.ini -------------------------------------------- These settings usually produced papers in past experiments but they were too weak to be competitive on the SAL tiny hill. It is difficult and time-consuming to evolve papers for coresize 8000 and the results from a pure evolver such as RedMixer will probably never be competitive against anything stronger than warriors written by beginners or other purely-evolved warriors. The following settings are similar to those that produced Melior Lepus, an evolved paper that scores about 95 Wilkies. -------------- begin redmixer.ini ------------------------------------------ ; This is the settings file for RedMixer 1.1a for coresize 8000 6/3/09 ; Based on previous 1.0d-8K13(30) settings 4/26/09 ; pmars parameters... pmars pmars ;path\name of pmars binary coresize 8000 ;size of core processes 8000 ;how many processes are allowed cycles 80000 ;how many cycles to run per round rounds 30 ;how many rounds to run per battle maxlen 25 ;maximum evolved warrior length maxpmlen 100 ;-l -d numbers (0=same as maxlen) doublefixed no ;if yes then do double-fixed battles ; file/start parameters... soupdir SOUP8K ;name of directory to put warriors in deletefile DeleteMe ;name of file to delete to stop tempbase rmtemp ;base name for temp files redcodeline redcode-94 ;redcode comment line authorline anonymous ;author comment line versionline RedMixer 1.1a-8K1(30) ;strategy Evolved by line (use to track parms) minstartsize 1 ;minimum instructions for new warriors testnew no ;if yes test new warriors testwarrior test.red ;name of warrior to test new warriors against mintestscore 150 ;minimum score to pass the new warrior ; soup/display/benchmark parameters... xsize 77 ;number of warriors in X-dimension ysize 10 ;number of warriors in Y-dimension displaysoup yes ;if yes then show the soup and user interface screenlines 0 ;number of lines for listings (0=auto) colormethod 2 ;0=color by size 1=by origin 2=by species colorshift 0 ;to offset colors if needed textcolor 2 ;color used for border and stat text pmarsv pmarsv ;path\name of pmarsv program vparms -v 014 ;rounds and display parms for pmarsv listprog ;path\name of external list program benchdir WILKIES ;directory containing test warriors benchmask *.RED ;filemask for benchmark warriors benchrounds 100 ;number of rounds for benchmark battles benchfixed yes ;if yes then use fixed sequence for benchmark benchprog ;path\name of external benchmark program ; redcode strings... maintain field structure... instructions mov mov mov mov spl spl spl djn djn dat instructions sne seq slt jmp jmn jmz add sub mul div mod modifiers i i f x a b ab ba adrAmodes # $ $ @ < > * { } adrBmodes # $ $ @ < > * { } ; mutation parameters... deletechance .008 ;chance of deleting a line insertchance .006 ;chance of inserting a line duplinechance .4 ;chance of inserted line being previous instchance .012 ;chance of changing an instruction modchance .018 ;chance of changing a modifier modeAchance .015 ;chance of changing A-field mode dataAchance .035 ;chance of changing A-field data dataAincdec .6 ;chance of inc/dec A-field data dataAsmall .6 ;chance of using small A-field number modeBchance .015 ;chance of changing B-field mode dataBchance .035 ;chance of changing B-field data dataBincdec .4 ;chance of inc/dec B-field data dataBsmall .4 ;chance of using small B-field number endchance .05 ;chance of changing end number endincdec .5 ;chance of inc/dec end number end0chance .1 ;chance of using end 0 ; crossover/species parameters... crossmode 1 ;0=none 1=species 2=origin 3=size 4=any attraction yes ;if yes pick surrounding mate with most wins flipstart .7 ;chance of starting with winning warrior flipitemchance .01 ;chance of flipping per item fliplinechance .2 ;chance of flipping per line randomspecies yes ;if yes then use random numbers for species tag randomtagrange 20 ;range of each number in random species tags specieschanges 5 ;percent instruction changes for same species ; end of parameters -------------- end redmixer.ini -------------------------------------------- Links to further resources -------------------------- http://newton.freehostia.com/cw/redmixer.html - the RedMixer home page http://newton.freehostia.com/cwevol.pdf - a doc about evolving tiny warriors for coresize 800 (and also explains how the RedMixer evolution code works) http://newton.freehostia.com/cw/rm8k.html - evolving for coresize 8000 http://newton.freehostia.com/cw/test.zip - the (dos) program I use for benchmarking an entire soup (for now, need to make a native Linux version) http://newton.freehostia.com/cw/ - other corewar stuff, Linux pMARS binaries http://www.infionline.net/~wtnewton/corewar/evol - my old evolving page http://www.corewar.co.uk/ "Corewar - the Ultimate Programming Game" - benchmarks, software, tutorials, links to hills and other evolvers http://www.corewar.info/ "The Corewar Info Page" - Corewar happenings, tutorials, links to software, hills and other evolvers http://www.koth.org/ "Corewars - King of the Hill" - one of the oldest sites with several on-line hills, info, tuturials, links and software http://sal.math.ualberta.ca/ - the SAL on-line hills including Nano and Tiny http://users.ociw.edu/birk/COREWAR/koenigstuhl.html - the "Koenigstuhl" infinite hills, contains published warriors for every popular coresize License ------- RedMixer is Copyright 2009 Terry Newton and may be used according to the terms of the GNU Public License (any version). If COPYING[.txt] is present read it for terms and/or go to: http://www.gnu.org/licenses/licenses.html The main aspects of GPL are this program may be freely distributed provided the source code for any changes is made available and copyright(s) remain, and that this program is provided as-is and without warrantee. ---------------------------------------------------------------------------- This doc last modified June 4, 2009 Terry Newton (wtn90125@yahoo.com) ------ end redmixer_docs.txt ----------------------------------------------- **************************************************************************** ------ readme.txt for the Dos/QBasic version ------------------------------- RedMixer 1.1a(Q) for Dos/QBasic =============================== This version of RedMixer can be used on MsDos, FreeDos, Windows 95/98 and Windows XP systems. It can also be used under DosEmu/FreeDos under Linux. It runs (slowly) under DosBox and QEmu (running Win95). It likely won't run on versions of Windows that are dos-hostile such as Vista and Windows 7. Files... nanotest\ directory containing warriors from Koenigstuhl for testing COPYING.txt GNU Public License readme.txt this file redmixer.bas QBasic source for RedMixer redmixer.exe binary compiled using FirstBasic rm_docs.txt main RedMixer documentation run_rm.bat batch file that runs redmixer.bas in QBasic Requires Dos or Windows versions of pmars and pmarsv, suitable binaries are linked from http://www.koth.org/pmars/ and http://www.corewar.co.uk/pmars/ For Windows the SDL versions work the best, don't forget to get the required DLL. The SDL pmars binaries are named pmars-server and pmarsw, either rename the files to pmars and pmarsv or edit redmixer.ini to specify the names. Running interpreted requires qbasic.exe which can be found in the qbasic11.zip archive from many sources, or downloaded from MS as part of the OldDos package: http://download.microsoft.com/download/win95upg/tool_s/1.0/w95/en-us/olddos.exe This is a self-extracting file that turns into many files when run (so if doing that put in an empty directory first), or rename with a .zip extension (this requires Windows be set to show the extension which should be done anyway, it's hard to work with files if you can't see the extension) then using normal zip software extract the qbasic.exe binary and optionally the qbasic.hlp file. Setting up and running RedMixer ------------------------------- RedMixer is fairly file-intensive and if run for an extended period of time (evolving can take days to weeks) it should be run from a ram disk or at least from an external hard disk that doesn't contain anything important. Never run a file-intensive program like this from a solid-state drive such as those often found in netbooks, it will quickly wear it out. See "Setting up a ram disk" for potential solutions. RedMixer consumes 100% of the available CPU time while running, only run it on a system that doesn't care about that. The pmars and pmarsv binaries (and QBasic if used) can be copied to a path directory, copied to the RedMixer program directory, or edit the redmixer.ini file to specify the full location. Placing in a path directory is usually the most convenient method since the binaries can be run from anywhere without having to specify the directory name. A "path" directory is any of the directories listed by the PATH command (entered into a dos prompt), for best results create your own directory (usually in C:\) for putting things like qbasic, pmars/pmarsv, needed dlls, benchmark programs and test batches or anything else you might need to run as a command without specifying the full directory name. To do this, create the directory first then on dos/Win9x systems edit C:\AUTOEXEC.BAT or on WinXP edit C:\Windows\System32\autoexec.nt (or whereever autoexec.nt is located) and add the directory name after the existing PATH command using a semicolon to separate. For example if the new path directory is C:\path then something like... PATH C:\Windows;C:\Windows\System32;other entries;C:\path Make a work directory on the ramdisk or whereever the program is to be run from, and copy redmixer.exe (or redmaker.bas and run_rm.bat if running in qbasic), redmixer.ini and the nanotest directory to the work directory. If the binaries aren't in a path directory edit redmixer.ini to specify the locations or copy the binaries to the work directory. If the binaries aren't named pmars.exe and pmarsv.exe either rename them or edit redmixer.ini to specify the proper names. If evolving for a different coresize then obtain an appropriate benchmark set (such as TinyBM04 or Wilkies) and copy the benchmark set directory to the work directory. From the work directory run redmixer.exe to start the program, or if running in QBasic run the run_rm.bat batch file to start the program. If the screen flickers while evolving when running redmixer.exe, run from a batch file such as... :: save as say "run_redmixer.bat" @echo off mode con lines=25 redmixer.exe ...or edit and reconfigure run_rm.bat to do the same thing. The last time I tested on my Windows XP system with SP3 there was no flicker when just running redmixer.exe but in previous tests I had to use a batch containing mode to keep the screen from constantly resizing itself while evolving. Using larger soup displays -------------------------- By default RedMixer uses a 21x77 soup (1617 warriors) for a normal 25x80 display. The redmixer.exe version only supports a 25 line display but if running in QBasic a larger soup can be used if desired, up to 46x77 or 3542 warriors. To configure edit run_rm.bat and change the number after lines= (typically the choices are 25, 43 or 50) and edit redmixer.ini and change the ysize setting to be 4 less than the number of lines, for example for a 50 line display set to 46, or for a 43 line display set to 39. When using a larger soup typically dos versions of pmarsv cannot be used since they reset the screen back to 25 lines. Should be fine with the SDL version (pmarsw) running under Windows. Larger soups require more time to evolve and benchmark, but provide more genetic diversity and theoretically can produce better results. However, in my tests I have not observed any better results than from using a 21x77 soup. Setting up a ram disk --------------------- For my Windows XP system I use Microsoft's "sample" ramdrive.sys from: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q257405&SD=MSKB& After installing the size can be adjusted through regedit by changing the DiskSize item under: HKLM\SYSTEM\CurrentControlSet\Services\Ramdisk\Parmeters The maximum supported size seems to be around 27 megabytes, enough for several soup configurations. NOTE!!! According to the MS documentation this solution is incompatible with NTFS and disables system restore!!! My XP installation uses Fat32 and I don't use system restore so it works fine on my system but do not use ramdrive.sys on a stock Windows XP system. Googling "Windows ramdisk" shows other ram disk programs for Windows, including "A R RAM Disk" from http://www.arsoft-online.com/ (under downloads). I briefly tried this program on Windows XP installed in VirtualBox (not on my "real" install since I already have ramdrive.sys installed there) and it seems to work fine, after installing set to provide about 25 megabytes and reboot to enable. After rebooting a new ramdisk icon should appear under My Computer, make a shortcut to it on the desktop for easy access. Saving and restoring the ramdisk... Everything on a ram disk goes away when the power is removed or the system is rebooted, so after evolving make sure to copy the work directory back to a real hard disk. The saved work directory can be copied back to the ram disk to for further evolving. It's not difficult to do this manually but using batch files the process can be automated so you just have to double-click a "save ramdisk" icon to save and a "restore ramdisk" icon to restore. The following batch files are copied from my system and provided as examples, edit them to work with your particular ram disk setup. Note... these files are presented as-is and without warranty (like everything else in this package). These are the scripts I use for my systems at the time of this writing, but they contain system-specific commands and should be researched and modified as needed to ensure compatibility with your system. These are for the ramdrive.sys method, for other ram disk methods edit the string in the find commands to match the drive label (to find out in a dos prompt enter dir z: or whatever the ramdisk drive letter is), and change the set rd=r: lines to correspond with the ramdisk drive letter. The save directory is C:\Ramdisk - edit to use a different save directory. Note that if this directory already exists it will be removed. ------- cut, file "saverd.bat" -------------------------------------- @echo off ::winxp only set rd=r: dir /-p %rd%\ | find "MS-RAMDRIVE" >nul if not errorlevel 1 goto check4files echo Not a ramdrive pause goto end :check4files if exist %rd%\*.* goto doit echo No root file(s), not saving pause goto end :doit if exist C:\Ramdisk\*.* rd /s /q C:\RamDisk md C:\RamDisk xcopy %rd%\*.* C:\RamDisk /e /h >nul :end ------- stop cutting ------------------------------------------------ ------- cut, file "loadrd.bat" -------------------------------------- @echo off set rd=r: dir /-p %rd%\ | find "MS-RAMDRIVE" >nul cls if errorlevel 1 echo Not a ramdrive if errorlevel 1 goto end if not exist %rd%\*.* goto doit echo Ramdisk already loaded pause goto end :doit xcopy C:\RamDisk\*.* %rd%\ /e /h >nul cls :end ------- stop cutting ------------------------------------------------ New Features in RedMixer 1.1a ----------------------------- The following new features have been added to the INI file... maxpmlen If specified permits using a different length for pmars so that shorter warriors can be evolved without disturbing the battle environment or benchmarking - this is useful for coresize 8000 which normally uses a max length of 100, too messy for evolving. screenlines If specified permits setting the number of lines available for listing warriors, benchmarks, etc. Previously was based partially on soup size (and still is if omitted or set to 0), this makes it easier to set up for smaller terminal views such as on a netbook. benchmask Linux is case-sensitive, and many benchmark sets are named with all-capitol filenames (coming from a dos background) or have a different extension. Default is *.red but can be *.RED *.RC etc. These are all optional, existing INI files don't need to be changed. Other issues have been addressed, including... Soup coloring now uses the correct formula (not that there's much difference). TIMER code for timing the startup text has been modified to work under Linux. All number prints now use STR$(n) for compatibility with the Windows FreeBasic. Permits using Esc to stop the evolver when used with a server version of pmars. The benchmark code has been rewritten to minimize OS-specific techniques. A bit of code was added to better randomize the random-number generator. Package history --------------- June 4, 2009 initial Redmixer 1.1a Dos/QBasic package based on the 09.06.01 version of RedMixer. ---------------------------------------------------------------------------- This doc last modified June 4, 2009 Terry Newton (wtn90125@yahoo.com) ------ end readme.txt for the Dos/QBasic version --------------------------- **************************************************************************** ------ readme_linux.txt ---------------------------------------------------- RedMixer 1.1a(L) 09.06.01 - x86 Linux Version ============================================= This doc includes platform-specific information about the Linux version, refer to redmixer_doc.txt for general RedMixer information. Files... nanotest/ benchmark warriors taken from the Koenigstuhl Nano Hill COPYING GNU Public License readme_linux.txt this file redmixer.ini INI file for RedMixer redmixer_docs.txt documentation for the RedMixer program redmixer_linux x86 Linux binary for RedMixer redmixer_linux.bas FreeBasic source code for RedMixer run_redmixer.sh shell script for running RedMixer in a terminal Requires Linux binaries for pmars and pmarsv, the binaries I use are at: http://newton.freehostia.com/cw/pmars092N.tar.gz (source code included) These include a simple mod to prevent interpreting "\" as a continuation character when it appears in a comment, sometimes used in warriors to point out blocks of code. Versions of pMARS source code that can be compiled to produce binaries are linked from http://www.koth.org/pmars/ and http://www.corewar.co.uk/pmars/ These are fairly easy to compile for Linux, edit the Makefile to specify options (both pmars and pmarsv are made from the same source). The SDL version also compiles for Linux. Details for applying the continuation mod are at: http://newton.freehostia.com/cw/pm092mod.txt If using a stock version of pmars check benchmark warriors (like PaperOne) and make sure that there is a space after all \ characters, otherwise the line after the \ will be treated as a comment and incorrect scores will be produced. The redmixer_linux binary contains customized FreeBasic library code, see "Source code and library notes" below for a link to the modified source. Setting up and running the Linux version of RedMixer ---------------------------------------------------- RedMixer is fairly file-intensive and if run for an extended period of time (evolving can take days to weeks) it should be run from a ram disk or at least from an external hard disk that doesn't contain anything important. Never run a file-intensive program like this from a solid-state drive such as those often found in netbooks, it will quickly wear it out. See "Setting up a ram disk" for potential solutions. RedMixer consumes 100% of the available CPU time while running, only run it on a system that doesn't care about that. To run the Linux RedMixer as-is the pmars and pmarsv binaries should be put in /usr/local/bin (or another path directory) and named "pmars" and "pmarsv", or symlinks made with those names to the actual binaries. Alternatively the binaries can be placed anywhere and the pmars and pmarsv entries in the redmixer.ini file adjusted to include the full path/name (if placed in the RedMixer program directory then include ./ in front of the filenames). The run_redmixer.sh script is set to run RedMixer in an xterm terminal, edit to use another terminal (konsole and gnome-terminal examples included). The script cannot be used as-is from a directory containing spaces, if you just have to do that an alternate cd is included in the script comments. To set up for a run, create a directory whereever it is to be run from, and copy redmixer_linux, redmixer.ini, run_redmixer.sh and the benchmark directory to the work directory. Run run_redmixer.sh to start. Alternatively, open a terminal in the program directory and enter ./redmixer_linux to run. Note that on my Asus with Xandros if RedMixer is run from a terminal, after exiting the program the terminal no longer responds to keyboard entry. All FreeBasic-compiled binaries do that on that machine, probably something to do with the customized Asus libraries. Running from a script eliminates the issue. RedMixer runs fine from an open terminal on my Ubuntu system. Setting up a ram disk --------------------- As with all material in this package, the following scripts are presented as-is and without warranty. Please check carefully to ensure compatibility with your system. It is assumed that the user is familiar with normal Linux conventions such as making sure the script text is in unix-format and making executable. Edit the scripts as needed or use for ideas to make new scripts. Alternative methods are available by searching for Linux ram disk in a search engine, this was the first hit: http://www.vanemery.com/Linux/Ramdisk/ramdisk.html For my Ubuntu Linux system to make a ram disk I presently use these scripts: ------- cut, file MakeRamdisk --------------------------------------- #!/bin/bash # Create a ramdisk under Ubuntu - take two (2/21/09) # gksudo can be flakey and worse with a sequence of [gk]sudo's # if cancelled or the wrong pw entered and then the correct pw is # entered it can do steps without doing the previous steps requiring # manual intervention such as having to delete /media/ramdisk to fix. # This version uses Xdialog to prompt, should be Ubuntu stock. # Small bug... if a sudo password was previously entered correctly # and sudo's no-prompt mode is still active, then it doesn't matter # what password is entered... but good enough.. better than it was. rddevice=/dev/ram14 rdmountpoint=/media/ramdisk rdworkdir=/media/ramdisk/work if [ ! -e $rdworkdir ]; then # only run if ramdisk workdir doesn't exist # use Xdialog to prompt for password and assign it to pword variable... pword=`Xdialog --stdout --password --inputbox \ "Enter your password to create the ramdisk..." 10 40` if [ ! "$pword" == "" ]; then # if a password was entered then if [ ! -e $rdmountpoint ]; then # if mountpoint doesn't exist echo "$pword" | sudo -S mkdir $rdmountpoint # create it fi echo "$pword" | sudo -S mke2fs -m 0 $rddevice # format the ramdisk echo "$pword" | sudo -S mount $rddevice $rdmountpoint # mount it echo "$pword" | sudo -S mkdir $rdworkdir # create a workdir echo "$pword" | sudo -S chmod 777 $rdworkdir # make so anyone can use it fi fi ------- stop cutting ------------------------------------------------ ------- cut, file UnmountRamdisk ------------------------------------ #!/bin/bash gksudo umount /media/ramdisk ------- stop cutting ------------------------------------------------ The main issue with using the above /dev/ram method of making a ramdisk is the size of the ramdisk is fixed in the kernel and not easily changed, on my Ubuntu system it gives me 64 megabytes, plenty, but on my Eee PC I only get about 3 megabytes, not big enough. For my Eee PC 701SD running Xandros I use the following ramdisk scripts: ------- cut, file mkrd.sh ------------------------------------------- #!/bin/bash if [ ! -e ~/rd/work ];then echo "Creating 25 meg (max) ramdisk with ~/rd/work directory" if [ ! -e ~/rd ];then mkdir ~/rd fi sudo mount -t ramfs none ~/rd -o maxsize=25000 && sudo mkdir ~/rd/work if [ -e ~/rd/work ];then sudo chmod 777 ~/rd/work sleep 2 else echo "Operation failed" echo "Press enter..." read nothing fi else echo "~/rd/work directory already exists" echo "Press enter..." read nothing fi ------- stop cutting ------------------------------------------------ ------- cut, file unmountrd.sh -------------------------------------- #!/bin/bash echo "" echo "This will remove the ram disk losing all contents" echo "Press enter to continue or control-c or close now" read nothing echo "Unmounting..." sudo umount ~/rd sleep 2 ------- stop cutting ------------------------------------------------ Under KDE shortcuts can be set to run in Konsole so no problems seeing the text without having to rig up extra scripts etc. One slightly annoying feature of the "ramfs" method is free space is always reported as 0 so the GUI complains when copying files to the ram disk, fortunately it has an ignore button and copies anyway. Gnome won't work at all with this method. It should be obvious but everything on a ram disk goes away if power is removed or the system is rebooted, be sure to save the work directory to a real hard disk when done. I have not bothered with making scripts to do this automatically. Source code and library notes ----------------------------- The redmixer_linux binary contains modified library code, source code and recompiled library is at: http://newton.freehostia.com/fb020shellmod.tar.gz Details of the library mod... The stock version of FreeBasic for Linux has an issue with the Shell command, after about a thousand shells (to run pmars or anything else) it fails with a "too many open files" error (issued by the OS). The reason appears to be that it closes then opens /dev/tty with each shell only fails to release the handle so the OS runs out of file handles (based on the existing bug report). To work around this problem I edited the src/rtlib/unix/libfb_sys_shell.c and commented the calls to fb_hExitConsole and fb_hInitConsole, made a similar change for the Exec in src/rtlib/unix/libfb_sys_exec.c, then recompiled the libfb.a library. This might not be the ideal solution but it seems to work fine on my systems running the kinds of shells I need to do. If there are any issues let me know. Compiling the RedMixer source for Linux... The Linux FreeBasic compiler is required to compile RedMixer for Linux, get it from: http://www.freebasic.net/ I recommend the "standalone" version since it can be put anywhere and requires practically no installation other than optionally making a symlink in /usr/local/bin to fbc to make it easier to run. RedMixer requires a perfectly functioning shell command, it uses it hundreds of thousands to millions of times over the course of a run. Unless the shell issue has been addressed in a new version of FreeBasic, get the modified library and replace libfb.a with the modified version. This file is in lib/linux under the main FreeBasic directory, rename the stock libfb.a in case needed again and copy the new library in its place. To compile the redmixer_linux.bas source, open a terminal and enter... fbc -exx -lang qb redmixer_linux.bas That assumes you made a symlink to fbc in a path dir, otherwise enter /path/to/freebasic/fbc -exx -lang qb redmixer_linux.bas replacing the path to where the fbc program is located. Converting the RedMixer source to other platforms... To convert to Windows FreeBasic change pathsymbol$ from "/" to "\". To convert to Dos QBasic-compatible source change pathsymbol$ from "/" to "\" and replace 'RESUME with RESUME throughout the source. Optionally if using an old dos version of pmars that enters the debugger if any key is pressed, set breakavailable to 1 and set quitavailable to 0. The existing settings are for server versions of pmars. New Features in RedMixer 1.1a ----------------------------- The following new features have been added to the INI file... maxpmlen If specified permits using a different length for pmars so that shorter warriors can be evolved without disturbing the battle environment or benchmarking - this is useful for coresize 8000 which normally uses a max length of 100, too messy for evolving. screenlines If specified permits setting the number of lines available for listing warriors, benchmarks, etc. Previously was based partially on soup size (and still is if omitted or set to 0), this makes it easier to set up for smaller terminal views such as on a netbook. benchmask Linux is case-sensitive, and many benchmark sets are named with all-capitol filenames (coming from a dos background) or have a different extension. Default is *.red but can be *.RED *.RC etc. These are all optional, existing INI files don't need to be changed. Other issues have been addressed, including... Soup coloring now uses the correct formula (not that there's much difference). TIMER code for timing the startup text has been modified to work under Linux. All number prints now use STR$(n) for compatibility with the Windows FreeBasic. Permits using Esc to stop the evolver when used with a server version of pmars. The benchmark code has been rewritten to minimize OS-specific techniques. A bit of code was added to better randomize the random-number generator. Package history --------------- June 4, 2009 initial Redmixer 1.1a Linux package based on the 09.06.01 version of RedMixer. ---------------------------------------------------------------------------- This doc last modified June 4, 2009 Terry Newton (wtn90125@yahoo.com) ------ end readme_linux.txt ------------------------------------------------