DosEMU, Ghost: VGA screen garbled...

DosEMU, Ghost: VGA screen garbled...

[Frantisek Rysanek]

[-- 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
 }
 

Re: DosEMU, Ghost: VGA screen garbled...

[Frantisek Hanzlik]

Frantisek Rysanek wrote:
> 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
-- 
I probably not help You, but I just quickly tried run ghost (v7.5,
in DOSEMU devel svn1954 on Fedora11/i686 non-emulated mode).
When run in console, screen was garbled as You wrote. Under root,
"dosemu -s" switch screen to some mode unsupported by my monitor,
screen was black and I wasn't able switch to other virtual console
or X, I must reboot via remote SSH.
But, when I run ghost in xdosemu (from X terminal), all appears OK, mouse
was working too.

Franta Hanzlik

Re: DosEMU, Ghost: VGA screen garbled...

[Frantisek Rysanek]

On 15 Sep 2009 at 8:46, Frantisek Hanzlik wrote:
> I probably not help You, but I just quickly tried run ghost (v7.5,
> in DOSEMU devel svn1954 on Fedora11/i686 non-emulated mode).
> When run in console, screen was garbled as You wrote. Under root,
> "dosemu -s" switch screen to some mode unsupported by my monitor,
> screen was black and I wasn't able switch to other virtual console
> or X, I must reboot via remote SSH.
> But, when I run ghost in xdosemu (from X terminal), all appears OK, mouse
> was working too.
> 
Thanks for your information :-)

I tend to think that the "-s" switch merely calls "sudo" to get admin 
privileges => there's no point to using -s when dosemu is already run 
by the root.

As for "it works in X but not in console", my explanation is that 
under XWindows, the dosemu VGA graphics runs entirely in an emulator, 
whereas at the text-mode console, dosemu tries to access the graphics 
hardware directly, which fails for some reason...

Maintaining X in a diskless "boot anywhere" setup is not an option 
for me. Effectively it defies the purpose of my Linux+DOSEMU 
adventure, an important part of which is seamless simplicity :-)

The one point I forgot to mention is that I've tried dosemu 1.4.0.0-
release and yesterday's latest from SVN and both behave the same.
I compile them for i486-pc-linux-gnu for maximum compatibility.

Frank Rysanek

Re: DosEMU, Ghost: VGA screen garbled...

[Richard]

Hi,

I was recently successful in running Ghost with DosEMU. I know what you 
mean by garbled, you can see there is some structure to the "random" 
ascii characters but no options seem to make a difference.

Fortunately, there is a working combination of options. DosEMU has 
changed since I last used it, it used to run Ghost with a different set 
of options. The set that works with my 32 bit Debian Etch is version 
1.4.0.0, using these (mostly important) options:
Run DosEMU as:
dosemu.bin -V -s -d
with these extra options:
$_rdtsc = (on)   # helps stability
$_hdimage = "drives/* /dev/sda"
$_video = "vga"   # should already be the default
$_pktdriver = (off) # might not be necessary
$_chipset = "plainvga" (or "vesa" on some hardware)

I'm still working on the options. Using a much older dosemu (possibly 
1.2), I'd found a set of options where Ghost was 100% stable without 
config changes on all machines I tested. With DosEMU 1.4, Ghost mostly 
works, but the graphics sometimes stop updating. It is still working, 
you just can't see it. Also, on one motherboard with onboard graphics, 
"plainvga" doesn't work, it needs "vesa".

The screen is a real graphics mode. Using the mtd driver to access the 
gfx ram, I was able to find the graphics and decode it, it is 640x480, 
16 colours, bit plane encoded, with 4 planes. An approximation of the 
screen is available at 0xA0000 (or there abouts), I think this was bit 
plane encoded as well, but not in exactly the same way.

Notice I turn off the packet driver. C: contains Ghost and an 
autoexec.bat to NFS mount the remote backup drive onto a drive letter. 
For performance you must use the async option, which is ignored on the 
client side and must be set on the server side in /etc/exports

For full automation, Ghost can be given options on the command line. But 
the "Mark drives as Ghost" has no option to skip. You can use the uinput 
kernel module and some C to send fake "tab tab enter" keys to skip this.


Richard

Frantisek Rysanek wrote:
> 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
> 
> 

Re: DosEMU, Ghost: VGA screen garbled...

[Frantisek Rysanek]

On 15 Sep 2009 at 13:53, Richard wrote:
>
> dosemu.bin -V -s -d
>
Thanks for that gem, Richard :-) Thanks for pushing me in the right 
direction.

I thought I didn't need "-s" if I was logged in as root (because I 
noticed that that way, DOSEMU asks for /usr/bin/sudo). This is not 
entirely true, there's more to "-s" than just the sudo. It 
effectively tells DOSEMU "don't be shy, feel free to do all the stuff 
that you need the root privileges for".
I.e., without -s, DOSEMU probably doesn't even pass the direct VGA HW 
accesses through to the VGA hardware. That's why the screen appeared 
as a videoRAM dump containing pixels, but displayed in text mode. 
Precisely what it was :-))

-V looks like a "video mode sanitizer", can't say if it has any 
effect in my case or not...

-d = "detach". I can see that the dosemu command returns to the shell 
immediately, but only after it has "forked a demon", that in turn 
attaches to the first free virtual console. It also switches you 
straight to the newly picked console that dosemu has attached to, so 
you don't quite notice, until you try switching consoles using 
CTRL+ALT+Fx :-) 
Without "-d", dosemu merely stays attached to the virtual console it 
was started from.
There's one thing I haven't tested yet: if the "detached" state also 
means "nohup" :-) I have no use for that feature anyway.

I don't know if it's due to -V or essentially a result of -s alone, 
but my LCD display now shows significant pauses of "no signal" (two 
seconds or so) as the VGA modes change. => Everything seems to be 
working allright :-)

Frank Rysanek

Re: DosEMU, Ghost: VGA screen garbled...

[Bart Oldeman]

On Thu, Sep 17, 2009 at 5:06 AM, Frantisek Rysanek
<Frantisek.Rysanek@post.cz> wrote:
> I thought I didn't need "-s" if I was logged in as root (because I
> noticed that that way, DOSEMU asks for /usr/bin/sudo). This is not
> entirely true, there's more to "-s" than just the sudo. It
> effectively tells DOSEMU "don't be shy, feel free to do all the stuff
> that you need the root privileges for".

exactly. It's just a way to avoid running "dosemu" as root and
accidentally crashing the system because direct hardware access
doesn't work.

By the way, it looks like with KMS (kernel modesetting) direct console
graphics can't work: VGA text mode is entirely unsupported then. I
will see about adding a check for that.

> -V looks like a "video mode sanitizer", can't say if it has any
> effect in my case or not...

-V just does the same thing as setting "$_graphics=(1)", i.e. the
switch has no effect if $_graphics is already set that way.

> -d = "detach". I can see that the dosemu command returns to the shell
> immediately, but only after it has "forked a demon", that in turn
> attaches to the first free virtual console. It also switches you
> straight to the newly picked console that dosemu has attached to, so
> you don't quite notice, until you try switching consoles using
> CTRL+ALT+Fx :-)

Yes, it works like X that way.

Thanks for your patch for wholedisk. I adjusted it a bit also after
reading a bit of Linux fdisk source code: just unconditionally ignore
the cylinder value from HDIO_GETGEO and compute it instead. In fact
HDIO_GETGEO gives bogus info so I changed it to look at the MBR as
well to determine CHS limits. It's now in SVN.

Bart

Re: DosEMU, Ghost: VGA screen garbled...

[Alain Mouette]

Would it be possible to run dosemu over a simple system like framebuffer?

I am interested in making a simple linux, with something like BusyBox, 
only to run dos programs...

Alain

Bart Oldeman escreveu:
> On Thu, Sep 17, 2009 at 5:06 AM, Frantisek Rysanek
> <Frantisek.Rysanek@post.cz> wrote:
>> I thought I didn't need "-s" if I was logged in as root (because I
>> noticed that that way, DOSEMU asks for /usr/bin/sudo). This is not
>> entirely true, there's more to "-s" than just the sudo. It
>> effectively tells DOSEMU "don't be shy, feel free to do all the stuff
>> that you need the root privileges for".
> 
> exactly. It's just a way to avoid running "dosemu" as root and
> accidentally crashing the system because direct hardware access
> doesn't work.
> 
> By the way, it looks like with KMS (kernel modesetting) direct console
> graphics can't work: VGA text mode is entirely unsupported then. I
> will see about adding a check for that.
> 
>> -V looks like a "video mode sanitizer", can't say if it has any
>> effect in my case or not...
> 
> -V just does the same thing as setting "$_graphics=(1)", i.e. the
> switch has no effect if $_graphics is already set that way.
> 
>> -d = "detach". I can see that the dosemu command returns to the shell
>> immediately, but only after it has "forked a demon", that in turn
>> attaches to the first free virtual console. It also switches you
>> straight to the newly picked console that dosemu has attached to, so
>> you don't quite notice, until you try switching consoles using
>> CTRL+ALT+Fx :-)
> 
> Yes, it works like X that way.
> 
> Thanks for your patch for wholedisk. I adjusted it a bit also after
> reading a bit of Linux fdisk source code: just unconditionally ignore
> the cylinder value from HDIO_GETGEO and compute it instead. In fact
> HDIO_GETGEO gives bogus info so I changed it to look at the MBR as
> well to determine CHS limits. It's now in SVN.
> 
> Bart
> --
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Linux vs. DOSEMU geometry (Was: Re: DosEMU, Ghost: VGA screen garbled...)

[Frantisek Rysanek]

Thanks for your comments and for your polite attention, 
Mr. Oldeman :-)
And you're right, I forgot to convert one "perror" into the DOSEMU 
style of warnings...

On 18 Sep 2009 at 18:00, Bart Oldeman wrote:
> In fact HDIO_GETGEO gives bogus info so I changed it 
> to look at the MBR as well to determine CHS limits.
> It's now in SVN.
> 
> Bart
>
you mean completely bogus?
I understand that the cylinders value is limited by a 16bit variable 
(clamped to (ushort) -1). Other than that, I used to think that 
HDIO_GETGEO always provides whatever the Linux kernel thinks is the 
right geometry, which in my experience is as correct as it gets :-) 
At least for my purposes, that is. My benchmark of geometry 
correctness is that the drive partitioned by Linux can boot in the 
same system (same BIOS) and in other hardware setups too...

With IDE (ATA) devices, Linux is aware of two geometries: "physical" 
and "logical". Physical is what the disk drive suggests at the IDE 
level in some service registers. In addition to that, Linux takes a 
peek into the partition table, and infers some values from that - 
that's logical geometry. The "H" and "S" values for the two 
geometries can differ. If they do differ, Linux defaults to using the 
"logical" geometry, as that's how it gets the partitions to work 
right.
I guess I've discovered that Linux does not ask the system BIOS for 
its opinion about a particular drive's geometry.

The system BIOS distinguishes several "geometry styles", typically 
CHS, LBA, LARGE - and the c/h/s values do change immediately if you 
change the geometry style in the BIOS setup. So if you change the 
geometry style in the BIOS, for a factory clean drive, and then you 
partition the drive with a tool that uses BIOS calls to access the 
drives (such as DOS fdisk), and then you reboot to Linux, this is 
what Linux infers as its "logical" geometry and what it keeps on 
using. 

If you want to get rid of the logical geometry being different from 
the physical geometry, either instruct your fdisk to use some other 
explicit CHS values, or just dd if=/dev/zero of=/dev/hda bs=512 
count=1 and invoke the BLKRRPART ioctl() somehow (such as using 
'blockdev --rereadpt', or using a cold reboot).

SCSI devices are a different matter. SCSI itself doesn't mention 
drive geometry, it only speaks LBA addresses. The sytem BIOS doesn't 
care about SCSI drives, and so its choice between CHS/LBA/LARGE is 
not applicable. The BIOS option ROM of your SCSI HBA does present 
some geometry via its services, and again if you partition the drive 
with a DOS fdisk, you also get that geometry in Linux. 
For SCSI drives, Linux can only assume a single geometry. There's no 
distinction between physical and logical. Now how does it arrive at 
that single geometry?
If the SCSI drive has a valid partition table in its MBR, the 
geometry is inferred from there. If the drive is pristine (MBR all 
zeroes), caveat: Linux invents its own geometry that it considers 
plausible! And, the geometry is yet different from the common BIOS 
"cookbook of bogus geometry recipes".

Note that USB Mass Storage devices act like SCSI devices even in this 
respect. One funny aspect: note that CF cards attached to an IDE bus 
do have a "physical" geometry, possibly distinct from the "logical" 
geometry. If there is a different logical geometry, it has probably 
been mandated by some BIOS rules. In a USB card reader though, the 
card has no way of presenting its physical geometry, and acts as a 
SCSI device. If you try to partition a factory clean CF card in a USB 
reader, you'll likely end up with a geometry that's incompatible with 
any BIOS, and the card won't be bootable when attached to an IDE 
bus... Same thing if you get the card with some compatible BIOS 
geometry, but you dd all zeroes into the MBR, and call BLKRRPART. 
This is when Linux forgets about the previously inferred geometry and 
applies a new one, and because the MBR is now blank, there's nothing 
to infer, and Linux will invent its own alien SCSI geometry thing...
The same gotcha applies to all ATA drives connected via an ATA-to-USB 
(mass storage) converter. Basically the morale is: if you want the 
ATA drive to be bootable on native ATA attach under BIOS, you have to 
partition the drive on native ATA attach, rather than in a USB 
converter :-)   (unless you know ufdprep.exe, but that's likely off 
topic here)

I wouldn't go as far as saying that the geometry provided by Linux 
HDIO_GETGEO is completely bogus. The 16bit Cylinders value is clamped 
to the max for that datatype, and the rest of the geometry can indeed 
be bogus with SCSI and USB devices that were attached with a blank 
MBR. Otherwise Linux follows the pre-existing partition table. I'd 
suggest generally to trust Linux on its guess.

Then again, it's been a while since the last time I fumbled through 
the relevant kernel guts :-) I may be wrong about some details...

Frank Rysanek

DOSEMU VGA graphics on a FrameBuffer (Was: Re: DosEMU, Ghost: VGA screen garbled...)

[Frantisek Rysanek]

On 18 Sep 2009 at 21:11, Alain Mouette wrote:
>
> Would it be possible to run dosemu over a simple system like framebuffer?
> 
> I am interested in making a simple linux, with something like BusyBox, 
> only to run dos programs...
> 
> Alain
> 
While I was looking for some solutions to my problem, I noticed 
there's vgaemu - the emulator that's used to display VGA graphics in 
a window under XWindows. Immediately it occurred to me that it might 
be useful to run run vgaemu outside of X, in "console mode", i.e. 
rendering its output into a (Linux standard) framebuffer.
According to some notes in the documentation, this is possible if you 
compile DOSEMU with support for SDL (configure --with-SDL, if memory 
serves). The SDL library can work without X and in that case, it 
renders its output into a framebuffer device. Obviously you need to 
have SDL installed in the build system first (and included in your 
target distro). SDL support is a DOSEMU plugin and you need to 
explicitly ask for that at compile time (configure time, really) as 
well as at runtime, by including the -S cmdline switch.

I do have that compiled in, but I haven't gotten as far as actually 
testing that feature, because others have pointed out a better way of 
making VGA graphics work for me :-)

BTW, what graphics hardware do you have in mind? Have you met some 
framebuffer graphics device coupled to an x86 CPU, that is not VGA 
compatible? Okay, I know the VGA compatibility can have glitches... 
If you did have some such VGA-incompliant graphics device, you might 
face other challenges, such as getting a Linux kernel framebuffer 
graphics driver for that, or direct support (driver) in SDL...

Good luck with your DOSEMU mini-distro. I suggest that you include a 
bootloader option to boot plain DOS (FreeDOS?) straight on bare metal 
:-)

Frank Rysanek

Re: DOSEMU VGA graphics on a FrameBuffer (Was: Re: DosEMU, Ghost: VGA screen garbled...)

[Alain Mouette]

Frantisek Rysanek escreveu:
>>
>> I am interested in making a simple linux, with something like BusyBox, 
>> only to run dos programs...
>>
> While I was looking for some solutions to my problem, I noticed 
> there's vgaemu - the emulator that's used to display VGA graphics in 
> a window under XWindows.
 >
> BTW, what graphics hardware do you have in mind? Have you met some 
> framebuffer graphics device coupled to an x86 CPU, that is not VGA 
> compatible? Okay, I know the VGA compatibility can have glitches... 
> If you did have some such VGA-incompliant graphics device, you might 
> face other challenges, such as getting a Linux kernel framebuffer 
> graphics driver for that, or direct support (driver) in SDL...

I am not thinking of VGA graphics, but VESA... First of all because I 
use 800x600.

There are very good drivers that autodetect all existing video hardware. 
That is basicaly what I have in mind.

My point is that Dosemu works very well in grahic mode under X, *better 
then any other simulator* so my idea is just to use that as a basis for 
a dos system.

Thare is also a few advantages: Linux network support and better 
filesystem. I have noticed that compiling a program under dosemu is 
*faster* that with plain DOS on the same machine !!!

Alain

> Good luck with your DOSEMU mini-distro. I suggest that you include a 
> bootloader option to boot plain DOS (FreeDOS?) straight on bare metal 
> :-)
> 
> Frank Rysanek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: Linux vs. DOSEMU geometry (Was: Re: DosEMU, Ghost: VGA screen garbled...)

[Bart Oldeman]

On Sun, Sep 20, 2009 at 4:05 PM, Frantisek Rysanek
<Frantisek.Rysanek@post.cz> wrote:
> On 18 Sep 2009 at 18:00, Bart Oldeman wrote:
>> In fact HDIO_GETGEO gives bogus info so I changed it
>> to look at the MBR as well to determine CHS limits.
>> It's now in SVN.
>>
> you mean completely bogus?

Well it may not be completely bogus as you explained -- however things
have changed in the Linux kernel too. particularly from 2.4 to 2.6.
And I could not find anywhere where the kernel parses the MBR to find
CHS values though fdisk certainly tries.

I have a 4G USB key that I used to test "wholedisk" with a
preformatted geometry (as I could see in the DOS boot sector) of
CHS=978/128/63; however HDIO_GETGEO reported CHS=1017/125/62. This
value was invented by setsize() in the Linux kernel's
drivers/scsi/scsicam.c. Similarly, there's ata_std_bios_param() in
drivers/ata/libata-scsi.c which invents xxx/255/63 (the standard
values used for large hard disks nowadays).

Linux fdisk even says 5922/37/36 because it parses the MBR, assuming
that the partition ends at a cylinder boundary (it does not; the MBR
is
Nr AF  Hd Sec  Cyl  Hd Sec  Cyl     Start      Size ID
 1 80   0   9    0  36  36  978          8    7888888 0b
 2 00   0   0    0   0   0    0          0          0 00
 3 00   0   0    0   0   0    0          0          0 00
 4 00   0   0    0   0   0    0          0          0 00
so it stops a little before the boundary).

All I wanted in DOSEMU was some kind of geometry that agrees with the
MBR so DOS can make sense of it (and FreeDOS boots without warnings).
And an "S" value of 63 is very common so I put some code there to
check whether that values makes sense.

Of course in reality for modern OSes CHS is irrelevant but the older
DOSes that also may get used in DOSEMU such as MSDOS 6.22 only use
CHS.

Bart

Re: Linux vs. DOSEMU geometry (Was: Re: DosEMU, Ghost: VGA screen garbled...)

[Frantisek Rysanek]

On 24 Sep 2009 at 17:42, Bart Oldeman wrote:
> > you mean completely bogus?
> 
> Well it may not be completely bogus as you explained -- however things
> have changed in the Linux kernel too. particularly from 2.4 to 2.6.
> 
oh...

> I have a 4G USB key that I used to test "wholedisk" with a
> preformatted geometry (as I could see in the DOS boot sector) of
> CHS=978/128/63; however HDIO_GETGEO reported CHS=1017/125/62. This
> value was invented by setsize() in the Linux kernel's
> drivers/scsi/scsicam.c. 
>
I see...

Thanks for the update :-) It's indeed been many months since the last 
time I bothered to investigate :-) Now I fully approve of your 
approach. Good luck and thanks for the great job that you're doing.

Frank Rysanek