My LineF question is, is there an official way to find the Trap #F
system entry table? Someone here wants to scan for hacks/patches.
I've noticed that the 3.3 roms use a lot of hard-coded "movea.l $122,
a1" calls and then grab the fuction address directly from the table.
Presumably this was done to improve speed at a slight cost in code size.
Back to whining about DmWrite:
First, OK, I'll follow the rules - dutifully!!! I will brow beat
everyone I meet into following the rules... But, unless my
mini-debugger is lying to me, DmWrite is not quite implemented as it has
been previously described.
I looked at 2.0 and 3.3 roms. In both, DmWrite is basically:
MemSemaphoreReserve(1);
MemMove(...);
MemSemaphoreRelease(1);
The 3.3 roms access the calls as sub-routines and the 2.0 roms use Trap
#F, but they are basically equivelent.
DmSet() is basically:
MemSemaphoreReserve(1);
DmWriteCheck(...);
MemSet(...);
MemSemaphoreRelease(1);
I'll spare everyone the details, but MemMove is basically smart enough
to use the largest bus accesses it can for as much of the move that it
can. It also does some parameter checking, but it makes some
reasonable, but not perfect assumptions.
In both Roms, MemSemaphorexxx() is a bust. Basically:
return 0;
They also seem to indicate that Palm could spring for a better compiler.
Both functions are:
link a6
moveq #0, d0
unlink a6
rts
Even if the function is declared with an unused argument (it is being
passed a 1 by the Dm functions), you would think that the compiler would
catch no arguments used, no automatics... I'm guessing that these calls
are place holders for harware write protection of data records, but my
guesses are usually wrong...
Thanks in advance for the help on the Trap #F function table.
-jjf
P.S. I promise to never mention DmWrite again...
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
