Notes on TurboLife version 0.50 (12/25/86) (PLEASE READ THESE!): To contact me ============= Direct all problem reports, suggestions, complaints, cash donations etc. to Bela Lubkin via USnail, Ma Bell, CompuServe or local BBS. My various addresses and numbers are: USnail: Bela Lubkin 406 Murray Ave. Aptos, CA 95003 Ma Bell: (408) 662-0535 (voice) CompuServe: 73047,1112 (EasyPlex) Local BBS (Santa Cruz, CA): "Filbo" on Pyrzqxgl, (408) 336-3134 (Zend mail) PLEASE CONTACT ME IF YOU FIND A BUG OR WANT TO SUGGEST A FEATURE!!!! Apathy sucks!!! What has changed since version 0.39 =================================== Most importantly, I converted the innermost loop of the generation routine from Turbo Pascal to assembly language. The first step was a straightforward port to assembly language, making use of registers as much as possible. This resulted in a 3-to-1 speedup. Next, I modified the algorithm in certain ways, and "bummed" the code as much as possible. This brought the speedup to about 4-to-1. Finally, I ran into a program called FASTLIFE on a local BBS. It had radically different performance characteristics: it was much faster for densely packed action, but much slower for sparse areas. I spoke to the author, Dan McMullen, and got some extremely useful ideas. I had been dealing with a bit at a time, in registers; I now deal with a byte at a time, as much as possible. This brings the total speedup to 5.5-to-1 for the simplest figures, and an amazing 16-to-1 for densely packed action. My benchmark suite, which has a great deal of variety in its tests, shows an overall speedup of 6.45 times. Mileage may vary . My heartfelt thanks to Dan! Other changes include: o Directory window: when saving or loading a file, if you give a wildcard filename such as *.LIF, a directory window pops up and you can select the desired file interactively. The directory window is fully aware of the DOS 2.0 directory structure, and will let you walk about different directories. o Overwrite protection: you are asked before TurboLife will overwrite an existing file. o The Undo command will undo one Go, single step or Load command. If Undo does not appear on your main menu, you don't have enough memory for it; you will need up to 32K more than you need to be able to run TurboLife at all, depending on your video board. Total memory needs range from about 105K on a CGA (Undo disabled) to about 220K on a VEGA Deluxe in 640x480 resolution (Undo enabled). o Mutations: when mutations are enabled, a single, randomly chosen pixel may be changed in any particular generation. How often this occurs is settable, anywhere from every generation to once per thousand generations. o Support for more graphics hardware: EGA with mono or ECD monitor (640x350) Olivetti M24/AT&T 6300/Xerox 6030 (640x400) Toshiba T3100 (640x400) (-experimental-) Video-7 VEGA Deluxe/QuadRAM QuadEGA Prosync (640x480) (-experimental-) Any reports on the Toshiba T3100 and the VEGA/QuadRAM cards will be appreciated. o On graphics hardware with several resolutions available, you can choose which resolution to use. This may be useful for looking at saved figures which make use of wrap effects. FACTORY.LIF is an example of such a figure: it is interesting on any board, but particularly amazing at a resolution of 640x200. o When a file is loaded which was saved on lower resolution graphics hardware, a check is made to see whether any features of the saved figure were meant to wrap around the edges of the screen. If the first and last lines of the saved image are found to be identical, the additional lines of the screen are filled with copies of that same line. The same is done for the first and last columns of the saved figure. This means that, for instance, "great circle" images saved on the CGA can be loaded on an EGA, at 640x350 resolution, without losing their continuity. o More stringent checking is done when files are loaded to ensure that only valid files are loaded. (In particular, using the wrong function to load a .RUL or .LIF file will no longer appear to work while actually failing). o The rule "a dead pixel with no neighbors springs to life" may now be declared. o When changing rules, the entire screen is considered under the new rules, not just the points that had been active under the old rules. o File load/save status messages now stay on screen for 5 seconds or until a key is pressed. These delays now work properly on the Tandy 2000. o Save files are now 1/2 as large as before. o WordStar key sequences are supported everywhere that keypad keys work; keypad keys do not require NumLock to be turned off, except the "5" key, used in the Rule editor. Why IBM chose to make that key generate no data is beyond me... o Many bugs have been fixed. o Probably more that I forget. It's been a year! "Flicker between the graphics and text areas" ============================================= If you see a rapidly flickering point just to the right of the playing field (to the left of the menu and other text), good! You're supposed to. While the generation algorithm is thinking about a single line of the screen, it turns on a point at the right of that line to show its progress. This was put in the program when it was more than 20 times as slow as it is now, and I was using an 8088 machine with 640x400 resolution, to boot. While waiting up to a minute for a generation to complete, it was good to have some indication that the program hadn't crashed yet. I've left the indicator in because it acts as sort of a "heartbeat meter", giving you an at-a-glance idea of how fast the program is moving at the time. You can gain some insight into how the program works by observing the indicator while playing with complicated figures. For instance, draw a line all the way across the screen horizontally. Turn wrap on, Go, and watch the indicator. What's in the distribution ARC file =================================== The distribution ARC file contains this file (README.050), LIFE050.COM, and DEMOS.ARC (a nested ARC file). DEMOS.ARC expands to about 175K, so be prepared. Inside DEMOS.ARC are a number of rule sets and figures; unless otherwise noted, all rule sets and figures, and their names, are my own. The rule sets are as follows: LIFE.RUL - standard Life rules (John Horton Conway) 3-4LIFE.RUL - 3-4 Life, as defined in "The Recursive Universe" (TRU) FREDKIN.RUL - Fredkin's Game (TRU). Anything you enter is duplicated CRYSTALS.RUL - Homebrewed set of rules that make pretty crystals A.RUL - Slightly modified normal Life, has some interesting patterns FIRE.RUL - interesting rules that generate fire-like patterns -- try a vertical or horizontal bar, for instance LACE.RUL - makes lace-like patterns DOWN.RUL - inspired by Graeme McRae. Any figure simply moves down the screen DOWNGROW.RUL - modified DOWN.RUL, sends interesting streamers down the screen OOZE1.RUL through OOZE4.RUL - four variations on a theme: rules that... ooze! The figures are as follows: 3WAY.LIF - An engineered 3 way collision R5OMINO.LIF - The famous R Pentomino (TRU). 1103 generations to completion OSCILLAE.LIF - An assortment of oscillators from TRU. Left to right, they are: Toad, Beacon, Clock, Pulsar, Figure 8, Pentadecathlon, Barber Pole, Flip-flop, Galaxy, Tumbler, Clock II, stabilized Shuttle, B Heptomino Shuttle, Glider, Lightweight, Middleweight and Heavyweight spaceships FLOTILLA.LIF - An overweight spaceship with flotilla escort (TRU) ACORN.LIF - Another long messy figure, this one goes for 5206 generations before stabilizing (TRU) GLIDRGUN.LIF - A glider gun (TRU). Includes an Eater (TRU) to consume the gun's output MAKEGGUN.LIF - "Thirteen gliders collide to form a glider gun" (TRU) NEWGUN.LIF - "New gun", a different flavor of glider gun. (TRU) MACHNGUN.LIF - A "machine gun" made out of multiple concatenated glider guns FACTORY.LIF - A glider factory made out of cooperating glider guns PUFTRAIN.LIF - Puffer train. Given enough screen space, this eventually stabilizes (becomes periodic), generating an ever- lengthening tail of debris. Stabilization occurs at generation 5533, but there is not enough screen space on any TurboLife-supported video board to see more than a hint of the stabilization. (2800 pixels horizontal would be necessary to carry it out to full stabilization). (TRU) OSCILLAE.3-4 - A bunch of oscillators from 3-4 Life (load the 3-4 Life rules first -- these won't do much under normal Life rules). Around the outside, clockwise, ignoring duplicates, are: Ward Christensen's object (I'll let him name it!), Broken T (TRU), Bleeper (TRU), Frog, T (TRU), and Y. On the next row in are: 3-4 Spaceship (TRU), 3-4 Clock (TRU), Shaker, Broken 3-4 Clock. In the center are a Bullfrog and a Twombler YOW.CRY - an interesting initial pattern for the rule set "Crystals". It is saved with mutations enabled, set at a low rate; you may also want to run it with mutations disabled entirely T-BARS.3-4 - a very interesting scenario for 3-4 Life MOREBARS.3-4 - similar to T-BARS.3-4 CREATION.OOZ - let there be ooze! Adding support for additional video boards ========================================== I am continually on the lookout for more video boards to add support for. If you have a video board which does something beyond the standard IBM 640x200 mode, give me information on it and I'll try to support it. Each added board costs me something like 100 bytes of code, so I am not even going to start worrying about it yet. What I need to know: I access the video memory of the board directly. The memory layout must be similar to the CGA's in that each scan line must consist of contiguous bytes, each byte containing 8 pixels, the high bit being the leftmost displayed bit. Therefore, in order to plot, all I need to know is the formula for the address of a scan line, given its vertical coordinate. Thus for the CGA, BaseAddress(Y)=2000h*(Y AND 1) + 80*(Y DIV 2). Other than that, I must have the following information: the resolution; how to turn this mode on; how to turn it off; how to generate text, if not through standard BIOS writes; and most importantly, how to detect that a machine has this capability. I may end up forced to add a manual install-for-video-board routine to the program, but I will not if I can possibly help it. Additional information that would be useful: how to modify the foreground and background colors, if applicable. Note that in all cases I'm interested in the highest possible resolution of the card, and that in fact my code cannot support multicolor modes like the CGA's 320x200; it can support multiplane setups like EGA mono, but only by ignoring all but one plane. Thus it may be necessary to diddle palette registers to make a single plane look good. Sigma SR400! ============ IN PARTICULAR, I am all ready to support the Sigma SR400 board, with 640x400 resolution, but I do not know how to detect this board at runtime. The detection method must be unambiguous. If you have an SR400, or have any information on it, please let me know! Thanks ====== I want to thank John Conway for inventing Life; Piers Anthony and Martin Gardner for making me aware of it; Dan McMullen for helping me refine my generation algorithms; Kim Kokkonnen, Neil J. Rubenking, Doug Hogarth, Dave Hoagland, Don Watkins, Joan Friedman, Grame McRae, Joe Kyle and many others for helping me test the latest versions; and most especially the dozens of people who have made comments and suggestions about the program even when I wasn't actively soliciting responses. Believe me, I >like< getting suggestions and even bug reports. Easy suggestions may get implemented right away; bug reports will be dealt with as quickly as possible. Even if I don't take you up on your suggestion, I appreciate knowing that you're out there and have enjoyed using my program. By the way, one suggestion that I am not going to take up is that of using color as another dimension of the program. I may eventually support the ability to set the foreground and background colors of the playing screen, for esthetics; I will not support color as an active part of the game. It slows things down, and the uses I've seen for color in Life games have seemed contrived at best. Any input appreciated. - Bela Lubkin December 25, 1986