For one thing, not all car stereos have an aux input. For another, it would cost hundreds of dollars more per year for a dumbphone user to switch to a phone that plays MP3s. Verizon and Sprint won't activate a smartphone on a dumbphone plan, and AT&T is known to "cram" a data plan onto a dumbphone SIM if it is ever inserted into a smartphone.

I don't see how "You need a tissue?" or "Go make me some copies" is so hard to say.

You must not be an American. Due to poor or nonexistent public transit in much of the United States and a perception that public transit is for people with poor hygiene, a lot of American workers end up driving a motor vehicle to and from work. You can't wander YouTube while driving, and even if you can take good public transit, you still need an expensive data plan to do so on the commute.

In my experience, a radio doesn't "play[] all manner of music". It plays only music published by labels big enough to afford payola, and this music is inevitably non-free.

There's a cap on listening from "mobile" devices unless you pay.

The only reason those lawsuits happened in the first place is that the Monitor ROM (the BIOS of the Apple II) used entry points at fixed addresses in $F800-$FFFF. Fixed entry points mean that the implementations of BIOS routines have to be the same length in bytes as the existing routines, which pretty much ensures that only one specific copyrighted implementation will work. The IBM PC BIOS was more easily cloned because it used a proper syscall mechanism.

How do people discover these services and these free-culture-supporting bands in the first place? Not everybody has a data plan, a car stereo with an AUX input, and the motivation to keep plugging an audio cable into the phone. This means people keep discovering RIAA bands through the convenience-by-default of in-car FM radio.

If you know what a "PHK PLB" is,* you'll see how the 65816 is still very, very PAE. The 65816's address space is 24-bit, but a machine register can hold only a 16-bit pointer, so pointers to anything bigger than 64 KiB have to be manipulated in a 3-byte variable in the stack frame.** The 24-bit address space on the 65816 is more like the "segmentation" on an 8086. I'd amend your claim slightly: the move to 64-bit CPUs is more like the move from 65816, Z80, or 6809 class CPUs to the 68000 family.

Call me guilty. I designed a mapper that subsumes NROM, AOROM, BNROM, CNROM, and UNROM in a fairly slick way, and a commercially released homebrew multicart uses it.

* 65816 mnemonics to push the code segment (K) and pop the data segment (B).
** The stack frame or "direct page" replaces 6502's zero page.

Thank you for the detailed analysis and the recommendations. Bookmarking.

If ARM Cortex-A15 supports 40-bit PAE, I don't see how it's so x86-exclusive.

Provided you're willing to split your application up into hundreds of processes, each responsible for managing a few GB of RAM.

Same diff. In the wired market, the other carrier is cable. There are places that can get service from Verizon but are unserved by cable.

PAE? Good luck trying to split your application into dozens of different processes just to fill memory.

Right now it's either on the device or in the cloud. And users have every right to be concerned because unless one subscribes to broadband at home and happens to be at home, files in the cloud are limited to a couple GB up or down per month. Does the OS attempt to hide whether files are in iCloud vs. Dropbox vs. Google Drive vs. the service formerly known as SkyDrive? If not, then inserting a memory card could be handled like logging in to one of these online storage services.

Apply 1.21 GW of power for 2.47 seconds and you will have done 2.99 GJ of work.