[NTLK] Factory calibration problem
victor at chuma.org
Wed Jun 13 00:46:43 EDT 2018
I can't speak to how your eMate got into its confused state. But I have
been working on Einstein lately, so I can tell you what *it* does, since
it boots the Newton OS ROM without this message.
When Einstein creates a new file for the Newton's virtual flash, it
writes a bunch of values to block 0 (starting at flash address 0) and
block 1 (starting at flash address 0x10000, the next 64KB block in the
linear flash) to satisfy the NewtonOS. The values it writes in each
block are identical, and everything after offset 0x8F is zeroed.
The code for this starts around line 139 in TFlash.cp in the Einstein
The OS does modify block 0, as the block 0 in my virtual flash file is
no longer identical to what the emulator wrote, but block 1 is still
identical. Your eMate either has the wrong values there, or the flash
has worn out to the point where it cannot be read (!)
So I guess what you need is some way to rewrite those blocks.
Coincidentally, I was trying to hack together some hardware to let me
read/write linear flash cards images on a PC, with the idea that I could
take the K diags image, write it to a flash or SRAM card, and boot it on
an eMate. Unfortunately, I didn't get anywhere and put it on the back
burner. If only I had some 1990s era laptop hardware still...
On 2018-06-12 08:10 PM, NewtonTalk wrote:
> Hi folks,
> Recently, I put one of David's memory upgrades into an eMate that was
> working fine. The eMate had a newly rebuilt battery that had successfully
> passed three subsequent capacity tests only a week earlier.
> The memory board did not contain the Flash memory, but only the RAM. I
> wanted to know if it would be possible to build a memory upgrade board that
> only contains RAM. Since the eMate blinked its backlight at startup and did
> not boot, I guess it can be safely assumed that there must be both RAM and
> Flash present. But that is another story that'll require more digging and
> The problem I'm referring to here is that after I left the eMate alone for
> about three weeks, I removed the upgrade board and then turned the eMate on.
> The battery was empty, which should not happen after only three weeks, and
> after connecting the ac adapter the eMate greeted me with the dreaded
> message that factory calibration had been lost and that it wasn't going to
> charge any batteries until it is sent to Apple for immediate repair.
> I temporarily put a Newton ROM board in to remove any system patches and
> bring the eMate back to factory conditions, which worked fine. But the
> calibration message still appears.
> The newly rebuilt battery pack seems to be toast. I tried to charge it in
> another eMate, but it does not take a charge although the cell voltage is
> around 1 Volt per cell.
> Of course, it might be a sheer coincidence that the factory calibration
> message appeared at that time. It might also be a coincidence that a newly
> rebuilt and fully charged battery pack was dead after leaving it in a
> turned-off eMate for three weeks. But I doubt it.
> Searching 18 years' worth of NewtonTalk digest messages turned up some
> interesting info found by The Incredible Paul Guyot. One, written on 14 Aug
> 2004, sounds especially promising:
>> Could the people who get this message on the restart of their 2.1
>> Newton contact me off-list? I may have found a cure.
> Are there any people on this list who remember contacting him? What was the
> Here are some more of Paul's insights collected from various NewtonTalk
>> What I figured out is that this calibration data is written on both
>> block 0 and block 1 of flash. During a system patch installation, the
>> patch is written on block 0. On boot, if the calibration is invalid
>> on block 0, it is copied from block 1 to block 0. If it's invalid on
>> block 1, default values are applied. Block 1 is considered as a
>> fallback, somehow.
>> To remove the system patch from a Newton, you need to restart it with
>> a different ROM. NewtonOS, I mean all the 2.1 ROMs I am aware of,
>> makes a checksum of the ROM during the boot process and compare this
>> with the value written on the first two blocks of the flash (where
>> the factory calibration is). If this value is different, all the
>> flash but the first two blocks are erased. This includes the system
>> The boot process is as follows: (simplified)
>> First, the NewtonOS powers every subsystem. This means powering cards.
>> This is why BlueTooth and WiFi cards blink during boot. It looks for
>> test cards which it usually cannot find. Then it powers them down.
>> Then, the OS checks if the boot is a cold boot or a warm boot. The
>> is that there are some globals in RAM that live accross warm boots. If it
>> cannot find these globals, it considers it is a cold boot.
>> If the boot is a cold boot, the OS next checksums the ROM. This
>> takes a while on the Newton and on Einstein as well.
>> After it has checksummed the ROM, it looks if this ROM is the one matching
>> block 0 of the internal memory. On the Newton, it usually is, so it
>> with the boot process, powering the screen on (this is why the screen
>> on immediatly, much later than the blinking of cards).
>> If the checksum doesn't match, it looks at block 1 which is a backup of
>> block 0. These blocks also contain factory calibration data for the clock,
>> the temperature sensor and the tablet.
>> If block 0 and 1 don't contain valid data (I mean besides the checksum),
>> the Newton displays the alert saying that the Newton needs repair. The one
>> you can see in Einstein screen shots.
>> If the checksum doesn't match at all, the Newton erases everything on the
>> internal flash except the first two blocks. This is not a complete erasal,
>> but it is the deepest erasal the OS can perform.
>> Then it resumes the boot process, which means quickly powering the screen.
>> This is why swapping the ROM boards (a German and a US one) leads to a
>> complete removal of the system patch and all the data on the Newton.
>> However, it doesn't yield to the removal of some data such as
>> factory-calibration data.
More information about the NewtonTalk