Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts in Hardware

Boom: the Return

No comments

A few years ago I wrote a series of posts about Apple’s then-new Lightning connector for iOS devices:

No doubt you’re noticing a trend there… 🙂

Anyway, the recently-released iPad Pro seems to have the much-awaited USB3 capability on its Lightning connector. It does ship with a Lightning-to-USB2 cable, though, and USB3 capability isn’t mentioned in the tech specs.

The main objection to this actually happening is that Lightning, with its 8 pins, doesn’t have enough pins to support the standard USB 3 specification. This is, again, the old assumption that Lightning cables are “just… wires leading from one end to the other”.

To restate what I posted previously, if you actually look at the USB3 pinout, there are the two differential pairs which Lightning already has, and one additional pair for USB2 compatibility. So a legacy wire-to-wire USB3 cable would need 9 pins — but, remember, Lightning connectors don’t work that way!

In other words, if you plug in an old Lightning-to-USB2 cable into an iOS device, the cable itself already has to convert the two differential pairs to USB2’s single pair. So, no need to have the extra legacy pair on the Lightning connector itself — a future Lightning-to-USB3 cable will generate that as well, and use the two high-speed pairs when plugged into a USB3 peripheral. The current pinout is, therefore, quite sufficient.

Watch Update

No comments

Tomorrow (we suppose) the Apple Watch will be out. For months, there’s been lots of interesting documentation on Apple’s site — but it’s all about WatchKit, the framework used on the iPhone side to run “Watch” apps. Almost nothing about the Watch itself. I think most of my previous speculations were confirmed: specifically, the part about the Watch mostly being a remote display for the iPhone:

Perhaps… just a sequence of drawing orders? The important part is that there’ll be a single process on the Watch for doing the UI, and all the application-specific parts can be offloaded to the iPhone.

So, for now, the application logic will all be on the iPhone side — where the actual WatchKit part runs — and “assets”, meaning storyboards, xib files, and PNGs with pre-rendered icons, buttons and so forth, are downloaded to the Watch and displayed as needed. My back-of-the-napkins calculations about battery life (around 15 hours) still seem valid: Tim Cook said that you’d have to charge the Watch every night. I also said:

Watch OS … will not be a stripped-down iOS; maybe even not a Darwin derivative. It will be a highly optimized embedded system that runs as few processes as possible. It will be very robust because it will be able to do only a fixed set of functions.

Of course, this clashes with everybody else’s assumption that of course the Watch will be running iOS. Apple continues to be very careful about this: the OS that actually runs on the Watch is named nowhere that I could find. Likewise no hardware specs beyond the two screen’s pixel sizes were revealed. Details about the OS may not be revealed until next year, when developer apps supposedly may run on the device itself. It might make make sense for Apple to repurpose, say, the OS running on the smaller no-app iPods.

Beyond speculations about functionality, rumors have concentrated on price and updatability. I’m not competent to speculate about prices, but John Gruber’s final thoughts on the issue seem very reasonable.

Opinions are split on updatability, since few of Apple’s products can be upgraded, and none can have their hardware updated to a next generation. Then again, here’s a completely new type of product, smaller and (in some versions) more expensive than any other; it’s also, perhaps, the most personal Apple product ever. If you get an expensive Watch, say, as a graduation present — with an engraving, perhaps — you’ll be very reluctant to dispose of it and get a new one in a few years, even if the new version does much more.

At absolute minimum, the battery will have to be replaceable, and in my opinion, the entire Watch module (probably including the battery, probably excluding the display) will be upgradeable for a fee once a better version comes out — maybe not forever, but for at least 2 or 3 generations. We’ll see.

Apple’s (pre-)announcement of the Apple Watch left the tech world in the usual disarray. Is it an expensive knock-off of Android watches (people tell me there is such a thing!)? Is it an attack on the high-end Swiss watch market? Is it an attack on the low-end Japanese watch market? Is it an even more transparent lock-in attempt on soi-disant “Apple fanbois”? I’d answer “no” to all those questions, but right now I’m more interested in the hardware and software technology of the watch.

Notice that the above link doesn’t mention iOS anywhere, but this other link has the magic word: WatchKit. Quote: “WatchKit Apps. Soon your favorite apps will feature controls and interactions unique to Apple Watch, enabling you to enjoy them in dynamic new ways.

Speculations about WatchKit since then usually have mentioned one or two assumptions:

  1. WatchKit will be written in/accessible only from Swift;
  2. WatchKit apps will run under iOS on the Apple Watch.

The first is, of course, wishful thinking from developers investing in the new Swift language. The second is, in my opinion, completely unwarranted and I’ll try to explain why.

This post is the most plausible so far: “WatchKit apps will ship as embedded binaries in iPhone apps, using the same basic principals [sic] as iOS 8 extensions. There will be some mechanism for the watch paired to an iPhone to detect and automatically install these ‘apps’ based on what is available on the paired iPhone. Delete the container app from the iPhone, it disappears from the watch. Xcode will have a template to add a WatchKit app to an iPhone app project.

Let’s back off WatchKit for a second and look at what we’ve seen of the hardware. The entire main board is shrunk down to a single unit: the S1. If you stop the middle introduction film at 4:46, you’ll see that it’s really a collection of chips and SMT components on an encapsulated multilayer board — not really a “single chip” as the narration says, but many large CPU “chips” nowadays are like that, too. Other than the S1, there’s of course the “Taptic Engine” assembly which does the wrist tapping, the crown sensor assembly, antennas and display, and the most important part: the battery.

Battery life is the make-or-break feature of the Apple Watch. iFixit’s disassembly of the Moto 360 watch shows why: there’s a square peg battery inside a round casing, rated at 320 mAh. Even though Motorola apparently build their own batteries, they don’t have enough volume to do a round one. Apple doesn’t have a volume problem and their casing is square, so they’re free to use all remaining volume for a longer-lasting battery.

The 320 mAh rating and the typical battery life of 12 hours of the Moto 360 means that the watch consumes, on the average, just under 27 mA. But they run Android on the watch, using an off-the-shelf TI ARM processor with attached RAM, flash memory, and so forth, so that figure is not surprising. In other words, it’s a stripped-down cellphone/MP3 player.

Suppose that Apple did its usual optimization of battery size, usage, etc., in a stripped-down iPod nano. It’s half the size of the nano, which has a 30-hour life, so we can assume half the battery, meaning 15 hours. OK, that would be marginally acceptable, perhaps.

But remember, the Apple Watch needs an iPhone nearby. In fact, many of the published functions, such as Siri, cellphone call response, GPS and so forth certainly use the iPhone’s hardware and software for that. Remember that one of the culprits of excessive battery usage is generic apps and processes running on the device. Remember that Apple, since the first iPod in 2001, has been very aggressive in optimizing their embedded systems. Remember that the first iPods and iPhones didn’t have any generic apps running on them, either. Remember that Apple already has technologies like Clang, OpenCL and Metal…

All that said, why run iOS and generic applications on the Watch at all? So here’s what I think likely about the real implementation.

  • Watch OS (or whatever it’s called — did they explicitly call it anything?) will not be a stripped-down iOS; maybe even not a Darwin derivative. It will be a highly optimized embedded system that has a few apps running in as few processes as possible. It will be very robust because it will be able to do only a fixed set of functions.
  • In other words, it will run only those things that may run while the paired iPhone is not available; we don’t know yet, but that might be just the timekeeping and pulse measuring apps. If the iPhone is there, the Watch will also work as a specialized I/O and display device for the apps installed there.
  • WatchKit will run on the paired iPhone inside a special server process; a matching iOS app will show installed Watch apps — probably those apps will be from the normal App Store, since they usually will have an iOS counterpart.
  • So, an installed Watch app will have at least some sort of preference app or pane on the iPhone; no use typing in passwords and such on the Watch, right? The part written in/for WatchKit will contain a server plugin that does the heavy lifting, data collating and communicating with the outside world, but it will also contain the application logic itself, commanding the Watch to do or display certain things.
  • I don’t mean to imply that the Watch will run a full WebKit client and the iPhone a web server, that might be overkill. Perhaps a useful subset of that, perhaps some variation of Display Postscript, some interpreted command language, or just a sequence of drawing orders? The important part is that there’ll be a single process on the Watch for doing the UI, and all the application-specific parts can be offloaded to the iPhone.

One consequence is that you can forget the idea of “jailbreaking” the Watch to connect to a non-iPhone, of course. Another one is that battery life might be at least a day, maybe even two or more. Nothing on Apple’s site so far contradicts any of my reasoning.

So, will WatchKit be accessible from Swift apps? Certainly. Will it itself be written in Swift? I doubt it for now. Maybe in iOS 9 some of the frameworks in iOS (and OS X) will have been rewritten, assuming that by then the Swift optimizer will be good enough. But that won’t be the case in a few months.

Possible but unlikely: WatchKit may have an API to download actual application code to the S1, which may (or may not) have an ARM-like architecture. Only in such a case — and since there will be no Cocoa/iOS frameworks on the Watch — I would expect the downloaded code to be in Swift (without optionals!), for extra safety; can’t have the Watch crashing and rebooting, right?

Update: Marcel Weiher kindly reminded me of CarPlay, which apparently works like that; nobody would say that cars are running iOS. On the other hand, in that case, the device is connected over USB (that is, reasonable bandwidth) and the car doesn’t have any battery life problems.

Comments welcome.

[continued from part III]

So, here I was back in Brazil with my brand-new Mac 128. Of course, the first thing I did was to disassemble it — a tradition I kept up for almost three decades, until Apple’s increasing use of glue and special tooling began to make it too risky for some Macs (especially laptops and the latest iMacs).

The hardware team at Quartzil was as interested in the machine as I was, and we learned a lot from it. Remember that this was for our upcoming QI900 8-bit microcomputer. At that time (mid-1984) PAL chips, injection-molding and four-layer boards were new and too expensive for all but very large-scale production runs, and we had to postpone adoption on all those. Similarly, when we looked at the Mac’s video circuits, we found that it used a horizontal flyback transformer that worked at higher frequencies than any commercially available in Brazil. That, and the fact that (because of the lack of PALs) we had to fall back to the MC6845 video controller chip, meant that we had to keep close to the 24×80 character display standard; the final display resolution was 27×90, with the first two lines reserved for a menu:


the menus were opened by the corresponding function keys, with shortcuts accessible by the special “QI” key. Notice the special “Edit” menu with “Undo”, “Copy”, “Paste” and “Delete” equivalents — sound familiar? 🙂

My Mac was used extensively for the QI900 design. All of the documentation was done in MacWrite/MacPaint (later, in WriteNow). I used a quite primitive C compiler (from Aztec) to write utility programs; one to optimize the MC6845 parameters to stay within certain constraints, another one to design the QI900 character set, which used an extended MacRoman encoding to allow accents and frame/window/menu-drawing characters. The “extended” part was also necessary because Apple’s original encoding didn’t include capital accented characters. The character set was then sent over one of the serial interfaces to an EPROM burner, and a copy was saved on the Mac itself as a FONT resource file. Unfortunately, all of these old files are still in my backups, but no longer readable — at a later time, they were encoded with DiskDoubler and, beyond that, were originally in long-obsolete file formats.

Subsequently I met other Mac users at a huge computer industry event in São Paulo; most important for my immediate future, the team from Unitron were there with their successful line of Apple II clones, and we talked about their plans for doing a Brazilian Mac clone. More about this (hopefully) in the next chapter.

My 2012 series of posts about Apple’s Lightning connector was (and still is!) the most-visited material here on the Solipsism Gradient: over 120 thousand visits so far, and counting. Most comments elsewhere about the posts have been positive.

Several of my surmises about the connector have since been confirmed; my main miss was that I supposed all 8 pins to be dynamically assignable. The actual pinout has not been officially released, but the Wikipedia article seems reasonably accurate there. Lower-cost 3rd-party Lightning cables and accessories have arrived and users seem to have quieted down with complaints about the connector.

Last month my new iPad Air arrived and now I finally am in a position to comment on the actual user experience of the Lightning connector.

Build quality of the Apple cables and adapters is excellent – I bought an extra USB cable as well as the SD, VGA and HDMI adapters. I’ve never had one of the old 30-pin cables or adapters fail (one of them is 10 years old!) and the new ones look to be even more robust.

Inserting or removing  the connector gives strong positive feedback – there is a distinct “click” and it needs more force than required by the old connector. In fact, I had to get used to not simply pulling the iPad off; some hilarity ensued when I didn’t notice it was plugged in and attempted to walk away.

All in all, I can now confidently say that Lightning is a Good Thing™. 🙂

Update: Yet Another Follow-Up — this time about Lightning and USB3.

[continued from part II] This, my first Mac, consisted of: • a system unit with 128K of RAM, 64K of ROM containing the system toolbox and boot software, a 9″ black&white display (512×342 pixels), a small speaker, a 400K single-side 400K floppy disk drive, two serial ports using a new mini-DIN 8 pin connector DB9 connectors, a ball-based mouse also connected via DB9, and an integrated power supply; • a small keyboard with no cursor keys or numeric keyboard, connecting to the front of the system over a 4-pin phone connector; • a second 400K floppy drive, which connected to the back of the system; • an 80-column dot matrix Imagewriter II printer, connecting to one of the serial ports; • System 1 (though it wasn’t called that yet) on floppy disks with MacPaint on one, and MacWrite on the other; • a third-party 512K RAM expansion board which fit somewhat precariously over the motherboard but worked well enough; (this RAM upgrade board, from Beck-Tech, was actually 1024K and I now remember buying it a year later) • a boxy carrying case where everything but the printer would fit — I didn’t buy Apple’s version, though. I went to Berkeley and bought it together with a BMUG membership and a box of user group software; • a poster with the detailed schematics of both Mac boards (motherboard and power supply); • a special tool which had a long Torx-15 hex key on one end and a spreading tool on the other end. The Mac’s rather soft plastic was easily marred by anything else; • The very first version of Steve Jasik’s MacNosy disassembler software. All this cost almost $4000 but it was worth every cent. (Also see the wonderful teardown by iFixit.) Taking it back to Brazil proved to be quite an ordeal, however. We had made arrangements to get my suitcase unopened through customs, but at the last minute I was advised to skip my scheduled flight and come in the next day. We hadn’t considered the fact that the 1984 Olympics were happening in LA that month, and getting onto the next flight in front of a huge waiting list of people was, of course, “impossible”! As they say, necessity is the mother of invention and I promptly told one of the nice VARIG attendants that I would miss my wedding if she didn’t do something — anything! She promised to try her utmost and early the next morning she slipped me a boarding pass in the best undercover agent manner. And her colleagues on board made quite a fuss about getting the best snacks for “the bridegroom”… 😉 Anyway, after that everything went well and I arrived safe and sound with my system. More on what we did with it in part IV.

[continued from part I]

In 1983 I’d started working at a Brazilian microcomputer company, Quartzil. They already had the QI800 on the market, a simple CP/M-80 computer (using the Z80 CPU and 8″, 243K diskettes) and wanted to expand their market share by doing something innovative. I was responsible for the system software and was asked for my opinion about what a new system should do and look like. We already had all read about the Apple Lisa and about the very recent IBM PC which used an Intel 8088 CPU.

After some wild ideas about making a modular system with interchangeable CPUs, with optional Z80, 8008 and 68000 CPU boards, we realized that it would be too expensive — none the least, because it would have needed a large bus connector that was not available in Brazil, and would be hard to import. (The previous QI800 used the S100 bus, so called because of its 100-pin bus; since by a happy coincidence the middle 12 pins were unused, they had put in two 44-pin connectors which were much cheaper.)

Just after the Mac came out in early 1984 we began considering the idea of cloning it. We ultimately decided the project would be too expensive, and soon we learned that another company — Unitron — was trying that angle already.

Cloning issues in Brazil at that time are mostly forgotten and misunderstood today, and merit a full book! Briefly, the government tried to “protect” Brazilian computer companies by not allowing anything containing a microprocessor chip to be imported; the hope was that the local industry would invest and build their own chips, development machines and, ultimately, a strong local market. What legislators didn’t understand was that it was a very difficult and high-capital undertaking. To make things more complex, the same companies they were trying to protect were hampered by regulations and had to resort to all sorts of tricks; for instance, our request to import an HP logic analyzer to debug the boards turned out to take 3 years (!) to process; by the time the response arrived, we already had bought one on the gray market.

Since, theoretically, the Brazilian market was entirely separate from the rest of the world, and the concept of international intellectual property was in its infancy, cloning was completely legal. In fact, there were already over a dozen clones of the Apple II on the market and selling quite well! This was, of course, helped by Apple publishing their schematics. A few others were trying their hands at cloning the PC and found it harder to do; this was before the first independent BIOS was developed.

To get back to the topic, it was decided to send me to the NCC/84 computer conference in Las Vegas to see what was coming on the market in the US and to buy a Mac to, if nothing else, help us in the development process. (In fact, it turned out to be extremely useful — I used it to write all documentation and also to write some auxiliary development software for our new system.)

It was a wonderful deal for me. The company paid my plane tickets and hotel, I paid for the Mac, we all learned a lot. I also took advantage of the trip to polish my English, as up to that point I’d never had occasion to speak it.

The NCC was a huge conference and, frankly, I don’t remember many details. I do remember seeing from afar an absurdly young-looking Steve Jobs, in suit and tie, meeting with some bigwigs inside the big, glassed-in Apple booth. I collected a lot of swag, brochures and technical material; together with a huge weight of books and magazines, that meant that I had to divide it into boxes and ship all but the most pertinent stuff back home separately. I think it all amounted to about 120Kg of paper, meaning several painful trips to the nearest post office.

The most important space in my suitcase was, of course, reserved for the complete Mac 128 system and peripherals. More about that in the upcoming part III.

30 years ago, when the first issue of MacWorld Magazine came out – the classic cover with Steve Jobs and 3 Macs on the front – I already could look back at some years as an Apple user. In the early days of personal computers, the middle 1970’s, the first computer magazines appeared: Byte, Creative Computing, and several others. I read the debates about the first machines: the Altair and, later, the Apple II; the TRS80; the Commodore PET, and so forth.

It was immediately clear to me that I would need one of those early machines. I’d already been working with mainframes like the IBM/360 and Burroughs B6700, but those new microcomputers already had as much capacity as the first IBMs I’d programmed for, just 8 years later.

So as soon as possible I asked someone who knew someone who could bring in electronics from the USA. Importing these things was prohibited but there was a lively gray market and customs officials might conveniently look the other way at certain times. Anyway, sometime in 1979 I was the proud owner of an Apple II+ with 48K of RAM, a Phillips cassette recorder, and a small color TV with a hacked-together video input. (The TV didn’t really like having its inputs externally exposed and ultimately needed an isolating power transformer.)

The Apple II+ later grew to accomodate several accessory boards, dual floppy drives, a Z80 CPU board to run CP/M-80, as well as a switchable character generator ROM to show lower-case ASCII as well as accents and the special characters used by Gutenberg, one of the first word processors that used SGML markup – a predecessor of today’s XML and HTML. I also became a member of several local computer clubs and, together, we amassed a huge library of Apple II software; quite a feat, since you couldn’t directly import software or even send money to the USA for payment!

Hacking the Apple II’s hardware and software was fun and educative. There were few compilers and the OS was primitive compared the mainframe software I’d learned, but it was obvious that here was the future of computing.
There were two influential developments in the early 1980s: first, there was the Smalltalk issue of Byte Magazine in 1981; and then the introduction of the Apple Lisa in early 1983. Common to both was the black-on-white pixel-oriented display, which I later learned came from the Xerox Star, together with the use of a mouse, pull-down menus, and the flexible typography now familiar to everybody.

Needless to say, I read both of those magazines (and their follow-ups) uncounted times and analysed the screen pictures with great care. (I also bought as many of the classic Smalltalk books as I could get, though I never actually suceeded in getting a workable Smalltalk system running.)

So I can say I was thoroughly prepared when the first Mac 128K came out in early 1984. I practically memorized all articles written about it and in May 1984 I was in a store in Los Angeles – my first trip to the US! – buying a Mac 128K with all the optionals: external floppy, 3 boxes of 3.5″, 400K Sony diskettes and a 80-column Imagewriter printer. (The 132-column model wouldn’t fit into my suitcase.) Thanks to my reading I was able to operate it immediately, to the amazement of the store salesman.

More about this in the soon-to-follow second part of this post. Stay tuned.

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2017 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.