|
|
Post by elpoco on Mar 18, 2007 16:54:48 GMT 1
Hi everyone, I have a Zodiac since a few days. I know a bit of C/C++ programming (all I need to code small apps) and I'd like to port some C/C++ applications to PalmOS. But after searching a bit on the Internet, I couldn't find any guide about porting apps. As there seem to be some people here who are quite experienced at that kind of thing, I thought that maybe one of you could give some guidelines. That might take you some time, but that will save a lot more by having other people do the ports they want done.  |
|
|
|
Post by metaview on Mar 18, 2007 22:13:15 GMT 1
I use CodeWarrior and until now I used either the environment from ZDoomZ (yoyofr) or some demo game from vilmos to do the port. I try to avoid C++ as it is very difficult to follow the app flow and CW seems to have problems with some C++ stuff in ARM. First you pick up your favorite env then you add the source and make it compile and link, then you fix the unaligned mem accesses in the original code. Have fun :-)
|
|
|
|
Post by elpoco on Mar 19, 2007 10:45:34 GMT 1
Is the environment you speak about something specific to codewarrior or some sort of porting API ?
Do you have any example or more detailed explanations ? I took a look at ZDoomZ source code, but without any explanations, it's a bit complex to me...
|
|
|
|
Post by metaview on Mar 19, 2007 14:18:23 GMT 1
Environment means a m68k prc, a way to load and call the ARMlet (external zip packed file in Z-Games, or a plain ARM resource in Crimson Fields and PalmPDF) and some already working stuff like stdio, screen refresh, input handling. You should understand the difference between m68k and ARM code and the PalmOS restrictions. Mainly, you don't have a std-c lib.
About ZDoomZ: Do you have CodeWarrior 9.3? You will need it. Load the project and try to resolve all missing paths and SDKs. It's a pain, but when ZDoomZ runs you are ready to use it as a template (just copy, paste) for other projects.
You will see several subprojects: the m68k launcher app, the tapwave patch to access the gfx API on Zodiac without signing, the zip module and the game engine.
The m68k app is just a plain PalmOS app which allows to make some settings and then calls the engine when the user presses launch. The zip module is a port of the zlib. It works and I wouldn't touch it. The game engine retrieves values like screen pointer etc fro mthe m68k app and then calls the main function from the original game.
|
|
|
|
Post by elpoco on Mar 19, 2007 15:49:21 GMT 1
Ok. Thanks.
So if I understand correctly: once I have an environment, all I need is to adapt this m68k app to whatever I am porting and fix some mem access in the original app source code?
... I guess it's not as simple as it sounds.
Does anyone know of an environment/template I could use with prc-tools? I don't really feel like buying a 400$ application just to port some free apps/games...
|
|
|
|
Post by metaview on Mar 19, 2007 22:15:58 GMT 1
Well, I don't know a port made with prc-tools. It seems to me, it's your task to be the first :-) You might just look for "peal" and then try to report ZDoomZ in prc-tools. Would be really great to have also a working env in prc-tools.
|
|
|
|
Post by elpoco on Mar 20, 2007 7:54:39 GMT 1
Ok, I'll try to do that... I'm getting more comfortable with PRC-Tools and started playing around with the Zdoom files... [EDIT : Figured it out. That was just me being stupid.  ] Anyway, I will surely need some help from you in the process, so if you mind me asking questions, tell me now |
|
|
|
Post by metaview on Mar 20, 2007 11:06:52 GMT 1
Just ask. You might also send me an email in addition, because I don't get email notifications of responds in this forum.
|
|
|
|
Post by elpoco on Mar 20, 2007 17:43:15 GMT 1
I tried to get ydkmain68k.c to compile. I'm nearly there but I have troubles with zodiac.c
zodiac.c compiles with a lot of warnings (one for each call of sysTrapTwDispatch - I don't know if that's normal) but then, when I try to compile the whole thing, it tells me that zodiac.o has undefined reference to sysTrapTwDispatch.
(zodiac.c does include the Tapwave.h file which includes the TwTraps.h file which defines sysTrapTwDispatch.)
I had the same thing with MemGlueNewPtr (or something like that) but I solved it by adding the PalmOSGlue library for the compilation. But there doesn't seem to be any library with sysTrapTwDispatch...
Do you (or does anyone one else) have any idea of how to solve this problem ?
|
|
|
|
Post by metaview on Mar 20, 2007 19:56:52 GMT 1
sysTrapTwDispatch isn't correctly defined for prc-tools. Check on skeezix site for a fix: www.codejedi.com |
|
|
|
Post by elpoco on Mar 21, 2007 8:28:41 GMT 1
Didn't find it on his website... Looks like there was a way to get the Tapwave SDK to work with prc-tools on emuboards, but I can't find it... I asked the question there.
If I understand correctly, the launcher is 68k code while the game engine itself is in ARM. So I guess the next step (after getting the Launcher to work) is to convert the game engine into ARM code. Do you just compile it as ARM or is it more complicated than that ?
|
|
|
|
Post by elpoco on Mar 21, 2007 16:15:02 GMT 1
Great ! I've got the Launcher working !
(I just removed the Treo support for now because I don't have the Sony SDK).
So what would be the next step ?
|
|
|
|
Post by metaview on Mar 21, 2007 20:57:51 GMT 1
Treo: Handspring or even better Palm.com SDK :-)
Now, when the Launcher works, try to get the ARM compile, link and run. You will need global variables, look for peal and how to use it. Also on zodiacgamer.com / tapland.com, there is some new code from Hans Schmucker for creating ARMlets.
|
|
|
|
Post by elpoco on Mar 22, 2007 15:24:26 GMT 1
Well... this is far more difficult.
I've got a lot of missing libs...
PACEInterfaceLib.h, I guess it's some CodeWarrior specific stuff. I don't know what I should use to replace it.
size_t.h and searching for it on the Internet turns up a whole lot of code extracts...
cstddef : I've got two files like this, but none of them looks like it's made for PalmOS
There's also a call to a math.h file, I thought I'd use the m68k-palmos specific file, but then I've got warnings telling me the data type is conflicting with the built-in... But maybe that's what it's supposed to do.
Anyway, with these missing/problematic libraries, I'm kind of stuck.
|
|
|
|
Post by metaview on Mar 22, 2007 22:32:47 GMT 1
PACEInterfaceLib.h is for calling m68k API functions. You might replace it with stuff from peal.
cstddef shouldn't be used, not even on codewarrior.
size_t.h, you might only need some parts from it.
|
|
|
|
Post by elpoco on Mar 23, 2007 11:23:14 GMT 1
Just to make sure, the main file for the ARM is PNOMain.c in Src/Native or is it something else ?
If so, is there any main function inside it or should it be compiled without any ?
|
|
|
|
Post by metaview on Mar 23, 2007 14:32:49 GMT 1
ARMlet_Startup.c seems to be the main source file. But it only setup everything to call PNOMain.c. You need to check with peal how to define the main entry function. PNO_Main(const void *emulStateP, void *userData68KP, Call68KFuncType *call68KFuncP) is basically what to be called first, when globals, stack etc. are ready.
There might be also a function called main(), but this is the entry point from the ported app and will be called by PNO_Main after all parameters from the m68k site are retrieved by FtrGet etc.
You really need to check with peal how to set the ARMlet or PNOlet up with prc-tools.
|
|
|
|
Post by elpoco on Mar 23, 2007 14:44:14 GMT 1
Thanks to various sources, I've more or less seen how to setup ARMlet/PNOlet with prc-tools and peal... but it looks like it's quite different from CodeWarrior.
For example, what are the parameters I have to send to PNO_Main ? In the PEAL examples I have, the main function is called without any parameters...
|
|
|
|
Post by metaview on Mar 23, 2007 19:24:15 GMT 1
The ARMlet is always called with these params, you will need them to call back into m68k code (for API calls for instance).
// Demonstrate 68K calls using globals set by PealArmStub()
uint32_t Call68K(void)
{
return (*gCall68KFuncP)(gEmulStateP, (unsigned long)Callback_m68k, NULL, 0);
}
Means they are already globals. The userData is the 3rd arg (myArg):
unsigned long result = PealCall(m, address, myArg);
|
|
|
|
Post by elpoco on Mar 24, 2007 8:39:16 GMT 1
I think I'm calling the main function as I should... I basically took the PARM example from Hans Schmucker and have it call the PNO_Main function with (hopefully) the good parameters.
Now I've got a lot of 'undefined references' to standard function such as malloc, Run, free, vsprintf and so on. I tried a lot of different approaches to get rid of them, but I didn't find any satisfying solution...
I'm beginning to sincerly doubt my abilities to do something like this.
|
|
|
|
Post by metaview on Mar 24, 2007 14:41:32 GMT 1
The missing of malloc, free, vsprintf and such stuff from the c-lib is one of the difficults when porting to PalmOS. But most stuff is already there. Especially malloc/free is #defined as MemChunkNew/MemPtrFree. It's not that easy and fast, I told you...
|
|
|
|
Post by elpoco on Mar 24, 2007 15:15:49 GMT 1
Ok thanks (again).
Could you please tell me if there's anything to build before compiling the PNO_Main ?
I was able to sort it out for the 68k app, but for the ARM part, it's a bit more intricate.
|
|
|
|
Post by metaview on Mar 24, 2007 20:48:37 GMT 1
Well, do you also added the files from /Src/Native ? There is oscompat.c/h where malloc is declared and defined.
|
|
|
|
Post by elpoco on Mar 25, 2007 11:05:11 GMT 1
In the sources of ZdoomZ found on your website the definition of malloc is commented out, should I put it back in ?
|
|
|
|
Post by metaview on Mar 25, 2007 20:51:53 GMT 1
Ah, ok, it's using the __sys_alloc(size_t size) stuff. Just rename it to malloc etc. and you should be fine.
|
|
]