Re: please explain to me why video/bios shadowing must be disabled to use graphics...

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Stas Sergeev]

Hello.

phrostie wrote:
>> not support this video card and does not open up enough ports.
>  what ports?
>  could you expand on this part?
>  i have a S3
For S3 cards you must not worry about this issue
at all. Setting $_chipset="s3" worked for my S3 Trio
flawlessly both for VGA and VESA modes. Don't remember
about setting $_chipset="plainvga", but I think it could
work as well.
This problem exists only on some (modern?) cards for VESA
modes, but for VGA modes there must be no such problem at
all (Bart, do you really have any examples when this is a
problem even for VGA? Correct me then, please).
To verify if you have this "port" problem, just start your
DOS prog under WinNT. If it can't set mode also there, then
yes, you have this problem (I bet you don't have it with
S3 though). Unfortunately opening the ports doesn't always
help: still no VESA modes on my Radeon7500, but VGA works
perfectly. Thinking about returning my old S3...

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Bart Oldeman]

On Tue, 24 Sep 2002, Stas Sergeev wrote:

> This problem exists only on some (modern?) cards for VESA
> modes, but for VGA modes there must be no such problem at
> all (Bart, do you really have any examples when this is a
> problem even for VGA? Correct me then, please).

Well VGA only uses standard ports so the only problem is to pass the
VBIOS initialization in the first place, that is executing the code at
c000:0003 (or c800:0003, whereever the VBIOS is). On some graphics cards
this init routine requires additional open ports and maybe even
accessible MMIO.

Some people reported black screens, or even machines hanging which
happens when the VBIOS init routine is called.

I'm not sure why this VBIOS init routine is always called if you set
$_graphics, but at least it gets the video card into a clean state. This
is esp. important if you use fbdev graphical textmodes on the console
instead of the standard VGA textmode (80x25).

Maybe by just bypassing the VBIOS init you can avoid this problem; I
just have never looked into that possibility.

The VBE 2.0 spec defines a protected mode interface - if DOSEMU would
use that it could ask which ports should be used and opened. However it
does not currently use that interface, I don't know how to do that and
am not able to test it anyway (being far away from my desktop where I
could take some risks).

Bart

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[phrostie]

an update i did finally get dosemu working.
i can run EZ cosmos, commander keen 1-3, and battle chess.
commander keen 4 and above still lock up.  i did notice that the startup 
windows are reporting no or low memory.

On Monday 23 September 2002 17:14, Bart Oldeman wrote:
> On Tue, 24 Sep 2002, Stas Sergeev wrote:
> > This problem exists only on some (modern?) cards for VESA
> > modes, but for VGA modes there must be no such problem at
> > all (Bart, do you really have any examples when this is a
> > problem even for VGA? Correct me then, please).
>
> Well VGA only uses standard ports so the only problem is to pass the
> VBIOS initialization in the first place, that is executing the code at
> c000:0003 (or c800:0003, whereever the VBIOS is). On some graphics cards
> this init routine requires additional open ports and maybe even
> accessible MMIO.
>
> Some people reported black screens, or even machines hanging which
> happens when the VBIOS init routine is called.
>
> I'm not sure why this VBIOS init routine is always called if you set
> $_graphics, but at least it gets the video card into a clean state. This
> is esp. important if you use fbdev graphical textmodes on the console
> instead of the standard VGA textmode (80x25).
>
> Maybe by just bypassing the VBIOS init you can avoid this problem; I
> just have never looked into that possibility.
>
> The VBE 2.0 spec defines a protected mode interface - if DOSEMU would
> use that it could ask which ports should be used and opened. However it
> does not currently use that interface, I don't know how to do that and
> am not able to test it anyway (being far away from my desktop where I
> could take some risks).
>
> 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

-- 
Oh, I have slipped the surly bonds of DOS,
and danced the skies on Linux silvered wings.
http://pfrostie.freeservers.com/cad-tastrafy/
http://www.freelists.org/list/cad-linux

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[phrostie]

thanks to all for the responses.
last night i was going thru the different runtime options, but regardless of
what i try i still can't seem to get any of my VGA stuff working again.

under video it asks for video address.  
where do i get/verify this for my card?

> For S3 cards you must not worry about this issue
> at all. Setting $_chipset="s3" worked for my S3 Trio
> flawlessly both for VGA and VESA modes. Don't remember
> about setting $_chipset="plainvga", but I think it could
> work as well.
> This problem exists only on some (modern?) cards for VESA
> modes, but for VGA modes there must be no such problem at
> all (Bart, do you really have any examples when this is a
> problem even for VGA? Correct me then, please).
> To verify if you have this "port" problem, just start your
> DOS prog under WinNT. If it can't set mode also there, then
> yes, you have this problem (I bet you don't have it with
> S3 though). Unfortunately opening the ports doesn't always
> help: still no VESA modes on my Radeon7500, but VGA works
> perfectly. Thinking about returning my old S3...
> 
> -
> 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


=====
phrostie
Oh I have slipped the surly bonds of DOS
and danced the skies on Linux silvered wings.
http://pfrostie.freeservers.com/cad-tastrafy/
http://www.freelists.org/webpage/cad-linux

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Stas Sergeev]

Hello.

phrostie wrote:
> an update i did finally get dosemu working.
What update you did and where was the problem
at the end?

> keen 4 and above still lock up.
Update your keen. See this:
http://marc.theaimsgroup.com/?l=linux-msdos&m=103211907106200&w=2

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Stas Sergeev]

Hello.

phrostie wrote:
> last night i was going thru the different runtime options, but 
> regardless of
> what i try i still can't seem to get any of my VGA stuff working again.
Then create a log of video events (-D9+v option
to dosemu) and see what's going wrong.
And upgrade your dosemu: something suggests me
that you are using one of those 1.0.x versions,
hence the problems.
And what version of util-linux package do you
have? There were a lot of broken versions, where
/bin/login doesn't set a console ownership for the
login shell process. No graphics also in that case.

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
>> > c000:0003
>> Where does it do that? I have found only
>> init_vga_card(), but that doesn't seem to be
>> the place. Also I searched the +g log for
>> c000:0003 and found nothing... 
>  src/base/bios/bios.S, line 507, F800:4200. 
>  init_vga_card() pushes f800:4200 on the stack as cs:ip, so that is what
>  DOSEMU gets to execute in the next vm86().
Which means that I've found the proper place not
even realising it:)
Now I also tried to nop out the hardcoded call
directly in bios.S - same effect - no graphics
modes, no even any other text modes, terminal
chars here etc. Only the progs that are setting
modes directly via ports are still working.
Doing the reset call from within DOS brings
everything back in a sane state.
Just wondering, why this reset is needed so badly?

>> > Some people reported black screens, or even machines hanging which
>> > happens when the VBIOS init routine is called.
>> Of course, that was me:) But does the problem still
>> exist after 1.1.3.1?
>  Maybe, maybe not?
Hmm, my point was that having only the VGA regs
in hands, it is not possible to lock up the entire
system. Or is it? But then it would be possible
to lock also NT, isn't it?

> It wasn't clear to me whether they used terminal mode or not. Probably
> missed something :(
Well, at least the vbios init was not passed, hence
the term chars.

>> list:( That is why, I think, XFree 3.3.6 or 4.1 are not
>> able to set any VESA modes, but not the 4.2, which can!
>  using VBE 3.0?
What advantages of VBE 3 are you suspecting?
Any chances to find this out without looking into an
XFree sources? Oh well, I just have to look there and
find out all the answers myself, but it is a big pain to
download the entire XFree sources...
Btw, I also played with LRMI package. There is a
program to set the VESA modes. It does iopl(3) and
then int10 in vm86(). Locks up as well...

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Bart Oldeman]

On Tue, 24 Sep 2002, Stas Sergeev wrote:

> Doing the reset call from within DOS brings
> everything back in a sane state.
> Just wondering, why this reset is needed so badly?

Just a very rough guess: proper initialization of certain BIOS variables
in the range 0x400-0x4ff (0040:0000-0040:00ff) ? Try to see what changes
during the init.

> Hmm, my point was that having only the VGA regs
> in hands, it is not possible to lock up the entire
> system. Or is it? 

some video cards can be completely manipulated using only VGA ports; for
instance on the SiS the extended registers are 0x3c4, al=5 and up IIRC.
You need to unlock those extended registers, but for that you only need
access to 0x3c4 and 0x3c5, i.e. standard VGA ports.

DOSEMU, because it opens those ports in the "fast" mode, does not check
whether your DOS prog or BIOS tries to write "5" to port 3c4 and then
the appropriate unlock byte to port 3c5.

Now I'm not sure about locking up, but there's certainly a lot you can
do to the graphics card.

> But then it would be possible
> to lock also NT, isn't it?

I have no idea what NT does. I don't know how it opens ports ("slow" or
"fast"). Try billg@microsoft.com - he should have access to the source
code, I don't.

Bart

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
> Well VGA only uses standard ports so the only problem is to pass the
> VBIOS initialization in the first place, that is executing the code at
> c000:0003
Where does it do that? I have found only
init_vga_card(), but that doesn't seem to be
the place. Also I searched the +g log for
c000:0003 and found nothing...

> On some graphics cards
> this init routine requires additional open ports and maybe even
Yes, my Radeon is trying, but only if all the
extra ports are *disabled*, it works.

> Some people reported black screens, or even machines hanging which
> happens when the VBIOS init routine is called.
Of course, that was me:) But does the problem still
exist after 1.1.3.1?
Anyway, no one of the people that started that thread,
had lock-ups on startup, they just have dosemu in a terminal
mode (should it display graphics then? :), why do you
think it can by any chance be the same problem?

> Maybe by just bypassing the VBIOS init you can avoid this problem; I
> just have never looked into that possibility.
I tried to comment out the end of the init_vga_card()
(which seems to call int10 but for what?) and dosemu
started fine and without the card logo. However none
of the video modes (including VGA) were available.
Have to figure out why yet.

> The VBE 2.0 spec defines a protected mode interface - if DOSEMU would
> use that it could ask which ports should be used and opened.
If everything could be so easy... I tried this already
and my Radeon is completely silent, returning an empty
list:( That is why, I think, XFree 3.3.6 or 4.1 are not
able to set any VESA modes, but not the 4.2, which can!

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Bart Oldeman]

On Tue, 24 Sep 2002, Stas Sergeev wrote:

> Bart Oldeman wrote:
> > Well VGA only uses standard ports so the only problem is to pass the
> > VBIOS initialization in the first place, that is executing the code at
> > c000:0003
> Where does it do that? I have found only
> init_vga_card(), but that doesn't seem to be
> the place. Also I searched the +g log for
> c000:0003 and found nothing...

src/base/bios/bios.S, line 507, F800:4200.

init_vga_card() pushes f800:4200 on the stack as cs:ip, so that is what
DOSEMU gets to execute in the next vm86().

> > Some people reported black screens, or even machines hanging which
> > happens when the VBIOS init routine is called.
> Of course, that was me:) But does the problem still
> exist after 1.1.3.1?

Maybe, maybe not?

> Anyway, no one of the people that started that thread,
> had lock-ups on startup, they just have dosemu in a terminal
> mode (should it display graphics then? :), why do you
> think it can by any chance be the same problem?

It wasn't clear to me whether they used terminal mode or not. Probably
missed something :(

> If everything could be so easy... I tried this already
> and my Radeon is completely silent, returning an empty
> list:( That is why, I think, XFree 3.3.6 or 4.1 are not
> able to set any VESA modes, but not the 4.2, which can!

using VBE 3.0?

Bart

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
> your problem is mostly not video shadowing
I tried this privately already - doesn't work:)

> but just that DOSEMU does
> not support this video card and does not open up enough ports.
Note however that this must not be the case for
VGA modes.
And esp. if the person have a terminal chars in
a dos box (which most likely means that the video
bios was not even mapped in), yet have a text-based
progs working.

> ports it tries to access and dosemu doesn't understand. You can enable
> then in the "ports" section.
If someone could explain why this method works
no more with the modern cards, I would be very happy.
What you now get opening these ports, is a hard lock-up:(

> Stas tried hard to get
> DOSEMU working on his ATI Radeon, and Vesa modes do not work for him.
But not all hopes are lost here: now XFree 4.2 can set
any vesa mode on my Radeon, while 4.1 couldn't. So at least now
I know that getting VESA to work again is somehow possible,
probably by stealing some code from XFree.

please explain to me why video/bios shadowing must be disabled to use graphics...

[matt]

Awhile back I tried getting graphics to work in dosemu on some linux 
distros I was playing with at the time. Sadly, I was totally unsuccessful. 
I realized after reading the docs that one had to disable video/bios 
shadowing in order to use graphics. The problem is, my computer (HP8570C) 
*does not* have any setting in the bios that lets you do this. So I guess 
that means I can't run dosemu in a graphical mode on my computer at all eh? 
What I don't quite understand is WHY do you have to disable video/bios 
shadowing to get graphics working in the first place?! I tried searching 
the web/usenet for information but apparently no one ever decided to write 
a technical document to explain why video/bios shadowing in dosemu must be 
disabled. I still think that perhaps this is some kind of quick hack that 
was put into dosemu to get graphics to work. Did it have to be programmed 
this way or was there another way graphic support in dosemu could've been 
implemented without having to require video/bios shadowing to be disabled? 
It would be great if there's another solution to get graphics working in 
dosemu without having to disable video/bios shadowing. To tell you the 
truth, i've been a windows user for quite awhile now (started with win3.1 
and i'm now using win98se) although i've used linux/bsd/solaris/etc... 
through shell accounts i've acquired over the years and from playing around 
with linux distros that are configured to run on top of a dos partition. 
Ultimately, I hope to make a complete transition to linux from wind0ze (I 
already purchased suse linux to try out). I'm guessing i'm going to have to 
go the dual boot route and keep a seperate windows partition behind to run 
my dos/windows games since i've come to realize that both dosemu/wine are 
still premature. If it wasn't for some of the technical problems with both 
emulators (probably due to microsoft's monopoly on *stuff*), I would 
quickly switch from windows to linux in a heart beat and say ados micros~1 
heh :P

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[phrostie]

i had a number of cga/vga games working in dosemu at one time.  battle chess,
commanderkeen, mario,,,.  i have not been able to get tem running even with the
same dosemu.conf files.  maybe this is why.  when did this start?

--- matt@snip.net wrote:
> Awhile back I tried getting graphics to work in dosemu on some linux 
> distros I was playing with at the time. Sadly, I was totally unsuccessful. 
> I realized after reading the docs that one had to disable video/bios 
> shadowing in order to use graphics. The problem is, my computer (HP8570C) 
> *does not* have any setting in the bios that lets you do this. So I guess 
> that means I can't run dosemu in a graphical mode on my computer at all eh? 
> What I don't quite understand is WHY do you have to disable video/bios 
> shadowing to get graphics working in the first place?! I tried searching 
> the web/usenet for information but apparently no one ever decided to write 
> a technical document to explain why video/bios shadowing in dosemu must be 
> disabled. I still think that perhaps this is some kind of quick hack that 
> was put into dosemu to get graphics to work. Did it have to be programmed 
> this way or was there another way graphic support in dosemu could've been 
> implemented without having to require video/bios shadowing to be disabled? 
> It would be great if there's another solution to get graphics working in 
> dosemu without having to disable video/bios shadowing. To tell you the 
> truth, i've been a windows user for quite awhile now (started with win3.1 
> and i'm now using win98se) although i've used linux/bsd/solaris/etc... 
> through shell accounts i've acquired over the years and from playing around 
> with linux distros that are configured to run on top of a dos partition. 
> Ultimately, I hope to make a complete transition to linux from wind0ze (I 
> already purchased suse linux to try out). I'm guessing i'm going to have to 
> go the dual boot route and keep a seperate windows partition behind to run 
> my dos/windows games since i've come to realize that both dosemu/wine are 
> still premature. If it wasn't for some of the technical problems with both 
> emulators (probably due to microsoft's monopoly on *stuff*), I would 
> quickly switch from windows to linux in a heart beat and say ados micros~1 
> heh :P
> 
> -
> 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


=====
phrostie
Oh I have slipped the surly bonds of DOS
and danced the skies on Linux silvered wings.
http://pfrostie.freeservers.com/cad-tastrafy/
http://www.freelists.org/webpage/cad-linux

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[matt]

I think it's been like this for a very very LONG time. I've been monitoring 
dosemu's progress using google groups and it apparently has been in 
production since like 93. I think the requirement for having to disable 
video/bios shadowing has been a part of dosemu for years if not since the 
beginning. I still don't have an answer to my question (or should I say 
questions <g>): Why was it programmed this way? Why does one have to 
disable video/bios shadowing? Is this due to the way linux works? Is this 
the only programming solution that had to be done or could there have also 
been another way that probably would've been a lot more challenging to 
implement but would've allowed people to run there graphical games without 
any requirements to disable video/bios shadowing in the first place? 
Personally, I still think this was some sort of quick hack to get graphics 
to work in dosemu. I hope to be proved wrong heh...

At 04:26 AM 9/9/02 -0700, you wrote:
>i had a number of cga/vga games working in dosemu at one time.  battle chess,
>commanderkeen, mario,,,.  i have not been able to get tem running even 
>with the
>same dosemu.conf files.  maybe this is why.  when did this start?
>
>--- matt@snip.net wrote:
> > Awhile back I tried getting graphics to work in dosemu on some linux
> > distros I was playing with at the time. Sadly, I was totally unsuccessful.
> > I realized after reading the docs that one had to disable video/bios
> > shadowing in order to use graphics. The problem is, my computer (HP8570C)
> > *does not* have any setting in the bios that lets you do this. So I guess
> > that means I can't run dosemu in a graphical mode on my computer at all 
> eh?
> > What I don't quite understand is WHY do you have to disable video/bios
> > shadowing to get graphics working in the first place?! I tried searching
> > the web/usenet for information but apparently no one ever decided to write
> > a technical document to explain why video/bios shadowing in dosemu must be
> > disabled. I still think that perhaps this is some kind of quick hack that
> > was put into dosemu to get graphics to work. Did it have to be programmed
> > this way or was there another way graphic support in dosemu could've been
> > implemented without having to require video/bios shadowing to be disabled?
> > It would be great if there's another solution to get graphics working in
> > dosemu without having to disable video/bios shadowing. To tell you the
> > truth, i've been a windows user for quite awhile now (started with win3.1
> > and i'm now using win98se) although i've used linux/bsd/solaris/etc...
> > through shell accounts i've acquired over the years and from playing 
> around
> > with linux distros that are configured to run on top of a dos partition.
> > Ultimately, I hope to make a complete transition to linux from wind0ze (I
> > already purchased suse linux to try out). I'm guessing i'm going to 
> have to
> > go the dual boot route and keep a seperate windows partition behind to run
> > my dos/windows games since i've come to realize that both dosemu/wine are
> > still premature. If it wasn't for some of the technical problems with both
> > emulators (probably due to microsoft's monopoly on *stuff*), I would
> > quickly switch from windows to linux in a heart beat and say ados micros~1
> > heh :P
> >
> > -
> > 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
>
>
>=====
>phrostie
>Oh I have slipped the surly bonds of DOS
>and danced the skies on Linux silvered wings.
>http://pfrostie.freeservers.com/cad-tastrafy/
>http://www.freelists.org/webpage/cad-linux
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Finance - Get real-time stock quotes
>http://finance.yahoo.com
>-
>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: please explain to me why video/bios shadowing must be disabled to use graphics...

[Bart Oldeman]

1st note: you do not need to (and never needed to) disable shadowing if
you use graphics in xdosemu, which is quite usable nowadays, but in
certain cases too slow, for some graphical programs not perfect and not
full screen (your apps run in the "DOS in the BOX").

Only on the linux console, IF your graphics card is supported by DOSEMU
and IF you run DOSEMU as root or suid-root you *might* need to have to
turn off vbios shadowing. There are quite a few graphics cards out there
that DOSEMU does not support, and moreover suid-root is discouraged.

On Fri, 20 Sep 2002 matt@snip.net wrote:

> Why was it programmed this way? 

Nothing really intended - DOSEMU basically mmaps the contents of
/dev/mem to 0xc0000-0xc8000 or some such, if it has permission to do so.
Otherwise console graphics don't work.

> Why does one have to disable video/bios shadowing? 

I guess because the RAM that is used for the shadowing at boot time 
might be overwritten by Linux and things get messed up. This is highly
system dependent; that's why I said *might*.

> Is this the only programming solution that had to be done or could there have also 
> been another way that probably would've been a lot more challenging to 
> implement but would've allowed people to run there graphical games without 
> any requirements to disable video/bios shadowing in the first place? 

yes, that's called "vgaemu" and is what you use when you run graphical 
applications in xdosemu - no need for a graphics card specific video
BIOS, so shadowing is irrelevant.

simply run them in xdosemu or wait for "vgaemu on console or fullscreen 
X" support, that does not need the systems BIOS or root privileges.

Bart

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[matt]

Thanks for the explanining things. I haven't messed around much with the X 
version of dosemu except when playing around with ZZT (I seem to recall all 
the characters were squished probably because it wasn't running in full 
screen). I was never trying to be rude or anything and I hope I didn't come 
off as such. I do appreciate the work that you and the dosemu team have 
done and look forward to "full screen support in X" and "vgaemu on console" 
support in the future. Thanks again, later...

At 10:29 PM 9/20/02 +0100, you wrote:
>1st note: you do not need to (and never needed to) disable shadowing if
>you use graphics in xdosemu, which is quite usable nowadays, but in
>certain cases too slow, for some graphical programs not perfect and not
>full screen (your apps run in the "DOS in the BOX").
>
>Only on the linux console, IF your graphics card is supported by DOSEMU
>and IF you run DOSEMU as root or suid-root you *might* need to have to
>turn off vbios shadowing. There are quite a few graphics cards out there
>that DOSEMU does not support, and moreover suid-root is discouraged.
>
>On Fri, 20 Sep 2002 matt@snip.net wrote:
>
> > Why was it programmed this way?
>
>Nothing really intended - DOSEMU basically mmaps the contents of
>/dev/mem to 0xc0000-0xc8000 or some such, if it has permission to do so.
>Otherwise console graphics don't work.
>
> > Why does one have to disable video/bios shadowing?
>
>I guess because the RAM that is used for the shadowing at boot time
>might be overwritten by Linux and things get messed up. This is highly
>system dependent; that's why I said *might*.
>
> > Is this the only programming solution that had to be done or could 
> there have also
> > been another way that probably would've been a lot more challenging to
> > implement but would've allowed people to run there graphical games without
> > any requirements to disable video/bios shadowing in the first place?
>
>yes, that's called "vgaemu" and is what you use when you run graphical
>applications in xdosemu - no need for a graphics card specific video
>BIOS, so shadowing is irrelevant.
>
>simply run them in xdosemu or wait for "vgaemu on console or fullscreen
>X" support, that does not need the systems BIOS or root privileges.
>
>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

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Pat]

Sorry, that link wasn't so good as I thought.
Better:
 http://www.lostcircuits.com/video/asus_ti500/2.shtml

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Pat]

On Mon, 9 Sep 2002 matt@snip.net wrote:

>Awhile back I tried getting graphics to work in dosemu on some linux 
>distros I was playing with at the time. Sadly, I was totally unsuccessful. 
>I realized after reading the docs that one had to disable video/bios 
>shadowing in order to use graphics. The problem is, my computer (HP8570C) 
>*does not* have any setting in the bios that lets you do this. 

So how does the HP8570C do shadowing?  Perhaps there is a bios upgrade 
possible that would allow it. Something like is available on vectra.

Cheers, Pat

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[matt]

Sorry about this late reply.. um.. How am i suppose to know how the HP8570C 
does shadowing? It just does it and there's no way to turn it off through 
bios setup. I've tried getting graphics to work in dosemu before in the 
past but everytime i tried to run a game such as wolf3d the thing went 
black which forced me to switch terminal screens and log back in to kill 
the dosemu process. I then realized that I probably needed to disable 
video/bios shadowing.This is what most people seem to suggest when someone 
asks the question "how do i get graphics to work" (It's also mentioned in 
the docs included with dosemu). The HP8570C is 3 years old  (i bought it 
back in 99 - was state of the art back then heh :P) so there's no new bios 
updates for this system. I have the latest and final bios update for it. I 
realize the problem with wolf3d might have been related to other issues but 
even old games such as ultima1 or 4 didn't work. I only got ZZT to work 
(since it's a old text based game that uses pc speaker sound only) but the 
fonts were screwy since it was using the default terminal font and I never 
did figure out how to fix that. Oh, I also got QBasic to work too but it 
appears to be really slow so i'm afraid even games like wolf3d would be 
coming to a halt on this 450 mhz system. Seems you need like a ghz system 
to even handle those games if something such as QBasic would act quite 
slow. Of course, I was doing these tests on a distro that was set up to 
work on top of the dos partition so perhaps a real linux setup would be 10x 
faster *shrug*. I intend on messing around with dosemu again in the future 
with a distro running on top of it's own partition and not dos. I was 
really hoping there was another solution to getting graphics to work in 
dosemu without having to really disable video/bios shadowing in the first 
place.

At 07:08 PM 9/9/02 -0700, you wrote:


>On Mon, 9 Sep 2002 matt@snip.net wrote:
>
> >Awhile back I tried getting graphics to work in dosemu on some linux
> >distros I was playing with at the time. Sadly, I was totally unsuccessful.
> >I realized after reading the docs that one had to disable video/bios
> >shadowing in order to use graphics. The problem is, my computer (HP8570C)
> >*does not* have any setting in the bios that lets you do this.
>
>So how does the HP8570C do shadowing?  Perhaps there is a bios upgrade
>possible that would allow it. Something like is available on vectra.
>
>Cheers, Pat
>
>
>-
>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: please explain to me why video/bios shadowing must be disabled to use graphics...

[Pat]

On Fri, 20 Sep 2002 matt@snip.net wrote:

>.. How am i suppose to know how the HP8570C  does shadowing? It just 
> does it 

Well, after paying all the moola to buy such a beast, would think a few 
more bucks for the hardware manual wouldn't hurt much.  But maybe HP 
doesn't make hardware/software manuals for their equipment like other 
proprietary systems, ie. apple/sun.  

Still, that question might prompt another: How would the 
programmer do shadowing to help the memory-starved program along a 
bit?  Why do shadowing?  Because the hardware is too slow, is my guess.  
And then there is the more detailed matter of directly addressing the 
video hardware everytime you want to flip a bit or two.   

And, somewhere in the early install faqs that mention shadowing in 
linux, why to turn it off, is that linux does a much better job doing 
its own shadowing.  More efficient.  Perhaps linux docs will show how it 
does this shadowing so much better, and it might show how in principle 
it is done.  Is the actual architecture so different?  Forgive me, I 
have no HP to explore, but it would be fun.

There is a book,
Assembly Language: Step-by-Step, (2nd Ed.) by 
Jeff Duntemann, publ. Wiley, 2000 

It is very easy reading, deals with the basics well. 

Since I've only begun to use dosemu, I expect to have to 
check that book out again, because it dealt with the problem of writing 
to video RAM and even shadowing, I think.  

>and there's no way to turn it off through 
>bios setup. 

So the bios for vectra is significantly different than that of your 
machine?  I have no hp machine to look at.  But if I did, I'd want to 
see where it keeps video data in the first place.  The manufacturer of 
the video chips almost always do publish hardware manuals, otherwise no 
one would write software for them.  The standard video 
addresses/switches are well-documented.

The bios setup program is just 
software that addresses the settings.  Usually there is an address in 
memory that when referenced, changes state, becomes writable or not it 
points to another area that is writable. That area could be either 
video RAM or some other memory.  That's as specific as I can get at the 
moment, but you get the idea.

I'd want to know specifically if 
video hardware on hp is significantly different in some way from any 
other pc-compatibles.  Bet it isn't.  

It makes no sense there is no hardware switch  to turn off shadowing, so 
now I'm curious what method hp uses.

Surely this info would be available to a hardware 
owner.  And if there are no hp-specific publications, perhaps a phone 
call to one of their engineers that works on video addressing would 
yield something.  Somebody had to decide how things would be done at 
some point in your machine's history.  A direct call might just be the 
fastest way to get an answer and maybe even a reference or two, or a 
private privileged (you paid your moneys) online link for users.

> I've tried getting graphics to work in dosemu before in the 
> past but everytime i tried to run a game such as wolf3d the thing went 
> black which forced me to switch terminal screens and log back in to 
> kill the dosemu process. 

Forced how?  Did it hang, no response?  Going all black might mean just 
no memory, no pointer to memory, the memory it needs.  

Wolf3d does have source code available for free.  Have you compiled it 
to work on your system?  Somewhere in that code would be the video 
addressing routines.  Compile, run with lots of stderr, study the error 
messages, find the trouble spot.  See how it would be solved in the 
non-proprietary system.  Forgive, all theoretical, you're probably in a 
hurry to play the darn game.  

> .. needed to disable video/bios shadowing. This is what most people 
> seem to suggest when someone  asks the question "how do i get graphics 
> to work" 

Need a more specific question to get a better answer.  There are refs 
that cover these things, search for "svga programming shadow methods".
I tried it, found this to start:

http://www.geocities.com/SiliconValley/Park/9784/tut.html
2D  Basics, VGA Mode 13h
    SVGA - vesa, vbe 2

By the way, what kind of video do you have?  VESA?  Lots of docs on that 
standard.  Find out all the details you can on your video interface, 
what the range and limits of your monitor/video firmware.

> ... but the  fonts were screwy since it was using the default terminal 
> font and I never did figure out how to fix that. 

But therein lies some secrets.  Text on video is done much the same way. 
Maybe slug through that, find out how it does switch to non-hardware 
fonts.  Map the known.

> Oh, I also got QBasic to work too but it 
> appears to be really slow so i'm afraid even games like wolf3d would 
> be coming to a halt on this 450 mhz system. 

It would of course be slow, not comparable to compiled C or assembly 
code, processed in RAM.  Imagine running X with 8 megs free RAM.  It 
would swap on the hardware.  Be click and wait. ;)  

> I was really hoping there was another solution to getting graphics to 
> work in  dosemu without having to really disable video/bios shadowing 
> in the first place.

Not without getting down and dirty, I expect. HP somehow uses its own 
shadowing algorithms/switches/memory moves.  Where and how it does it is 
documented somewhere or no one could write code for it.  Are those 
routines built into ROM by any chance?  

Apologies if I'm way off base here.  Am new.  Will shut up and listen 
now.

Cheers, Pat

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[matt]

>I'd want to know specifically if
>video hardware on hp is significantly different in some way from any
>other pc-compatibles.  Bet it isn't.

I'm sure it isn't...

>It makes no sense there is no hardware switch  to turn off shadowing, so
>now I'm curious what method hp uses.

Well i'm not much of a hardware person so I never really looked to see if 
there was a hardware switch in the first place. I've heard from other HP 
users about bad experiences trying to take the case on the HP off. It 
sounds as if it's a general pain in the a$$. Regardless of whether or not 
there's a hardware switch in the system, it's still very annoying that HP 
never decided to put in a setting in the bios setup program to disable 
video/bios shadowing.

>Surely this info would be available to a hardware
>owner.  And if there are no hp-specific publications, perhaps a phone
>call to one of their engineers that works on video addressing would
>yield something.  Somebody had to decide how things would be done at
>some point in your machine's history.  A direct call might just be the
>fastest way to get an answer and maybe even a reference or two, or a
>private privileged (you paid your moneys) online link for users.

heh most systems that you buy in the store don't give you detailed manuals 
and are you suggesting I call tech support because I hate the very idea of 
that. I never ever had to call tech support for any of my past and present 
systems. I choose not to because it's a royal pain the a$$ and most of the 
time they can't help you anyway. You end up wasting money, especially if 
you were to ring up microsoft's god awful tech support line from HELL (i'm 
glad I never called them. all the horror stories *gasp*). I seem to get the 
impression that hp's tech support is crap too, especially from when I use 
to browse there now semi defunct tech forums.

> > I've tried getting graphics to work in dosemu before in the
> > past but everytime i tried to run a game such as wolf3d the thing went
> > black which forced me to switch terminal screens and log back in to
> > kill the dosemu process.
>
>Forced how?  Did it hang, no response?  Going all black might mean just
>no memory, no pointer to memory, the memory it needs.

Yeah the process locked up. The system didn't lock up (if it was winblows 
it probably would've).


>Wolf3d does have source code available for free.  Have you compiled it
>to work on your system?  Somewhere in that code would be the video
>addressing routines.  Compile, run with lots of stderr, study the error
>messages, find the trouble spot.  See how it would be solved in the
>non-proprietary system.  Forgive, all theoretical, you're probably in a
>hurry to play the darn game.

Yeah I know the source code is available but I don't have the right tools 
to compile it right now and I don't even think it will compile on linux 
without having to tweak it some bit. I'm not much of an expert at 
programming (although i'm learning).

> > .. needed to disable video/bios shadowing. This is what most people
> > seem to suggest when someone  asks the question "how do i get graphics
> > to work"
>
>Need a more specific question to get a better answer.  There are refs
>that cover these things, search for "svga programming shadow methods".
>I tried it, found this to start:
>
>http://www.geocities.com/SiliconValley/Park/9784/tut.html
>2D  Basics, VGA Mode 13h
>     SVGA - vesa, vbe 2
>
>By the way, what kind of video do you have?  VESA?  Lots of docs on that
>standard.  Find out all the details you can on your video interface,
>what the range and limits of your monitor/video firmware.

Well the system isn't that old. It's only 3 years old. I bought it back in 
99. My video card is an ATI Rage Pro btw.

> > ... but the  fonts were screwy since it was using the default terminal
> > font and I never did figure out how to fix that.
>
>But therein lies some secrets.  Text on video is done much the same way.
>Maybe slug through that, find out how it does switch to non-hardware
>fonts.  Map the known.

I get the impression after reading your entire post that you think i'm some 
sort of programmer <g>? I know some programming (assembly, qbasic, c, c++, 
etc...) but i'm not that good at it. Like I said, I'm still learning heh 
<g>. I seem to recall someone once saying on some usenet group that you 
might need to switch the default console font to a font that supports ibm 
ascii characters. I don't think any distro I played with came with such 
fonts. However, I did play around with the console fonts included with the 
distros. I think I almost got the characters looking right too (ZZT wasn't 
as messed up but there was some things that were still screwy). So I think 
what I need is a console font that uses ibm ascii characters. I also think 
I read somewhere that running the X windows version of dosemu might fix 
this problem too, that the problem is only with the console.

> > Oh, I also got QBasic to work too but it
> > appears to be really slow so i'm afraid even games like wolf3d would
> > be coming to a halt on this 450 mhz system.
>
>It would of course be slow, not comparable to compiled C or assembly
>code, processed in RAM.  Imagine running X with 8 megs free RAM.  It
>would swap on the hardware.  Be click and wait. ;)

heh yeah I know that. QBasic wasn't that bad under the console. It loaded 
up quickly just that the screen being drawn was much slower than it was in 
native dos (I expected it to be a little slower, but not that slow). I 
suspect that a game such as wolf3d would be even slower to the point where 
it might be unplayable. I'm thinking it could've been something else that 
was making it slower then usual. Perhaps it was because I was running the 
linux distro, that I was playing with at the time, on top of a dos 
partition? I haven't yet tested dosemu on a linux distro that runs on it's 
own partition so i'm hoping it'll be faster when I do.


> > I was really hoping there was another solution to getting graphics to
> > work in  dosemu without having to really disable video/bios shadowing
> > in the first place.
>
>Not without getting down and dirty, I expect. HP somehow uses its own
>shadowing algorithms/switches/memory moves.  Where and how it does it is
>documented somewhere or no one could write code for it.  Are those
>routines built into ROM by any chance?

heh there you go again, asking me as if I should know. Seriously, this HP 
system is probably like many other pcs out there. I'm sure it does 
shadowing in a similar fashion. What do you mean no one could write code 
for it? This system is like any other pc clone/compatable out there. It has 
an x86 processor (Pentium III) and it's not a sparc or an alpha, etc... 
Anything written for other pcs or operating systems (windows, linux, 
etc...) should work on it as long as they don't have any specific hardware 
requirements (like a graphics accelerator, a particular sound card, more 
ram, etc...) or operating system requirements. Just so you know, this 
system came with windows 98 (and a upgrade CD to 98se). If you want more 
information on it then just browse on over to:

http://www.hp.com/cposupport/personal_computing/support_doc/bph05044.html

That link takes you to a page with the specs for the system. Keep in mind 
this system is atleast 3 years old. My bios is a Phoenix bios btw (modified 
for this system obviously so any other Phoenix bios update that didn't come 
from HP would probably hose the bios and the system).

>Apologies if I'm way off base here.  Am new.  Will shut up and listen
>now.
>
>Cheers, Pat


heh np =P




>-
>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: please explain to me why video/bios shadowing must be disabled to use graphics...

[Bart Oldeman]

On Sat, 21 Sep 2002 matt@snip.net wrote:

[about having an ATI Rage Pro where the screen goes black]

your problem is mostly not video shadowing, but just that DOSEMU does
not support this video card and does not open up enough ports.

I remember talking about this before when I still used console DOSEMU.

   Date: 2000/03/28

On Tue, 28 Mar 2000, Tuomas Jormola wrote:

> I've got some problems to enable graphics with Dosemu. I think it's
> because of the graphics card, ATI Xpert@Work 8MB AGP.
>
> +$_chipset = "ati"

I don't know much about the X stuff.
For the console, the problem is that "ati" refers to older ATI cards.
dosemu probably hanged while trying to initialise the video card, that's  
why you couldn't type exitemu.
Try $_chipset = "plainvga" for now. If that still doesn't work, the
following can give you a clue:

Run "dos -D+i -o /var/tmp/errors" and analyze /var/tmp/errors to see which
ports it tries to access and dosemu doesn't understand. You can enable
then in the "ports" section. Don't do this is if you're paranoid about
security though.

If it works you probably won't be able to do console switching, except to
and from X.

Bart

-----
you could also try a development version of DOSEMU with svgalib support
compiled-in and $_chipset = "svgalib".

And then still, no guarantees, vesa modes may still be broken, the
screen can go black, your computer may hang, and you may harm yourself
and your monitor (depends a lot on the monitor though, but older
fixed-frequency types are easily damaged). Stas tried hard to get
DOSEMU working on his ATI Radeon, and Vesa modes do not work for him.
Neither do they in NT DOS boxes.

Bart

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[phrostie]

> not support this video card and does not open up enough ports.
> 
what ports?
could you expand on this part?

i have a S3 card but have not been able to get dowemu working since MDK 7.0

also, i was wondering, does dosemu currently rely on Xfree being version 4.x or
newer?  MDK7.0 was the last dist that i've used that came with 3.3.6 as the
default.  i forget which but there was another application that i was having
trouble with that(i was told) required xlibs for 4.x.

=====
phrostie
Oh I have slipped the surly bonds of DOS
and danced the skies on Linux silvered wings.
http://pfrostie.freeservers.com/cad-tastrafy/
http://www.freelists.org/webpage/cad-linux

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Bart Oldeman]

On Mon, 23 Sep 2002, phrostie wrote:

> > not support this video card and does not open up enough ports.
> > 
> what ports?
> could you expand on this part?

That is video card dependent - you have to run with the debug flags as I
explained before to find out which ones.

> also, i was wondering, does dosemu currently rely on Xfree being version 4.x or
> newer?  MDK7.0 was the last dist that i've used that came with 3.3.6 as the
> default.  i forget which but there was another application that i was having
> trouble with that(i was told) required xlibs for 4.x.

xdos(emu) does not rely on X being 3 or 4.

The dos(emu) we're talking about here, using console graphics, is
completely independent of X.

dos(emu) in a terminal is X independent too, but without graphics.

Bart

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[matt]

Well I don't have any problem with graphics in native dos so I guess i'll 
have to go the dual boot route and keep a small dos/windows partition 
available to run my dos stuff. thanks again.

At 05:04 PM 9/21/02 +0100, you wrote:
>On Sat, 21 Sep 2002 matt@snip.net wrote:
>
>[about having an ATI Rage Pro where the screen goes black]
>
>your problem is mostly not video shadowing, but just that DOSEMU does
>not support this video card and does not open up enough ports.
>
>I remember talking about this before when I still used console DOSEMU.
>
>    Date: 2000/03/28
>
>On Tue, 28 Mar 2000, Tuomas Jormola wrote:
>
> > I've got some problems to enable graphics with Dosemu. I think it's
> > because of the graphics card, ATI Xpert@Work 8MB AGP.
> >
> > +$_chipset = "ati"
>
>I don't know much about the X stuff.
>For the console, the problem is that "ati" refers to older ATI cards.
>dosemu probably hanged while trying to initialise the video card, that's
>why you couldn't type exitemu.
>Try $_chipset = "plainvga" for now. If that still doesn't work, the
>following can give you a clue:
>
>Run "dos -D+i -o /var/tmp/errors" and analyze /var/tmp/errors to see which
>ports it tries to access and dosemu doesn't understand. You can enable
>then in the "ports" section. Don't do this is if you're paranoid about
>security though.
>
>If it works you probably won't be able to do console switching, except to
>and from X.
>
>Bart
>
>-----
>you could also try a development version of DOSEMU with svgalib support
>compiled-in and $_chipset = "svgalib".
>
>And then still, no guarantees, vesa modes may still be broken, the
>screen can go black, your computer may hang, and you may harm yourself
>and your monitor (depends a lot on the monitor though, but older
>fixed-frequency types are easily damaged). Stas tried hard to get
>DOSEMU working on his ATI Radeon, and Vesa modes do not work for him.
>Neither do they in NT DOS boxes.
>
>Bart

Re: please explain to me why video/bios shadowing must be disabled to use graphics...

[Pat]

On Sat, 21 Sep 2002 matt@snip.net wrote:

>Well i'm not much of a hardware person so I never really looked to see if 
>there was a hardware switch in the first place. I've heard from other HP 
>users about bad experiences trying to take the case on the HP off. 

The "hardware" switch means really a firmware address whose memory can't 
be accessed except to "look" at it with software, load the accumulator 
with the  value it has just to make it change state--on or off.  So 
don't look for it inside the box.

I have an older book, Programmer's PC Sourcebook, by Thom Hogan, that 
documents this stuff.

>sounds as if it's a general pain in the a$$.

Only if you don't like to do it.  8)

> .. it's still very annoying that HP 
>never decided to put in a setting in the bios setup program to disable 
>video/bios shadowing.

Am sure it is.  

>heh most systems that you buy in the store don't give you detailed manuals 

oh, no, always for sale, not in the store, usually.  Not a general 
public kind of item.  Except perhaps in Japan where even little kids 
build robots.

> you suggest I call tech support because I hate the very idea of 
>that. 

Yes I agree it is wasteful to call m$oft because they are in business, 
and all of their subcontractor support companies are in business to 
extract the money from customers.  But they must be the worst example of 
that.

I would have thought that hp would be more supportive though, for its 
proprietary parts.

>I never ever had to call tech support for any of my past and present 
>systems. I choose not to ....

Unfortunate.  But I didn't mean to call "tech support", exactly. I see 
where hp toll-free's on the site you gave me warns the call might be 
directed to toll number.  I meant call, identify the department, perhaps 
the engineer who decided to leave out the  access.  Perhaps that is 
unrealistic for HP.  

It wouldn't work to call  with just general "why" questions because 
someone has to figure out what you  really want to know, and that's what 
costs money.  Sort of like going to a lawyer.  The meter is running, 
have to have the right questions ready.  Looks like they have a 
different number for potential customers.  They aren't likely to charge 
for prospective customer's questions, like "I hear that particular pc 
has no shadow switch, isn't that unusual? ...I need to know before I 
buy..." 

>I get the impression after reading your entire post that you think i'm some 
>sort of programmer <g>? I know some programming (assembly, qbasic, c, c++, 

gee, I thought that dosemu was still in the experimental stages, that it 
would require some programming to get it working.  Also, it is dangerous 
to mess with video without knowing something of how it works, so am 
hoping I too can learn using the manuals and source.

>> HP somehow uses its own
>> shadowing algorithms/switches/memory moves.  Where and how it does it 
>> is documented somewhere or no one could write code for it.  

> ... What do you mean no one could write code  for it? This system is 
> like any other pc clone/compatable out there. 

Except for no shadow switch...

> My bios is a Phoenix bios btw (modified 
> for this system obviously so any other Phoenix bios update that didn't 
> come from HP would probably hose the bios and the system).

Have an old Phoenix Technical Ref, a guide to ROM-Based system software.
It's the hp system programmers who refer to and write code based on 
these  manuals.  This one probably too old, but it essentially addresses 
the video adapter switches, ports and other I/O component switches.

Without reference manuals, the Phoenix people wouldn't be able to write 
the BIOS programs either.

Now, am going to see if dosemu will work for me.  I  have the Quake II  
cd and Tombraider to get working, hopefully.


Cheers, Pat