Qemu entering the 1.2 rc phase!

I just got word that Qemu is now aggressivly entering the 1.2 release phase.  Of interest to people who like old OS’s, namely Windows NT 3.1 this is going to be in the release:

  • Three new SCSI host bus adapter devices are available: am53c974 and dc390 emulate respectively an AMD PCI PCscsi and a Tekram DC-390 device, both of which are supported on older operating systems including MS DOS 6.2, MS Windows 3.11, 98 SE, NT 3.1 and NT 4.0. megasasemulated an LSI SAS1078 RAID controller. The next version of SeaBIOS will support booting from am53c974 and dc390 disks.

That’s right!  With the Tekram DC-390 you will be able to install Windows NT 3.1 with only a install floppy & CD-ROM.  I also hope this includes stability fixes for Novell Netware..

I’ve naturally added in my sdl update for a quick control-alt-delete & reset


case 0x13: /*r on US keyboard */
qemu_system_reset_request();
break;
case 0x20: /* 'd' key on US keyboard */
kbd_put_keycode(0x1d); /* left ctrl key */
kbd_put_keycode(0x38); /* left alt key */
kbd_put_keycode(0xd3); /* delete key */
kbd_put_keycode(56);
kbd_put_keycode(29);
kbd_put_keycode(157);
kbd_put_keycode(184);
kbd_put_keycode(29);
kbd_put_keycode(56);
kbd_put_keycode(224);
kbd_put_keycode(83);
kbd_put_keycode(224);
kbd_put_keycode(211);
break;

And to configure it with the parameters…

$ ./configure --audio-drv-list=dsound,sdl,fmod --audio-card-list=ac97,es1370,sb16,adlib,hda,gus --disable-curl --fmod-lib=/mingw/fmod/libfmod.a --fmod-inc=/mingw/fmod

I’m not too thrilled on the audio aspect, while I’ve managed to compile in Direct Sound & Fmod, fmod doesn’t produce any sound, and Direct Sound is very laggy.  Another thing I don’t “get” is that inside of mingw SDL displays Qemu with a normal aspect ratio and runs fine, but copying the same binaries  & DLLs out of Mingw gives me that weird and slow display.. So I’ve removed the full screen capability (did anyone use it? it never worked right anyways…) as I had done before, and it seems ok.

I haven’t gotten around to looking at the new SCSI adapters or how to configure them, but I hope to do that real soon! It will be cool for sure!

Doom on Qemu 1.2.0 rc1

Doom on Qemu 1.2.0 rc1

That said it is a *LOT* faster than 1.1.1 or 1.1.0 !

As always, my binary is here.

Windows NT 4.0 MIPS on Qemu 1.1.1 (OS X)

I’ve got to find a way to build Qemu for Win64, it looks like the only way for it to produce anything other than trivial hello world applications is to cross compile on linux.. which no doubt will need a billion dependencies…

But in the interim the MIPS emulator in Qemu 1.1.1 has made a bunch of progress and can install & run NT 4.0 without any issues!

There are a few things to look out for, the first is that you have to specify a NVRAM image file to keep it persistant across instances. And you need to ‘expand’ it beyond the definition size to get things like the MAC address to be stored.

./qemu-system-mips64el  -L . -M magnum -hda MIPS.disk -net nic -net user  -global ds1225y.filename=nvram  -global ds1225y.size=8200

And by default the Qemu MAC address to configure within the Magnum BIOS is 525400123456 ..

Windows NT 4.0 MIPS on Qemu 1.1.1 on OS X

I’ve been able to download & install Internet Explorer 3, and Quake World.. And even connect up to quake.xs4all.nl and it worked!

One thing I’d advise is to copy the directory OS\WINNT40 on the system partition to OS\NT to make it that much easier to re-add the boot statement, if you have to go down that road.

ARC boot statement

As always, special thanks to Herve Poussineau for making all of this possible.

I’ve removed the fullscreen/resizing on Qemu 1.1.1

And now it is *MUCH* faster…

Next I’ll have to investigate better audio libraries, as winwave seems to leave a lot to be desired.

Basically the changes in ui/sdl.c were:


case 0x21: /* 'f' key on US keyboard */
// toggle_full_screen(ds);
// gui_keysym = 1;
break;
case 0x16: /* 'u' key on US keyboard */
// if (scaling_active) {
// scaling_active = 0;
// sdl_resize(ds);
vga_hw_invalidate();
vga_hw_update();
// }
// gui_keysym = 1;
break;

And


case SDL_VIDEORESIZE:
// sdl_scale(ds, ev->resize.w, ev->resize.h);
vga_hw_invalidate();
vga_hw_update();
break;

So now it keeps the correct video display size, so it isn’t going like crazy trying to scale the screen 30 times a second..

Doom now looks normal!

As you can see stuff like Doom now looks normal.  As mode changes are initiated by the video card, it keeps the scale to where it was in prior versions.  At least its not going 1:1 native as looking at a 320×200 window on a 1280×768 desk would be a tad hard..

And yes, even things like Windows 3.0 look correct when the screen changes resolution:

Windows 3.0 in 386 enhanced mode

Also I should add that if you are going to try to use disk images that are *NOT* 1.44 MB they will not work.  You’ll have add this flag to Qemu:

-global isa-fdc.check_media_rate=off

I’ve been told the new handling of disks is better in this version so I’ve left this setting where it was..

I have just updated the download link, but for those who missed it, you can download the i386  win32 version here.

Building Qemu 1.1.1-1 for Win32

I still can’t see how to build this for win64 … 🙁

The first major stumbling block on Win32 is glib, and again going back to the MinGW wiki there is a good laundry list of how to bootstrap Glib on MinGW.

Things you’ll need:

Be sure to run ming-get install for the following:

  • gcc
  • g++
  • libiconv
  • zlib
  • libz
  • gettext
  • msys
  • msys-perl
  • msys-m4

Install Python.. Nothing to fancy from what I gather Qemu still requires you have a level 2 Python, not 3 …

Build libffi

This should be the usual dance of configure & make / make install…  But sure to at least run configure like this:

./configure –prefix=/mingw

Build Glib without pkg-config

Be sure to add Python to your path..

PATH=/c/Python27:/c/Python27/DLLs:$PATH
export PATH

Glib is packed with something called ‘xz’ so hopefully you have xzcat .. Otherwise add it!

export LIBFFI_CFLAGS=’-I /mingw/lib/libffi-3.0.9/include’
export LIBFFI_LIBS=-lffi
export lt_cv_deplibs_check_method=”pass_all”
export CFLAGS=”-O0 -g -pipe -Wall -march=i486 -mms-bitfields -mthreads”
export CPPFLAGS=”-DG_ATOMIC_OP_USE_GCC_BUILTINS=1”
export LDFLAGS=”-Wl,–enable-auto-image-base”
configure –prefix=/mingw –with-pcre=internal –disable-static –disable-gtk-doc –enable-silent-rules

* You may have some weird issue where when running configure it tells you it cannot create executables, or you get a bunch of weird errors trying to paste in the CFLAGS line.. For me the MinGW prompt was stripping the quotes and the leading – to the -O0 (disable optimization) bit.  I don’t know what on earth its issue was, but I had to type that line in manually.

Then do the make/make install dance. This will take a WHILE. At least with -pipe it’ll run each stage of GCC on multiple processors… But yeah.. This is intense to build.  Good thing we get to do it twice.

I also ran into some weird error in the GIO directory where it couldn’t find my Python, and was looking for python2.5 .. So I copied python.exe to python2.5.exe …

PYTHON = /usr/bin/env python2.5

pkg-config

Naturally pkg-config depends on Glib2, and pkg-config to build… Which of course is a circular problem, much like Glib2 requires pkg-config to build.   So to configure it, it goes something like this now that we’ve built a Glib2 ..

export GLIB_CFLAGS=”-I/mingw/include/glib-2.0 -I/mingw/lib/glib-2.0/include”
export GLIB_LIBS=”-lglib-2.0″
configure –prefix=/mingw

At the same time I can’t help but wonder if this version of pkg-config can use it’s own Glib with the following config:

configure –prefix=/mingw –with-internal-glib

Anyways with any luck we can now build & install pkg-config.  This only takes a few seconds..

Glib2 (again)

From this point you should open a new MinGW prompt window, as you don’t want the old CFLAGS screwing things up.  Re-eport the Python path/dll vars and now we can get on to building glib2 (again!) …

configure –prefix=/mingw;make;make install

 

SDL

This should be somewhat straightforward …

configure –prefix=/mingw;make;make install

In the old days we built zlib, but now we can just quickly add in the package (as we did way above) so we should.. now be ready for the main event!

 

And now we can finally build Qemu 1.1.1-1!!!

Now there is a few things I like to tweak, the first is in the configure script, I like to add in AdLib support.  Look for the line

audio_card_list=”ac97 es1370 sb16 hda”

and add adlib into the list

audio_card_list=”ac97 es1370 sb16 hda adlib”

Next I like to modify hw/pc.c and alter the ISA NE2000, as Qemu doesn’t like to share IRQ 9 with the card, so it is just easier to remove the 0x300/IRQ 9 definition.

static const int ne2000_io[NE2000_NB_MAX] = { 0x300, 0x320, 0x340, 0x360,
0x280, 0x380 };
static const int ne2000_irq[NE2000_NB_MAX] = { 9, 10, 11, 3, 4, 5 };

to this:

static const int ne2000_io[NE2000_NB_MAX] = { 0x320, 0x340, 0x360,
0x280, 0x380 };
static const int ne2000_irq[NE2000_NB_MAX] = { 10, 11, 3, 4, 5 };

The next tweak deals with the ability to use older qcow2 disk images… I guess converting them to RAW with an older version of Qemu, then using the new version of Qemu to convert them back into qcow2’s may be a “good ideaâ„¢” but for now modifying the source is a quicker fix.

Comment out the “return -EINVAL;”  in block/qcow2.c

if (ext.len > end_offset – offset) {
error_report(“Header extension too large”);
//return -EINVAL;
}

Now one fun thing I’ve noticed is that building with the default O2 flags Qemu will crash out the moment you access a hard disk image.  It appears that coroutine-win32 is at issue (again?).  So the “easy” way I address it is to first build qemu as normal, and verify that if you attach a hard disk image (any kind) and try to access it, partition it etc, it should crash.  Next remove the file coroutine-win32.o , and edit the file config-host.mak and change the CFLAGS that specify

CFLAGS=-O2 -g

to

CFLAGS=-O1 -g

Now run make again, and it *should* just rebuild coroutine-win32.o with the lesser optimization flags, and relink all the exe’s.  If I’ve done this right, you should now have a working Qemu.

You can go ahead and strip the binaries if you so please, but that should be it.

PHEW.  For anyone who wants my build, but doesn’t want to go through this ‘exciting’ process, you can find the Win32 i386 build here.

Weird scaling in action .. Control+ALT+u kind of undoes it, but it just doesn’t look right and it is far too slow.

In preliminary testing I’ve found this version to be MUCH slower than 0.15.1 .. I think it has something to do with it wanting to scale the SDL window.  Also I’ve had issues with various network cards not initializing with the BIOS that ships with this version of Qemu so I’ve included the bios directory from 0.15.1 .  And lastly yes the disk images… I’ve had major issues with my qcow2 disks, and disk corruption with this build.  I’ve gone ahead and  included the qemu-img tool from 0.15.1 so you can convert qcow2 to raw, then use the 1.1.1 tool to take them from raw back into qcow2 … But I’d probably only do it as a test.

You may want to kick the tires on this version but 0.15.1 really blows this one away…

Qemu on OS X …

So after the whole mountain lion thing I got the latest Xcode..

$ gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/src/configure –disable-checking –enable-werror –prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 –mandir=/share/man –enable-languages=c,objc,c++,obj-c++ –program-prefix=llvm- –program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ –with-slibdir=/usr/lib –build=i686-apple-darwin11 –enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/dst-llvmCore/Developer/usr/local –program-prefix=i686-apple-darwin11- –host=x86_64-apple-darwin11 –target=i686-apple-darwin11 –with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

And it ‘compiles’ a Qemu but it just hangs… LLVM really broke Qemu … So in the interim if you want Qemu on OS X keep a copy of Snow Leopard handy!

Of course I tried using Snow Leopards gcc on Mountain Lion, but it won’t compile any of the Cocoa stuff.

Go figure.

Quick update on Qemu 1.1.0-1

It seems that I’m not the only person getting this error with existing qcow2 images:

Header extension too large

The good news, is that if you have any way to build your own Qemu its a trivial thing to uh “fix”.  Now I haven’t done that much in the way of testing, maybe there is something fundamentally wrong with Qcows created from older versions of Qemu but the error comes from HERE.

You could just comment out the “return -EINVAL;” and Qemu will continue on its merry little way.

Now I’ve tried converting my qcow2’s to other formats with 0.14 but they all have slight errors that wind up preventing OS/2 from booting (I know that 99% of the would wouldn’t care..).

I’m not sure what to make of it, but it looks like to me, that if you really really want this version its best to remove that check so you can keep your old disk images.. try converting them, but.. they may not work `exactly` right.. TEST…!!!

Good news on the QEMU fronts!

First I found this blog post about building Qemu with CLANG instead of GCC, and I didn’t  even run it through google translate, but I had a feeling that it must work because there is simply too much text there for something that doesn’t work… Although it is with the TCG interpreter…

Qemu 1.1.0-1 on OS X 10.6.8 via clang!

And sure enough it works! (well so far I’ve only booted the IBM PS/1 MS-DOS 4.00 image I had handy. But that is good news for me as I’m planning on shifting away from running Windows all the time, and it was annoying having this powerful mac pro, but not being able to run / play with Qemu.

The move the clang would make sense as I under stand it Apple is moving away from GCC at any rate.

Also on the road to a non TGC build of Qemu I did find out the compiler included on the 10.6.3 DVD works while the later IOS update one does not…

Using built-in specs.
Target: i686-apple-darwin10
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/src/configure –disable-checking –enable-werror –prefix=/Developer/usr/llvm-gcc-4.2 –mandir=/share/man –enable-languages=c,objc,c++,obj-c++ –program-prefix=llvm- –program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ –with-slibdir=/usr/lib –build=i686-apple-darwin10 –enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/dst-llvmCore/Developer/usr/local –program-prefix=i686-apple-darwin10- –host=x86_64-apple-darwin10 –target=i686-apple-darwin10 –with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

GCC for update for IOS 5 … which doesn’t build a working Qemu exe

Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646~6/src/configure –disable-checking –enable-werror –prefix=/usr –mandir=/share/man –enable-languages=c,objc,c++,obj-c++ –program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ –with-slibdir=/usr/lib –build=i686-apple-darwin10 –with-gxx-include-dir=/include/c++/4.2.1 –program-prefix=i686-apple-darwin10- –host=x86_64-apple-darwin10 –target=i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646)

While the one that does come on the 10.6.3 DVD works fine.

Next up for all those of you on Windows or Win32 i386 platforms, rainbow has kindly provided a Win32 build of Qemu, which you can download from his site!  Ive booted MS-DOS on it from within VirtualBOX and it seems to work fine!

One thing I’ve noticed about 1.1.0 is that it cannot read low density 3 1/2″ disks!!!!

Qemu enters the 1.1 release candidate stage…

Of the interesting changes this one caught my eye:

64-bit Windows hosts are now supported.

I’ll have to see about how easy/hard it’ll be to load up a 64bit toolchain and build from there…

Anyways nothing to show for it just yet, but if I get it building I’ll be doing 64bit Qemu builds going forward, the 32bit stuff was fun back in the day, but who isn’t using a 64bit CPU in this day & age?