#15335 - void - Tue Jan 20, 2004 11:48 pm
I don't really know much about coding C/C++, but I'm wondering if it would be possible (and feasible) to make a PalmOS emulator for the GBA. Palm has an emulator for the PalmOS that runs on PC, Mac, and Unix... they also make the source code available... is there any way it could be compiled the the GBA's ARM proc?
This seems somewhat possible, due to the emulator being open-source and the Palm application ROMS being available for free (you have to sign up as a developer)... If this works, could you, in theory, run apps designed for PalmOS on a GBA? I'm imagining something like the NES emulator for GBA... you bundle the NES emulator and NES ROMs all into one GBA ROM.
There are tons of gameboy emulators for the palm... seems like the hardware in a GBA is much better and would emulate the palm better than the other way around.
#15337 - ampz - Wed Jan 21, 2004 12:15 am
Older Palms are 68000 based. The new Tungsten devices are ARM based.
The Tungstem devices definitely has more CPU power than the GBA. On the other hand, most Palm applications do not require the full speed of a Tungsten.
One problem might be the resolution of the GBA... I think the older black and white Palms have a 160*160 screen or something like that. The Tungsten has something like 320*320.
The Palm (all models) has _much_ more RAM than the GBA has. This is the second problem.
#15339 - void - Wed Jan 21, 2004 12:42 am
OK, wasn't sure what CPU new palm's use... last I knew they were using Morotola DragonBall CPU's. However, I'm thinking of programs like datebook, todo, etc. - things that don't require a lot of CPU.
The resolution... in OS 5 didn't they make it possible for palm devices to run almost any resolution? (The new Tungstens have a virtual graffiti pad & rectangular screen, don't they?)
A few more obstacles I've thought of...
Pointer - Could the D-pad somehow be made into a pointer? This could be tough
PC Connection - Would be awesome to have the GBA think it's a palm, then install Palm Desktop on PC and sync... but something tells me that this is nearly impossible given the way most GBA programs are. Unless you could use the GBA's save files to save user data... who knows
#15342 - ampz - Wed Jan 21, 2004 1:47 am
| void wrote: |
The resolution... in OS 5 didn't they make it possible for palm devices to run almost any resolution? (The new Tungstens have a virtual graffiti pad & rectangular screen, don't they?)
|
I think all Palms have square screen... Even the Tungstens..(?) I might be wrong about this.
| Quote: |
A few more obstacles I've thought of...
Pointer - Could the D-pad somehow be made into a pointer? |
Why not?
| Quote: |
| This could be tough |
Why would it?
| Quote: |
| PC Connection - Would be awesome to have the GBA think it's a palm, then install Palm Desktop on PC and sync... but something tells me that this is nearly impossible given the way most GBA programs are. Unless you could use the GBA's save files to save user data... who knows |
Sync is easy. Palms have a standard serial port that is used for syncing. The GBA serial port would work just nicely.
The biggest problem is most likely the huge amount of RAM that Palms have and the GBAs don't have. If I remember correnctly, Palms store everything (code and data) in battery backed RAM rather than flash memory.
#15343 - void - Wed Jan 21, 2004 2:23 am
| ampz wrote: |
I think all Palms have square screen... Even the Tungstens..(?) I might be wrong about this.
|
No, there are ones with rectangular screens. This was one of the major steps forward in OS5.
| apmz wrote: |
Sync is easy. Palms have a standard serial port that is used for syncing. The GBA serial port would work just nicely.
|
This seems far too simple for adding programs, at least. You would have to sync it using the PC Emulator, burn an image of the palm system, then send it to the GBA... once you write a ROM image on the GBA you can't modify it, so you couldn't add programs, etc, but you could keep preferences, user data, etc in RAM.
| apmz wrote: |
The biggest problem is most likely the huge amount of RAM that Palms have and the GBAs don't have. If I remember correnctly, Palms store everything (code and data) in battery backed RAM rather than flash memory. |
Not necessarily... the ROM on palm devices is basically just an archive of .prc files. You could build a palm ROM for the GBA with all the programs you want included (see http://romeo.sourceforge.net/ for more info on that. The only thing you would need to keep in RAM is user data. Just to get a sense... my old palm pilot had about 50 addresses, a detailed calendar, a few todo's and memos. The total amount of RAM used by these applications is only about 50k. (These are the files backed up to your computer when you sync) To put things in perspective, the amount of RAM used to save game info on Advance Wars 2 is 512k. Considering the only things that really change on palm programs are preference settings, high scores, etc. This seems like an issue that would have to be addressed- programs would have to be stored in ROM, not RAM, but it doesn't make it impossible.
#15344 - ampz - Wed Jan 21, 2004 3:00 am
| void wrote: |
| apmz wrote: |
Sync is easy. Palms have a standard serial port that is used for syncing. The GBA serial port would work just nicely.
|
This seems far too simple for adding programs, at least. You would have to sync it using the PC Emulator, burn an image of the palm system, then send it to the GBA... once you write a ROM image on the GBA you can't modify it, so you couldn't add programs, etc, but you could keep preferences, user data, etc in RAM.
|
That is a memory problem. Not a sync. or cable problem.
| void wrote: |
| apmz wrote: |
The biggest problem is most likely the huge amount of RAM that Palms have and the GBAs don't have. If I remember correnctly, Palms store everything (code and data) in battery backed RAM rather than flash memory. |
Not necessarily... the ROM on palm devices is basically just an archive of .prc files. You could build a palm ROM for the GBA with all the programs you want included (see http://romeo.sourceforge.net/ for more info on that. The only thing you would need to keep in RAM is user data. Just to get a sense... my old palm pilot had about 50 addresses, a detailed calendar, a few todo's and memos. The total amount of RAM used by these applications is only about 50k. (These are the files backed up to your computer when you sync) To put things in perspective, the amount of RAM used to save game info on Advance Wars 2 is 512k. Considering the only things that really change on palm programs are preference settings, high scores, etc. This seems like an issue that would have to be addressed- programs would have to be stored in ROM, not RAM, but it doesn't make it impossible. |
When you say 50k RAM on your Palm you are most likely talking kilobytes. AdvanceWars 2 have 64kilobytes savegame area. (512kilobits==64kilobytes). And advance wars use a flash memory for savegames, but that's not important.
I also guess thoose 50k are stuff like user settings... Things that must be saved. How much work RAM do the applications require?
#15346 - void - Wed Jan 21, 2004 3:22 am
Ack, looking at the Palm developer's page, it looks like the emulator they have only runs versions 4.x. HOWEVER, they are working on an emulator that works with PalmOS 5 and uses the ARM instructions. There is a "simulator" which is basically PalmOS compiled for x86, this is from the simulator's site:
| Quote: |
From http://www.palmos.com/dev/tools/simulator/
What does it run on?
It has been tested on Windows 98, NT, 2000, ME and XP. Because the Simulator relies on the endianess of Intel x86 chips being little endian like that of the ARM chips Palm OS 5 is targeted at, there are no plans to create a Mac version of the Simulator. Instead we are working on an ARM Palm OS Emulator that will run on both Windows and Mac OS. |
Will this work better for creating a GBA Palm emulator, since it will be directly written for ARM?
#15347 - tepples - Wed Jan 21, 2004 3:41 am
| void wrote: |
| once you write a ROM image on the GBA you can't modify it |
My experience says differently. If you know how to communicate with 1. your flash cart's ASIC and 2. your flash cart's flash chip, you can rewrite any sector of the flash cart up to 10,000 times before it wears out.
| Quote: |
| To put things in perspective, the amount of RAM used to save game info on Advance Wars 2 is 512k. |
As ampz points out, GBA saves are on the order of 512 kilo-bits (64 KBytes), not 512 kilobytes. Typical flash carts have about 2 Mbits (256 KB) of SRAM in four 512-Kbit (64 KB) banks; the flash cart's ASIC controls the bankswitching.
| Quote: |
| Considering the only things that really change on palm programs are preference settings, high scores, etc. This seems like an issue that would have to be addressed- programs would have to be stored in ROM, not RAM, but it doesn't make it impossible. |
More issues:- you'd have to use an EZF cart, as the F2A carts that work don't include a clock.
- you'd have to leave the GBA turned on all the time, or it wouldn't be able to beep on an event. How much current would this take, even with sleep mode?
- how would you do text entry for jotting down the occasional contact or event into the machine? Graffiti doesn't work well with a digital pad.
- at what speed are the PalmOS 5 devices clocked? How much slower will an app run on a 16.8 MHz ARM7TDMI?
- do Palm devices have ARM9's extensions to the instruction set?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15360 - ampz - Wed Jan 21, 2004 12:13 pm
| tepples wrote: |
| how would you do text entry for jotting down the occasional contact or event into the machine? Graffiti doesn't work well with a digital pad. |
A keyboard of course :)
| tepples wrote: |
| at what speed are the PalmOS 5 devices clocked? How much slower will an app run on a 16.8 MHz ARM7TDMI? do Palm devices have ARM9's extensions to the instruction set? |
If Palm OS is closed source, then it does not matter if it uses ARM7, ARM9 or 68000 instructions. It must be emulated anyway.
#15628 - torne - Mon Jan 26, 2004 11:06 am
I don't know about PalmOS 5, but all previous revisions of Palm OS were based on a third party closed-source proprietary kernel called AMX that not even Palm's own developers got to modify in any significant way (it was licenced to them under pretty restrictive terms). The interfaces to AMX were totally, utterly undocumented to anyone outside Palm, to prevent anything except the core PalmOS code from calling them usefully (AMX is fully preemptive multithreaded, but PalmOS <=3 is single-tasking from a developer POV; the extra threads are only used by the system internally and you can't get to them).
If PalmOS 5 has in any way a similar situation, you may not have a lot of luck. The PC simulator for the previous OS versions still ran the normal AMX kernel from the Palm ROM, and thus had to emulate the (totally undocumented) hardware interface expected by AMX.
#15636 - frag - Mon Jan 26, 2004 8:39 pm
| Quote: |
| If Palm OS is closed source, then it does not matter if it uses ARM7, ARM9 or 68000 instructions. It must be emulated anyway. |
Not necessarily. Windows is closedsource (obviously), yet look at the open source project WINE.
They aren't emulating windows. They took the established, documented APIs and rewrote their functionality to run under a *nix environment while providing the same interface to them.
Something similar could be done on the GBA for PalmOS. Perhaps a subset of the total API.
If you are interested more in the hacker just-cause-its-cool aspect of this project ignore the following line.
The Zodiac by TapWave (tapwave.com) runs PalmOS 5 with extensions by TapWave, which would certainly be an easier route for high performance gave development on a handheld.
Frag