Enjoy your retirement, JE7420LHAYL
After twelve years of service, my first MP2100 is headed for retirement. It has been working very reliably over the years, but recently, one strange problem started to occur: It stopped playing sounds. I checked the usual suspects (wiring, software patches, …), however the very first Newton on this planet to play MP3 files is now mute.
This device is one of the first German MP2100s, and I bought it back in 1997 from a Swiss web store. I used to baby the Newton way too much, before I realized that it can only realize its full potential if I have it close by all the time. The case looks pretty battered now, even though all clips and doors are still in place. The backlight it maybe at 50% brightness, and the screen is slightly worn. This particular Newton has seen quite a bit of places from California to Australia, and went up all the way to 70° 54’ 48" North.
Now it is time to retire this lovely device, and start using its successor, probably one of the last produced MP2100 I bought already quite a while ago. I’m not sure if it will also see twelve years of service, but you never know :)
The case of the never ending project
One observation from using Nitch now for almost two years is that GTD is not only about projects and actions, but a higher level concept on top of projects is still needed. I added roles and goals earlier to Nitch, and while that has been helpful to bring projects and actions into focus as needed, I still ended up too opften with projects that did not have a clear outcome.
The concept of a goal looks promising in this context, and I am adding more functionality to Nitch to have goals which in turn are made of projects. That allows to use goals for more longer term planning, and restrict projects to efforts which are not longer than a month.
SourceForge improvements
SourceForge seems to be on a roll… even though things were a bit rocky due to their site redesign, I’m happy to see that the file release system now again allows direct links to packages for download, no more searching through dozens of packages! It also seems that it will soon be possible to use multiple Mercurial repositories per project, so that I can finally use a real version control system for the Newton packages.
Year 2010 problem no more ...
After more testing by brave volunteers , I’m happy to announce that all NewtonOS 2.1 devices should be ready for year 2010 and beyond. In the patch collection, we now have:
- Patch 71J059 : Patch for the US MessagePad 2000/2100
- Patch 73J186 : Patch for the eMate 300
- Patch 74J185 : Patch for the German MessagePad 2100
And finally, a Patch Remover which removes all user applied patches on NewtonOS 2.1 devices (you should never need this, but I supplied it just in case).
All files are as usual on SourceForge, who have been busy with the download interface, but it’s still not quite there yet, the patches are under the “Patches” section on the 40Hz download page .
Updates coming
This is just a short headsup, I’ll be making some changes to the Y2010 patch related web pages, and as usual, those changed pages will show up in the RSS feed.
eMate in 2010
The Y2010 patch for the eMate is now also almost ready, like the patch for the german MP2100, it still needs some testing, but things are looking good. The eMate seems to take the ROM board changes (which are necessary to erase a faulty patch) less lightly than the MessagePads. I had a couple of moments where I thought I had fried the little green machine, but it always recovered after a while. I’ll hopefully be able to release the patches during next week, still in time for 2010 ;)
Willkommen zur Zukunft, MessagePad!
I’m just putting the final touches on a fix for the Y2010 bug for german MP2100s. It seems a bit easier and more structured when doing it now for the second time :) So far no ROM board swapping was necessary, and some parts of the patch creation are now just copy and paste of existing code. It’s still exiting to see the new OS version “74J185” shown in the splash screen! Next up would be the eMate patch. Creating a patch takes about two days, I hope to find that time soon.
On another note, SourceForge has at least now fixed the download page so that all packages are listed, but direct linking to files just for a specific package is still not possible…
Damn you, SourceForge!
It seems that the new fancy UI on SourceForge has screwed up all external download links, and what’s even worse, it doesn’t show the complete list of packages for the 40Hz project anymore. That makes downloading files now impossible, I’m looking into this, but it should ideally be fixed on the SourceForge end…
RDCL on Windows
I just tried out the latest one click installer for Ruby 1.9, and it seems that the RDCL works out of the box :) I am using a generic USB to serial converter with the common Prolific PL 2303 chip, and after correctly setting the parameters, I could connect to my Newton without problems.
It’s great to see that Ruby 1.9 is slowly becoming more mainstream, and that installation is nowadays quite easy!
Patch 710031 and 71J059
One quick but important note: The 71J059 patch is not compatible with patch 710031 which Paul Guyot has created. I’m not sure about the reason, but before applying the 71J059 patch, the 710031 patch needs to be removed with the 717260 Install Override patch (it’s contained in the 71J059 patch ZIP file).
The Patch is out
I released the [Y2010 patch
](/Pages/Patch 71J059) for US MP2100 models yesterday, and hope to be able to work on the German model, the MP2000 and the eMate next. That requires reverse engineering the respective base batches for those models, and I decided to automate this a little bit. I started adding some functionality to the RDCL to read package files. If you have followed the RDCL development recently, you might have noticed that I also started putting together a simple Qt-based wrapper application for the nwt command line tool, to make operations like installing or syncing easier.
Patch Preparations
If you have subscribed to the RSS feed for Mottek, you might have noticed that not only these posting appear, but also all other changes I do to the 40Hz site. Makes it easier to follow what I’m up to :) I’m mentioning this because I’m about to release the patch for the year 2010 problem for the Newton. So don’t be confused if you see items about the related web pages appear in the news feed.
RDCL to the rescue
I recently got a new Mac mini to start playing around with Leopard-only software like MacRuby , and moved most of my day-to-day files and programs. The problem is of course that Leopard does not come with Classic, and apps like NCU won’t run.
Fortunately, the RDCL library and tools work quite nicely, and after downloading Ruby 1.9, I was able to get first my address book in vCard format onto the Mac (using IC/VC), as well as some other important notes. There’s still lots to be done in terms of converting data (ink and drawings would be great), but it’s a good start!
Blast from the past
I added now also the Mottek archive from 2003 onwards to the MoinMoin setup, so happy digging into really old stuff ;) I should soon be able to get back to the year 2010 fix .
If you can read this ...
in your feed reader, then also the migration of the Mottek blog to MoinMoin has worked. Just as a reminder, the RSS feed now lives at http://40hz.org/Pages/40Hz?action=rss&unique=1, but the old links should still work as well. I’ll convert the old blog entries prior to 2005 very soon as well.
Work on the Newton’s Y2010 fix has not stalled, but I want to make sure that I put in all the necessary safeguards to not cause more problems than the fix would solve. The main problem is that there’s no way to unpatch a Newton unless you have a ROM board for a different language, or an eMate’s ROM board.
Moin, Moin
I’m in the process of changing the backed of 40Hz.org from MediaWiki to MoinMoin to be able combine the web pages and the blog. Some hiccups are to be expected, so please bear with me :) I’ll try to put redirects into place so that external links still work.
John Arkley was wrong
Just to make it clear: Despite reports to the contrary, it is possible to create NewtonOS patches. It’s not for the faint of heart, and you need a german and a US ROM board to erase broken patches, but statements like “Apple is the only one who has the tools to build a new System Update,” and “Building and testing a System Update is complex and expensive process and no single engineer could do it” are plain wrong. The proof is on SourceForge for a simple test patch I created as the start for fixing the [2010 problem](/Pages/Newton Year 2010 Problem), and on UNNA for a more elaborate patch Paul Guyot has put together.
The real challenge is not so much creating a patch, but knowing what to patch and how.
Patch day
The Newton’s [Y2010 problem ](/Pages/Newton Year 2010 Problem) would best be solved with a low level patch which kicks in very early in the boot process. I have played around now for a while with the patching mechanisms, and got a nice pile of information gathered. I got a great start with the work done by Kip (Jonathan Knight), who reverse engineered the original 717260 patch by Apple and uploaded it to UNNA.
I created some test patches, and while it is a bit complicated, I was able to add new code to an existing patch, patch previously unpatched functions, remove patches completely, and change existing NewtonScript functions. In the process, I managed to disable one of my Newtons (I patched a function in the startup phase), but that should be reversible by changing the ROM temporarily, that will erase all patches.
Getting done even more
I’ve been using Nitch now for over a year, and it seems that it allows me to hit the right balance between planning and executing, thanks to a large part to the built in Notes and Todo applications.
I just added functionality to support planning still a bit better via the addition of “Someday” and “Waiting for” lists. I’m always amazed how fast it is possible to add functionality to Newton apps, and even though I’m sometimes worried whether the result is too much of a hack, I find myself still be able to maintain my creations after longer pauses!
I also improved some minor details in RDCL, mostly in the synching area. Ruby is quite hack-friendly as well!