Win95 on real Raspi


281 posts   Page 1 of 12   1, 2, 3, 4, 5 ... 12
by Dietmar » Sun Jul 08, 2012 5:41 pm
Hi all,
after long work I got it,
Win95b ^^ on a real Raspberry Pi via Qemu 1.101,
greetings Dietmar

Image
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by reiuyi » Mon Jul 09, 2012 2:03 pm
Is it responsive?

Emulating x86 on ARM cannot be very efficient. What kind of percentages are you looking at this way (if you know)?

Very amazing software project you have there, nonetheless. Gates would be proud
User avatar
Posts: 165
Joined: Sun Oct 09, 2011 4:59 pm
by Dietmar » Mon Jul 09, 2012 2:50 pm
Hi reiuyi,
I played famous Moorhuhn on Win95b on Raspi,
it is playable. When velocity could be powered up by a factor 2, it would be nice.
Via qemu I noticed, that both squezze and whezzy versions from debian do not run very stable on the Raspberry Pi. For example, sometimes you see all the symbols on desktop, sometimes not.
I do not know, from whjat this comes. I changed my power device, I also use USB hub or without, always the same. I changed my SD-card, no effekt. And another crazy thing happens in the new Debian version whezzy: A USB harddisk is recogniced, can be mounted but you do not have full control to it, means copy and paste, brrr. Not important, if the USB harddisk is connected direct to Raspi or via extra powered USB-Hub. So, there is a lot of work to be done. In MS-Dos via Qemu, Raspi is really quick. But most old games need at least an Win95 environment,
greetings Dietmar

Image

PS: I will try all other systems, that are on the market today for Raspi. I like Debian, but until now debian does not work good on Raspi..
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by reiuyi » Mon Jul 09, 2012 3:14 pm
Debian and other raspberry pi-oriented operating systems are currently in a developmental phase. Support for raspberry pi will very likely increase as more and more people receive their model B and experiment with it. Much work has already been done to increase the user experience, and it'll get even better in the near future.

Are you maxing out the raspi CPU when you emulate an 486? Does Qemu let you put the maximum "speed" of the emulated cpu?

There are 2 testing points on the raspberry. They're labelled "TP1" and "TP2" on the silkscreen. If you put your multimeter on tp1 and tp2, it'll read out the voltage of the 5v rail. If it's far below 5v (like 4.2), your raspberry is likely acting weird due to power loss. There are actually surprisingly few plugs that can power the raspi at a proper 5v. I have one plug here that actually drops to as little as 4.0v (!), though surprisingly the device actually works (albeit very unstable and unpredictable)
User avatar
Posts: 165
Joined: Sun Oct 09, 2011 4:59 pm
by Dietmar » Mon Jul 09, 2012 3:44 pm
Hi reiuyi,
the emulation via -cpu 486 was the only way to make Qemu work on Raspi.
I played a lot with Qemu, so I know its crazy behavior:-).
The bootime of full Win95b is now about 1 min:-) on real Raspi, via Qemu.
But it does not always come to desktop. This belongs to the not stable underlying Debian Whezzy.
I know this, because this Win95.img runs stable as much as possible in other cases.
When it comes to Desktop, you can play. This is really a nice project. If there are some switches in Qemu or can be switched on in raspberry (for example V.. for floatingpoint processor in Raspi, which is now switchted off), this will be a nice base for games,
greetings Dietmar
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Mon Jul 09, 2012 5:02 pm
Hi,
my voltage between TP1 and TP2 is 4.813 Volt during boot,
4.852 Volt during doing nothing (just Desktop)
and 5.006 Volt if Raspi is off.
This looks not very stabilized^^,
greetings Dietmar

PS: The power device should can 2.5 Ampere at 5 Volt.
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by AndrewS » Thu Jul 12, 2012 11:53 am
A few various points:

According to http://elinux.org/RPi_Hardware#How_Can_ ... dequate.3F anything above 4.75V is fine.

I suspect the instability is with Qemu rather than with Debian Wheezy - if it was the OS that was unstable you'd get crashes etc. but things not working properly inside Qemu will be the fault of Qemu - like most software it'll have been primarily developed on/for x86, so running it on ARM may show up a few quirks. Are you running a precompiled version of Qemu, or are you compiling the latest version yourself from source?

I'm surprised with how quick Win95 boots - some Youtube videos would be great :)
WinXP loads much slower viewtopic.php?f=62&t=6014

If you want maximum performance, you'll want to try using Raspbian - this is specially optimised to make maximum use of the RPi's FPU hardware.

If you want to copy and paste on a USB harddrive, you'll need to play with the mount options so that the drive is writable by a normal user, not just by the root user. An alternative (but not recommended) approach would be to run the file-manager as root.
User avatar
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by asb » Thu Jul 12, 2012 12:22 pm
QEMU on ARM is interesting. QEMU on an ARM host was broken for a good while, I think the squeeze armel version is old enough to have missed that. The QEMU 1.1 in wheezy offers support for ARM host again, but of course bugs are very possible.
Forum Moderator
Forum Moderator
Posts: 851
Joined: Fri Sep 16, 2011 7:16 pm
by ukscone » Thu Jul 12, 2012 12:52 pm
asb wrote:QEMU on ARM is interesting. QEMU on an ARM host was broken for a good while, I think the squeeze armel version is old enough to have missed that. The QEMU 1.1 in wheezy offers support for ARM host again, but of course bugs are very possible.


i built the linaro qemu a few days ago on wheezy. x86-64 won't build but all the other processors build & work as long as don't have a life & have a predeliction for watching paint dry
User avatar
Forum Moderator
Forum Moderator
Posts: 3697
Joined: Fri Jul 29, 2011 2:51 pm
by ghans » Thu Jul 12, 2012 3:43 pm
Dietmar ,
how did you set that up ?
I'd be interested in any special instructions you followed !

ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org
Posts: 6794
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany
by Dietmar » Sat Jul 14, 2012 1:11 am
Yeeah, this is Win95b in
Dosbox on real Raspi, with the new Rasbian Image with hardware float enabled VFP:-).
Its fast^^,
Dietmar

Image
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Sat Jul 14, 2012 10:38 am
Hi all,

I succeed to get a STABLE, fast Win95b on real Raspberry Pi:-).

I installed the new Raspbian Image from
http://www.linuxsystems.it/2012/06/rasp ... mal-image/
with VFP enabled. I enlarged this image to 16GB on a Sandisk cat 10. Then I run apt update and apt upgrade.
There I installed xorg, lxde-core, leafpad and some more to get a small, fast, workable Debian.

I noticed, that all newer Qemu Versions from >= 1.0 do not work good for ARM.
I remembered my work from September. So I downloaded
qemu 15.50 from http://thoronir.net/raspi-dev/qemu-git.tar.bz2

and did not git pull --rebase on this.

1.) apt-get install git zlib1g-dev libsdl1.s-dev
2.) mkdir raspidev
3.) cd raspidev
4.) In this raspidev folder I copied the Qemu from Thoronir qemu-git.tar.bz2
5.) cd qemu
6.) ./configure --target-list="i386-softmmu" --enable-sdl --prefix=/usr
7.)make

Then comes after some time an errormessage about tcg.

I repaired this error in the file
qemu/tcg/arm/tcg-target.c

I changed in this file with editor leafpad

static void tcg_out_addi(TCGContext *s, int reg, tcg_target_long val)

against

static inline void tcg_out_addi(TCGContext *s, int reg, tcg_target_long val)


The same error in qemu\tcg\i386\tcg-target.c
stops the compiler. So, if you want to have Win95 on Raspi,
it is impossible until you do the same fix as above.

After this, go back to folder qemu and type again

8)make (the error is gone and the compiler just continues)
9.)make install
10.)qemu win95.img -m 64

Thats all, good luck
Dietmar

PS: Do not give up, it works. I play just Moorhuhn an real Raspi, boottime for win95 is about 1 min,
no overclocking at all:-).


EDIT: All Windows games work fast and stable: Minesweeper, Solitair..

Now I have a compi, that my pupils will like^^
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Sat Jul 14, 2012 11:54 am
There is an error in 1.)

1.) apt-get install git zlib1g-dev libsdl1.s-dev

has to be

1.) apt-get install git zlib1g-dev libsdl1.2-dev
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Sat Jul 14, 2012 11:56 am
Yeaah,

Win98SE works also on real Raspberry Pi:-)

Boottime is about 2 min^^

Greetings Dietmar
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Sat Jul 14, 2012 12:46 pm
Image


^^
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Sat Jul 14, 2012 1:59 pm
And Voila,
there it is,
full XP on real Raspberry Pi.
Little bit slow, boottime to desktop for XPSP1 is 12 min^^,
but stable:-)
Dietmar

Image
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Joe Schmoe » Sat Jul 14, 2012 2:30 pm
Dietmar wrote:And Voila,
there it is,
full XP on real Raspberry Pi.
Little bit slow, boottime to desktop for XPSP1 is 12 min^^,
but stable:-)
Dietmar

Image


The next thing for you to do would then be to run QEMU under Windows (on the Pi) (see below for thread title) to produce an emulated Pi.

And then finally, I suppose for those of us who don't yet have a Pi to test this on, we ought to be able to package up and run your whole kit and kaboodle under Windows - following the instructions in (inter alia) "Emulating the Pi under Windows, the easy way".
And some folks need to stop being fanboys and see the forest behind the trees.

(One of the best lines I've seen on this board lately)
Posts: 4277
Joined: Sun Jan 15, 2012 1:11 pm
by reiuyi » Sat Jul 14, 2012 2:32 pm
With 12 minutes boot time, you are significantly faster than the other person (who reported several hours of boot time :P )

Do you think you can emulate raspberry pi inside windows xp inside qemu on a raspberry pi? (inception)

I remember I once did this with virtual servers (an old citrix metaframe presentation server). It would actually go until level 7 before it crashed and the connection timed-out. So there was window 2000 in windows 2000 in windows 2000... you get the idea, 7 times :D

Another question.. does the virtual LAN interface work? Can you get internet inside qemu?
User avatar
Posts: 165
Joined: Sun Oct 09, 2011 4:59 pm
by Dietmar » Sat Jul 14, 2012 8:03 pm
Hi,
I loaded small Video up^^,
Dietmar

http://www.youtube.com/watch?v=5aYG13uYj1A
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Sun Jul 15, 2012 4:15 pm
Settlers 2, but still no sound:-).

Image
Last edited by Dietmar on Sun Jul 15, 2012 4:30 pm, edited 1 time in total.
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Sun Jul 15, 2012 4:29 pm
Hi reiuyi,

"Was Qemu compiled for floating point hardware?"

I do not know a switch in Qemu to achieve that.
I know, that Qemu knows about VFP.
So, the video and the games are on Raspian with VFP enabled,
very small build, but I think after and in Qemu there is no VFP.
Any idea?
Dietmar
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Sun Jul 15, 2012 4:50 pm
First I thought,
I can control this with
$ cat /proc/cpuinfo
Processor : ARMv6-compatible processor rev 3 (v6l)
BogoMIPS : 331.77
Features : swp half thumb fastmult vfp edsp java

This VFP cannot be seen, when the underlying kernel (and/or Processor) does not support VFP.
But this belongs not to Qemu, because when you ask cat /proc/cpuinfo,
you get only an answer of the last Kernel in the row after Qemu and not what is going on before,
Dietmar
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Sun Jul 15, 2012 5:25 pm
I found vfp in Qemu code
only in target-arm,
not in target-i386. This makes sense, because an I386 processor has no idea about vfp:-).

So in my thinking, Qemu makes always use of vfp,
when it is offered.

machinecode>>qemu>>other machinecode (with vfp) for ARM
So, Qemu MAKES only vfp, but takes no use of.
Am I right?

Dietmar

PS: What is really going on you can only see, when you enable, disable vfp on both sites of Qemu with Arm, I386 mixed. So, because I have realy Raspi Arm on left side with vfp enabled, the left side with Raspbian is fast, but then comes Qemu, making code for I386 (Win95) without vfp.
So, from Arm to I386 vfp is useless on right side, but not on left:-). So, this Qemu is not fast.
But vice versa, when you have I386 hardware, then Qemu, that makes vfp and then ARM processor with vfp enabled, this "Quemu" is fast I think.
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Sun Jul 15, 2012 9:03 pm
Hi,
I bootet the same xpp.img file now via Raspi
to Desktop as in video XP on Arm.
All together is real Raspi with VFP enabled by a factor 3.25 faster than in emulation.
This is not very much. In Video it lasts 6:30 min and on real Raspi 2:00 min.
For a compare:
On my Desktop compi Intel Core i7 920 2.67GHZ,
the same xpp.img needs in Emulation with Qemu
11sec:-):-), xpp.img booting from the same Sandisk Cat 10 card.
I am not sure,
may be the ODROID-X (price is 4 times and Ram is 4 times and velocity is about 7 times there)
is the better choice for pupils,
Dietmar
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
by Dietmar » Tue Jul 17, 2012 1:00 pm
24.45 Bogomips
for full XPSP1 running via Qemu on Raspbian with VFP enabled.
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm