It would be nice to have dynarec for ARM based handhelds... I suppose this is the architecture which is behind most of various mobile devices, isn't it?
I do not have any mobile device which could use DOSBOX, but I definitely plan to buy one next year... So I am very interested...
I am sure DOSBOX developers will support you as much as they can.

As for developer access to DOSBOX CVS (or did DOSBOX already migrated to SVN?) - it depends on QBix/Harekiet/WD...
But from what I saw in past:
Developer access to DOSBOX CVS is given only rarely. A lot of things made by people here were done as patches which were integrated only when developers saw them mature enough. And people behind them have no developer access (gulikoza, vasyl, kronus, moe...).
In any case I think you will have to show something before trying to become officiall developer...
If you need public repository, maybe you can start another project on sourceforge...

Anyway - I hope this will not dicourage you - I am certain that a lot of people would appreciate your work. Mobile devices have weaker processers, so the dynamic core is even more important. So good luck with your work.
By the way - WD also started by making patches and only later after some excellent work (for example on Win 3.x support) was admitted as developer...

Mirek

@hey zodttd, welcome to this forum, i've been following your work over on gp32x.com for a while now, nice job ^^

wish you luck with your current idea 😀

You should be aware that the dynamic core is biased towards x86 hosts
at the moment. This considerably simplifies the flags handling, which
would have to be rewritten for non-x86 hosts.
The rest should be adding a risc_arm.h (that is rewrite the routines of
risc_x86.h to generate arm-code), which might/might not be hard/fun/whatever.
As of help about the dynamic core and dosbox in general, you can use
the board for questions. Especially because the dyncore lacks source
comments.

Great to hear these responses! 😀
mirekluza: I fully expected to have to produce the dynamic recompiler for ARM first before being able to submit it, so no issue's there. I just wanted to see if it's something that has potential to be submitted to the CVS since I didn't want to maintain a seperate build of DOSBox. Less donations for me 😀 but better overall for DOSBox, which is what really matters.

Spearhead: Hi! Good to see familar faces. 😀

wd: Do you think I'll run into the problem of having to change much within the DOSBox sources outside of the dynamic core source? If changes have to be made, I'll make them compatible with all hosts, or in certain cases configurable depending on how DOSBox source is setup in regards to this.
risc_arm.h will be the most tedious (yet fun, if that makes sense) process for me, since I'm more familar with ARM than X86. So I'll have to study the risc_x86.h carefully but if I have any questions, it's good to know there's help here. I'm very used to source without comments (I've dealt with horrid open source code beyond people's imagination), so I'm quick to figure out what's going on in undocumented code.

For testing the ARM Dynamic core, I'd have to use an unofficial ARM port of DOSBox it seems. There's some that keep up with DOSBox and are nicer than others. I plan on testing with a Sharp Zaurus and GP2X.
Once complete it should be compatible with a large amount of ARM based handhelds including:
- PocketPC (the Gizmondo gaming handheld and most recent PocketPC's use an ARM based Intel xScale)
- Palm (some of the recent Palm's use ARM but have a restriction on certain registers)
- GP2X (a large community of people support the GP2X handheld, popular for homebrew gaming )
- Sharp Zaurus C series (really cool Linux based PDA with built in keyboard and 640x480 screen)
- Very likely a bunch more ARM based builds of DOSBox. 😀

Most the handhelds listed run DOSBox but at slightly less speed than possible to find enjoyment playing games the user's want to. So I'm hoping this dynarec will help the performance issue. 😀

Should be a fun project.
Time to get the sources from the repository and see what I'm in for. ;P

> Do you think I'll run into the problem of having to change much within
> the DOSBox sources outside of the dynamic core source?

No, the changes can be done solely by rewriting/adding stuff to the
dynamic core.
But the flags problem is a bit crucial, as for x86-to-x86 recompilation
everything can be done by the host. This won't be possible on the
arm, so you'll have to find some different solution for that part.
Currently on an x86, recompiling the code

1cmp eax,0
2jnz 1234

recompiles to something like

1[kick saved flags]
2cmp edx,0
3pushf
4jnz 1234

That's not really what it looks like, but i hope you got the idea 😀

Did you look into it yet?

Are there other people with knowledge about non-x86 architectures
(asm level), who'd be willing to help out with some parts?

Hi wd,

For the X86 -> ARM Dynarec, I have the ARM part covered. I've been having a hard time finding a low (lowest) level X86 person to help me out. There's a few other emu writers such as Exophase who are willing to help but don't have time to be "dedicated" to the project.

I was a bit shy of asking DOSBox developers for help with the X86 part, as it would show my lack of knowledge of the architecture. But since options are running out...If what's stopping an ARM target for the dynarec, I can get the work done to get it completed, I'm just new to the X86 instruction set, so I'll need someone's help with that.

Also of interest might be a X86 -> MIPS32 dynarec, if you believe it would be an easier project to build up to an ARM dynarec. Like ARM, I have a good amount of expierence with the MIPS32 instruction set (down to the bitsets) as well.

There's been a lot of support for this project on various handheld forums.
How should we start? 😀

> I was a bit shy of asking DOSBox developers for help with the X86 part

Feel free to ask any kind of question on the board (this thread preferredly),
the worst thing to happen is that nobody answers 😉

> How should we start?

Imo the first problem is the flags handling, see above. The current
design of the dynamic core uses the pushf instruction to push the flags
(generated by some preceding instruction) onto the stack. That way
the flags can be protected, if they're to be used later they are restored
by a popf instruction.
That stuff is unlikely to work on non-x86 architectures, but i don't have
any knowledge about arm and similar. Maybe arm instructions generate
similar flags, so the gen_protectflags() and gen_needflagd() functions
can emulate the x86 flags states.