DosEMU, Ghost: VGA screen garbled...

["Frantisek Rysanek" <Frantisek.Rysanek@post.cz>]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 3498 bytes --]

Dear DOSEMU developers and users,

first of all thanks for keeping this wonderful project alive :-)
I've used it for several minor tasks in the past, I recall how amazed 
I was when I ran Sid Meyer's Civilization under DOSemu...

I've been wondering for some time, if it would be possible to run 
Symantec/Norton Ghost under Linux. 

I've been aware for some time that "wholedisk is not supported". To 
me, this has been a show-stopper - I never even tried Ghost under 
DOSEMU for that reason. Much to my amazement, I've recently found out 
that this is not quite true anymore, if it ever was, and I've managed 
to make "wholedisk" work for me. I can use the fdisk from FreeDOS to 
partition physical hard drives...

I'm attaching a short patch to this message, which adds support for 
disk drives reporting >16k cylinders to the OS. I've noticed that 
DOSEMU internally uses "int" variables for CHS, so I've added some 
ioctl()s to src/base/misc/disks.c to get the LBA size of the disk 
drive and calculate the correct "cylinders" value based on that, if 
the 16bit value obtained via HDIO_GETGEO is clearly bonkers...
And the IBM/MS extensions seem to work just right with that, judging 
by the fact that the FreeDOS FDISK reports my big drives correctly :-
)

So today I've finally tried Ghost under DOSEMU, and yikes: the VGA 
screen is all garbled. Ghost is clearly alive behind the veil of 
ASCII garbage, responds to keyboard - but the user interface is 
unusable, because you can hardly use Ghost blind-folded. The screen 
consists of random non-text characters with random foreground and 
background colours, in 80x25 VGA text mode. As if Ghost was writing 
pixels to the video RAM, but the VGA hardware was really in 80x25 
text mode. And yes, this is the native VGA screen of the machine, not 
a remote SSH session :-)

There was a time when I used to think that Ghost ran in some VGA 
graphics mode, maybe 640x400x16 or some such - judging by the 
"graphics mode" arrow for a mouse cursor. Today I suspect that maybe 
it's just a text mode with a custom font and with the arrow cursor 
implemented by an on-the-fly font swapping hack I've read about the 
other day: the four characters overlapped by the graphical cursor are 
transparently toggled to a few special ASCII codes, whose mapped 
characters in the VGA font table are modified with every movement of 
the mouse, to display an arrow when combined with the 
original/underlying text characters...

Native Ghost under DOS runs just fine on bare metal on the hardware 
that I'm using (Intel 865G).

I've noticed someone else's posts from back in 2004, that he was able 
to run Ghost under DOSEMU and the user interface looked allright.

I've tried fiddling with some graphics configuration options in 
dosemu.conf, but the defaults are clearly all I could hope for / 
liberal enough.
I've tried with $_chipset=svgalib and plainvga, I've tried specifying 
a range of ports for direct access (along with device /dev/null). To 
no avail.
I've also noticed that, on graceful exit, DOSEMU complains about 
UTF/non-UTF mismatch between my terminal and the "Locale" environment 
variables. If I export LC_ALL=en_US.utf-8, the error message on 
shutdown is gone, but Ghost produces garbled screen output just the 
same...
I've nuked the framebuffer drivers out of my kernel .config. No 
improvement there... (this is vanilla Linux 2.6.28.6).

And that's where I ran out of good ideas :-)
Any further hints are welcome...

Frank Rysanek


[-- Attachment #2: Attachment information. --]
[-- Type: text/plain, Size: 467 bytes --]

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  llsize.patch
     Date:  14 Sep 2009, 23:44
     Size:  1471 bytes.
     Type:  Text

[-- Attachment #3: llsize.patch --]
[-- Type: Application/Octet-stream, Size: 1471 bytes --]

--- disks.c.old	2007-05-04 07:59:48.000000000 +0200
+++ disks.c	2009-09-14 12:56:16.000000000 +0200
@@ -373,7 +373,12 @@
 {
 #ifdef __linux__
   struct hd_geometry geo;
-
+  unsigned int sector_size = 512;
+  unsigned long size = 0;
+  unsigned long long llsize = 0;
+  unsigned long long llbytes = 0;
+ 
+  /* No point in trying HDIO_GETGEO_BIG, as that is already deprecated again by now */
   if (ioctl(dp->fdesc, HDIO_GETGEO, &geo) < 0) {
     error("can't get GEO of %s: %s\n", dp->dev_name,
 	  strerror(errno));
@@ -387,6 +392,35 @@
     d_printf("HDISK auto_info disk %s; h=%d, s=%d, t=%d, start=%ld\n",
 	     dp->dev_name, dp->heads, dp->sectors, dp->tracks, dp->start);
   }
+
+#ifdef BLKSSZGET
+  if (ioctl(dp->fdesc, BLKSSZGET, &sector_size) != 0) {
+    error("Hmm... BLKSSZGET failed (not fatal): %s\n", strerror(errno));
+    sector_size = 512;
+  }
+#endif
+
+#ifdef BLKGETSIZE64
+  if (ioctl(dp->fdesc, BLKGETSIZE64, &llbytes) != 0) {
+#endif
+    // BLKGETSIZE is always there
+    if (ioctl(dp->fdesc, BLKGETSIZE, &size) != 0)
+      perror("Error getting capacity using BLKGETSIZE and BLKGETSIZE64. This is fatal :-(\n");
+    else 
+      llsize = size;
+#ifdef BLKGETSIZE64
+  }
+  else
+    llsize = llbytes / sector_size;
+#endif
+
+  if (llsize > (unsigned long long) dp->tracks * dp->heads * dp->sectors)
+  {
+    /* destroys llsize : not needed anymore */
+    llsize /= dp->heads * dp->sectors;
+    dp->tracks = llsize;
+  }
+
 #endif
 }