And, well, no. I can't think of a single product from that particular salvo that actually survived, let alone thrived. But we've got one of them here — and, as you might expect, there's a few odd things about it. First off, it's a slate. (We call them tablets now, kids.)
Not a vanishingly rare form factor for a Windows CE device, though hardly the most common. It's also got a full-size dock, a camera and ... a Data General badge? The Nova-AViiON-CLARiiON-Data General/One Data General that put two I's into everything? Yup, it's really that Data General with that naming convention. In fact, as the history will show, the Data General WiiN-PAD is quite possibly the last computing device DG ever produced before EMC bought them out and shut (most of) them down in 1999. (No, near as I can determine, the name WiiN-PAD has nothing to do with the unreleased Microsoft WinPad.)But that's not the really wacky part. Check out the CPU it's running.
That's right: it's PowerPC, the most unloved of the architectures CE ever ran on — in fact, this is the first PowerPC Windows CE device I've ever found, and I'm the self-described biggest pro-PowerPC bigot in the world. Here's an unusual form factor Windows CE device, running on the operating system's least used CPU, from a storied computer company near the end of its run, intended for medical applications, produced in very small numbers and cancelled within months.What are we going to do with it? Well, what do you think we're gonna do with it? We're going to program it, so that we can finally have some software! And, of course, since this wacky thing was there at the bitter end, we'll talk more about the last days of Data General and what happened next.
We last ran into Data General in the 1980s with the Data General/One, their (for 1984) ultraportable DOS laptop with a great form factor and terrible screen that we rehabilitated. Data General was founded in 1968 in Hudson, Massachusetts by three disaffected Digital Equipment Corporation employees, Edson de Castro, Henry Burkhardt III and Richard Sogge, along with Herbert Richmond from Fairchild Semiconductor. de Castro had been chief engineer of DEC's 1965 12-bit PDP-8 minicomputer which by then was one of the company's strongest sellers. The PDP-8 was a less expensive system than their bigger machines, but it was nevertheless costly to manufacture due to its use of discrete logic modules and wirewrap. To de Castro's surprise and frustration, however, DEC management was uninterested in an even lower-cost PDP-8 concept produced with newer printed circuit board and wave soldering technologies. He was convinced he could do better.
And the 1969 Nova did, in fact, do better. It used a similarly simple accumulator-oriented instruction set like the PDP-8, but it was smaller, faster and cheaper to produce, and its 16-bit word size could even compete with DEC's higher-end PDP-11. DEC's unsuccessful lawsuit probably only legitimized the upstart and it had stratospheric growth into the mid-1970s — which came to a rapid halt with the 1974 Eclipse, DG's intended successor to the Nova with virtual memory and a proper hardware stack. DG could not solve production problems with the Eclipse for several years, leading to a wave of legal action from customers when preorders didn't arrive, and an effort to make a microcomputer Nova (the microNOVA) failed in 1977. Data General's attempt to leapfrog into the 32-bit world was the subject of the Pulitzer Prize-winning The Soul of a New Machine, detailing a skunkworks project codenamed Eagle that developed a backwards-compatible architecture, while another team hit the second-system effect wall with Fountainhead as a more direct technical assault on DEC VAX. Eagle became the extremely successful AOS-based MV systems in 1980, a stupendous reversal of fortune for the company that by 1984 had over US$1 billion in annual sales.
Still, the MV project was costly for Data General to develop, and many former customers had abandoned them. This led to smaller projects in the 1980s as minicomputer makers confronted their fates against the rise of the microcomputer. The Desktop Generation systems, using microECLIPSE and Intel CPUs to run MS-DOS or CP/M concurrently with DG/RDOS, were complex to use, expensive and unpopular, and only the Data General/One laptop, an upscale product in a segment with relatively few competitors, gained market traction. By 1988 Eagle and DG/One designer Tom West convinced de Castro that DG's proprietary legacy systems had no long-term future against those from IBM (and, at the time, DEC), and that they should become more commodity-focused and Unix-based, since the market was going that way.
West's prophecy was of course correct, though in ways the company couldn't have predicted. The 1989 Unix-based AViiON (a name likely suggestive of "Nova II") had the bad luck of selecting the Motorola 88000 as its CPU just two years before Motorola joined the AIM alliance and later cancelled it, and their second generation x86-based systems ended up hitting the market roughly at the same time as everyone else's. Worse, their attempts to distinguish themselves with an innovative custom NUMA design turned out to perform suboptimally with Windows NT. What had more of a lasting effect was the 1994 CLARiiON RAID array, introduced as the HADA "High Availability Disk Array" for AViiON systems in 1992 before DG management realized it could have broader market appeal. Although splitting CLARiiON off as its own product made AViiON packages less attractive, CLARiiON arrays became a solid moneymaker in their own right as they were regarded as more reliable and higher-quality than other offerings.
A much lesser known part of Data General's business were their portable data entry terminals, introduced around 1994 and sold variously as the DataGenies (I'd thought they'd call them DATAGENiiES but even DG's marketdroids have some taste). These were AA-powered rugged handheld devices intended for use in the field, based around the 80C88 or a clone like the NEC V25 and capable of running custom applications. DataGenies were dockable with a PC to transmit information and usually fitted with a small LCD screen, keypad and barcode reader. The units were approved for hostile environments like oil rigs and boats and largely used for tracking and inventory management. It seems they were produced in some numbers as used examples even today are not hard to find.
Like most tech companies then and now, Data General had a small Healthcare Division to get a taste of the dough flowing through the moneyed halls of medicine, which existed in one form or another since at least 1987. Much of their work involved using Data General server kit to back partner frontends, such as a 1996 partnership that used AViiON hardware and CLARiiON disks as the backend for separately-developed PACS teleradiology workstations, but at least some of the Division's operations sold customized DataGenies to hospitals and clinics where they were used for basic nursing tasks like vital signs and point-of-care testing. In 1998, Microsoft announced a new "strategic alliance" with DG for "integrated systems" using what Microsoft grandly termed "ActiveX for Healthcare." In reality this was actually more of the same: independent vendors would use ActiveX (i.e., Microsoft COM) components in their client software, encouraged and supported by Microsoft and Data General's network of "Healthcare Competency Centers," which would connect to BackOffice installs on Windows NT running on AViiON. The first of the HCCs was scheduled to open in Boston nearby the DG offices in July.
DG's relationship with Microsoft had an impact on their portables line as well. Expanding the line to introduce a full medically-oriented clinical handheld made sense to DG management, especially in a environment where "vertical mobile markets" had just popped up on the buzzword bingo card and were driving other small form factor devices. This time, however, no doubt with Microsoft's strong urging, the product managers selected Windows CE as the base — not only to take advantage of the ecosystem but also almost certainly as a sales adjunct to AViiON hardware running Windows Terminal Services (now Remote Desktop Services) to which Windows CE thin clients could connect. The WiiN-PAD's trademark application was filed September 29, 1998 and development occurred in the handheld division alongside Microsoft's subsequent Windows CE healthcare announcement in October. (At least some additional development work was done by Windows CE specialist bSquare, but it's not clear exactly what.) Notably, the product they constructed seems to have been completely specific to DG and not a rebadge of anything else. Given that the device was completed around the spring of 1999, it's likely the WiiN-PAD was the last new computer system Data General ever developed under its original name.
And here it is. Need your medications refilled? How's that mucus going? Is this the first and last time I'll use the word "mucus" in a classic computing blog? (Wanna bet?) The screen is nice and legible for 1999 (backlit 8" 640x480), the form factor is attractive, and the bright blue handle gives it charm. It's hard to say exactly why or what physical cues tickled my brain, but even the mere appearance of it gives off very strong health care vibes. Indeed, my wife, who's worked in several medical offices herself, asserted the very minute I unpacked it that it was a clinical unit. The industrial design was contracted out to a Plainville, CT company named Anderson Design Associates which built it to be durable and survive a four-foot fall to hard flooring (I'm not going to test this!), but also able to be tucked in against your hip with one hand so you could use the stylus or keyboard with the other. (As she demonstrates.) The device isn't waterproof, but it has seals for fluid resistance, and it can be cleaned and wiped with care. The handle has a divot to store a stylus, but that seems to have been lost, so I just used a spare Belkin Palm stylus I had on the shelf that also happens to fit.There were supposedly two versions of the WiiN-PAD, the first being this basic slate, and then a larger unit called the WiiN-PAD MK with a 66-key splashproof cleanable membrane keyboard. I've never even seen pictures of the keyboard variant.
But it turns out you don't need the MK's keyboard anyway: you can dock it, and the dock has a PS/2 port to accept a full keyboard. The dock is a sturdy metal job with feet for the desk. You'll still need a stylus for the screen (no mouse?), but when you're at a desk you can use it mostly like any PC. Pogo pins in the base of the dock connect to the charging circuit in the slate and provide both power and keyboard data. The back of the dock has the PS/2 port, the serial port (for syncing to a PC to load apps and exchange documents, like any other Windows CE device), and the barrel jack for the power supply. I don't have the original power supply for this, but the scrapper who found it (hat tip to the Atlanta404Store on eBay, not affiliated, just satisfied) was able to start it up with a center-positive AC laptop power supply set to 12 volts. Since my usual multiadapter system didn't generate enough watts for it, I bought an off-the-shelf 12V/5A (60 watt) supply and that seems to be sufficient. The jack looks like a 5.5/2.5mm barrel jack if I'm reading my calipers right.The dock must be powered to use any external keyboard. The hole in the back appears to be for putting in a spare battery; there are contacts in the base and it's about the right size. More about the battery in a moment.
The WiiN-PAD has a single PCMCIA Type II slot, which in this unit is flaky and does not reliably recognize cards (or sometimes makes the machine freeze until the card is reinserted). I suspect this machine had a bit of a hard life and I blame the port. I was able to work around it for flash cards by worming a PC Card SD card adapter in and out until it got to the point where the card was recognized but the machine didn't seize up. I could then pull the SD card out of the adapter instead of the entire PC Card and have it reliably operate. However, it was very hard to get other cards to work in it that way; after several attempts, I decided I was likely just to do more damage and I never did get any of the Ethernet cards working that worked with my other Windows CE 2 systems. There is no separate Compact Flash slot as is common in units of this era but it does have an interesting compensation for that, which I'll show you when we get to the internals and demonstrate the machine in operation. Much was made about the WiiN-PAD's wireless capabilities, but they were only ever options. If installed, it could support old-school 2.4GHz 802.11 (not 802.11b) with WEP reportedly using a Proxim chipset. Just to see if it would work, I also tried a ProximStrangely, the model number applique on this unit has been cut off, calling it the "Data General Model 53W." This doesn't match any DG SKU system I know of and is probably incomplete (although according to the dock sticker the WiiN-PAD's official power supply is model SW173, so who knows). It's possible it was a pre-release unit, but it seems to have all other production markings and a factory-generated UPC code and serial number.
The battery slots into a very secure set of tabs and divots covered by a door that's lost its own tab and won't stay on. The WiiN-PAD's power pack is blue like the handle, manufactured by JBRO and resembles a regular lithium ion camcorder battery (7.2V, 1600mAh), but I can't seem to find a replacement that fits. Fortunately it still holds some charge. Data General even patented the unit (6,144,552, applied for April 26, 1999), anticlimatically calling it a "handheld computer system." This exploded diagram is from the published patent, with the logic board marked as number 45. The wireless board, if one were present, would be number 63.But as mentioned, it's the chip it's running that's especially unique. Since we have the rear doors off and we have some idea how it all fits together, let's crack it open and find the CPU, then talk a bit about the processor and WinCE's brief, practically unremembered support for PowerPC.
The system is essentially a big plastic sandwich. The bottom back corners of the unit have two fat screws that hold it together. When these screws are released, the case slots I'm holding together with my hand widen and the base's rubber bumper can be removed. The bumper is part of the unit's fluid resistance, so be sure to reinstall the rubber tabs back into those slots when reassembling. The handle comes off with two exposed centre screws and then two sunken ones under appliques that you can pry out with a spudger. After you remove two more corner screws thus exposed, there are no other snaps holding the case together and you can just wedge it open. The case is held together in part by the big black rubber bumpers around the screen, which are sticky and also act as a partial fluid seal. They are pressed into the mounts at back and hold with a friction fit. The LCD inverter is at the top with the pogo contacts, microphone, speaker and telephone jack on the bottom. We merely lift up the screen carefully with its bumpers and rotate it towards us, mindful that it's connected in multiple places to the logic board. The LCD is a Sanyo LM-DA53-21PTW, an 8" CSTN (not TFT) display, probably selected for cost reasons. This was apparently a relatively common part and NOS replacements don't seem difficult to find. With the screen pulled out, we can now see the backsides of two boards. The top one is the camera board and the bottom is the main logic board. The camera board isn't very complex, but I wasn't sure how it was connected with its CCD and I didn't disturb it. A single ribbon cable runs to the mainboard. Notice the 1998 copyright date. The logic board is also not particularly complicated, at least as mainboards go. The most notable landmark is an M-Systems DiskOnChip MD2200-D24 DIP in the lower right which was an early flash drive for embedded systems introduced in 1995. They were very popular devices in their time for their convenient form factors (here a 32-pin DIP) and ease of implementation, which simply exposed an 8K window onto its contents via memory-mapped I/O, while the module itself implements internal wear leveling, bad block remapping and error correction. This particular one is a 24MB part (though stay tuned). M-Systems was even better known as the developers of the DiskOnKey in 2000, the first USB flash drive and available in capacities from 8MB to 32MB, and SanDisk bought them out in 2006.Although a sticker on the DOC says "programmed" ("Win Pad"?), and at least part of the operating system appears to be on it, the DOC has a more visible purpose to the user and we'll get to what it does a bit later. We also see a KM416S8030T-GL 16MB (2MB x 16-bit x 4-bank) DRAM chip, an STLC7550 analogue front-end interface for the softmodem, a MAXIM MAX148 which is probably used for the pen digitizer, and a MAXIM MAX745EAP which controls the battery charger. The RAM and the modem chip are clustered around what is obviously the backend of a large ball-grid array, and that has to be our CPU.
Rather than try to dig out the board and turn it over, the other alternative is to remove the PCMCIA card cage which is sitting on top of it (this has a 1999 copyright date, which is interesting). The card cage is held in by four tiny bolts with four tiny nuts sitting on four tiny plastic standoffs, but the alternative was possibly snapping wires from their solder points trying to free the board up inside the case, so the cage option seemed less dangerous (and I could try reseating the cage to see if that helped the card slot any — spoiler alert, it didn't). We carefully unscrew those nuts, cuss like a sailor when they fall into the casing anyway, cuss some more when the standoffs do the same thing, and then wedge the cage off its connector with a nylon spudger. After all that work, here we are: the CPU is a (somewhat scuffed, pretty sure I didn't do that) Motorola XPC821ZP50B3, a 50MHz MPC821, though there are reasons later on to suspect that it's been underclocked here. Next to it is another 16MB DRAM chip and a ST M29W400T 512K flash chip that contains the low-level system base. Now, to get those rotten little standoffs back on.The MPC821 was part of Motorola's first set of embedded PowerPC CPUs. The PowerPC embedded line started with IBM's 1994 PowerPC 403, nearly contemporary with the mainstream 601/603/604, which had no FPU and only later an optional MMU (both standard on the 6xx), running from 20 to 80MHz. These were ultra-low-end chips meant for limited duty in things like set-top boxes and personal electronics. The 4xx series is still manufactured today, primarily by AMCC, though IBM also offers synthesizeable versions and a PowerPC 405 is embedded in every modern POWER9 CPU (including the one I'm typing on) as the on-chip controller.
Motorola, as a manufacturing partner in the AIM alliance, got into the PPC embedded world early too. Motorola already had a line of 68K microcontrollers with a special communications procesosr on-chip called QUICC (the 68360 and others), and adapted an expanded version of the QUICC supporting Ethernet, serial and I2C into the 1995 MPC821 and MPC860 PowerQUICC series, which initially ran up to 40MHz at 540mW. Both chips carried a reduced PowerPC core with a peculiar MMU but no FPU, 12 lines of parallel I/O, 4K each of I/D cache, a DRAM controller and PCMCIA support. However, although the 860 supported up to 7 serial ports, the 821 supported 5 and an LCD controller, using system memory as the framebuffer for resolutions up to 1024x1024 and a 256-colour palette. The communications processor in the PowerQUICC also added a integer MAC (fused multiply-add) for DSP operations, though this required a trip to the hardware and wasn't part of the instruction set (compare with the Toshiba R3900 core we saw in the DataRover 840). The 860 turned up in some surprising places like Kodak's high capacity DT90/DT91 print stations, but the 821's onboard LCD controller was very intentionally meant for personal devices. It was accompanied slightly later by the cut-down MPC823, which replaced some of the serial channels with USB, slashed the I/D caches to 1K and 2K, and ran at 75MHz. (The diagram above is from Microprocessor Report, May 10, 1993.)The original Windows CE 1.0 in 1996 supported Hitachi SuperH (SH-3/SH7708), MIPS R3000 (Philips PR31500, derived from the Toshiba R3900) and MIPS R4000 (NEC VR4101) cores, though most of the devices sold were SH-3 due to its higher performance. 1.0's release was bumpy for a variety of reasons and the devices' form factor proved controversial with reviewers. Motorola's market failure with its own personal devices line, notably the Magic Cap Envoy but also the Newton-based Marco (both trademarks Motorola confusingly resurrected for unrelated products later), caused them to lobby hard to port CE 1.0 to the 821/823/860 and recoup their investment, though it was never released.
Nevertheless, Microsoft hadn't forgotten. For CE 2.0 in 1997, Microsoft made the operating system more modular and substantially broadened the architectures it supported, recognizing the plethora of embedded CPU options that were flourishing then. In addition to SuperH (SH-3 but now also SH-4), MIPS R3000 (Philips PR31500 but also Toshiba TX3912, both using the same core, and the NEC VR3900) and R4000 (NEC VR4101, but also VR4102 and VR4300), Microsoft added x86 support (486DX, Pentium and AMD Élan SC400), ARM (720T and DEC StrongARM SA-1100) and finally the PowerPC. For reasons unclear the 860 was excluded, though the core would probably have worked; instead, it was intended for the MPC821 and MPC823 as well as the 33MHz IBM 403GC, the first of the 403 variants to have an MMU.
Motorola produced evaluation boards for the 821 and 860 (the MBX821 and MBX860 respectively) that vendors variously used as reference designs. These boards could run Windows CE and Linux, Wind River Systems supported VxWorks on it (which the Kodak devices used), and there was even a partial port of (of course) NetBSD. Other than that, however, both the 8xx and 403GC failed to achieve a design win with any major Windows CE vendor, most likely due to the other better supported options, and for years it was widely believed there were no production PowerPC WinCE devices ever sold to consumers — the only other mention I've seen was some sort of modular controller for a security system, though it doesn't look like that was released. Its presence on this board must have been a surprise; Pen Computing, which is one of the few publications to even mention the WiiN-PAD, didn't have any idea what its CPU was at the time. (It also gives its specs as "16-64MB" of RAM and "24-72MB" of flash, but this one has 32MB and 24MB respectively, and I don't know if there were other configurations.) It's conceiveably possible that DG's old contacts at Motorola after the AViiON 88K debacle cut them a deal on 821 boards to make up for it, but regardless of how it came to be, here we are.
Before we tour the system, it would be nicer to take some proper screen grabs, maybe even run a benchmark. Unfortunately, though hardly surprisingly, there's almost no software available for PowerPC Windows CE. I only found one package even offering a PowerPC option, but it turned out to require CE 3.0, and that particular software package won't help us anyway since we have no network right now.
So let's build some basic apps of our own! I figured you never send a PC to do a PowerPC's job, and it only seemed right to build the WiiN-PAD's apps on my MDD G4 Power Mac running Windows 2000 under Virtual PC in Mac OS 9.2.2. For this task I chose Windows CE Platform Builder 2.11 because that was the easiest one for me to get my hands on and it should generate compatible binaries with Windows CE 2.12.
Installing Platform Builder. Don't typos on splash screens give you confidence, too? I'm sure it's not a reflection on the code quality! From the Platform Builder IDE, we'll create a test application as a proof of concept with one architecture, PowerPC. This will be a very simple application that just pops up a "hello world" message box and quits. This is the entirety of the source code I personally wrote; the rest was default boilerplate provided by the template. It compiled, so we'll grab the .exe and stick it on the WiiN-PAD's SD card. Success! We can write programs for it!It's worth looking at this file in detail since there aren't very many PowerPC CE binaries around, and this one is small enough to analyze thoroughly. Notably, the executable is little-endian. No production 32-bit PowerPC was ever truly little endian and they instead implemented a per-page mode that only applies to how memory is accessed, analogous functionally to the way 68K Alpha Micro systems run little-endian by swapping bus lines. (The absence of this mode in the G5 was why Virtual PC, which depends on this behaviour, didn't work on the PowerPC 970 until it was rewritten.) Windows NT, which ran on the mainline PowerPC 603 and 604 officially from NT 3.51 through 4.0, also runs the CPU in this mode.
Nothing understands these binaries anymore, but we can still disassemble them by building a trivial Portable Executable parser, extracting the opcodes, and feeding them into something else to disassemble. It's worth noting that modern Power ISA chips starting with the POWER8 do have a true little-endian mode, including the Raptor Talos II POWER9 I'm typing this on, so we can keep the byte order the same, turn this into a phony ELF binary, and have gdb act as the disassembler.
=> 0x00000000100101fc: stw r31,-4(r1) 0x0000000010010200: mflr r31 0x0000000010010204: stwu r1,-48(r1) 0x0000000010010208: stw r3,56(r1) 0x000000001001020c: stw r4,60(r1) 0x0000000010010210: stw r5,64(r1) 0x0000000010010214: stw r6,68(r1) 0x0000000010010218: li r6,0 0x000000001001021c: lis r11,1 0x0000000010010220: addi r5,r11,12360 0x0000000010010224: lis r10,1 0x0000000010010228: addi r4,r10,12384 0x000000001001022c: li r3,0 0x0000000010010230: bl _entry+72 0x0000000010010234: addi r1,r1,48 0x0000000010010238: mtlr r31 0x000000001001023c: lwz r31,-4(r1) 0x0000000010010240: blr
If you're new to this instruction set, PowerPC has 32 general purpose registers numbered r0 through r31. r0 has unusual limitations on its use, where it sometimes acts like a zero register (a la MIPS) and sometimes like an actual register, inspiring my favourite joke instruction mscdfr ("means something completely different for r0"). As a result, most compilers only use it for specific operations like getting values to and from special purpose registers and so forth. In the incomparable Raymond Chen's multipart treatise on the PowerPC and Windows, he mentions that the only thing the Microsoft compiler used r0 for was stashing the link register with the return address. Here, however, it doesn't seem to be used for anything at all: everything uses higher registers, despite the fact they'll need to be saved into the stack frame because they're non-volatile. r0 never appears in the disassembly anywhere.
Another interesting thing about this binary is that the portion of the function prologues that load and save those registers is actually separate from the main block of code and come at the end, at least in this unoptimized build. Those segments are called as subroutines, and the individual function prologues jump into them at the right point to load or save only the registers that need to be saved:
0x00000000100104a4: .long 0x0 0x00000000100104a8: .long 0x2 0x00000000100104ac: lwz r14,-72(r1) 0x00000000100104b0: lwz r15,-68(r1) 0x00000000100104b4: lwz r16,-64(r1) 0x00000000100104b8: lwz r17,-60(r1) 0x00000000100104bc: lwz r18,-56(r1) 0x00000000100104c0: lwz r19,-52(r1) 0x00000000100104c4: lwz r20,-48(r1) 0x00000000100104c8: lwz r21,-44(r1) 0x00000000100104cc: lwz r22,-40(r1) 0x00000000100104d0: lwz r23,-36(r1) 0x00000000100104d4: lwz r24,-32(r1) 0x00000000100104d8: lwz r25,-28(r1) 0x00000000100104dc: lwz r26,-24(r1) 0x00000000100104e0: lwz r27,-20(r1) 0x00000000100104e4: lwz r28,-16(r1) 0x00000000100104e8: lwz r29,-12(r1) 0x00000000100104ec: lwz r30,-8(r1) 0x00000000100104f0: lwz r31,-4(r1) 0x00000000100104f4: blr 0x00000000100104f8: .long 0x0 0x00000000100104fc: .long 0x0 0x0000000010010500: .long 0x1 0x0000000010010504: stw r14,-72(r1) 0x0000000010010508: stw r15,-68(r1) 0x000000001001050c: stw r16,-64(r1) 0x0000000010010510: stw r17,-60(r1) 0x0000000010010514: stw r18,-56(r1) 0x0000000010010518: stw r19,-52(r1) 0x000000001001051c: stw r20,-48(r1) 0x0000000010010520: stw r21,-44(r1) 0x0000000010010524: stw r22,-40(r1) 0x0000000010010528: stw r23,-36(r1) 0x000000001001052c: stw r24,-32(r1) 0x0000000010010530: stw r25,-28(r1) 0x0000000010010534: stw r26,-24(r1) 0x0000000010010538: stw r27,-20(r1) 0x000000001001053c: stw r28,-16(r1) 0x0000000010010540: stw r29,-12(r1) 0x0000000010010544: stw r30,-8(r1) 0x0000000010010548: stw r31,-4(r1) 0x000000001001054c: blr
Now, if we're going to take a tour of this machine, we'd like to take screenshots like we did for our MIPS R4000-based "MIPS ThinkPad" IBM WorkPad z50. Fortunately there's an open-source Windows CE screenshot program, Eiichiro Ito's CaptCE, for which he released the source code under the MIT license (arigatō gozaimasu!). We'll try to build that next.
Unfortunately, this build wasn't quite so easy. It looks like this code, which was written originally for older versions of Windows CE, adds definitions for obtaining the system palette which now conflict with the operating system's. We comment that out ... ... and the call that tries to fish it out from a system DLL, and make it just a direct call instead. That builds!This tool sits in the system tray and takes a numbered screenshot every time you click or tap on it. We'll use these shots for the rest of our entry.
Before we do anything else, we need to fix the clock. On machines where the battery has died, sometimes the residual time can reflect when it was last used; if that's so for this device, it can't be later than April 8, 2003. This machine came from the Atlanta, Georgia area based on evidence I'll demonstrate (and not just based on the seller), and certain identifiers left on it trace it back to Patient Care Technologies, a home-care, hospice and telehealth software provider. It's not clear if this machine was actually in the field or only used internally for testing. PtCT was bought by Meditech in 2007. And here we are at the Windows CE desktop. Compared to other contemporary WinCE systems like my WorkPad z50 and HP Jornada 690, the desktop is rather spare, demonstrating only Microsoft Pocket Word, Inbox (E-mail) and Internet Explorer. The Power Off shortcut is because the Suspend option from the Start button doesn't do anything, and this fault I do blame on Data General. To resume from sleep, you press one of the rear buttons. There are some additional applications in the Start menu, however, and I'll demonstrate those to you in good time. Under My Computer we see a standard list of folders and devices you'd expect from a WinCE 2.x system, but our DiskOnChip volume is also exposed here. That's the compensation for not having a separate flash memory slot: the flash is built-in. Still, its presence doesn't seem nearly as convenient or useful as removable media would be, and it was probably another deliberate choice to reduce cost and eliminate another slot that couldNone of this tells us how fast the CPU actually is, nor was I able to easily see an obvious oscillator on the portions of the board I exposed. Some operations seem slower than you'd expect from a 50MHz CPU, especially with Motorola's data sheet touting it as "a high-performance embedded PowerPC core." Their data sheet even quotes Dhrystone 2.1 benchmarks, alleging 66 VAX-MIPS at 50MHz. Let's check that.
Since I'm converting the venerable Reinhold Weicker version, which was intended for command line use, we'll make it run from the Windows CE command prompt. Microsoft's C/C++ compiler seemed brain-damaged here (in particular the preprocessor) and wouldn't ignore parts of the timers file not meant for Win32 even with the correct defines set. I ended up moving that snippet over to the main code, as well as creating a stub WinMain() that just calls into the main Dhrystone program. As my systems here are MIPS R4K, SH-3 and PowerPC, I built optimized versions for all three. The register option was selected. I ran the benchmarks on my "known" systems first just to make sure I was getting sane results. Pen Computing had benchmarks for Jupiter-class CE systems including the WorkPad z50 here, a 133MHz NEC VR4121 (MIPS R4000). They reported a VAX-MIPS of 72.36; we got 78.830 on 1.5 million runs. At about 9% variance, that puts us in the ballpark. Our next datapoint is my HP Jornada 690, a 133MHz Hitachi SH7709A (SH-3). Pen Computing doesn't report a VAX-MIPS in that table for the J680, its close sibling with the same CPU, but we can extrapolate an expected score of 88.87 from the 66.82 showing of the LG Phenom Express with a lower-clocked 100MHz SH7709A. Here we get 90.528 VAX-MIPS on 2 million runs, a variance of just 2%. With those figures in mind, the WiiN-PAD is mush by comparison — 27.976 VAX-MIPS. That's pretty bad, and way off from Motorola's advertised 66, even keeping in mind that figure was likely a marketing one under ideal conditions. One possible explanation could be Microsoft's compiler here is worse on the PowerPC than it is for the (better and longer supported) SuperH and MIPS families. We already know it generates somewhat unusual code; although I wouldn't think that the omission of r0 would cause a massive difference, that's still one of the 32 registers it's not using at all, and Dhrystone's use of register might make it more sensitive to it. Alternatively, maybe there's power-saving hardware or clock slewing or some such that saps its performance, though it was plugged in and charging the entire time.A better theory, however, is that it's simply not running at 50MHz. The 821 also comes in a 25MHz part, XPC821ZP25, and if it were downclocked to 25MHz (33 VAX-MIPS) instead of 50MHz then that would be not too far off our observed value (18%). Data General might just have been using a 50MHz part here because that's what they could get and ran it slow for power savings. Alternatively, if we do a straight scale we get a rate of 21.19MHz, which seems a little slow but not ridiculously so, or it could be a combination of any of these factors. If I find a second one, it would be interesting to see what it's running as well — though I don't think I'll run into another one of these anytime soon.
Overall, the WiiN-PAD appears well adapted to its purpose and one with a wireless option would likely have made a very compelling clinical device. The PS/2 docking feature is great, the case is well-designed and the dock and hardware are robust. But it's slow, it's got obvious (though not crippling) bugs, and even its built-in software suite is meager — to say nothing of the fact that the only other software it can run are the programs I wrote specifically for it. I'll not ding it for the PCMCIA issues, which are likely due to rough treatment, but everything else are black eyes. Still, I like it. It's cute and looks good on a desk, it can do some useful work, and it's very unlike many other CE devices out there. I get more wear out of my WorkPad today, but I certainly could have seen myself using this in 1999.
At any rate, let's finish our story. The WiiN-PAD had existed for just a handful of months before storage specialist EMC announced it was buying Data General in August 1999 for US$1.1 billion (in 2024 dollars over $2.05 billion). The price surprised industry observers somewhat, but not the buyout itself: EMC was not only eliminating a competitor in storage systems, they were also acquiring a mid-market storage product in CLARiiON that their existing high-end Symmetrix line didn't serve.
EMC was only interested in Data General's storage systems, but the terms of the buyout required them to maintain the AViiON line and not sell it for at least two years. No such condition applied to any other division of Data General, however, and EMC management swiftly shut down the handheld line (and other units as well); the September 16, 1999 build date for this unit's ROM may well be the last update it got before it was discontinued. Although there appears to have been some support for PowerPC at least in initial releases of Windows CE 3.0, assuming that single executable isn't otherwise defective, Microsoft had already eliminated PowerPC support for Windows 2000 and it definitely wasn't present in CE 4.0 or later. (Interestingly, the PowerPC-based Xbox 360 console used big-endian executables on a highly modified Windows 2000 kernel, the last gasp to date of Microsoft's support for the architecture.)
As for the WiiN-PAD, I could find no record of new computer hardware developed subsequently under the original Data General name nor any company that produced any more of them, and it appears to truly have been Data General's last official computer system. The WiiN-PAD's IP, like most other components of the former Data General, is now part of Dell after it bought EMC in 2016. Data General's original dg.com domain was subsequently snapped up by discount store chain Dollar General, and the modern Data General trademark today is owned by unrelated Spanish networking corporation Landatel who purchased it in 2023.
I've gotten a request for the software, so I've put it up on Github along with the builds I generated. Have fun!
Another brilliant article! As a developer and product manger of that era I love these pieces!
ReplyDelete