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

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

[Stas Sergeev]

Hi.

Bart Oldeman 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) ?
Exactly! Plus some int vectors, which I can
easily identify as they are pointing to a
vbios seg.
Now I am getting that vectors together with
0x40:00-ff from /dev/mem, skipping the INIT
and opening the high ports and... - I have a
full-screen VESA!
There are still some minor problems to resolve,
but I expect to get the new video startup code
within a few weeks, just let me play full-screen
GTA a little:)
Oh, and there is still one very bad thing, which
is that we can't open the high ports in a fast
mode (or can we?), so sometimes it works even
slower than xdos... why ioperm() doesn't allow
 >0x3ff ports?..

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

[Bart Oldeman]

On Thu, 17 Oct 2002, Stas Sergeev wrote:

> Oh, and there is still one very bad thing, which
> is that we can't open the high ports in a fast
> mode (or can we?), so sometimes it works even
> slower than xdos... why ioperm() doesn't allow
>  >0x3ff ports?..

Once upon a time Linus decided that a 128 byte per-process i/o bitmap is
ok, but 8192 bytes is excessively large.

see also iopl(2)

Bart

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

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
>> slower than xdos... why ioperm() doesn't allow
>>>0x3ff ports?..
> Once upon a time Linus decided that a 128 byte per-process i/o bitmap 
> is ok, but 8192 bytes is excessively large.
Yes, and there was a reason then, which was
that ISA had 10-bit IO space most likely, but
why it wasn't altered since, is still unclear.

> see also iopl(2)
I don't think it can be used. Even if I trap
int10, do iopl(3), then trap iret and do iopl(0),
it is still dangerous, because pesky vbios calls
some other ints in a mean time.
iopl() is used in ports.c anyway to access that
ports...
I think there is no way around: VESA in WinXP have
the same speed (which means that they also doesn't
have an ability to manipulate the large IO bitmap? -
strange).

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

[Bart Oldeman]

On Thu, 17 Oct 2002, Stas Sergeev wrote:

> Bart Oldeman wrote:
> >> slower than xdos... why ioperm() doesn't allow
> >>>0x3ff ports?..
> > Once upon a time Linus decided that a 128 byte per-process i/o bitmap
> > is ok, but 8192 bytes is excessively large.
> Yes, and there was a reason then, which was
> that ISA had 10-bit IO space most likely, but
> why it wasn't altered since, is still unclear.
>
> > see also iopl(2)

(I meant the man page, which has this explanation about ioperm too)

> I don't think it can be used. Even if I trap
> int10, do iopl(3), then trap iret and do iopl(0),
> it is still dangerous, because pesky vbios calls
> some other ints in a mean time.

I'm sure it cannot be used to get fast port access. CLI and STI are no
longer virtualized (very dangerous - this can crash the machine) and
moreover inside V86 mode the IOPL setting is ignored for "IN" and "OUT".

The only way to get around this is to hack the kernel to have 8k/process
IO bitmaps. Searching lkml I found out that Ingo Molnar attempted (in
1998) to get ioperm bitmaps allocated on the fly (only if the app tries
to do ioperm()) but he said it was very difficult.

Bart