x86 Emulation makes it to the H/PC - BOCHS 2.1.1

The Pocket PC (PPC) I will admit - through circumstance and not for any prevailing feature of its own - does have one advantage. Developer focus.
When you have a critical mass of active developers confined to a small, 240x340 space inevitably someone will push the boat out from harbour and sail it right over a waterfall; surfacing in the realm of what most people would call abject fantasy.

Of particular note in this category are the exploits of a number of overly excited Axim (Dell PPC) users who have been swapping images of the Windows 98 desktop in their QVGA and VGA displays since the middle of last year. Nothing spectacular in that one would think. Anyone with a network connection and a VNC client can achieve that in a relatively short space of time. Here though this wasn't an experiment in remote connectivity, this was a far more highbrow exercise.
The PPC wasn't using a network connection; there was nothing out of the ordinary in the hardware makeup of the PPC itself - just a run of the mill Windows Mobile 2003 device.

Windows 98 was actually running on the Axim in front of Windows Mobile.

Background on emulation

The art of running any operating system is one that requires a fundamental understanding of the makeup of the hardware it will run on. Just as with how a H/PC user will appreciate that a MIPS application cannot run on a StrongARM backed device, and a Windows CE application cannot run on your Windows or Linux desktop PC. An operating system designed for a specific CPU architecture; say the x86 architecture on your desktop PC, simply could not contemplate running under another processor type (for instance the XScale on your Handheld PC).

So, is this an elaborate trick designed to fool those users of less experience?
Not quite, though users of less experienced disposition may wish to turn away now and be happy in their naivety.

The process of running an operating system literally on top of another one is not a new one. Using a method known as virtualisation back in the heady days of large symmetric mainframe systems, it was common for resources to be better optimised by taking the multiprocessor system and through virtualisation dedicating different installations of the operating systems to run against one of the available processors. Over the years as accessible computing has made vast inroads into our every day lives, and inexorably the cogitative abilities of the humble home or office PC have increased. The idea of spreading the disparate abilities of the hardware behind this revolution has become more of a reality, and will become something everyone will invisibly benefit from in the coming years.
Taking the concept of virtualisation, which separates the hardware of a computer and in simple terms allows it to be seen by more than one operating system. This can be stepped up to another level called Emulation. An emulated system provides an environment in which whatever is running within it is oblivious to the physical hardware and native operating system of the computer. There is a trade off to be made through this. While on the one hand you can use the software emulator to create a map between the physical system architecture and that of the virtual, this in itself is less than ideal, notably from a performance perspective. The physical processor in the computer not only has to manage it's own native operating system, but also the virtual operating system and the mapping or substitution of the architectural calls made by the virtual system.
The overall result of this is that substantially more powerful underlying processing hardware is needed to maintain performance between all three components. If that wasn't enough, you then have to consider the other inflated system requirements such as RAM, video and storage.

The most wide spread use of Emulation in the consumer market comes from the games console and legacy platform sector. Remember those classic arcade games from your childhood? Or perhaps you have a portable games device and are tired of carrying around both your H/PC and console?

The chances are that an emulator already exists to allow you to run those games directly onto your Handheld PC. Admittedly the usefulness of this is trivial and you will find, depending on your targeted console that emulators operate with varying degrees of success.
Given that there is already precedence for emulation in the Windows CE world, the fact that eventually someone tried it with the IBM PC architecture isn't all that surprising… but it did take some gall.

BOCHS 2.1.1

Enter the rather unfortunately named BOCHS. BOCHS is an open source development project dating back to 1998. Its aim and purpose was to emulate the IA32 (and later the EM64T and AMD64) processor architecture on a diverse number of other platforms, including Mac OS and indeed the IBM PC itself.
If at this point you are scratching your head wondering why on earth anyone would want to emulate a CPU type that you have never heard of, perhaps the IA32's colloquial name of x86 or i386 will make things clearer.

In the spirit of open source, early last year, a melancholy Pocket PC developer decided to have a crack at porting it, and in 2004 a conceptual build of BOCHS for the StrongARM / XScale processor (or if you're revelling in the terminology the SA11xx / PXA25x architecture) complete with source code hit the web.

The release failed to make much of an impression, on any side of the Windows CE community, with little to no commentary subsequently. With what little discussion on the BOCHS port exists. There is one common fact that time and time again prevails in all the discussion on the Pocket PC port, and is undoubtedly its Achilles heel. You need a keyboard to even begin to make use of it; and keyboards are something the H/PC community has in abundance.
The obvious benefit of trying this on a H/PC over a Pocket PC should be immediately apparent, they read identical to the main selling points of the H/PC and put the average Handheld PC user in a better stead for attempting such hapless activities. With that in mind, it was a pleasant surprise to discover that the BOSCH port had been written using common Windows CE 3.0 core API, rather than using dedicated libraries present only on the Pocket PC.

Let the games begin

Armed with a Jornada 720, a half a gigabyte CF card and a clear file system on both the H/PC and CF card. The 1.42MB BOCHS single file executive sits comfortably in faster main RAM, a delight because there are performance benefits to be gained from keeping it on the fastest medium possible. Considering all of highly advanced abilities which BOCHS contains, 1.42MB is exceptionally lean, and something which in all certainty is attributable to its open source roots.
BOCHS is written in the spirit of all the best Open Source applications, in that it is a terminal driven application interfacing through the Windows CE Command Prompt. Equally as common to the most prestigious Open Source programs, BOCHS's user interface to a 'point & click' generation user can only be considered on par with that of attempting to debug a C program in Windows notepad. To any experienced shell user, or anyone who has been exposed to working in a command line / terminal interface should be fairly straightforward.

The interface is made up of sequences of numerically driven menus, each driving you down further into the application configuration options and inevitably into some very high level environmental settings which the vast majority of general users will never likely see again during their IT lives.

With no online help available with the application - though the documentation on the BOCHS sourceforge website remains largely applicable - and little to no prompting on what additional options are valid for multi choice selections (aside from the default; usually [none]). Wading through the configuration menus to build you initial emulator profile is somewhat time consuming, but there are no shortcuts in this, you simply have to spend the time doing it and be prepared to undertake the research on any terminology you're not up to speed with.

Unlike most emulators, which are preconfigured and come with predefined layers of core system functionality, BOCHS, even with a fully configured configuration file is still an unusable blank canvas. Attempt to initialise the emulator and BOCHS will drop you back to the command prompt with advice completely at odds with that afforded to us by the author Douglas Adams.

[MEMO ] >>PANIC<< …

Buried within that revelation, is BOCHS's way of telling you that you're missing two vital pieces of software. Namely a computer BIOS and Video firmware.
Both of these components will ordinarily be found mounted in some fashion on your computers motherboard. For BOCHS there are software images of BIOS firmware written once again by open source developers and released under GPL.
Locate both files, plug them with paths into your BOCHS configuration and finally you will have a fully configured emulation environment.
It just doesn't do anything yet.

The BOCHS BIOS provides virtual access to Floppy disk, Hard disk and CD/DVD-ROM drives for installation and storage purposes. This access is completely virtualised, and provides no path into the Windows CE file system, or mounting capabilities for using attached storage devices as additional drives. You are also unable to switch mounted volumes ad-hoc; meaning virtually ejecting a CD to insert another one is not an option. BOCHS attempts to make up for this by providing four emulated IDE channels and two floppy drives, each IDE channel supporting master and slave capabilities - allowing for a possible 8 hard drive / CD/DVD combinations. Only one of the 10 possible devices can be set as the boot device, and must be manually specified in the configuration file.

Additional reprieve comes in the form of the format understood by BOCHS for floppy disk images. BOCHS reads standard .IMA images, the same found on bootdisk.com, used against Microsoft Virtual PC 2004 and created by WinImage.
Equally CD ISO images are also supported by virtual CD/DVD drives, though I will admit it was not until the second day that I thought of trying it - what was that about reading the manual?… manual?
This opens up the capabilities of the emulator vastly. The creation of hard drives is a time consuming, long-winded process, where as if you apply out of the box logic to the capabilities of an ISO image, there is a lot of time saving to be made.
Instead of trying to copy operating system install files for your legacy systems into a preformatted hard disk image, or imaging floppy disks in futile manor. Using the likes of Nero Burning ROM's Image Recorder driver you can create a CD image of all the files needed to install an operating system, cut out unneeded bloat from the installation files that you do not need and add in additional applications and utilities that will be beneficial to the installation. Saving precious space on your storage cards. You can even make the ISO bootable, bypassing the boot disk phase completely.
As an example, using Nero I copied the CAB store on a Windows 95 upgrade CD into an ISO, and added the content of the first Windows for Work Groups 3.11 install floppy into a sub folder.
This reduced what would have ordinarily been a 150MB CD and the contents of a 1.44MB floppy disk's worth of data down into a 34MB ISO file, and allowed me to get past the "This is an upgrade version of Windows" screen without juggling floppy disk images.

The hard drive images themselves are more complicated. They need to be written as a binary image format that is understood by BOCHS, and contain the structure needed to virtually emulate a hard drive.
The binary images are nearly identical to the floppy disk ones but cannot be created by the likes of WinImage. After many hours of frustrated experimenting, reading up on the BOCHS make-up and the specifics of the x86 desktop PC version I was able to build a correctly formatted image file. Unfortunately for me, only to discover by chance some time later that the Win32 version, which runs on Windows NT based systems contains an image creation application.
Like with any PC emulator you have to think of a hard disk image file as if it were a band new, off the shelf hard disk. After all it is oblivious to the fact that it is a hard disk; and may well indeed believe itself to be a very special mechanical toaster! - Who knows?
Personification aside. As with any new hard disk drive you must perform two operations before the image can be used. It needs to be partitioned with at the very least with a Primary partition area, and then have that area formatted. Once you have undertaken both of these operations, the drive is ready to receive an operating system… and things steadily start to get worse.

If you have gotten your own BOCHS installation up to this point, then one thing certainly wont have escaped your attention. It's slow. In fact it's more than slow; it's painfully slow.

If you have ever used VNC with a Handheld PC, you will be pretty confident in the idea that you know what underperformance is. Let me assure you that you don't.
Booting onto a Windows 98 SE boot floppy image, running out of main RAM with CD-ROM support takes 10 minutes to deliver you to the prompt. The BIOS POST itself set with 12 MB of ram takes over a minute to configure the boot environment.
As an IT consultant by day, I've had to indulge in more than my fair share of Windows installs, on some of the oddest configurations that could be thrown my way. Suffice it to say, I was prepared for the long hall.

BOCHS Windows 95 Installation on the Jornada 720
Figure 4 - 7
Figure 8 - 11
Figure 12 - 15

… and nearly 17 hours later, I felt vindicated in not expecting too much from BOCHS as it slowly slid onto the Windows 95 desktop for the first time.

Both the Hard disk, floppy disk and CD ISO images were located on the 512MB CF card by this time, which admittedly is less than ideal, and certainly not friendly on the limited read/write operational life of a CF card. Worth noting here is that you can host the images on a network share if you wish to save your CF card the stress and strains involved in the emulation process.

There is something to be said for only having provided the emulator with 12MB of addressable RAM, and for running screen capture sessions throughout the installation.
You could even lay the blame on the 206MHz StrongARM processor, which forms a portion of the performance issues. The real culprit can be pinpointed when you read the anecdotes and testimony of the Axim users. When 600MHz XScale users see the same performance degradation, I doubt that they are prevaricating.
The roots of the BOCHS for Windows CE release are mostly in proof of concept, demonstrating that it can run under Windows CE devices. The release lacks product refinement and has not been rewritten to make the most of the SA11xx architecture that it must interoperate with. Fully optimised code will never provide an environment where the mainstream Windows world can seamlessly meet the Windows Mobile world, at least not on the 200MHz generation of Handheld PC, but it would make the collision of two worlds a little softer.

BOCHS's continued existence on the Windows Mobile platform is not simply dependent on the optimisation of its base code, but on the restoration and modification of features available to the desktop version.
Crucially lacking from the release is the network layer. This requires specific network drivers to be installed on the Windows release, and on the Windows CE release the entire function is unavailable. This isolates the installation from the Windows CE device it is running on, and means the primary reason most people would consider using this technology on a H/PC - for web browser support is moot.
The next issue that needs to be addressed is that of the screen. The emulator runs in a fixed size window, proportioned accordingly to the screen area between a title bar and the task bar. The emulated screen area - VGA by default - is not cropped to match the window size, and no scroll bars are available to navigate around the virtual display. On a HVGA device that leaves the available screen area at roughly 640x176, with no way to view the rest of the screen or the emulated task bar - except if you use Nyditot, which in turn produces an added performance hit. With Nyditot, because of the large Windows CE title bar and menu bar area, stretching the screen of a HVGA device out to 640x480 isn't quite enough. You need to stretch it to 640x600 to actually see the taskbar in the emulated OS.

The final issue requiring urgent attention is the one of mouse support. For an unfathomable reason, when porting the Win32 version over to WinCE, the original programmer left the mouse activation key stroke on F12, a key that doesn't exist on a H/PC - or on Pocket PC for that matter. The only way to activate the rather clumsy stylus to mouse mapping is to connect your device up to ActiveSync and using a remote display program use the F12 key on your PC's keyboard to activate the mouse - yet another performance hit.

If you have muddled through to this point with your own installation, you will undoubtedly have flushed the novelty clean through your system, and having done that myself, I am forced to conclude that while the era of this technology is dawning on the mainstream hardware market, it is still a long way off being an acceptable technology on the PDA.

Inexorably there will be a time in the not to distant future where the exponential increases in processing power, and demand spurred on from the benefits found in the desktop market will deliver this sort of technology onto the PDA.
So long as a 34MB Windows 95 install takes 16 hours, and boot time from execution to desktop is 19 minutes 8 seconds. BOCHS will remain nothing more than a nice party trick.
You can now see why the PocketDOS formula hasn't changed in all these years, I'm sure.

Whether it was worth the time invested into coming to this conclusion. That is down to you…

Source Code for BOSCH 2.1.1 for Windows CE can be found at the following URL.
http://mamaich.kasone.com/

Chris Tilley  
Editor-in-Chief  

Want to have You say about BOCHS 2.1.1?

Contact Chris by e-mail.
Alternatively visit the Forums for a discussion thread.