Eee PC Stuff

On 11/25/08 I took delivery of a Galaxy Black Asus Eee PC model 701SD mini-laptop, an amazing little machine with a 7" 800x480 display, 512 megs ram, an 8 gig solid-state disk (SSD) drive, a MMC SD memory card slot and 3 USB ports. Cost with tax was about $300 from Target online.

My 701SD came with a customized version of Xandros GNU/Linux, with a highly simplified GUI that provides easy access to the installed applications using tabbed screens. I like being able to make my own icons for my stuff, and I don't like having to launch a file manager to run anything that wasn't officially installed, so "easy mode" lasted about a day before it got hacked to provide a more normal desktop environment. It took about 3 weeks to hammer it into shape, an ongoing process, but I now have a very portable computer for doing my thing when away from my main Ubuntu system.

Here's a screen dump of my desktop as of 12/15/08 (resized so it's a bit blurry)...

I use a mix of modern and old stuff... surfing the web, email and music is nice but I also need a desktop I can plop down shortcuts to frequently used files and applications, and like to run older-style software like QBasic under FreeDos and '70's-style operating systems under the SimH HP2100 simulator.

Here's an old "The Need For Speed" demo running in DosEmu/Freedos...

Often I prefer less graphical games...

Often I need to type in trivial programs to compute various things, so I've got a few BASIC interpreters. QBasic under FreeDos lets me enter and save programs, or enter variables and formulas in immediate mode. ISbas_ecalc is a HTML/Javascript BASIC interpreter which serves a similar function for simpler things, I have it preloaded with computations I frequently use for electronics but I can stop it and enter formulas in immediate mode if I need to calculate something else (numbers must begin with a digit - 0.123, not .123). At the moment the most convenient BASIC environment I have for strictly numeric computations is MSU BASIC running on a simulated HP-IPL/OS disk system, I simply double-click the HP-IPL/OS icon, press A and type in a program, or press other keys to load saved programs. I also have another HP minicomputer BASIC called TSB-E (Time Share BASIC, version E is simple and only requires a single simulated CPU), for more "advanced" uses I've got FORTRAN running on a couple versions of RTE. These old HP OS's are handy for running antique games such as various versions of Trek, Adventure and Mystery Mansion. One of my favorite games is Reversi, got a few versions I wrote myself in BASIC and FORTRAN II.

Yea, I'm into old software... I first got into computers in the early '80's way before all the fancy GUI stuff came about, although I appreciate the modern things computers can do these days I also like to keep older stuff around. At first it was difficult to "do my thing" on the 701SD, "easy mode" doesn't even let me make my own icons except for programs installed using the provided software, OK for casual users but not so useful for what I want to do. This is an account, for whatever it's worth, of how I hacked the default 701SD Xandros OS into submission.

Enabling a normal desktop...

The first task was to get the thing to boot into a normal KDE desktop so I could make the icons I want. There is a lot of information about how to do this at the Eee User Wiki and Eee User Forum, but the 701SD is slightly different and version 1.6 of the default OS kind of discourages doing this, eventually leading to have to remove incompatible components (like much of the easy mode OS). I made the "mistake" of updating my system when I first got my 701SD, probably leading to some of the problems I encountered, now updates from Asus have been disabled to prevent further problems. These steps were performed before 12/1/08, and after updating to version 1.6 of the OS.

The procedure calls for installing the "kicker" and "ksmserver" packages, replacing a couple of scripts called "" and "" with customized versions, then selecting advanced mode to be the default in easy mode's Personalize app. But the documented procedure wouldn't work, the required packages were not in the default repository. I found the needed .deb files in another area of the repository under downloaded the latest versions (with -1 extensions if that matters, two of each were available so used version 3.4.2-201-1 of each, no idea if this was the correct choice) and installed the deb's manually by right-clicking them and choosing install (kicker first). After doing that the rest of the wiki procedure worked.

Adding Software

The 701SD is essentially a miniature PC with a (up to) 900mhz Celeron M processor. The Asus version of Xandros is specific in places to support the hardware but is still "just" Linux, the usual standard-issue libraries are installed so it can run simple x86 Linux-compatible binaries without much "installing" beyond simply transferring the required files and creating scripts to set up the run environment. All my SimH hp2100 simulations ran fine in Konsole after copying them to a directory in my home/user directory. I already had scripts in the sims directory which run hp2100 with the appropriate startup script, edited these to run hp2100 from the current dir (i.e: ./hp2100 filename.sim) and added startup instructions to remind me of what to do. After copying the bash scripts and unzipping the hp2100 binary I had to right-click, properties and check the execute bit as usual with Linux. In my home directory I added a script for each sim containing lines such as...

cd ~/sims
konsole --keytab vt420pc -e

...where ~/sims is where my hp2100 sims are and is the name of the startup shell script which ultimately does ./hp2100 filename.sim to run the simulated system. The --keytab vt420pc selects a key table which uses an ascii-8 backspace, expected by most antique operating systems. After marking the home dir script executable a shortcut can be made on the desktop for it, double-click and antique OS runs. This same general procedure should work for any SimH-supported system if compiled on another Linux system to generate the binary. To compile SimH natively requires installing gcc and libc6-dev (or the build-essential package), at first this was tricky due to dependency errors but ended up having a simple solution (see below).

Generally Linux software is installed using a package manager which automatically installs or updates other packages required by the package being installed. The default Asus version of Xandros uses the popular "apt" system with the Synaptic GUI front end, same as Ubuntu and many other Linux distributions. The Asus repositories contain very little beyond what was already installed in my 701SD, however Asus Xandros is derived from Debian stable (aka "etch") and with care can run many of the thousands of apps available from the Debian repositories. The important thing is /etc/apt/preferences must be edited to give preference to the Asus packages to prevent them from being overwritten by newer but incompatible packages from other repositories, see the Eee User Wiki for instructions. Better to use sudo nano path/filename to edit system files, at first I was using sudo kwrite file but this caused error messages and might have caused other problems (perhaps with associations). Major dependency problems can result from mixing repositories... after installing something or after an update (didn't determine which) I started getting apt errors complaining that libgnome2-perl wasn't installed and that it couldn't reconfigure asus-categories. Installed libgnome2-perl (from Debian) to get rid of the first error but the only to resolve the reconfigure error was to remove asus-categories which also removed asus-launcher (and easy mode, just as well, messed up my icons when I used it). The only thing I used from easy mode was the touch screen setup, this can be done from the full desktop by running gsynaptics from the command line or a menu item. There are many updated items in the Asus repositories which are incompatible with some of the Debian apps I've installed (including FireFox 3 and Flash 10), to eliminate the possibility of updating something and breaking my system I removed asus-updatesapplet and renamed UpdateService in the /opt/xandros/bin directory to keep it from loading.

The Asus repositories plus Debian stable let me install most of the things I wanted, but was getting dependency errors when I tried to install libc6-dev or build-essential (needed to compile things from source). As in it either refused or wanted to uninstall vital parts of the system. The trick (thanks to a post I read in the user forum) was to disable all repositories Except for Debian etch, then it replaced libc6 with a similar version from Debian and all the components installed without error. SimH compiled properly by entering "make" in its source directory. I am unclear as to if I should just leave it set to just Debian or if I should reenable the default repositories? Probably the latter. The main thing to watch out for is if it marks vital packages for removal then back out and don't do it. The default software was designed for consumers who want to surf the web and run typical productivity software, it was not necessarily designed to run compilers or for that matter run anything outside of the supplied apps (some like me just do it anyway). From a support perspective I can understand this approach. However, unlike other netbooks the 701SD is not "locked" in any way, offending packages can be removed, and if desired the whole thing replaced with an entirely different operating system. Once tamed the default OS works well and for some things is faster and more stable than my main Ubuntu desktop system. If anything it's a chance to learn how apt really works, with rewards for successful hacking.

Here's a partial list of Debian stable apps I've installed and use on my 701SD...

VLC media player - works fine except for audio visualizations
DosEmu(1.2)/FreeDos and fonts - QBasic, Dos games, full-screen or windowed
Frotz for playing Infocom and other games from "Z" files
Telnet for accessing old HP mini sims such as TimeShare BASIC and RTE-6
Iceape Navigator with composer for editing HTML files (using it now)
Curator for turning a collection of graphics files into an editable website
gFTP for uploading and downloading files to and from my websites
Audacity and liblame0 for recording audio and exporting to MP3
gcc/build-essential for compiling (some) applications from source
(compiling some apps requires -dev packages which might be tricky to obtain)

Eliminating Unnecessary Disk Writes

The 701SD uses a solid state disk drive which has a limited number of writes to any one location. Although algorithms spread the writes around to avoid overusing a single location, still it's desirable to minimize writes to disk. The biggest offender was the .xsession-errors file which got unreadable garbage written to it every time something was done using the GUI. A very handy command I learned about:

sudo find / -xdev -mmin 1

This lists files which have been accessed in the last minute. To redirect the offending .xsession-errors writes to the bit-bucket and keep them from writing to disk I opened a console in the /home/user directory and entered:

rm .xsession-errors
ln -s /dev/null .xsession-errors

That took care of that. There was still a spike in processor usage every few seconds, that ended up being the ethernet being polled so used the network applet and told it to manually connect to ethernet only when I tell it to.

Linux by default updates the last access time in the directory every time a file is read, in effect wearing out the disk just by reading it. To keep that from happening (I hope) I did sudo cp /etc/fstab /etc/fstab_orig (to make a backup) and then sudo nano /etc/fstab and positioned the cursor right after options (nano isn't that smooth when editing long lines, S at the beginning or end of a line indicates the line is split and there's more) and changed options to options,noatime then saved (using control-O then control-X).

A handy utility for measuring write frequency is iostat, available by installing the sysstat package from Debian. This little program shows how much data has been read and written to the disk since bootup and can be used to roughly estimate the lifetime of the flash disk. For example...

/home/user> iostat -d
Linux (asus-71950145) 12/26/2008

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.80 23.75 2.64 469652 52136

/home/user> df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 4972972 3280812 1439540 70% /

This is after light use, much of it idling, but for example. Each block is 512 bytes, where as a flash block is 4096 bytes (I presume [but I may presume incorrectly - more like 128K! ouch!]). This is highly simplified since a flash block is completely rewritten even if only one byte changes, but say the average write size was 512 bytes and all widely separated, then the Blk_wrtn/s figure can be used directly. Flash memory uses wear leveling, which depends on there being free space to use to spread writes to avoid wearing out a single location. The following formula can be used to roughly estimate lifetime...

Years = (endurance / (BWPS * 31,536,000)) * (free1K / 4)

...where endurance is the rated lifetime per cell (typically 10,000 to 100,000 writes), BWPS is the Blk_wrtn_s figure from iostat, and free1K is the number of free 1K blocks from df plus the built-in 3% reserve (about 250,000K for 8 gigs). With this particular light-use session that works out to over 50 years with a 10K-write device. Higher rates of use with less free disk space can drastically reduce estimated wearout time. Here's a short BASIC program to calculate what should be worst-case...

210 LET F1=F+G*R*10485.8
220 LET Y=(E/(B*3.15360E+07))*(F1/4)
240 END



Remember this is only a rough estimation, assuming 4KByte flash blocks (change the 4 in the formula if not [and do! using 128 rather than 4 is probably more accurate judging from some papers I've read]) and that each 512 byte disk block is written to separate blocks. Sequential writes of unfragmented files "should" cache 8 disk blocks per flash block thus wearing out the device 8 times slower. Don't assume my formula is correct, just winging it the best I can from information I've read in the user forum. The main concepts are to minimize disk writes unless real information is being written and to maximize free space to spread the wear.

After much searching I could not find any endurance information about the Samsung "807" K9LAG08U0A-PCB0 flash chips used in the 701SD, unless I find out otherwise I'm assuming they're rated for 10K writes like other MLC (multi-level cell) flash devices.

[11/14/09 - after reading a few more papers about flash memory and learning block size is much larger than 4K bytes, I'm much more skeptical about their viability of being a disk replacement. After correcting the program to specify 128K blocks, assuming 100,000 cycle endurance and punching in my current iostat reading of 1.47 blocks per second and 777360K free I get over 17 years - not bad if the endurance really is 100,000 cycles or more. If only 10,000 then that works out to only 1.7 years which isn't good at all... lack of specs makes it impossible to estimate the true figures but my latest impressions of the technology is it is junk, mis-configuring the OS even a little bit will quickly fry them. Best used for thumbdrives and transferring information, using as a main disk is rather scary.]

Shutdown issues

Sometimes my 701SD would fail to shut down, seemingly stuck on the Shutting Down System screen. Holding the power switch will force the unit off but once I did this too soon and the bios complained about it on the next start, offering among options to start with defaults which worked with no apparent problems. The "fix" reported by users is to remove the snd_hda_intel module from the kernel when shutting down. I edited the /etc/default/halt script using nano (sudo nano /etc/default/halt) and added "rmmod snd_hda_intel" (without the quotes) on its own line at the end of the file. This helped a lot but occasionally it still leaves the power on after the screen goes  blank, when that happens I just hold the power switch with no adverse effects. Sometimes it still stays on the shutdown screen for a fairly long time (a few dozen seconds) but so far it eventually completes. I've noticed that disabling the wireless then shutting down seems to aggrevate the shutdown problem (not sure if the correlation is real) so there might be other kernel modules that need a little help unloading, but so far after the "fix" the incidents are rare enough to not bother pursuing further. Just make sure the drive light has been out for many seconds before forcing off.

File Associations

This was a puzzling one... after installing Frotz I was unable to associate *.z3 *.z4 etc through *.z8 to the Frotz binary (running in a console), nor associate them to a bash script I wrote to run Frotz in konsole passing the file name. In the associations dialog I could go through the motions and it looked like it was going to work but after the Updating System the app was no longer present in the associated apps box. When right-clicking and selecting run with other I could specify frotz, check console and remember, it would run the app properly but would not remember the association. Searching the web didn't do much good, lots of people complaining about this (using a variety of KDE systems) but the closest thing to a solution was a user who deleted the entire .kde directory structure and redid all associations from scratch. I read an implication that it might have been caused by running KDE as root, I had been using sudo kwrite to edit system files and ignoring the errors, I do this all the time with gedit on my Ubuntu system with similar error displays but no ill effects but who knows, might have caused damage in this case. Self-inflicted or not it's still a bug, got to find a workaround as custom associations are important when setting up a custom system and I didn't want to run Konsole every time I played a Z game, I wanted to just double-click the Z file like it should work.

The solution was a bit odd but trivial - I found that I could associate files to applications installed into the menu structure just fine, so used Menu Editor to add a submenu just for associated applications, added frotz to it, then I could associate the various Z file extensions to it without problem. It's only direct specification or browsing for the app file that was broken, presumably because it requires a .desktop file to work and it wasn't being created.

Sometimes the procedure doesn't work - I make a type for .sim files, used the menu editor to add an option to run hp2100 in a console specifying --keytab vt420pc then tried to associate .sim files to the hp2100 entry (not running in a console because the menu entry already specifies that), wouldn't go for it, association would not stick. Instead I created a script that runs hp2100 in konsole passing the parm, added the script to the menu with no options, then it would let me associate .sim files to the hp2100 entry. Just as well, pure association leaves the working dir set to /home/user so wouldn't have worked anyway, instead had to edit to...

cd `dirname "$1"`
~/sims/hp2100 "$1"

...that way it would change to the directory containing the .sim file before processing it with hp2100 so it can find the disk image or other needed files.

There is a tendency to duplicate associated entries, likely due to the "magic" used by Linux associations where it attempts to associate files by content - if a file matches two types that each have text editor associated, then there will be two text editor entries. My Ubuntu system also does this, but there I use Rox MIME Editor for more control over my file types to permit associating only the applications I want (it also works on the 701SD). Occasionally when doing associations through KDE, actual launch menu entries become duplicated for no apparent reason, these can be removed by rerunning the menu editor.

Running Other Operating Systems

The 701SD has somewhat unusual hardware but it's still an x86 PC and can boot another operating system from an external CD/DVD or flash memory device. The 701SD is relatively new and uses a different wireless card than the other 7" models, so wireless support on some of the alternates doesn't work "out of the box" yet on some of the alternate Eee distros but can be done with suitable hacking. Booting another OS is very handy for making image backups of the system, I used Slax with a couple of Eee-specific lzm modules to copy the internal 8 gig SSD to an external USB drive in case I need to restore the system with my hacks intact.

If the stock disk structure isn't disturbed by installing another OS then the system can restore itself to factory software by pressing F9 when booting and selecting the restore option. Pressing Esc while booting brings up a boot selector to permit booting from a USB device but so far I have not found a way to make it simply boot from USB if a thumbdrive is present unless it remains present (if removed on boot then the disk boot order reverts to the internal drive first - but this probably means if an alternate OS were installed to a MMC SD card and left in place the setting would "stick"). Pressing F2 while booting brings up the BIOS setup utility. Only problem is Esc, F2 or F9 must be pressed at precisely the right time to have any effect as the default time given is very short, and if pressed while the system is loading then problems result such as the touchpad not working. The solution is get F2 to work then disable boot booster, disable fast boot options, and make sure it's set to actually display the bios boot screen so it says "Press Esc" etc to know when it's expecting a keystroke. The fast boot options only save a couple of seconds anyway, time better spent being able to control the computer when needed.

Slax works great as a rescue OS and it's hard to beat its ease of configuration - simply put what you want in the modules directory. Slax is small (about 200 megabytes or less) and can co-exist with other files on a plain FAT-formatted thumbdrive. To set it up I copied the boot and Slax directories from a Slax CD to a thumbdrive, then to make the thumbdrive bootable I booted the CD on my main system and used it to navigate to and run the /boot/ file on the thumbdrive (Ubuntu wouldn't run it). I have a fairly stock version of Slax 6.0.7 with the addition of the acpi-eee-607.lzm and eeedrivers-607.lzm modules. There is a procedure for getting the wireless working but I haven't tried it yet.

To make image backups I stuck in the USB containing Slax, pressed Esc on boot and selected USB, then once booted connected an external USB hard drive and used the dd utility to copy the internal drive to a file on the USB drive. I also copied just my user partition to a separate image file which if needed I can mount on my Ubuntu system using loop techniques (haven't tried yet). Doing this requires familiarity of the shell, being able to navigate to the mounted drive, and knowing exactly which /dev/ devices are the internal drive and its partitions to specify for the input, specifying the output file by name minimizes risk but dd is still a very dangerous command if misused. In my version of Slax the 701SD's disk appears as /dev/hdc (this may vary!) and my changes are on partition /dev/hdc2 - I found this out by seeing what was mounted under /mnt (also to find out where the external hard drive was mounted). Slax's Konqueror got a bit unstable when using it to do file management on my 200gig external and crashed when creating a directory to put my eee backups (but succeeded), memory is limited and there's no swap file so best to work from the command prompt as much as possible. The copy was done by launching a prompt and using the cd and ls commands to navigate to where I wanted to save the image files, then entering dd if=/dev/hdc of=hdc_full(date) to start the transfer, which took a long time (seemed like an hour but maybe less, seemed like USB1.1-ish speed). There is no feedback, just the led's blinking for the internal and on the external drives. When that was done I repeated the command but using if=/dev/hdc2 to save just my user partition so I can restore just that provided the disk structure hasn't been changed. Be Extremely Careful when using dd, by specifying of=/dev/anything it writes directly to the device and can totally wreck a disk if not used properly, but if care is used dd provides a powerful way to save and restore the system.

Content by Terry Newton (, above text was last modified 12/30/08. Systems vary so check for compatibility and back up important data before attempting changes, not responsible for damage that occurs from using the information on this page. All trademarks mentioned are the property of their respective owners. Blog-like entries below....

1/5/09 - My little 701SD has become a very valuable part of my routine, the form factor is perfect for "field" tasks. At the shop it sits by my bench ready to compute parts values, look up data sheets or write quick one-off programs to compute the problem of the moment. A few days ago I used it to dump a bunch of old wire recordings from the early '50's to MP3 files. Yes I said wire, from an old Webster model 181 wire recorder I fixed for a friend of mine (just needed a few caps, otherwise worked perfectly). To do this I wired up the following rig...

               + >----*---------*----1K-----.              To computer
| | |
From Spkr Out 15 ohm 150 ohm 2.5K trimmer <---*----> tip 1/8"
| | | `----> ring plug
- >----*---------|-----------*----------------> sleeve
| |
| `----> to monitor [updated 1/8/09]
`--------------> speaker

The 15 ohm resistor puts a load on the speaker output of the Webster (or whatever) to keep the amp happy, the trimmer sets the input level going to the computer. When the Webster was set to external speaker it cut the internal speaker and I couldn't figure out how to make Audacity play the input signal through the Asus' speakers so wired up a small computer monitor speaker so I could hear what I was doing. The 150 ohm resistor in series with the speaker sets the monitor volume, less ohms = louder. I set Audacity to use a thumbdrive for its temp directory to keep from putting wear on my SSD. Set Audacity to mono, after recording each "track" I exported the clip to MP3 files. Occasionally I restarted Audacity to get the temp space back. Once I had MP3 files of the wire contents I used Ubuntu and Serpentine to burn them as tracks to CD's. Worked great except for two things... once the screen timed out and when I touched the pad to bring it back it "clicked" the stop button and I had to redo that wire (sometimes autoclick makes it faster to operate, but often causes unintended clicks, haven't found a way to disable - Slax doesn't do it so it's something about the Asus driver), and apparently one of the CD's I used was bad and failed to play properly on another CD player, had to redo the burn.

Another cool app for my 701SD is burning PIC chips using a PICkit 1 programmer and the pyk software. The pyk "make install" is for an earlier version of python and Linux, make install failed but still added me to the pickit group to avoid having to sudo to run, and copied the files into the /usr/local tree. It runs fine just from the home directory it was untargz'd to (~/pyk-0.3) so deleted the installed files from /usr/local/bin and /usr/local/lib but probably would have worked fine from the installed locations. Pyk needs a command line like [path/]pyk --device=12F675 program.hex but I needed to program hundreds of chips so I wrote a pair of bash scripts to launch in Konsole and repeat the burn when I press enter...

----- begin -----
if [ -e "$1" ]; then
konsole -e ~/pyk-0.3/ "$1"
----- end -------

----- begin ------
echo ""
echo " Program file: $1"
echo " Attach Pickit 1, insert chip then press enter..."
read nothing
while ((1)); do
echo ""
~/pyk-0.3/pyk --device=12F675 "$1"
echo ""
echo " Press enter to burn next chip... (ctrl-c to exit)"
read nothing
----- end --------

Actually at first I wrote the scripts hard-coded to the one file I had to burn to the PIC, these are generalized to burn the file specified on the command line. The was added to my start menu under associate-only so I could associate .hex files to it (the mime type was already defined). I put both scripts in my ~/pyk-0.3 directory, paths are hard-coded (the first script should point to the second script, adjust the path to pyk accordingly - if installed to /usr/local remove the ~/pyk-0.3/ part).

Wonderful... pyk is almost 10 seconds faster per chip than the Windows-based software running on my Ubuntu system under VirtualBox, plus I didn't have to turn around to hit enter for every chip, the 701SD is small enough to sit right on my work table next to the programmer and the pile of chips to program. First use saved me about an hour of accumulated time on a run of about 250 chips.

Although a typical user probably won't ever need to burn code into PIC chips, the point is writing little scripts is how one makes software behave as needed. The first script launches the application in a terminal as needed (the associations and menu editor permit selecting a console, but in practice I found doing that caused the KDE bug mentioned in the File Associations section above - failed to stick). The second script gives me a chance to get ready, then runs the same command over every time I hit enter. I can think of many things that would require a similar execution plan. Some may object to the command line, but in fact scripts are how one Avoids repeatedly using the command line by formulating the required commands once then just using the thing like any other app. Bash is a wonderful tool once the basics of it are learned. Myself, I don't bother to memorize it all, I just look at other scripts to remind myself "oh yea, that's how to loop" or whatever needs doing and make the machine do what I want.

1/20/09 - The recording rig morphed into this line/speaker recording adapter which I made for my friend to use with her laptop running Audacity under Vista to dump old wire recordings and 78 records. Yea Vista... got really scared when the first time through it locked up as soon as hitting recored, set the Audacity exe file to run in XP compatibility mode then it worked fine. Just in case I needed a plan B I reconfigured by Slax thumbdrive without Eee-specific drivers and put Audacity on it, didn't need it for that but discovered that for what I use Slax for (making backups, in case I need to fix something, or otherwise run an isolated OS) I don't need the extra drivers, boots fine and the touchpad works with just the stock system.

I saw a post on concerning running a warrior evolver on a Eee PC and thought "that's a great idea!" Then I could keep an evolver task running when I'm away from my main machine without having to leave it on, have both machines working, or have my 701SD doing the number crunching without eating up cycles when I'm trying to do other stuff. I already had DosEmu/FreeDos installed so I could transfer my usual batch and QBasic tools I wrote long ago for testing warrior code. The main concern is avoiding disk writes, running something like an evolver would quickly break a solid state disk drive - REBS does about 50-100 writes per second, on a desktop system most get absorbed by the write-back cache but still writes roughly 10-20 actual files per second when evolving nano-sized warriors. The answer there was to always run it from a ram disk then there are no disk writes at all. The commands to set up a "ramfs" ram disk are fairly trivial...

mkdir ~/rd
sudo mount -t ramfs none ~/rd -o maxsize=25000 && sudo mkdir ~/rd/work
sudo chmod 777 ~/rd/work

...which I put into a script for error-checking...

----- /home/user/ ----------------------------------
if [ ! -e ~/rd/work ];then
echo "Creating 25 meg (max) ramdisk with ~/rd/work directory"
if [ ! -e ~/rd ];then
mkdir ~/rd
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
echo "Operation failed"
echo "Press enter..."
read nothing
echo "~/rd/work directory already exists"
echo "Press enter..."
read nothing
----- end of script ---------------------------------------

This assumes ~/rd is not used for anything else, otherwise edit. Since the drive is created root level for user stuff it creates a work directory on the ram disk with permission for all to read and write to. Once run a symlink to ~/rd/work can be put in the same area as other files that need to be copied to the ram disk. The symlink will be broken after rebooting until is run, everything needed from the ram disk needs to be copied back to regular disk before rebooting or shutting down as it all goes away. Konqueror works on the ram disk but when copying files to it have to click "ignore" for the size error as this kind of ram disk reports free size as 0, it only uses memory actually consumed by files rather than preallocating the entire amount.

Before shutting down or restarting enter sudo umount ~/rd or put in a script...

----- /home/user/ -------------------------------
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
----- end of script ---------------------------------------

That solves the problem when evolving, at least using REBS there are 0 writes when evolving. Testing was another matter, my benchmarking tools write many temp files before finally writing the tally which is the only file I really want. For the TEST.BAS/.EXE benchmark the answer was simple, copy it to ram disk too. A symlink linking ~/dos/work to ~/rd/work provides easy access to the ram disk from FreeDos. The batch files took more work, they had to be edited to write temps to %temp% instead, which gets mapped to a directory under /tmp which on the 701SD exists in only in ram. The rest was just gluing the tools to right clicks using associations and scripts and stuff. The Core War Files page has a link to a file with details.