On Tue, 15 Jun 1999, David Fedor wrote:
> >To compensate for the different dragonball processors, before you use
> >anything referencing the registers, do:
> >
> > if( !FtrGet(sysFtrCreator,sysFtrNumProductID, &id) && (id >> 16) >= 2)
> > TCMP2 = &TCMP2[-6];
>
>
> Eek, just noticed this bit of code. You do realize that for all future
> processors, this code will incorrectly assume it is using an EZ dragonball?
No, it will assume the timer registers correspond to the EZ dragonball's
memory map. But you are right that it is a bad assumption.
It is also a bad assumption that this will be the 100Hz tick.
The problem is that FtrGet isn't resource sensitive. For the sake of
example, assume that Motorola comes out with an EZ+ Dragonball, whose only
difference is a 68010 core (so it does the dbcc cache thing and speeds up
things greatly, and would allow restarts on bus errors so Palm/Linux could
be more interesting). You would increment the feature number, but it
would NOT affect the register map. And I really don't care about what
type of DragonBall or other Motorola processor it is, but I do care about
the timer.
(I also suggested a long, long time ago a mechanism for finer timing
gradations, but I suspect it is NOT in 3.3, though the VII does something
to do finer gradations, so this code would not work there either, but I
don't have the FtrGet values for that - and no I haven't run the Palm
VII rom under POSER).
> I hope that your software has first checked that you're on either a
> DragonBall processor or a DragonBall EZ processor... otherwise who knows
> what effect this code will have.
There is a version of PalmOS that runs on something else? What does the
FtrGet call return? I'll adapt it.
> (It would make me feel better if you'd just mention issues like this in
> your email when posting code like this; clearly you know about the issues
> but not everyone who reads your email does!)
I really should. But I am composing these things in haste, so don't
always remember to give the usual warnings and disclaimers.
