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 "startfull.sh" and
"startsimple.sh" 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 http://update.eeepc.asus.com/p701/pool/
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...
#!/bin/bash
cd ~/sims
konsole --keytab vt420pc -e filename.sh
...where ~/sims is where my hp2100 sims are and filename.sh 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 2.6.21.4-eeepc (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...
100 PRINT "FLASH MEMORY LIFETIME CALCULATOR"
110 PRINT "ENDURANCE RATING OF DEVICE ";
120 INPUT E
130 PRINT "CAPACITY OF DRIVE IN GIGABYTES ";
140 INPUT G
150 PRINT "RESERVE CAPACITY IN PERCENT ";
160 INPUT R
170 PRINT "BLOCKS PER SECOND FROM IOSTAT ";
180 INPUT B
190 PRINT "FREE SPACE IN K FROM DF ";
200 INPUT F
210 LET F1=F+G*R*10485.8
220 LET Y=(E/(B*3.15360E+07))*(F1/4)
230 PRINT "ESTIMATED LIFETIME IN YEARS:";Y
240 END
RUN
FLASH MEMORY LIFETIME CALCULATOR
ENDURANCE RATING OF DEVICE ?100000
CAPACITY OF DRIVE IN GIGABYTES ?8
RESERVE CAPACITY IN PERCENT ?3
BLOCKS PER SECOND FROM IOSTAT ?2.64
FREE SPACE IN K FROM DF ?1439540
ESTIMATED LIFETIME IN YEARS: 507.837
READY
RUN
FLASH MEMORY LIFETIME CALCULATOR
ENDURANCE RATING OF DEVICE ?10000
CAPACITY OF DRIVE IN GIGABYTES ?8
RESERVE CAPACITY IN PERCENT ?3
BLOCKS PER SECOND FROM IOSTAT ?100
FREE SPACE IN K FROM DF ?100000
ESTIMATED LIFETIME IN YEARS: .278775
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 run_hp2100.sh 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 run_hp2100.sh to...
#!/bin/bash
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/bootinst.sh 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 (wtn90125@yahoo.com), 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 burn_12F675.sh -----
#!/bin/bash
if [ -e "$1" ]; then
konsole -e ~/pyk-0.3/pyk_12F675.sh "$1"
fi
----- end burn_12F675.sh -------
----- begin pyk_12F675.sh ------
#!/bin/bash
echo ""
echo " Program file: $1"
echo " Attach Pickit 1, insert chip then press enter..."
read nothing
while ((1)); do
clear
echo ""
~/pyk-0.3/pyk --device=12F675 "$1"
echo ""
echo " Press enter to burn next chip... (ctrl-c to exit)"
read nothing
done
----- end pyk_12F675.sh --------
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 burn_12F675.sh 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 rec.games.corewar 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/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
----- 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 mkrd.sh 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/unmount.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
----- 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.