Feedback to "Color By Numbers"- Murphy's Law, January
Read the original artilce at Color
return to Murphy's Law
Further comment on Palm from your author:
The article mentions that Palm got bad press over thier marketing
departments lying tactics with the M130.
Palm offered to refund to disgruntled customers. It is probably
a fairly extreme response to something that makes little practical
difference to the functioning of the device for its typical user,
but it is a fitting punishment for dishonest marketing. The very
fact that so few consumers understand the real meaning of the
number of colors and techniques such as dithering is exactly why
the standards of honesty in marketing these types of devices needs
to be high.
Palms refund offer may be a bit disingenuous. Their web site
requests you to enter your details, and that they will contact
you 'soon'. Like many who have complained in the newsgroups, I
have heard nothing. They seem to be offering a refund for PR purposes,
but in practice they are, at the very least, dragging their feet.
It is a shame to be knocking Palm, a company that has produced
many impressive products in the past, but I am a firm believer
that reckless marketing should always be punished, so that we
can have some hope of believing advertisements in the future.
Now back to mails
"I still hope to find
a good candidate for a cheap platform for embedded graphics work.
If I ever do, I'll let you know. And if you try it with more luck
than I had, I expect you to reciprocate. "
The Charmed Labs Xport
2.0 and Nintendo GBA combination is quite good especially now
with the GBA SP with the on board lighting. I think you will find
the system relatively cheap, good quality and easy to program.
You get to play with an built in FPGA, plus you can play and/or
code games on it. A friend of mine and I both have the system
and we have been doing a few side projects for fun.
In reference to you cheap eval board, you should look into other
Palm devices that do have flash (I'm sure you've already gotten
some emails about this). The m500, m515, and i705 all have flash
ROM and run a Motorola CPU. The new Tungsten T also has flash
but runs an ARM. So, the cheapest eval board you can get would
be $149 w/o color(m500) or $299(after a rebate) w/ color(m515);
as an added benefit you get twice the RAM over the m130(or m500)
with the m515. Just an FYI. By the way, I really like your articles
and look forward to Mr. Ganssle's and your contributions to the
I just read your article about trying (unsuccessfully) to use
an m130 as an inexpensive evaluation board and thought I'd offer
a few quick thoughts.
You mentioned that you can't run from RAM because the interrupt
handlers are still fixed in ROM, which is not flashable. Why not
just prototype your application as a Palm OS .prc, run it from
RAM, and (when running) completely take over the device after
your application is launched? The processor runs in supervisor
mode, so you can easily turn off interrupts, replace low memory
exception (and hardware interrupt) vectors, re-configure the hardware
as you wish including disabling memory protection, etc. and the
device is yours to do with as you wish. When you're done, you
can either hit the reset button on the back or jump back into
the reset vector in ROM to reboot the device. Of course, doing
any of this requires intimate knowledge of the hardware and/or
at least the processor, but that information is available and
if you were considering buying a Motorola Dragonball evaluation
board in the first place (as you mentioned) then this shouldn't
be a problem.
The nice thing about this is that (depending on your exact needs)
you get a development platform that comes in a nice pretty demo-able
package instead of a big ugly development board.
Something else you might be interested in is the Palm OS Emulator.
It is an open source 68K emulator that emulates most Palm OS Devices
on the desktop, talks to various debugging tools (Metrowerks CodeWarrior,
PalmDebugger, gdb, etc.), and runs on Mac OS, Windows, and Linux.
You might find it helpful in (a) figuring out how various device
hardware works, and (b) re-using to create a customized emulator
for your own embedded projects.
Just read your Color by Numbers article. Have you considered
using the Nintendo GameBoy Advance as a GUI platform? The screen
is very good, it is cheap, and in March there will be a new version
with a lit display as well. There are lots of programming resources
on the web.
Karl H. Torvmark
Field Application Engineer Chipcon AS, Norway
This is an extract from a mail from Alex O'Donnell, which describes
a useful trick that I had not come across elsewhe:
I am a bit confused by your reference to overlaying planes
- some hardware >supprts this, but from the context I am wondering
if you are refering to >some trick with the color map to achieve
this. If there is one I am not familiar with it.
It's a technique I learnt at collage (Manchester Polytechnic),
and only used a couple of times in radar and mapping applications.
I was working on an Arm2 (Acorn A3000) based portable radar display,
we had 256 colour mode. We set up the palette so we had 4 bits
for Radar image, a bit for the text plane, a bit for cursors and
a bit for map info. We maintained the polar scan image in the
video buffer, updating live, this gave us smoother sweep than
buffered video mode. Each pixel in the radar image under went
a read modify write, ANDing to preserve text and icons, ORing
to set this sweeps radar image. Disabling graphics or text then
simply became a matter of changing the colour map. Moving a cursor
simply a case of XORing the bits involved. As you can see we were
down to 16 colours radar image, and three graphics colours, but
the savings in RAM and imaging processing time were tremendous.
So there we were, faking hardware overlays with software. I guess
most people have more fire power and memory, and can get away
without such techniques now. Strange what's happened in the last