Posting this to my favourite forum over at gp32x:

Word to the wise –

I don’t know how the TS (touchscreen) on the Pandora display is made/etc/so/on, but for PDAs I’ve done an infinite amount of development over the last 15 years. The way you wreck the TS on a PDA touchscreen is this — _removing_ a screen protector. Putting them on is an art (keep a credit card handy for pushing out bubbles if its a soft film kind), but the trick is removing them — especially if its been on for awhile. (Most protectors suggest removal and cleaning every month or two, because they want you to buy more; but in practice unless you hammer the hell out of them, you can leave them on for months or years. But when you take them off, the things are pretty suckered on there — if you pull them at a 90 degree peel, then you’re essentially pulling directly up on the TS and separating it from the underlieing screen. And what that means is you’re creating a very good opportunity to cause displacement in where the touch is registering, relative to where you’re actually touching it.

And guess what — when you’re applying your screenprot and you get it not quite right, you’ll want to peal it off and retry right?

Be gentle — last thing you want to do with your screenprot is bugger up your TS day one :)

I don’t have time right now for a full and proper right up, but hopefully these tips will get you going or experimenting.

Aside; I think DJWillis has a script that will pull the firmware out of NAND and deposit it on an SD card ready to go (more or less), so that will probably come to light soon. For now, suffer with my quike write-up!

The full ‘raw’ boot process goes through a number of steps (ie: The OMAP itself knows how to read a bit from a FAT filesystem on SD, and bull up a file called MLO to be first stage of the boot process, which in turn can pull up stage 2, etc.) I’m not going to go into that here, but our good man DJWillis posted in some detail here at Distant Earth

Fortunately, most people will have a flashed unit, where the boot files (such as MLO/etc) are in NAND and good to use. This makes the whole process a lot easier and less fiddly – we can piggy back on these guys, and our dear friend notaz has added some grand features to make booting from SD while using these bootfiles a piece of cake. Namely – you can set up a file called ‘autoboot.txt’ to tell the system what to do with a firmware on SD when the user doesn’t do anything special, and you can set up a file called ‘boot.txt’ to instruct the loader what to do when the user explicitly asks for an SD boot.

I’m writing this off the cuff; normally for development we booted the full bootfiles from SD, and after doing that several thousand times I can tell you how to do that in my sleep (maybe I should, for completeness, in another article.) Due to being over-busy the last couple weeks I’ve not had time to fiddle with this approach yet, so please let me know if the sun crashes into the Earth.

The basic process should be something like this…

Prepare the SD card

Nowadays, this is a much simpler thing than it was earlier during Pandora’s development lifecycle.

Format the SD as one big ext2 partition.

For Linux, it should be a piece of cake; for Windows/OSX you may well need an ext2fs driver, etc, but of course I heartily recommend either dual botting with Linux (or FreeBSD!), or setting up a VM (such as VMWare, VirtualBox, etc) to do your development and SD hacking in.

(You can also use ext3 as far as I know, but in my experience ext3 seems more prone to meltdown when cutting the power without a sync, and also took much longer to perform sync after large volume of data writes. Hence, ext2fs was my choice most of the time; note also that ext2fs does not like to be cut off before a sync, so when booting from SD .. be sure to always shutdown normally, otherwise you risk SD corruption leading to a fresh format; not really a problem since you’ll likely keep all your user data on SD2, but still.)

A few minutes ago, I wrote up the following; it doesn’t have to be like this anymore, so its much easier to just skip to the next section now ;)

Out of date:

In short; you’ll want to partition the SD into two (or more of course) partitions — the first one being small and formatted to FAT, and then the main body being a larger one, formatted (ideally) to ext2fs.

EDIT: Actually, it turns out boot.txt can be read from ext2fs, so we do not need the FAT partition at all; just format the whole SD as ext2fs ine one big partition, drop boot.txt on it, and good to go.

Order is important — first should be FAT, the second should be ext2fs. (Historically, we’ve used a small first partition since OMAP seems to not like giant multi-GB partitions, but thats probably a non-issue for our purposes here.)

The long version:

Edit: Make one big partition, and format it to ext2fs; previously I noted the two partition approach:

To partition and format the SD under Linux, this page seems a pretty good how-to: Linux Beagleboard Guide

For Windows, I imagine using the built in Disk Manager tools would be sufficient; sometimes you need to hit the SD with a good solid format, often using Panasonic formatter or the HP formatter, etc; they do a good thorough job. Try this guy, for instance: HP Formatter (requires USB SD widget, often will not recognize built in SD slots on a laptop)

Set up boot.txt

The NAND bootfiles take care of most of our heavy lifting; we do not need to set up MLO, u-boot or other handy bits. (Thanks notaz!)

We do need a boot script to instruct how to load the system. I’ve not had time to try this file out, so please let me know how it goes; this should boot the kernel from NAND (flash), and then start up the firmware from the second partition on the first SD (in your ext2fs partition.)

Using your favourite TEXT EDITOR (vi, emacs, windows Notepad, etc .. but not MS Word, etc) create “boot.txt” on your SD, in the FAT partition. As always, thanks to notaz:

setenv bootargs root=/dev/mmcblk0p1 rw rootdelay=2 vram=6272K omapfb.vram=0:3000K
ubi part boot && ubifsmount boot && ubifsload ${loadaddr} uImage && bootm ${loadaddr}

The firmware

You could probably just copy much of the firmware right off your NAND onto your second partition of your SD, using the Terminal or even Thunar directory browser. ie: cp / /media/mmcblk0p1 and good to go :)

An _OUT OF DATE_ firmware file in tarball format can be found here: Codejedi site

Untar this into your ext2fs partition, and you should be good to go.

(One untarred, you could further edit it to change /etc, add more packages, modify its boot, etc. Do that later if you want, a firmware on SD is pretty handy; pop it into your parent Linux box and hack away!)

Fire it up

When powering up the Pandora, hold right-trigger down to get presented with a boot menu; here you can select an alternate boot option (other than NAND, say), or power the unit off again. Pick “SD1:1″ and hit “B” to start the boot process, and it should read your boot.txt and fire up the firmware, without touching your NAND (beyond the bootfiles/kernel.)

Let me know how it goes, I’m jugglgin 35 things right now, so can’t keep on top of everything :)

This is a quick write-up just to provide a tipping-off point; if you would like a more in depth article, let me know (skeezix skeleton org) and I can write up something when I get a moment; I’m hoping that a few tidbits here will just provide some ‘eureka!’ moments and folks will be be off and going :) I wrote this seat of my pants, so don’t expect it to be very well organized!

Components you need to build ‘hello world’ for your Pandora (or other non-native platform.): a toolchain, libraries, and somewhere to run the toolchain.

Where to Run:

This usually a ‘given’ — you run on your PC, the very same one you’re using to run your web browser on

If you’re a little nutty like me, theres lots of other options, but normal folks – just skip this:  You could well build on a remote shell server, or your Pandora or smartphone, or any number of options (cloud based server?) So for most people.. think — you need a toolchain for Windows to run on your Windows box (or under cygwin, say.) But what I do is run from VMs, which I copy between USB and hard drives and all over the darned place. VM – a virtual machine. I’ve built up a number of them for various specific uses, and carry them around on a flash thumb drive (pick up a 16GB or 32GB flash drive for your keychain, say. Boot time is pretty fast actually, but shutting down the VM and storing the RAM snapshot etc back to a flash drive takes a few minutes. You could copy it to the local hard drive before/after if you wanted.) You could use the VM on a machine and never move it around, or transfer it on SD cards, whatever you like to do. (ie: There are uses for all combinations .. you might never move the VMs around, but want 5 different testing or build environments, or maybe you need move them all around all the time.) As an aside, an interesting hack is to make your flash drive bootable — I can boot from my flash drive into an OS, and I can run the VM off the flash drive to get the VM. To do both, I make a small bootable OS that has VMWare Player on it (use VirtualBox or whatever you prefer), then mount the VM and go. Or just use VMWare Player on the native OS wherever you’re sitting — so on the flash thumbdrive, I usually carry the VM, VMWare Player for installing to various OSes, and a bootable OS on the thumbdrive itself :)

I bought VMWare Workstation years ago and still use it, but you can get away for free with VMWare Player (and hand edit the conf files, or use online tools to generate them.) But VirtualBox and a half dozen other products are free or vary in price, so look around. Either way though you just get a VM hypervisor, a blank disk image (I keep zipped blank drive images around in a tiny zip file; since they’re _empty_, they compress like 99%, so one tiny zip has 1GB, 5GB, 8GB, 16GNB disk images, and its a few K of zip :), and OS .iso’s — suck down a Ubuntu .iso, and you can set it up into a VM in 20 minutes.

But for most people, they will just run the toolchain in their native OS.

Toolchain:

This is the ‘confusing part’; you can either roll your own (ie: build a cross compiler from sources, which takes an hour), or you can pull down someone elses prebuilt toolchain.

For purposes of the 5 minute setup, just grab CodeSourcery’s prebuilt gcc for the command line:

http://www.codesourcery.com/sgpp/lite/arm/portal/subscription3057

When using a prebuilt toolchain, just pick a directory and unpack it. Add it to your path, and you’re done.

ie: Create /code/toolchain and extract it all there, then add /code/toolchain/bin to your $PATH. Now you’ve got arm-none-linux-gcc (for example.) In CSL’s case, it comes with some basic core libs (like glibc) etc, so you can spit out Hello World there.

Consider: Extract, set path, build hello world — thats what, 1 minute of work, after the download?

Libraries:

For any remotely useful application, you need to link against libraries. And I dunno about you, I really don’t want to compile 200 libraries to get going, but you could do that. What I do, is use a copy of the Pandora firmware and pull all the libraries out of that.

We didn’t modify any headers, so you can compile against whatever Linux headers you already have (/usr/include); if you’re on Linux and don’t have them, you can ask your package manager to fetch them for you. If you’re on Windows, well, suck them out of a Linux distro’s .iso :)

As I code in a Linux VM (on a linux box, or a Mac, or Windows, or whatever), the Linux VM has my native and cross compiler toolchains and all the headers.

An OUT OF DATE copy of the Pandora first firmware is here:

http://www.codejedi.com/pandora/libpnd/pandora-xfce-image-omap3-pandora-20101705-image-for-checking-fixes.tar.bz2

Look in /usr/lib there, and you see a pile of libs you can use for linking.

Remember, those are already on real Pandora’s, so you don’t need to include them in your app or pnd-file. They’re _just for linking_, and then when you build hello.bin for running, thats the only file you need to copy around.

NOTE: Your toolchain’s linker naming policy might be different, so libfoo.so.1.2.3 in /usr/lib of the firmware might not get found when you -L to it; I created a short sh-script to ln -s to common names.. so libfoo.so.1.2.3 also gets a symlink of libfoo.so.1 and libfoo.so, so that it’ll be found by my cross compilers ld.

Tieing it all together:

1) Preparation; -> well, setting up a VM might take you 20mins, but I don’t count that in the timer; I already had one :)

i) Set up your VM, or whatever OS you want to run your toolchain in. ie: Install an OS. Make it have Linux headers, which is probably just default for many Linux distros, or maybe you need to add the basic developer package. (For random libs, you’ll want to pull down other packages too.. for SDL, your Linux distro will have the native libSDL, but not the SDL headers; so you might well need to apt-get sdl-1.3-dev (or whatever) to get the headers. We really should supply a list of packages to get, so that you have all the headers in your native linux that the Pandora would have libs for. But I digress, and its not hard to piecemeal them over time.)

ii) Build, or suck down a prebuilt, toolchain -> depends on your bandwidth speed of course :)

2) Set it up

i) Set the toolchain up in some well defined path; Try something like /devo/toolchains/arm/codesourcery/2009-q3/ (say), so that you have …../2009-q3/bin with the tools in it. It will use relative paths, so can find oits own libs and bits it needs. -> if using CodeSourcey (say), we’re saying: untar or unzip the files, and that takes .. 2 minutes.

ii) Set your PATH; something like “set PATH=${PATH}:/devo/toolchains/arm/codesourcery/2009-q3/bin”; then when you type arm-none-linux-gcc and hit return, it’ll say “no input files” instead of “file not found”, and that means you’re good to go. -> 30 seconds

iii) Extract the Pandora firmware to /devo/pandora/firmware/prerelease (say), so that …../prerelease/usr/lib has all the lib*so* files in it. -> 2 minutes

— thats it, 5 minutes of setup :)

3) Use it

i) When compiling., specify -I/usr/include – many prebuilt crosscompilers will drop native paths (rightly so), thinking you’ll tell them somewhere else to go; but I just use the native headers anyway, so -I/usr/include works fine

ii) Specify a lib path; something like -L/devo/pandora/firmware/prerelease/usr/lib (or whatever) will make most things happy; sometimes you’ll need to specify a hint to ld so that when it pulls in one lib, and that lib depends on another, it’ll still find the subsequent ones; its all pretty easy stuff.

iii) Set your CC/etc in the Makefile, since you want to use arm-none-linux-g++ instead of “g++” (the native one.)

Piece of cake!

I know, I’m glossing over quite a lot here, but feel free to ask!

We’re nearly there with the Pandora firmware; really, we’re aiming several arrows at once — the hardware, the kernel, the OS distribution, and the userland. We’ve got a body on each piece really, with some overlap.

Most people never think about the plumbing; you press a button your ipod, and the hardware clicks, the OS clacks, and something happens. But we developers build that stuff, make it all happen. Make it so you don’t have to think about it.

The last couple days, I finally got around to hooking up the Pandora button to pop up the menu; vimacs is our Script Lord — that man knows some shit :)  Likewise, you close the device lid and the screen goes off, and we were even so generous as to make the screen come back on when you open the lid. Just tonight I whipped up blinkenlights — when the battery gets low, the appropriate LED will throb at you, a friendly suggestiong to plug in or save up. And lots of other hacking lately, to get the user experience a little tighter, a little more smooth. EvilDragon, he’s good with figuring out what people want, and helping guide us .. arrows.

Good times; I really enjoy being a plumber, sometimes :)

I’m super busy with work/life right now so can’t say much right now, but have to at least post ..

THIS IS THE SEXY!

Heres a quick pic; this is the prototype (not final) case, but its still gorgeous.

http://www.codejedi.com/pandora/rev3_unbox/IMG_0098.JPG

People have often been asking how applications and firmware will be packaged for the Pandora, and other variations — how will apt-get work on the device when there are SD cards present, and so on. Now while the information that we’re letting out is still subject very much to change, I did reply in a thread on the forums and I thought the discussion might be of interest to folks.. so I thought I’d repost it here.

See thread here

The main post I made, warts and all, is reproduced here. Many follow-up questions and answers by various team members are posted. Also see a discussion on the Unofficial Pandora Blog for some extra flames and discussion.

You can of course do anything you want; your box, open source evreything, make it do what you like wink.gif But let me discuss a bit from a normal user perspective (ie: not hacking in knee deep.)

The normal unix filesystem will be on NAND. ie: /usr, /etc, all that. You can reflash that to put a new firmware in and several groups are even working on alternative firmware (ie: gentoo etc.) Anyway, consider — if you run a normal unix packager, it doesn’t know about SD versus the normal filesystem. It would be unadvisable to put user homedir on SD by default, since you might not have SD in, or might swap SDs, or any number of scenarios.. so user homedir must also be in NAND by definition. This means if you use a normal unix packager like apt or whatever, its going to install things in /usr/local/bin say, and your homedir ~ etc, all on NAND, which is fine, it’ll work.

But what if you keep installing packages that way..

1) They’re on your NAND; which is cool, no worry about losing them. But..

2) You have limited NAND space; you might want to reserve it for user documents that you find important or whatever.. but do you want ot fill it up with new builds of firefox etc? I mean, if you want 500 packages, your NAND will not have the space for it.

3) The firmware lives on NAND; if you fill it up, it might be hard for the pandora team to guarantee theres enough space for next firmware update (ie: not a reflash, but a patch, say.) So it’d be nice to not have everyone by defaut using a packager that fills up the limited resource

4) .. and so on.

The trick is unix packagers assume the filesystem is where they want to put stuff. It is less likely to be the case on a handheld.

(You could format an ext2fs on SD and mount that and so lots of tricks, but we want to make it simple. For the knowbies, they can do all that of course.)

So a bunch of keener fellows have been banging out what we think is a better idea.

THIS IS ALL UP IN THE AIR AND IN DEVELOPMENT, SUBJECT TO CHANGE ETC AND SO ON.

The nitty gritty ideas we had were to divide NAND up into a couple regions; a firmware chunk and a user homedir chunk. The trick is we could use unionfs (or aufs, a newer union-fs style system). We’d make te union setup so that writes to the firmware filesystem are actually written to the user section in your homedir somewhere, an the unionfs proprerties make it so the system doesn’t see this. ie: You write to /usr/foo and it ends up in your homedir in NAND, but reading /usr/foo works still. This way if you overwrite stuff in the firmware and blow it up, you just wipe your homedir and reboot, and bam, you’re back to a fully working stock firmware. For OS patches we can mount the real NAND fs instead of the union, update the filesystem, remount he union, and poof. Seems brilliant to me, and allows normal packagers to just work, reasonably risk free.

Thats the firmware side.

The app packaging system we’re designing uses some similar tricks, in theory. (We’re still bangin it out, but its looking cool so far.)

We define a new package type, .pnd. An app could be whatever.pnd, and it includes the PXML file as defined by ED. (Though we’ve modified the contents of the PXML a fair amount since his last update.) The pnd could be a number of file formats (think of it like a zip file with a PXML appended to it, but we’re likely going with an .iso format. Make an iso of the directory you want, append the PXML, rename to .pnd .. good to go.)

Insert your SD into the pandora, a daemon wakes up and detects the .pnd files in its searchpath, and it generates the .desktop files for the launcher in a configured location. (It could also be made as a module for matchbox or other window managers, but our current thoughts are to spit out .desktop files since they’re pretty standard and should work simply.) you pop out the SD, the daemon wakes up and rescans, and removes the .desktop files in question. (It should also handle if you just rm the pnd file from within the pandora usage, etc.)

In essence, you go to the gp32x archive (say, or others), download a few .pnd files, drop them on your SD, and thats it. Just works.

More nitty gritty — the idea is that when the system finds these pnd files, it uses filesystem tricks again.. using fuse filesystem it the pnd files are mounted as .iso’s into the filesystem, based on their unique-id in the PXML say. ie: mount whatever.pnd into /apps/123456uniqueid123 and the PXML file part identifies which file in there is the executable and icon, etc. The launcher shows the icons based on the.desktop files, and when you tap one, the launcher knows which executable to run, right out of /apps/123etc/.

What makes this extra clever is unionfs again (ao aufs etc), so that any writes back to /apps/123etc/ go to the SD card instead (but the app doesn’t have to know.) ie: Say, to SD card /pandora/appdata/123etc/ dir.

Anyway, the trick is you download a .pnd file, it gets shown in the launcher based on its PXML config. you tap to run it, and it gets mounted, run, and unmounted on exit. Everything works right off your SD including new/changed data. Your .pnd file remains clean (you can copy it to someone else, etc, or delete it) and your apps data stays on your SD card.

You can also unpack the .pnd files yourself into their directory and just drop it on the SD card. In that case, no mount voodoo is needed, so writes back to /pandora/apps/whatever just stay there, for those who want to keep it all together like a traditional gp2x app.

As to locations..

I’ve overkilled the design really.. everything is based on searchpaths. So pandora apps will use libpnd as their infrastrucuture (to save everyone rewriting all this every time.) A simple call will check the OS and find out the config search path (which can be altered in NAND as you see fit.) Then any time an app needs a config, the config search path is seeked to find it.. so you can use the default config in NAND as shipped, or put replacements of those config files on SD. (Pull out your SD and everythign reverts to defalut firmware config.. seems nice and safe to me!)

The search-path for where apps can be sought after is configured; by default the pnd files and unpacked pnds will be looked for in SD (both) in /pandora/apps if I recall right, including any subdirectories there so you can organize as you see fit, and also a path or two in NAND for built in pnds. (built in apps will probably be built into the normal filesystem like any unix app, but we could possibly include some apps as pnd files so that the user can remove them if they don’t want them, to get NAND space back.)

Now, if you want pnd files to be droppable right in SD root, you just add a /pandora/conf/apps config file and put the search path into it, or edit the master conf file in NAND (/etc/pandora/conf/apps is my current plan for that.) Thus you can put .pnd files anywhere you want, but we’ll have a defalut behaviour as shipp.ed

Now, before anyone complains, every single path and decision there is in conf files, so you can specify where you want to do things.

And you can use normal unix packagers.

And you can alter things to work as you see fit.

So I think we’re keeping the usual flexibility, but also making something dumb-simple for new users, and yet you can play with it to customize it for those woh want to roll up your sleeves. There should be little risk since you can just eject SD cards and/or wipe oyur NAND homedir to revert to built in functionality. And in a pinch, if you wipe everythign out, you can reflash the whole firmware.

Safe and awesome.

This one is for Pickle, the eminent DOSBox for gp2x expert. This man slaved and slaved to wring every last bit of hot DOSBox action out of the little gp2x. He’s been helping us out sorting out configs and fiddling to get DOSBox working on the Pandora. I asked what a good game to check would be, as I had been trying out some ‘lightweights’ .. he suggested WC2. Briliant I thought…Check it out..

This is a stock DOSBox (by which I mean compiled from source, with no optimizations _at all_, and not even tuning the config. Its got the wrong cycle settings and full audio enabled and installed _from my Warcraft 2 ancient CD_. DOSBox in dynarec mode though, so its working its ass off here :) The good news — runs nearly full speed, and fully playably. I’ve worked through the first Orc campaign mission. USB mouse and keybord.

Aside, I also tried Wing Commander 1 — peachy. Civilization 1 — perfect. Wizardry 7 Crusaders of the Dark Savant — perfect. System Shock 1 chugged it, but thats fair .. its all software math emulation to do the 3d mode, but possibly with high enough clock and optimization.. maybe. We’re just scratching the surface here.

The only thing thats chuggy at all is scrolling around the screen by mousing to the edge; was that smooth back in the day? Its possible with more units it would suffer more as this first campaign is nothing, but still.. this is quite an achievement.

Pandora was set to 800MHz .. and the Panda can go higher still; I probably should’ve tried for 900 or more to see if it corrected that one nit, but I was too busy drooling :)

Edit

For those of us so mightily curious, here is Dune 2 running; it is also playable (though I didn’t complete any levels, it seemed just fine to play.)

Was chatting with cpasjuste in IRC and he’d noted that before he even received his pandora devkit, he’d done a few ‘quick ports.’; ie: Just getting them to compile in the tool chain we’re all switching to for the device. I offered to give them a run so he wouldn’t have to wait until tomorrow to find out if they worked and to our surprise.. they did! (You would think a run before even testing it once would fail…)

So I’ve already ported OutcaST (gp2x version that uses SDL that I was doing Wiz speed testing with) to the pandora last night (a quick port!), and now cpasjuste has ported Hatari (another ST emu), HUGO (TG-16 emu) and SMS (Sega Mastersystem emu.) His Hatari worked pretty well out of the box (including sound!), and the SMS as well pretty good; HUGO had some minor oddities easy to fix when he gets his dev board. FWIW, a USB mouse plugged into the Pandora worked on the GEM desktop, too, right out of the box. How hot is that?

I’ve got performance numbers for my OutcaST but I’m not sure I want to post here about them yet. Suffice to say that the pandora _blows the hell_ out of other handhelds; same clock, same naive port, same unoptimized SDL used for the display backend, so on and so forth (I have details in a private thread.) Much more blown away than I thought, too.. so the Pandora is both easy to port to, and frighteningly fast!

Cheers cpasjuste for your quick work, and to notaz for the pandora kernel and SDL ports!

Some quick shoddy pics (Sorry!):

OutcaST running, displaying the GEM Desktop

Hatari, in A_133 Automation loader for Xenon 2

Everyone (me included) is already bubbling over with excitement and drama and cannot wait for the true Christmas day when the devices start shipping. With the devs being so utterly busy, I thought I might take a few pics of the just-arrived dev kit; maybe a few people will enjoy the pics; a few more will be relieved that things are in motion; finally still even more will be happy that there is another conduit for some information without bugging the poor guys. Mike agrees its okay for some leaks :) Theres not a lot of free time for me, and I’d rather be hacking anyway…

But if you do have any specific requests for pics, let me know :)

YES, I realize these are very nearly the worst pics ever; I’m no camera snob. I do need a tripod for steady shots, and some way to get diffuse lighting in. Daytime shots with a steadier hand.. I’ll do that next week when I’ve got more than 30 seconds and don’t need to work on installing bootstrap code :)

THIS IS NOT THE FINAL PRODUCTION BOARD. This is a mark 2 dev kit board and break out board .. which is to say it is relatively likely the final pcb, but the devs are surely able to change things as they see fit.

This is part hardware p0rn; part the excitement of being this close to starting some hacking on the bare metal of such a powerful and teeny little beasty. And equal parts fear and annoyance for bloody UPS leaving the package upon the steps in front of my house for a full 10 hours before I could get there to ensure it was safely cuddled in my loving arms.