Hello!

I recently got a new treo handspring 600 phone (palm os 5, 144mhz ARM processor). My thoughts obviously move to what emulators I could get on it :)

I'm quite tempted to try to convert some existing ones. I have some emu experience (well... I've done pacman hardware...). I was hoping that someone might be able to save me a lot of time by suggesting what might be a good open-source emu or two to try to convert across and get decent speed. So any advice from anyone who has experience with some clean open source emus?

I'm assuming something like:

From a C program I'll probably be able to get nes or master system working at reasonable speed with no sound in a quite short period of time

Perhaps Dave's new ARM-core might let me get genesis. in 100Mhz.. will that happen do you think?

I'm assuming without a core SNES is way out. GBA might be possible by some clever mapping of code, but that's way out of my league..

and of course, there is the classic arcade emus. I'm thinking MAME might be overkill.. any suggestions on some smaller open-source arcade emu (just an earlier version of mame? ^_^ )

Sorry for the long rambling post, and I'd be really happy to hear any or all comments to help me get started!

I reckon you'd probably have to do static recompilation to get genesis working, especially if you want sound too.

smf

> Hello!
>
> I recently got a new treo handspring 600 phone (palm os 5, 144mhz ARM
> processor). My thoughts obviously move to what emulators I could get on it :)
>
> I'm quite tempted to try to convert some existing ones. I have some emu
> experience (well... I've done pacman hardware...). I was hoping that someone
> might be able to save me a lot of time by suggesting what might be a good
> open-source emu or two to try to convert across and get decent speed. So any
> advice from anyone who has experience with some clean open source emus?
>
> I'm assuming something like:
>
> From a C program I'll probably be able to get nes or master system working at
> reasonable speed with no sound in a quite short period of time
>
> Perhaps Dave's new ARM-core might let me get genesis. in 100Mhz.. will that
> happen do you think?

Yes!! Cyclone runs great on the GP32 (132Mhz)

smf is right about the sound, there is no public Z80 core I know of, but at least you'll be off to a start


Please try porting PicoDrive, it designed to be as portable as possible and that would great to see how it runs on Palm.

You can get the latest source on my website: www.finalburn.com/cyclone/


It should port straight over if you are using GCC, just get Cyclone.o, compile the Pico\ directory, and then make an interface for it (e.g. TreoDrive).

In your interface you call PicoInit(), PicoCartInsert() with the rom image, and then setup PicoScan (a function which is called with the pixels for each scanline). Then repeatedly called PicoFrame and PicoScan gets called 224 times a frame with your pixels.

Voila! Plus if you can manage to do a Zodiac one at the same time Prophet will love you forever...


> I'm assuming without a core SNES is way out.
Probably... plus I think I'll scream if someone does another port of PocketSNES running at 15fps and then declares their SNES emulator 'done' :P

> GBA might be possible by some
> clever mapping of code, but that's way out of my league..
>
> and of course, there is the classic arcade emus. I'm thinking MAME might be
> overkill.. any suggestions on some smaller open-source arcade emu (just an
> earlier version of mame? ^_^ )
>
> Sorry for the long rambling post, and I'd be really happy to hear any or all
> comments to help me get started!
>


You learn something old everyday...

> I reckon you'd probably have to do static recompilation to get genesis working,
> especially if you want sound too.
>
> smf
>


This might be slightly controversial, but are we sure static recompilation is the solution on mobile devices? It's hard to say... I mean have a look at some of the profiling I have been doing on Cyclone running Sonic1.

Now as far as I can tell the slowdown isn't to do with the opcode fetch or anything - a 205Mhz ARM can run at about 73Mhz (one frame takes 1.7ms in the ideal case), but rather something else (yet the same opcodes crawl down to 20ms in the worst case). Maybe the RAM accesses (my best guess at the moment) are thrashing the cache in some weird way.

It affect Pocket PC, but not GP32 afaik

Now it's too early to say, but wouldn't this slowdown be true of a dynarec or a staticrec as well as an interpreter?
And in fact wouldn't this be *more* so because of the extra memory requirements for the translated rom?
Are we sure that for 68000 on ARM the bottleneck is for instruction translation? Maybe RAM access/coherence is more critical on mobile devices.


Do we actually know that recompilation would work well on devices other than the GBA with it's massive flat fast ROM cartridges? Remember the GP32 only has 8Mb, and Dynarecs on PC are typically run on machines with 128Mb or more?


You learn something old everyday...

> Now it's too early to say, but wouldn't this slowdown be true of a dynarec or a
> staticrec as well as an interpreter?

A static recompiler would do less ram access & it would be more cache friendly. If the cache is a simple design and you have two opcode handlers which use the same cache slot then it will be fast until someone uses those two opcodes one after another. With a static recompiler you put all the code inline, so the issue should be less. It depends on whether it's cache thats the issue, or whether you're overloading the video controller somehow ( like if palette updates take a long time ).

smf