DOS ain't dead

> I've made a smaller and faster binary using MinGW's GCC 4.3.0 alpha instead
> of GCC 3.4.5:
> qemu-0.10.0-win32-2.7z

Thanks! Is it possible to include the qemu64.exe binary to your package?

---
MS-DOS forever!

Another build is in qemu-0.10.0-win32-3.7z, where I've rebuilt SDL and zlib using GCC 4.3.0 alpha and used "-mms-bitfields -march=i686" flags for all QEMU binaries.

---
Forum admin

> I've made a smaller and faster binary using MinGW's GCC 4.3.0 alpha instead
> of GCC 3.4.5:

How much stable is the mingw gcc 4.3.0? Did you find some problems with compiling other programs? I still use 3.4.5 and it is in mingw for long years so it's time to update?

---
DOS gives me freedom to unlimited HW access.

> Qemu v0.10 has regressions:
>
> Running KEEN 4, it displays this screen:
> Qemu 0.91 doesn't have this problem, the screen is displayed fully.

Can you send me your image and how you run it? quazi@mail.ru

> Qemu 0.91 doesn't have this problem, the screen is displayed fully.

After lots of build sessions I can say, that the problem exists since revision 6349. I'll post that result to the QEMU mailing list.

---
Forum admin

> Interesting But what is TCG ? Maybe TCC ? But remember that latest TCC
> version got released on April the 1st

Apparently, Rob Landley (one-time hacker / forker of TCC) got mad that CVS was used to release the latest version of TCC, so he abandoned (yet again) his fork since he refuses to cater to "outdated CVS (as bad as 8.3 on DOS)". His version claims to support "-run" on x86-64 (unlike official). So TCC is maybe a bit stagnant right now, don't get your hopes up.

> > The QEMU team has released version 0.10.0 on 04 March 2009
>
> No 1.0 after 0.9.xx ?

Why are you confused? 10 comes after 9.

> Interesting But what is TCG ? Maybe TCC ? But remember that latest TCC
> version got released on April the 1st

Using a search engine is not that hard: Tiny Code Generator

---
Forum admin

> I've uploaded "qemu-0.10.0-win32-4.7z", which has been build using GCC
> 4.3.0 alpha w/o any additional CFLAGS.
>
> You also need fmod.dll and SDL.dll, which are available as separate
> downloads from http://www.bttr-software.de/qemu/.
>
> Modifications applied:
> - reverse SDL and VNC window caption
> - add icon and VERSIONINFO resources to EXE file
> - add SDL window icon
> - use wspiapi.h for Windows 2000 compatibility (IPv6)
> - fix VGA issue introduced by r6349

Thanks for the fixed release!

The 0.10.0 release claims to have support for the GUS. Is this support active with your binary? Because the GUS isn't recognized (tried with game Blood). With DosBox, I had no problems to setup Blood with GUS (both sfx and midi).

A minor issue: if one switches away from fullscreen Qemu to another application and then back to Qemu, the screen isn't restored properly. It might be a driver issue, so it just may happen with certain (my!) gfx cards? However, in 0.9.1 it worked ok.

---
MS-DOS forever!

> I've uploaded "qemu-0.10.0-win32-5.7z", which fixes the floppy drive issue
> by simply reverting r6677 changes.

Thanks! However, a true fix is preferable. The error is rather simple: GetFileSize() won't work with "disk" handles (those "\\.\x:" things).

Here's a possible fix to be applied to file block-raw-win32.c:
-----------------------------------------------------------------------

--- block-raw-win32.co  Wed Mar  4 22:54:44 2009
+++ block-raw-win32.c   Sat Mar 21 05:51:34 2009
@@ -32,6 +32,7 @@
 #define FTYPE_FILE 0
 #define FTYPE_CD     1
 #define FTYPE_HARDDISK 2
+#define FTYPE_DISK 3
 
 typedef struct BDRVRawState {
     HANDLE hfile;
@@ -305,6 +306,7 @@
         if (l.LowPart == 0xffffffffUL && GetLastError() != NO_ERROR)
             return -EIO;
         break;
+    case FTYPE_DISK:
     case FTYPE_CD:
         if (!GetDiskFreeSpaceEx(s->drive_path, &available, &total, &total_free))
             return -EIO;
@@ -402,7 +404,7 @@
         if (type == DRIVE_CDROM)
             return FTYPE_CD;
         else
-            return FTYPE_FILE;
+            return FTYPE_DISK;
     } else {
         return FTYPE_FILE;
     }
@@ -411,7 +413,7 @@
 static int hdev_open(BlockDriverState *bs, const char *filename, int flags)
 {
     BDRVRawState *s = bs->opaque;
-    int access_flags, create_flags;
+    int access_flags, create_flags, share_flags;
     DWORD overlapped;
     char device_name[64];
 
@@ -429,6 +431,10 @@
         }
     }
     s->type = find_device_type(bs, filename);
+    if (s->type == FTYPE_DISK)
+        share_flags = FILE_SHARE_READ | FILE_SHARE_WRITE;
+    else
+        share_flags = FILE_SHARE_READ;
 
     if ((flags & BDRV_O_ACCESS) == O_RDWR) {
         access_flags = GENERIC_READ | GENERIC_WRITE;
@@ -447,7 +453,7 @@
     else if (!(flags & BDRV_O_CACHE_WB))
         overlapped |= FILE_FLAG_WRITE_THROUGH;
     s->hfile = CreateFile(filename, access_flags,
-                          FILE_SHARE_READ, NULL,
+                          share_flags, NULL,
                           create_flags, overlapped, NULL);
     if (s->hfile == INVALID_HANDLE_VALUE) {
         int err = GetLastError();

-----------------------------------------------------------------------

---
MS-DOS forever!

> There's another regression in 0.10.0 concerning Ultra-DMA: if JLM
> XDMA32.DLL is loaded, option /B must be used. Same is probably true for
> XCDROM32.DLL as well.

I'll test this later. I was AFK this weekend.

> The speed differences are significant. Some results with IDECHECK , which
> reads HDs with Int 13h (using an 200MB image):

There was a lot of traffic related to I/O or DMA on qemu-devel lately, but as I didn't understand technical details ...

Maybe this has been fixed in yesterday's released version 0.10.1?!

From your previous messages, I understand, that you are able to build your own binaries until I've time to upload mine.

---
Forum admin

> There's another regression in 0.10.0 concerning Ultra-DMA: if JLM
> XDMA32.DLL is loaded, option /B must be used.

Why do you think so? What's the problem w/o "/B"? I didn't experience any problems here (MS-DOS 6.22, just JemmEx 5.72).

> The speed differences are significant. Some results with IDECHECK, which

QEMU's HDD speed nicely scales with CPU performance.

> reads HDs with Int 13h (using an 200MB image):
>
> - no XDMA32.DLL loaded: ~ 25 MB/sec
> - XDMA32.DLL /B ~ 73 MB/sec
> - XDMA32.DLL ~ 130 MB/sec
>
> With Qemu v0.91, XDMA32.DLL without option /B worked - and was even faster
> than with v0.10.0: ~ 195 MB/sec.

Some figures:

version 0.10.0:
vmdk  600 MHz  SmartDrv   10 MB/s
               clean      12.5 MB/s
      1.5 GHz             32.4 MB/s
raw   1.5 GHz             29.4 MB/s
vmdk  600 MHz  XDMA32    113 MB/s
      1.5 GHz            217 MB/s

version 0.9.1:
vmdk  1.5 GHz  XDMA32    409 MB/s

So QEMU 0.10.0 is only half as fast as QEMU 0.9.1.

---
Forum admin

> I've switched back to qemu v0.9.1. The final "drop" was a problem of
> v0.10.0 with LBA access (don't know if it's Qemu or the BIOS), which makes
> DOSLFN largely dysfunctional.

How to reproduce this here?

> I uploaded a binary where the "duplicate keypress" bug has been fixed:
>
> http://www.japheth.de/Download/qemukbdb.zip
>
> Remember: the patched to be applied to the original v0.9.1 sources are in
>
> http://www.japheth.de/Download/qemukbd.zip

Thanks!

---
Forum admin