>I hope this was fixed in version 4.x of CW...
In those old versions, the library contained one version of datapage.c, and if that one did not fit the target processor, you had to add the datapage.c to the project to build it. The main problem with this was that this just failed at run time, and that's bad.
Now datapage.c is no longer contained in the library, so you still have to include it into the project (it is added in every wizard created project), but if you fail to add it for whatever reason, it wont link if __far data support is used. So no incorrect automatic datapage.c anymore.
Also datapage.c does now use the PPAGE address as specified with -CpPPAGE, and if -CpPPAGE is not specified, it uses the right address by depending on the -cpu option. So there is little need to change datapage.c unless you have some very custom setup.
>Anyway, you are using the banked memory model(switch -Mb) so you shouldn't have to worry about this.
>The compiler will use call and rtc instructions rather than jsr and rts. The only time you need to
> think of this is when you are writing inline assembler.
PPAGE is used mainly/only for __far data, and the code snippets provided did explicitely ask for __PPAGE_SEG access to constants (which happened to be function pointers, but that does not really matter).
I doubt a bit that the use of __PPAGE_SEG in the original snippet was intended, if not then resolving the issue is as simple as deleting the __PPAGE_SEG qualifier.
Otherwise the -CpPPAGE option should be fixed. (well it should be fixed either way, I guess :smileyhappy:.
Daniel