Re: [NTLK] Bounty on 2010 time/date bug?

From: Jon Glass <>
Date: Sun Feb 15 2009 - 10:02:48 EST

And here, just the posts by John Arkley, aka Ex- NOSE. The previous
email is more for reference to see what he is replying to. This is the
better email for reading what he has to say.

Author Topic: Any recent news on Newton lawsuits vs Apple?
Ex Newton OS Engineer
Member posted 04-01-99 04:35 PM
Has anyone seen a web/print story about the status of the "newton
cancelation" lawsuits against Apple?
I am now ex Apple as well as ex Newton, so if anyone has any "newton
history" questions fire away in this thread.

FYI, i was Apple employee #88 and in Newton group Feb 95 thru Aug 98;
i was last software engineer standing in the "Newton group", because i
was the Newton OS "patch master" and they kept me around in case
another patch was needed.
I also was the author of the Newton C++ Tools for Macintosh and the
Newton group's ROM build system and build tools engineer.
an email address for me is now in my profile.

Ex Newton OS Engineer
Member posted 04-04-99 09:41 AM
Hi folks,
I am too busy with an easter gathering at my house today to begin to
answer the questions now, but i will take a cut at them tonight so
check back tomorrow. Also thanks for the kind words and email messages
that were send directly to me.
later, John Arkley

Ex Newton OS Engineer
Member posted 04-05-99 11:53 AM
Hi folks,
I will attempt to answer the questions above (in order) as well as
some questions that were sent via direct email.

decay: RE: parting with apple was intentional on my part?

Well, yes and no. I knew when Jobs did the "spin in" in August 97 that
Newton was doomed, but i stayed around expecting to get layed off with
the rest of the Newton engineering team in March 98. When that
happened i was initially told that i would be layed off, but they
doubled back at the last minute.

I was kept on because i was the Newton OS "Patch Master" and so i
didn't get layed off until late August 98 and terminated in late
October 98. I agreed to stay on because they said i would essentially
be "on call" rather than having real work. I spent most of Mar->Oct
re-modeling my house so i could sell it and relocate, as my girls are
in college and i don't need the large house and yard anymore. I am
Apple employee # 0088 and had 11+ years on my 2nd stint at Apple so
the severence pay was an enticement to hang around.
I still use my MP2100 some, but not a lot; i never seem to get very
organized, but maybe that will change.

Gary: RE:

1) Over the long life of "Newton" development Apple spent (i estimate)
in excess of $400 million on R & D. The early years (88-91) were
almost pure research on technologies, hand-writeing recognition, low
power CPU's (ATT Hobbit efforts), prototypes, UI design for pen, grand
schemes to create a large format "Slate" type products... The whole
"Newton" thing started as an attempt to implement Sculley's "Knowelege
Navigator" video as a real product. It was typical Apple "engineering
technology for its own sake" with little real world concern for what a
customer would want and how much a buyer would pay for a given level
of functionality.

Eventually the "slate" at $4000-$5000 was obviously not saleable,
proved by the Grid System product duds, and a "palace coup" occured, a
group of the Newtonite engineers set off to "shrink" the product to a
hand-held form factor, which was dubbed the "Runt" as a result.
This eventually led to pre-mature release of the original MessagePad
due to mgmt fears that the rurmors of Microsoft "PenPad OS" would be
released and "close the window" for Newton.
The rest is fairly public history of a product that cost too much for
what it did and was never small enough to really be a hand held
device. Relative to the total R & D dollars Apple spent on the whole
newton developement cycle Apple never recovered the first dollar of
profit above the $400 million sunk R & D costs.

During Apple's last couple of years the R&D expenses of the bloated
Newton group of about 175 people was burning about $27.3 million a
year; this follows from the "standard" cost per person for salary,
benefits, equip, office space and supplies and mgmt overhead of
$156,000 per person. Apple was NOT selling enough MessagePad,
accessories, etc to cover the costs, except for one or two quarters
during the years i was working in NSG (Feb 95- Mar 98).

BTW, its not "sales revenue" that has to cover R&D costs for a
business, but at least "pre-tax" profit. The "cost of goods" sold has
to be subracted from sales revenue, and sales revenue is the
"wholesale" price Apple gets for products selling to the distributors
or direct to "big" retailers. Apple's "Pre-tax" profit was usually
about $150-200 per unit; this was due to the units being manufactured
by Sharp or other asian manufacturers, and thus
Apple also had to pay the manufacturer some profit too. Typically a
distributor get 5-10% of the retail price and the retailer gets
15-25%, so best case Apple tends to get 75% of retail and had to pay
about $400 per unit to Sharp for an MP2000.

The "rational" that was expounded by Jobs for the Newton, Inc, spin in
was that they didn't want to lose "critical talent" (bogus since most
of it had alreay left apple). The one expounded for closing up Newton
OS development was not having the management talent to "focus" on more
that one "OS" as a time; in otherwords self admission of incompetence,
and the unwillingness to "delegate" responsibility and authority to
some other qualified management staff for Newton, which Apple has a
history of not being able to hire.

Certainly, in my opinion, none of the Newton, Inc senior managment was
capable of making Newton Inc a success, and Sandy Bennett got in
serious trouble with Jobs for how he handled the "spin in"
communication with employees.

2. Some effort occured, but the "real" kernel engineers were gone from
Newton/Apple by the time the bug manifested itself, and the folks that
were left (like me) weren't strongly movivated and/or skilled enough
to track it down. It appeared from the last work that was done that
the bug was very hard to reproduce and it seemed to indicate that the
problem was in the low level kernel Flash "demand pager". Apparently
some very complex combination of prior actions and heavy paging
eventually causes a paging failure that blows up the OS.
The exact cause was never isolated and so whether it was "patchable"
is unknown. The ROM patch table contains "most" of the ROM native code
routines, but there are many inner functions in the kernel that are
not patchable due to the performance penalty that being in the patch
table causes for a function. There was a good chance that it was NOT
patchable, but without knowing the EXACT nature of the bug, there is
no way to tell.

3. My primary job in Newton was as the Build System and Build Tools
engineer, in addition to being the Newton Patch Master. The Newton ROM
is most C++, some assembler and LOTS of NewtonScript. The ROM was only
built using custom ARM compiler, linker, (from ARM Ltd in England),
and a host of specialized MPW tools written by Apple all running under
MPW. This

was the ONLY build environment for the 6+ megs of the "base" ROM. The
"ROM extension" contains a set of NewtonScript packages and other
tables and "world data" etc, and was constructed with NTK and other
specialized MPW tools.

The ROM also contains source code licensed from other software
vendors, Paragraph Internalional for the cursive handwriting
recognition engine, and word dictionaries, and spell checking
dictionaries, and from ARM Ltd for the Std C-libraries. Apple could
certainly NOT release the licensed source code. In addition the ROM
contains some of Apple's most valued code, a modified of "Mac SE'
vintage Quickdraw and all the Printing support for Quickdraw and
PostScript printing. Apple also developed the "Printed recognition
engine" and it is written in C/C++ and is "newton" independant. It was
actually developed under Unix and the "results" of some fairly long
computational calcuations make up the neural net it uses to do text

Jobs thought that all this code was too valuable to even let it go
into the hands of Newton Inc, much less outside of Apple. Open Source?
No chance and besides the ordinary ROM code is not well layered many
large hunks are much too incestous, thus it's NOT something a random
team of engineers could work on pieces of independantly. Even with a
team in one building, it was not uncommon to have problems caused by
unexpected interactions and failures due to this lack of proper
layering and isolation in the OS and built-in applications. There was,
in 97, a "Modualr" OS project inside Newton to re-write major parts of
the ROM so it would become maintainable into the future, but most of
it never got done.
4) Yes, the Intellisync stuff was licensed and in my opinion it was
the biggest mistake Apple made with Newton, not to do it's own stuff.
Apple messed up big time by listening to bozo's in marketing who
claimed that others could deliver results on time yadeh yadhah and
then didn't even get blown away when they failed, probably as much
because Apple has seldom Spec'ed or managed ouside software
development with any skill, as because of the vendor's "lack of
motivation" (i.e. sufficient money). In other word if the "internal
cost of development" had be spent on the problem, there would have
been no reason to do it outside, but of course the internal cost
estimate was real and "too high". I believe the vendor correctly only
does stuff that pays and keeps the business growing. I don't know
anyone who works there. I doubt the vendor would make the interfaces
available and i don't know if NCU is even modular enough to accept new
"plug ins", it don't think it is.
5) Resource priorities. Newton IR was pre IrDA and IR never proved to
be that useful a feature because having it on all the time is a power
sink. Essentially, to have IR working software has to be constantly
looking for IR input and IR output uses power. In addition, full
duplex IR is nasty to do and multi sources for IR as the same time is
a problem, as it mangles the input. As a result most IR is half duplex
and thus the turn-around process is slow and expensive for lots of
small pieces of data, so it just isn't all it cracked up to be.

As for Ethernet, it is a transport layer and packet protocol that has
nothing to do with Windows; The MP2x00 has TCP/IP support which is the
most common protocol stack which uses Ethernet hardware for networks.
The problem with a "Network" on a PDA and in MPs, is that Newton
wasn't designed to be connected to a WAN or LAN and such networks
require constant hardware attention to "listen" to all the packets
going by on the wire. THe Newton OS was NOT designed to do this and it
was a hack to add it later, AND IMHO, the biggest mistake Apple made
with the Newton product line, was the attempt to make MessagePads into
"internet appliances". Instead of making a bigger, fatter, more
expensive, "internet" capable MP2000, Newton should have made a
smaller, thinner cheaper, less capable connected organizer, but Palm
Computing had better vision and make a hugely sucessful product as a
6. I was the author of the Newton C++ Tools for Macintosh, and because
the ARM C++ compiler, assembler and linker we had available were all
MPW tools, and there isn't any "standard" environment for tools on
Windows systems that these tools could plug into, a Windows version
was never in the works; It was discussed due to requests from
developers, but nothing more ever happened. I thought some of the DDKs
were available until March 98 under non-disclosure, but they were also
always MPW based for the same reason. We probably could have
take a Linux path for this stuff and been better off, but that was not
seen as viable by Newton mgmt or the "Tools product" marketing people
who were always trying to create "products" they could deliver, not
free stuff.
7. No internal modem was ever created. Yes there is an internal
connector and it could be brought out as a 2nd serial port with just
the RS 422 I/O pin driver chip, but the necessary "redirection"
controls and testing of them for all the different purposes that a
user might want, was not implemented in the OS nor was it debugged. It
isn't sufficient to have the just the hardware. Computer system
products have to have ALL the layers done to be useful; hardware is
the simplest to "see" and understand, which explains why some many non
"system engineers" think "oh that easy", just add a board, driver chip
and connector and it will work. There was talk on this forum at one
time that someone was going to make the adapter board and i recall
reading many a message about protos and hacks that some of the techie
types got working, only to discover the missing software support.
8. I could but i am a software engineer and i do engieering for a
living not a hobby, and i expect to get at least $50/hour for such
work, or incentive stock options that have a real chance of returning
more than $100K per year for the time i invest. I do other things for
hobbies. A Newton emulator has to emulate not only the ARM CPU but all
the specialized ARM MMU functions and the custom hardware for DMA, IR,
Flash, display, etc, etc. Not a simple job. I would estimate (and i
have 30 years experience in systems and software engineering) that
this is at least 5 Man years of effort; attempting it without the
detailed hardware documentation for a Newton MP2000 would almost
certainly fail. Seems a pointless endeavor,
because far too much of the Newton OS was very specific the ARM
CPU/MMU features and custom hardware. Apple attempted more than once,
to do a "Virtual Newt" as side projects in the Newotn Group, but it
never got funded and done for real. The last hack was done by Greg
Christie, and he got the NewtonScript Interperter to work under Mac
OS, but that left out all the low level hardware like networking and
serial I/O support and sort of produced a NewtonScript/Mac OS rather
than a Newton OS.
IMHO, it would be more relevant to implement a new "Free" handheld OS
using the Java/JWT model as most of the benefits of
NewtonScript/Newton OS are present in Java. I also think
it would be fairly easy to "clone" the Newton UI design, i.e. a
handheld "finder" and class libarary set that would parallel the best
aspects of the Newton toolbox. I would suggest that using Java and a
specialized hand held "JWT" would be more likely of success and
attract far more collabrative GNU type effort, than the preserve an
abandon propritary OS.
Pardon my bad spelling, i tend to type too fast and transpose letters a lot.
regards, john Arkley ex apple employee #88

Ex Newton OS Engineer
Member posted 04-05-99 12:06 PM
Hi again more question arrived after i printed the first batch.
RE: H Chung
1) The German MP120's, which are few in number, acutally has the MP130
ROM in it, and the ROM auto detects the minor differences between the
two units. Newton System updates are built specific to each different
ROM, not each different device (i.e MP2000 and 2100 have the exact
same ROM), and some of the patch fixes in the MP2100 do RAM size
detection as that is the only difference between them. An MP130 IS the
same unit as an MP130 except for additional memory and the backlight,
but its NOT upgradable as a minor revision on the MP120 main board was
to create the MP130 to handle the larger memory chips. "Unexplained
port" on some Newton is not specific enough for me to answer. There
aren't any external connectors for ports on any MP that i know of that
don't work in some way.

Ex Newton OS Engineer
Member posted 04-05-99 12:49 PM
Hi again,
Patching Newton OS
Would it be possible to do this sort of development with a stock
MP2100 and a Mac?
Well, yes most of the MP2000 development was done using proto MP2000's
instead of "bunwarmers prototypes". Apple quit building the
"bunwarmers" after MP120 because they cost too much ($3000 each). The
MP2000 proto's had Flash instead of mask ROM on the ROM daughter card
and MP2000 actually can "Flash" program the builtin "ROM" thru the
GeoPort (at 1 Mbit/second). This was done using the latest version of
the internal Hammer debugger or a tool called NewtFlasher (i think);
some developers were given these tools under NDA. Flashing the ROM is
not foolproof, however, as part of the ROM must work to be able to
interact with the debugger and load the new image and program it
without killing itself. During development, it was important to always
test the ROM before flashing it into a handheld, because if the new
ROM is really bogus, the next one may never be installable, and
required takeing the unit apart and flashing the ROM daughter card
Thus development was in fact done with a "Flash ROM" handheld and a
PowerMac using MPW and NTK and a build system running under MPW.
I developed and maintained and managed the Build Server system in
Newton; it was called the Autoserver and all the ROM software was
built with 27 Quadrs 950 and a few bunwarmers that tested the ROM
images before allowing engineering changes to be accepted into the
source project base and releaseing changes to other engineers on the

I've finally got my algorithm running, and now the Newton can stream
MP3s and HTTP and bake pizza without any pauses.

What would I need to do to make my code an OS patch that others could apply?
Well i am not sure how you have been doing this development but i
assume you did it with
the Newton C++ Tools for Macintosh? or do you
just have a prototype algorithm running on a desktop? or did you use
NTK? I suggest you just ship a complete app and forget about trying to
make a Newton OS "patch".
A Newton System Update or "system patch" is a complex intermixed
collection of MMU tables, 40-70 assembler "fixes" all packed together
in a collection of ordered 4K RAM pages. Building and testing a System
Update is complex and expensive process and no single engineer could
do it. The Newton OS only supports ONE system patch, so ALL the
existing "fixes" and any new ones have to be combined together to
combined to create the "next" System Update. Newton OS is unusual in
this reqard; it like only allowing ONE "init" in the MacOS instead of
a whole folder full of "Extensions".
You can't do this "as a system patch"; Apple is the only one who has
the tools to build a new System Update and all the engineers who know
how to do it don't work for Apple any more (me for example) although
_maybe_ there is one remaining employee who could eventually do a new
one given enough time.
A new NewtonScript GC is not very likely something you could complete
and test without
the ROM sources. The performance of MANY MANY things in the OS change
if the GC is messed with and you probably wouldn't find out just how
sensative the SYSTEM is to changes. Making GC "faster" probably would
have negative side effects you couldn't anticipate and it would thus
break all kinds of stuff. Having GC happen at the wrong time can have
just a bad an effect on the Newton OS as changing it speed would.
If you can engineer a new GC for newton OS without documentation and
source, i suggest you should be working as a programmer for someone
who will pay you well for your effort.


Ex Newton OS Engineer
Member posted 04-07-99 12:32 AM
Well, technically of course it POSSIBLE to write a new OS for the
MP2x00 hardware, but since essentially the entire hardware design is
non public, i doubt it could happen without getting Apple to release
the documentation.
You would also need ARM compilers, linkers and assemblers, etc. and a
development system to run them under. I suspect that a linux version
of the ARM Ltd Tools might be the only practical approach.
The Cirrus Logic chipset IS the MP2x00. It was a badly designed set of
chips; RAM cycles take 7 bus clock ticks! and the processor runs at 7x
the bus rate, but they are NOT available as a merchant chip set as far
as i know.
>How much of the hardware in the MessagePads is custom stuff, with no documentation outside Apple?
Essentially zero. The Cirrus chip set (4 chips) is essentially
everything except CPU, ROM, Flash, RAM and the sound I/O, serial and
IR drivers, and pwr supplies.
Surely someone has taken an MP2x00 apart and taken pictures of the
main logic boards (both sides). This is easily done and would readily
provide graphic documentation of the facts.
A "kernel" does not NOT an OS make. Without drivers, a toolbox,
application runtime model, UI, a "Finder" or other application
launcher you don't have anything very useful.

Ex Newton OS Engineer
Member posted 04-07-99 12:36 AM
>How much of the hardware in the MessagePads is custom stuff, with no documentation outside Apple?
Correction to the above reply; it should have read:
Essentially 95%. The Cirrus chip set (4 chips) is essentially
everything except CPU, ROM, Flash, RAM and the sound I/O, serial and
IR drivers, and pwr supplies.

And of couse it's the critical 95%.

Ex Newton OS Engineer
Member posted 04-07-99 04:01 PM
Ok, so maybe some parts of an Linux OS might be available and portable
to MP2x00 hardware, but without a screen driver and an "Inker" and
some kind of UI designed for _pen_ input all you would have is a linux
that needs a serial terminal console and keyboard. Doesn't seem like
much of a product for handheld use, but it could evolve into one if
enough work were done after reaching this initial protoype state.

A debugger nub for an external debugger would be essential to actually
creating a completely useful OS. I would tend to want a PCMCIA card
based debugger since Apple proved that serial based MP2x00 debugging
is horrible, even at GeoPort speeds.

Also someone would probably have to reverse engineer the Flash ROM
daughter card, so the those actually working on the new OS could have
the MP2x00 "Flash" new versions of the ROM during development cycles.
go for it! but i don't do heavy lifting system engineering for grins
or fame or a dwindling pool of users who already have something that
works; sorry but i'm not inclined to invest massive blood, sweat and
tears unless my work results has a large population of potential
users; at least millions.

 -Jon Glass
Krakow, Poland
"I don't believe in philosophies. I believe in fundamentals." --Jack Nicklaus
The NewtonTalk Mailing List -
The Official Newton FAQ     -
The Newton Glossary         -
WikiWikiNewt                -
Received on Sun Feb 15 10:02:50 2009

This archive was generated by hypermail 2.1.8 : Sun Feb 15 2009 - 13:30:00 EST