Psion Organiser II

In 1987, i picked up two Psion II Organisers. They were really hot when they came out! They look pretty much the same as each other, but one has 32 KB RAM, and the other has 8 KB RAM. RAM is used for file storage too, but internal RAM has some special features. There are two slots for expansion memory for file storage. They come in two flavors. RAM with a watch battery for persistence. And EEPROM. The Psion can write to it. But you can't rewrite. This can be overcome by marking records for deletion. When it becomes full, copy the stuff somewhere else, erase the pack, then copy stuff back to it. This is how you get the space back from deleted files. They also came with an RS-232 serial cable, and you can copy files to a host, like DOS, back and forth. This is how backups are done. The 8 KB system has some limitations. It can't use my 32 KB RAM pack. You must have 4 KB RAM free to use the serial port. They also can make beeping sounds. Pitch and duration are controllable, so i wrote a music program. Sounds like one of those birthday cards that you open and it makes noise. But, you can write your own tunes, with multiple octaves, repeats, etc. The display is two lines of 16 characters. There are user defined characters, giving one almost pixel by pixel control.

The serial port on my 32 KB Psion died. That meant it could no longer be backed up, and i stopped using it for anything more than a calculator. The 8 KB Psion is still nearly pristine. Well, except that dates past 1999 don't work in the calendar. Feh. Bloody Y2K.

These machines have the Hitachi 6303x processor. This chip can access 64 KB of memory. Half of this is ROM, more or less. They run at about 2 MHz. The 9 volt battery lasts a couple months of normal use.

The applications include a calculator, calendar (appointments), notes, file transfer (with special software on the other side) and remote login (can act like a terminal). The units are also programmable. On board, there is a language called OPL. OPL is something like BASIC, but without line numbers, and with block structure. Even after years of not seeing this language, i can read and write these programs without reference to the manuals. There's something to be said for a language that easy. There is also a cross assembler that runs under DOS. I studied the manuals, but never actually wrote anything for it.

So, a comment suggested that my new Nokia 770 is probably much faster. No need to guess. I have benchmark results for both, using benchmarks i started using in 1982. Here are some numbers:

Matrix Multiply

Time	x780	Machine & Language
0.0308	3143.2100	Athlon 1913 MHz C
12.1200	7.9900	Athlon 1913 MHz Perl 5.8.8
5.1596	18.7800	Nokia 770 C
238.4700	0.4060	Nokia 770 Perl
9.8200	14.1300	Compaq Aero 486sx/25 C
25920.0000	0.0037	PocketC Visor Platinum
612000.0000	0.0001	Psion Organiser IIXP OPL

Sieve

Time	x780	Machine & Language
0.060	2310.2300	Athlon 1913 MHz C
19.570	7.0900	Athlon 1913 MHz Perl
0.896	154.7900	Nokia 770 C
181.750	0.3800	Nokia 770 Perl 5.8
278.214	0.4490	Compaq Aero 486sx/25 C
90744.133	0.0014	Compaq Aero 486sx/25 Perl*
22135.000	0.0063	Palm Platinum Cbasic
57000.000	0.0020	Psion Organiser II OPL

Unfortunately, i don't have Perl benchmark runs for the Aero. I probably hadn't written them yet. I have extrapolated a Sieve Aero time using Athlon times. This doesn't work for the Matrix Multiply, as the 486sx/25 didn't have floating point hardware. But to be fair, i didn't use Perl on it much. No, i really don't have eight significant digits of timing information. I'm just trying to get the decimal points to line up. Benchmarks like this often have a ten percent variance between runs anyway. The Vax 780 was benchmarked in the early 1980's, and was considered by many to be the 1 MIPS (Million Instruction per Second) machine. But since some machines must execute more or fewer instructions to get something done, a more fair comparison is to test some workload.

There are two workloads here. The Matrix Multiply does lots of floating point multiplies and adds, with two dimensional array indexing. The Sieve performs integer comparisons and single dimensional array indexing. Since neither the Palm nor the Psion have floating point hardware, both of these machines perform relatively better at the Sieve than the Matrix Multiply. The Psion CPU doesn't have integer multiply, handy for two dimensional arrays.

But yes. The new Nokia is 300 times faster for the Sieve, and 2,500 times faster for the Matrix Multiply. And yet. Both of these benchmarks are in languages that compile to a virtual machine code, which is then interpreted. Any semi-modern desktop using a real compiler should be 20 million times faster than the Psion. When i get a benchmark run in C on the Nokia (easy enough), i expect a factor of 300 to 400 improvement over the Perl version. And if i manage to shoehorn the matrix multiply into the Nokia's DSP (Digital Signal Processor - a super computer's vector processor of sorts) (and more difficult to accomplish) then the sky's the limit. That's how the Nokia does sound and video, after all. Or, i might run into the short vector lengths (20). To be fair, i haven't attempted this in the Athlon's funky on-chip FPUs or GPU.

A brief note about Perl. Yes, there's a huge performance hit compared with C. But even on the 486sx/25, many applications would be fine. For example, many web based programs would still finish in much under a second, and you'd think it fast. And for some machines, it's not a factor of 300, it's a factor of 1,000. And it's still OK. This still bothers me. Perl 5.8 (and later, i suppose) comes with a Perl compiler, which improves things by a factor of five. I don't see it used much. Another odd thing is how little code i have hanging around written in Perl at home. For the past six years or so, it's been my primary language. But when i want to write something at home, it's nearly always in C.

Nokia 770

The digitizer on my 2002 vintage Handspring Visor Palm Pilot is crapping out on me. It's functional, but every few seconds, i have to recalibrate the digitizer. Sometimes, it messes up during the recalibration, and it can take five minutes to get through it. It often helps to try twisting the whole device this way and that to get it to work. So, i want to replace it.

Some history. Before getting the Visor, i had a 3.5 pound subnotebook. It could do everything my desktop could do, but with less memory and disk. Further, it could communicate with my desktop fast enough for backups and data sharing. But, it was more expensive than my desktop. When it died, i did without for a number of years. Eventually, i picked up the Visor, and though i lost much of what i'd used the subnotebook for, i started using the Visor for new things that i now depend upon.

One way to replace the Visor is to pick up a cheap Palm. The cheapest $100 Palms have three or four times as much memory, are faster, and have color. What's not to like? Just backup the Visor, restore to a new device, and get on with life. But i'm the type of guy who shops carefully for bananas. This is much more important and expensive than bananas.

The deep dive investigation should take into account the Three P's. Portability, Performance, and Price. If it isn't portable, you won't use it. If it can't do what you want, you won't use it. If you can't afford it, don't buy it. But otherwise, price can be optimized. You might get performance at the sacrifice of portability. That would be the desktop.

I did a wider search for bliss, and discovered that the Nokia 770 (in process of being replaced by the newer, bigger Nokia 800) has been heavily discounted, and appears in my price range. It has some new capability. It combines the functionality of my old subnotebook, but with the portability and applications of an organizer. It runs Linux, like my desktop, though that isn't evident from the casual look. Linux is under the hood, and i can get at it. It has the power and resources to do things even a new Palm won't do. Here's a comparison:

Feature	Compaq Aero	Visor	Nokia 770
Date	1995-1999	2002-2007	2007+
Display	640x480 grey	160x160 b/w	800x480 color
Data entry	keyboard, mouse	stylus	stylus *
Carry in	brief case	pocket	pocket
Performance	10 MIPS	5 MIPS	100 MIPS
Communications	Cable 22 KB/sec	USB 100 KB/sec	USB or Wireless 1 MB/sec
Programmable	Yes	Not really	Yes
Apps used	note pad, planetarium, book reader, calculator, Web GUI-DB backed app development, web browsing	note pad, planetarium, book reader, calculator, calendar, sketch, contacts, music apps.	Video clips, photo album,note pad, planetarium, book reader, PDF reader, calculator, calendar, sketch, contacts, music apps, Web GUI-DB backed app development, web browsing
User file store	70 MB	4 MB	192+ MB
Cost	$600	$110	$150 (sale)

While the 770 has a stylus, it also has remote login, as did the subnotebook. But that means that one can use the desktop's keyboard. Further, a wireless bluetooth (or WiFi?) keyboard can be purchased. A USB keyboard might be usable, but the 770 does not have a powered USB port, so a powered hub would be needed. To make it portable, you'd need a battery powered powered USB hub. A bluetooth keyboard would be cheaper and easier. I'll try remote login from the desk first.

In the last months of my Visor, i experimented with various languages for it. Chipmunk Basic is free, but is a crippled version of BASIC, and is slow. Lispme is free, implements a variant of scheme, nearly produces executables that you can hand out (you need to give them the whole environment), the environment is fragile, and the speed isn't very good. There is a free C cross platform compiler that runs under Linux, but what i'm looking for is something i can goof around with on the device. Really, the Visor is too slow to be acceptable for an interpreter. Further, the Visor's one-app-at-a-time execution environment means that the user has to wait for any computation to take place. My best guess is that Quartus Forth is the best language. It's not free, but it produces small standalone executables. Too late.

By contrast, the Nokia 770 has a Perl environment installed when you buy it. That means i can hand out a perl script, and that's it. It will just work. And tiny perl scripts can do alot. There's also a shell, so shell scripts are also possible out of the box. While there is a native C compiler - word on the street says it runs out of resources for non-trivial applications. There is a cross platform C compiler. Python and Ruby can be installed. Further, the processor performance is high enough that a language that does not compile to the native iron, like Perl, Ruby and Python, is acceptable for a large number of applications. Further, since it really multitasks, the user can start a computation, and do something else while waiting.

It's been about a week. So, for example, i haven't tracked down and installed a calendar application. So far, the search has only turned up an app that can't turn on the machine and beep. On the other hand, i haven't even gotten a wireless router set up. How have i gotten anything? Well, one of my neighbors, has an open wireless setup, and cable. Thanks, whoever you are. I've been real happy with it so far. But the real test is how i'll like it over the next few weeks.

The latest news is that it appears that there is a Palm OS emulation application. It may be possible to download my favorite Palm OS apps, and run them on the Nokia.

My job is so secret

So, imagine that you have a development cycle where a two line can take six months to make it into production, assuming diligent developers and savy management. By the time the fix gets into place, everyone involved has forgotten what needed fixing. Devlopers have been working in a devlopment environment, where the fix has been around for ages. Testers have to be reminded that it isn't a new bug, and, by the way, the fix is in the pipeline. End users have forgotten that they needed it fixed.

My job is so secret that not even i know what i'm doing.

Pirate talk

It was Talk Like A Pirate Day today. Arrg, mateys, and you can lay to that!

Dark Energy

I was at the store the other day, and noticed that they now sell disk drives that can hold a terabyte of data. Well, of course they hold more data. The whole Universe is expanding!

Queues

The third Rule of Acquisition clearly states, "Never pay more for an Acquisition than you have to", ST:DS9, The Maquis, Part II.

So, large American, Car companies want to save money while conducting their business. Business is complex, and computers can help keep track of things, etc., so they use them. Over time, the Information Technology department becomes rather large and complicated in and of itself, so they look for ways to save money there, too. All this is natural.

One of the issues with computers is that they themselves are rather complex, and require considerable training to use, program and maintain. Good database administrators, programmers, systems administrators, etc., are highly skilled people and therefore are expensive. In general, companies are drawn to organize these people by skill, putting like people into like groups. For example, there's a systems administration group, or a database administration group. A programmer, attempting to write or maintain some application needs to communicate with such a group to make use of such expertise, but also to get access to relevant systems to make needed changes.

As the organization grows, these groups change from technology enablers, to technology gate keepers. They become responsible for systems security, enforcing corporate policies, and so on. To reduce costs, these groups are reduced in size until each person is fully loaded with work. The result is that when a programmer needs to make changes in a system, their request enters a queue, and weeks go by before any action is taken. When mistakes are made, more weeks go by before corrective action is taken. This can be true even for the most trivial of changes, where the programmer had appropriate expertise to make changes, but did not have authority.

And, an honest analysis shows that the body count isn't reduced. It turns out that both the requesting programmers, and the servicing administrators are required to fill out paperwork, perform extra unneeded steps, and real productivity is minimal. The customer has to wait longer, and everyone ends up with more overhead than actual productive work. Far from ensuring quality, mediocrity is enforced. This is not the fault of the individuals.

This tendency to crowd people together by type has long been recognized in industry. The resulting stovepipes generate communications difficulties and pointless overhead. It is not unusual for the overhead to exceed an average of twenty or thirty times the amount of real work, as measured in hours. Worse, much of the overhead is geared to measure progress. Data from these logs are used by managers to show that the system is becoming more efficient, even as latencies grow ever longer. These statistics are, of course, wrong, not just misleading.

Clearly, it's no fun to work in an environment that is mired in bureaucracy. But how does one fix the system? The key is to point out just how terrible the system has become for the end customer. Further, one needs to point out how the head count has grown while productivity has decreased. The evidence clearly shows that small integrated teams, with all the expertise in a tighter nit group are considerably more effective. One needs systems administration, database administration, developers, business liaisons all in one place. If single individuals have competence in more than one area, they are that much more effective. That suggests that small groups control their hardware, systems software, and applications software. Small groups should develop their own standards for backup, source control, coding style and database naming conventions, application deployment, and so on.

Sure, the larger company should have policies, but the development group should be able to treat these as suggestions. If they decide to deviate from company policy, they should be able to do so without a waiver of any kind. Then, the policies will reflect business needs, rather than reflect blind guesses.

What about external requirements, like SOX? These are business requirements, like any other. Let the development group handle them. If they require reporting, then reports become policy or part of the automation, as makes sense. The key is that things should make sense.