Pandora Wine Working On N900 - Maybe Pandora?

[God Ginrai]

http://www.physics.ucla.edu/~grosenth/jwpce.html

I'd love my pandora even more if it ran that....

It's GPL (and oh i even found a source link in the page), and even if it uses the WINAPI, maybe it could be compiled against a native winelib (atleast someday) (open-source windows program, oh what a rarity ).

I worded my post the way I did because I couldn't find the source link. Where was it?

-God Ginrai

 

[Stuckie]

Someone has got some basic windows programs (eg solitaire) running on the N900 with a build of QEMU-i386, WINE and a chroot. Apparently the virtual machine equates to a P90 with 256MB of ram - perfect for a lot of pre-3d accelerated windows games.

Ironically, I went the other way to get Debian and Ubuntu running in the Extend stuff - I used qemu-arm in a chroot on my desktop machine!
Didn't actually think that this could run the other way around... hmm... think I now have something to do tomorrow

Probably a good thing I'm almost finished with the new version of Extend Utils! it's a beast as well, the script is currently 450 lines long, and I'm not finished it yet - still have Dev Extends and Root Overlays to support.. I was going to do customised Overlays and stuff, but that's bordering on the limits of madness.. you can already do crazy multiple extend and overlay mounting as it is!

It shouldn't be hard to support something like this as well, so I'll have a poke about in a minute or two...

--edit--
Also, "hero"? I'm just a lunatic that won't leave things alone! XD

 

[Blue Ion]

You do know that dosemu uses vm86, thus not possible on pandora (or on ARM devices in general)?...

Yes, I do know that, and I didn't imply porting Dosemu to the pandora, even though dosemu has a recompiler of some sorts as it can run in 64 bit linux (or so I heard, I don't have a 64 bit machine at home).
But it definitely won't be as optimized as dosbox.

I was asking to make a similar integration of qemu and dosemu in order to have some speed boost, in comparison of dosbox.
Then again, I haven't stopped to think that this is ancient legacy code (what freedos is trying to replicate that is) so porting this way might be near impossible.

Anyway, it could be interesting to run the complete x86 version of dosemu through qemu and see if it is slower or faster.

 

[Exophase]

Yes, I do know that, and I didn't imply porting Dosemu to the pandora, even though dosemu has a recompiler of some sorts as it can run in 64 bit linux (or so I heard, I don't have a 64 bit machine at home).

Highly doubtful. 64-bit CPUs still support v86 mode, which dosemu has always used.

I was asking to make a similar integration of qemu and dosemu in order to have some speed boost, in comparison of dosbox.

I think this won't work, or at least not in the same manner. Under qemu's full system emulation it'll work, but that defeats the entire purpose; you'd may as well just emulate a DOS machine directly. The reason why I don't think this will work under user mode emulation is because the emulation allowed via v86 doesn't fit the same profile usermode Linux and Windows emulation fits. DOS apps have lower level access to the CPU and hardware, and are not happy being abstracted in the way that user mode emulation requires.

 

[trix]

--edit--
Also, "hero"? I'm just a lunatic that won't leave things alone! XD

Dude, if you get this working well enough for Magestorm, you will be MY hero! (que annoying hero theme song)

 

[ldesnogu]

Everyone should take the Pentium 90 claim with a little more salt:

"feels like it's running at about Pentium 90 speeds, which I'm hoping is enough for what I really want to get going."

That sounds extremely vague and error prone. Not that I'm saying it's wrong, I just don't exactly expect Pentium 90 levels with qemu at the level it's at. Still should be loads faster than DOSBox, though.

That's vague indeed, but on what do you base your expectation that P90 speed isn't possible?

Current QEMU should be at about this level except for floating-point and unless the devs broke QEMU on ARM, since my major speedups were integrated into QEMU before I stopped working on it.

I agree an nbench number obviously can't reflect the speed of some random emulated application, but it's a hint anyway

 

[urjaman]

http://www.physics.ucla.edu/~grosenth/jwpce.html

I'd love my pandora even more if it ran that....

It's GPL (and oh i even found a source link in the page), and even if it uses the WINAPI, maybe it could be compiled against a native winelib (atleast someday) (open-source windows program, oh what a rarity ).

I worded my post the way I did because I couldn't find the source link. Where was it?

-God Ginrai

From that link click "Download the program", then "Download Version 1.50", then scroll to the bottom of the page, there will be a heading like "TECHNICAL: JWPce Code" with a link to http://www.physics.ucla.edu/~grosenth/jwpcesrc.zip

 

[Exophase]

That's vague indeed, but on what do you base your expectation that P90 speed isn't possible?

Current QEMU should be at about this level except for floating-point and unless the devs broke QEMU on ARM, since my major speedups were integrated into QEMU before I stopped working on it.

I agree an nbench number obviously can't reflect the speed of some random emulated application, but it's a hint anyway

Sorry, I didn't realize they actually incorporated your changes. With the proper recompilation > 90MHz Pentium levels should certainly be attainable, for user mode emulation, possibly even quite a bit more than that. Of course, there's also the overhead of Wine itself people have to look out for...

That said, the problem I (still) have with nbench vs that 90MHz Pentium is that it's still not the same compiler (Watcom 10 vs GCC 2.96), and the "memory" baseline is omitted entirely. In the K6 baseline it's quite a bit higher in the "integer" test than the "memory" one, although that could be due to the more (but substantially slower?) L2 cache.

I will also contend that for the things people are most interested in here in this thread (games) floating point performance will probably be important more than occasionally, especially for any 3D ones.

 

[trix]

Success!!

[...]

So I've used the x86 version of ls to list the folders on an arm machine and it was instant with no overclocking.

Next stop.... WINE

edit: fixed typos

Hi! Just wondering, any updates as to how it goes with Wine?
Sorry for impatience, but I'm dying to know!

- trix

 

[ldesnogu]

That said, the problem I (still) have with nbench vs that 90MHz Pentium is that it's still not the same compiler (Watcom 10 vs GCC 2.96), and the "memory" baseline is omitted entirely. In the K6 baseline it's quite a bit higher in the "integer" test than the "memory" one, although that could be due to the more (but substantially slower?) L2 cache.

That's the reason why I provided results on real x86 machines using 2.96, look here.

As far as the memory score goes it's partly due to the way QEMU translates rep-prefixed instructions. I changed that for some other project.

 

[Exophase]

That's the reason why I provided results on real x86 machines using 2.96, look here.

As far as the memory score goes it's partly due to the way QEMU translates rep-prefixed instructions. I changed that for some other project.

I know you provided it, but for totally different CPUs than Pentium 90MHz, and baselined against the K6 anyway. And while I appreciate how a compiler from a closer era gcc 2.96 is still not Watcom 10.0. You do realize that this compiler was released in 1994, right?

So I guess if we want to extrapolate something from these results, it'd be 0.327 0.452 0.258 vs P233 = 0.633 0.698 1.128, so memory = P120, integer = P150, float = P53, but that's of course with linear scaling that I don't think a P233 actually achieved over a P90 (memory catching up with things)

 

[javispedro]

Highly doubtful. 64-bit CPUs still support v86 mode, which dosemu has always used.

No; amd64 linux doesn't have v86 mode support. This is "by design": while it can be easily added and the CPUs support it (long mode -> legacy mode -> v. 8086 mode ), seems that both NT and Linux jointly decided it was time to drop public support for it.

DOSEmu on amd64 uses an interpreter (iirc) for real mode code. Protected mode code -- (applications under extenders, Windows/386, etc.) -- is run natively and thus the reason: a) dos4gw games are fast B) an armel port is not very feasible.

 

[God Ginrai]

Highly doubtful. 64-bit CPUs still support v86 mode, which dosemu has always used.

No; amd64 linux doesn't have v86 mode support. This is "by design": while it can be easily added and the CPUs support it (long mode -> legacy mode -> v. 8086 mode ), seems that both NT and Linux jointly decided it was time to drop public support for it.

DOSEmu on amd64 uses an interpreter (iirc) for real mode code. Protected mode code -- (applications under extenders, Windows/386, etc.) -- is run natively and thus the reason: a) dos4gw games are fast B) an armel port is not very feasible.

64-bit CPUs still support v86 mode

-God Ginrai

 

[Exophase]

I don't even know why they bothered using emulation for 16-bit code.. that was never the point of dosemu. Why try to compete with DOSBox all of a sudden? Should have just dropped support for it on 64-bit Linux.

 

[marovada]

Hi! Just wondering, any updates as to how it goes with Wine?
Sorry for impatience, but I'm dying to know!

- trix

trix, I spent some time setting up an x86 'environment' on my sd card using PC ubuntu binaries with a wine install. Now I've got to do some tests to ensure I've got all the files I need but I'm back at work unfortunately.

 

[Stuckie]

Hopefully you'll get further than my little play about
Best I could get was wine.bin causing segmentation faults, and wineserver attempting to start but failing to do anything much...
I also couldn't chroot directly in, which was annoying as I had set up binfmt... though I was kindof doing this through a Debian chroot, so perhaps that extra level of abstraction was stuffing things up ( going from Angstrom > Debian-Armel > Debian-i386 ) but if you do something like:
qemu-i386 /tmp/x86root/lib/ld-linux.so.2 --library-path=/tmp/x86root/lib:/tmp/x86root/usr/lib /tmp/x86root/path/to/binary ( think it's that, I'm typing from memory a bit so the ld-linux.so.2 bit could be wrong.. the library path is correct though - specify both the system and usr lib paths )
It does tend to work.. for the most part... /bin/bash will "work" but it won't fork() so it's utterly useless.
/bin/ls will through up unsupported syscall errors
/usr/lib/wine/wine.bin will just segfault and /usr/lib/wine/wineserver will attempt to do something, but doesn't seem to get much further due to forking as well ( if I remember correctly.. )

 

[javispedro]

I don't even know why they bothered using emulation for 16-bit code.. that was never the point of dosemu. Why try to compete with DOSBox all of a sudden? Should have just dropped support for it on 64-bit Linux.

Well, protected mode stuff is still run natively, without emulation -- Windows, dos4gw, dpmi.... It's only v86 missing.

 

[marovada]

Hopefully you'll get further than my little play about
Best I could get was wine.bin causing segmentation faults, and wineserver attempting to start but failing to do anything much...
I also couldn't chroot directly in, which was annoying as I had set up binfmt... though I was kindof doing this through a Debian chroot, so perhaps that extra level of abstraction was stuffing things up ( going from Angstrom > Debian-Armel > Debian-i386 ) but if you do something like:
qemu-i386 /tmp/x86root/lib/ld-linux.so.2 --library-path=/tmp/x86root/lib:/tmp/x86root/usr/lib /tmp/x86root/path/to/binary ( think it's that, I'm typing from memory a bit so the ld-linux.so.2 bit could be wrong.. the library path is correct though - specify both the system and usr lib paths )
It does tend to work.. for the most part... /bin/bash will "work" but it won't fork() so it's utterly useless.
/bin/ls will through up unsupported syscall errors
/usr/lib/wine/wine.bin will just segfault and /usr/lib/wine/wineserver will attempt to do something, but doesn't seem to get much further due to forking as well ( if I remember correctly.. )

The seg faults were also reported initially in the N900 thread (before Damion got more info from the qemu support forum). Even though ls throws an error, it still works. According to the N900 thread both the seg fault and ls error occur because qemu doesn't support NPTL for x86. I think if you're having trouble with a particular version of wine, maybe try another version (?)

 

[Exophase]

Well, protected mode stuff is still run natively, without emulation -- Windows, dos4gw, dpmi.... It's only v86 missing.

Obviously. I meant they should have dropped support for 16-bit applications, although I guess now that I think about it more it's not like you can really launch 32-bit ones without some 16-bit support. So I guess that's why it's there. But probably not with the purpose of actually playing full on 16-bit software, and hence not at all optimized.

 

[trix]

I wish I had a Pandora or other ARM device (and a bigger brain!) to help test this stuff with.

marovada: When you ran the x86 'ls' successfully, did it spit out the errors that Stuckie mentions?

Damion's post on the QEmu forum suggests he too is having problems with fork(). Maybe if one of you skilled coders hung out (with me!) in the #QEmu channel on freenode, they could help make this craziness work? Or at least get beyond the fork() problem.

I'm still trying to learn, so worst case scenario give me a couple months to learn C (I'm studying it now!) and a couple more to learn a bit of x86 Assembly, and maybe I can meaningfully contribute instead of just cheering you on and trying to play matchmaker.

Anyways good luck and I look forward to updates!

- trix