Tweaking the Code
The entire third partition, hda3, of the laptop's hard drive holds the JPG images, and I've included some NASA space scenery to get you started. However, because the loopback device can't handle a partition table, you can't mount the hard drive image like a floppy. Listing Three (a) shows how to do it.
(a) /sbin/fdisk -ul develop.ha (my hd3 is at 2209536 sectors) sudo mount -o loop,offset=$((512*2209536)) develop.hd /mnt/loop sudo cp images/*jpg /mnt/loop sudo umount /mnt/loop (b) cp /mnt/floppy/fbida-2.06.tar.gz /tmp cd /tmp/ tar zxvf fbida-2.06.tar.gz cd fbida-2.06 make make install fbi -u -t 3 -noverbose -readahead -autozoom /media/images/*jpg
Use fdisk -ul to list the start of each partition in units of 512-byte sectors; you can tuck those values into variables to save typing. Next, feed the third partition's starting address into the mount command's offset parameter and mount it on /mnt/loop. Then you can copy the files into the image and unmount it, using sudo as needed for root privileges. You could adjust the partition's ownership and permissions if you prefer.
Copy the fbi viewer's tar.gz file to a floppy image and follow Listing Three (3) to install it. Depending on the GCC version, remove the -Wno-pointer-sign CFLAGS option near the top of its GNUmakefile. The download file has notes on some other tweaks.
I recompiled the kernel to use the ThinkPad's Pentium II CPU, add built-in APM support, and omit unused modules and features. My .config file leaves only the floppy and CD support needed for the VM, but you may want to add networking and other creature comforts.
Recompiling and building modules for that configuration takes 321 seconds on a 2.8-GHz Pentium 4 HT using KQEMU's kernel acceleration and 330 seconds without. Omitting the KQEMU module entirely slows the VM to 1954 seconds. Recompiling from the same disk image on the ThinkPad's 233-MHz Pentium II provides 1218 seconds to do something else. I cannot provide a "native" compilation on button for comparison, as setting up cross-compilation was what drove me to QEMU in the first place.
Unaccelerated QEMU thus converts a peppy P4 into a 145-MHz P2, but with full acceleration the VM chugs along like an 884-MHz P2. QEMU claims to run at nearly native speed and I suppose the 3x I found is close enough. Remember that the compiler and kernel run with the 486 instruction set, so further optimization is obviously possible.
Incidentally, switching to a blank console with Ctrl-Alt-F2 dramatically speeds kernel compilation by not scrolling torrents of 2.4 kernel messages across the VESA framebuffer.
The kernel accelerator only works for x86 code, so I'd expect the QEMU ARM or MIPS VM to run at a tiny fraction of "native" speed. On the other hand, those microcontrollers have relatively low performance and you may find the VM produces similar wall-clock results.
Putting a development system into a VM won't solve all your problems, but it does remove much of the configuration complexity. In particular, a virtual network to a file server can eliminate the floppy shuffle, let you use your normal desktop hardware, and make the whole process relatively painless.
