PC Emulation and Wine...

This is a BIG wish list item but suggested in the hope that it might encourage some creative thinking.

The A3000 era of RISC_OS based systems, had as a paid option a software package that provided an emulation a PC chipset in software. This PC emulator could run Windows3.0 (just)

The RISC PC, included an option for a hardware i486 based card.

My question is thus, what would it take to get older Windows and DOS software running on the current generation of RISC OS based systems?

There are presumably a number of soloutions, some of the disadvantages are outlined.

a) Hardware card, and drivers to interface into the Iyonix architecture Expensive,would still need users to have an official license, Windows can be fussy about running on anything less than a full PC chip-set. Vista even more so.

b) QEMU/Bochs Style virtualisation Code would be Slow compared to running native, no real interfacing between apps on Host and guest OS.

c) Third party port of ReactOS to ARM, and x86 emulation – trapping calls. Hideously complex even for simple apps, potentially slow, in addition ReactOS code hygiene and stability leaves a lot to be desired.

d) WINE +X86 emualtion Unix->RISC OS call translation NOT simple, No support for kernel level operations, potentially slow. call trapping may be complex in respect of the x86->ARM side.

Any thoughts people?

Any thoughts people?

Well, um, why would you want to do this?

To allow some PC apps to work on Iyonix….. Unless someone plans on getting Open Office going natively :(

Hmm, it sounds like a massive job in order to possibly get some old Windows apps running at a crawl.

For those that want virtualisation, surely using Windows + VRPC is the sensible, complete, existing, fast solution?

I haven’t tried it, but there’s already a RISC OS port of Bochs: http://www.riscos.info/unix/indexes/x11_test.html I’d imagine it’s very slow, but even with a JIT I can’t see it being much quicker than a 10 year old PC.

JIT ARM->X86 can be done (Virtual RPC as mentioned), Why not the other direction?

In the initial opening discussion I did give 4 options, one of them being the hardware one (i.e a physical PC type CPU).

There are some packages that for whatever reason are not going to get ported ( in respect of Open Office I think that WILL eventually get ported by somebody given that Firefox was), why should someone with a RISC OS machine pay out for a PC as well (granted they are ridiculously cheap sometimes…)

JIT ARM->X86 can be done (Virtual RPC as mentioned)

A modern x86 CPU is about 80 times as fast as the 200MHz StrongARM it emulates. Most of the other components of a PC are a lot more advanced and complex than the RiscPC’s hardware, too. Even the most modern RISC OS hardware does not stand a chance at emulating even a seven year old PC at full speed. However software like OpenOffice.org barely crawls along on such old PCs.

Why not the other direction?

Well, of course it can be done. It will not be of much use, however.

In the initial opening discussion I did give 4 options, one of them being the hardware one (i.e a physical PC type CPU).

Now that is a much more realistic option. You can get relatively cheap PCI cards with almost complete PCs on them. But then someone would have to write the software to interface such a card with RISC OS. To me this seems like a very expensive way to get windows software running on a RISC OS machine. I think it would be much cheaper, as well as probably more compatible and performant, to simply get a cheap PC and a KVM.

I think a big hurdle to emulating x86 on ARM is that most RISC OS, ARM-based platforms don’t have hardware floating point. PC software tends to make heavy use of FP because x86 CPUs do tend to provide that in hardware. Thus, emulating x86 code on ARM ends up being much harder (read: slower) than the reverse. There are other similar factors with lead to the same conclusion.

All good comments people. So a slow QEMU it is then?

I think a software PC emulator might make just as much sence as a C64 emulator: People could use it to play old DOS games.

So are you asking ROOL to share the source to Acorn’s PC Emulator? (What’s the status on that, BTW?) Which will play DOS games already – someone could bolt on 386 extensions, SVGA emulation and all the other things it’s missing. Some might already be available as part of Aleph One’s PC card sources if the licences can be made compatible.

Does Castle/ROOL have access to the hardware documentation for things like the Gemini coprocessors?

I wasn’t, This was a wish list item for something to possibly replace the PC Emulator which is now based on an PC architecture that was aging even when it was produced.

Sharing the PC Emulator sources might also not be possible, as IIRC this was NOT strictly speaking an Acorn product made in-house, possibly one that was bought in..

Bochs and QEMU are possibilities though, assuming license compatibiliies can be resolved.

In terms of running games DosBox has already been ported to RISC OS?

In terms of running ancient applications a 32bit neutral PC emulator would be desired by some, but I suspect not entirely practical given that it still wouldn’t run Windows apps…(ARM Linux and WINE?)

To the best of my knowledge, Acorn either never had or didn’t retain the sources to the PC Emulator.

Also, rumour has it that it is one of the few applications that only ever used the APCS-A calling standard, so it won’t work with the 32-bit compatible C library (which withdrew support for APCS-A), even on a 26-bit machine. I can’t say I’ve heard many people complaining.

...there is a lot of issues into PC emulation nowadays…

1) The Risc OS PC Card project was based on a capability of ARM processors of to “use” a “slave” 2nd processor to execute “unknow” istructions (and by the way the PC Card reach the AMD 586 not just the i486 processors). We where not able to have Pentium based PC CARDS because the Pentium bus was enormously extended compared to what a RISC PC may be able to manage.

2) PC Emulator was a nice, but small, intel 80186 processor emulator (at not more then 12 Mhz), nowadays intel processors supports 3 Ghz clock, MMX, SIMD, 64bits system bus and more extensions that would be very hard to implement in a software emulation for ARM processors (and if you are interessed into play games, games use a lot of those extensions). (N.B. yes Iyonix ARM use SIMD too, i know but it is missing many other extensions).

3) Wine project is a system calls remapping project that first need a INTEL PROCESSOR, second need a system that is able to support most of the windows system calls… wont be a good idea (specially about prestational level)

What i suggest is to work on Iyonix PCI PC Cards (there is a lot of them already available on the market) it would be a simple way ‘cause the PCI PC CARD need a driver to be managed from the host OS, have indipendent RAM, clock sync and can use Host devices if allowed by the Host OS, this may run windows or linux with an RISC OS/ARM based application that remaps calls to obtain the effect of WinRisc project that is of to run PC apps in RISC OS GUI, with no speed limits.

Why i suggest that?

1) Because is a cheap way

2) Because it have market

3) It is easy to do

4) Have no future limitatins

5) May run good guest OS like BSD or Linux

6) This work could be reused to build drivers for Floatting point PCI cards very usefull in scentific, engineering, networking applications.