Etienne Lorrain wrote:
>
> The only time I ever needed this "end line recalculation" was when the
> heigh in
> graphic lines was not a multiple of the character heigh - i.e. 640x350 with
> 8x16
> or 8x8 chars - some VGA adapters do not hide the bottom graphic lines.
> The function vga_set_
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> >> - The VGA recalc has the same bug as the assembly version where a VGA
> >> write protected register is written (Overflow register) without setting
> >> the enable bit (see VGA docs).
>
> I dug into this, and it turns out you're incorrect. Both
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Etienne Lorrain wrote:
> > "mov %fs:(%ebx,%eax,4),%ecx" works for me.
>
> That's an example on what "m" can generate.
>
> "g" could produce stuff like:
>
> mov %fs:$1234,%ecx
> mov %fs:%eax,%ecx
My solution was to use %fs:%a1 inst
Etienne Lorrain wrote:
> BUGS: some implementations (including the original IBM PC) have a bug which
> destroys BP
> the Trident TVGA8900CL (BIOS dated 1992/9/8) clears DS to h when
> scrolling in an SVGA mode (800x600 or higher)
"When scrolling in an SVGA mode", sounds
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> - Does not save and restore %ds when printing a char on the screen (%ds
> is
> destroyed only when the content of the screen scroll - only for some
> video cards)
> >> %ds? Aren't you confusing it with the old bug which woul
I tested the 'x86 setup code rewrite revised' patches on a few new
Pentium systems and some virtualized environments without any issues.
Here are some further patches ontop of yours to remove some unused
code and ifdef the MCA setup.
-Andrew
-
To unsubscribe from this list: send the line "unsub
On Fri, 13 Jul 2007, Etienne Lorrain wrote:
>
> > >> Also, I do not know if "m" is right in here:
> > >> static inline u8 rdfs8(addr_t addr)
> > >> {
> > >> u8 v;
> > >> asm("movb %%fs:%1,%0" : "=r" (v) : "m" (*(u8 *)addr));
> > >> return v;
> > >> }
> >
> > The "m" is correct right there.
>
Chuck Ebbert wrote:
>> - The VGA recalc has the same bug as the assembly version where a VGA write
>> protected
>>register is written (Overflow register) without setting the enable bit
>> (see VGA docs).
I dug into this, and it turns out you're incorrect. Both the assembly
code and the C c
Etienne Lorrain wrote:
> --- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
>> Chuck Ebbert wrote:
>
> Wrong name.
>
Have fun, this code:
- do not open the fast A20 gate before checking if the slow A20 gate is
open or
>> closed.
>>
>> As does the current code; this is highly inte
--- "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Chuck Ebbert wrote:
Wrong name.
> >> Have fun, this code:
> >> - do not open the fast A20 gate before checking if the slow A20 gate is
> >> open or
> closed.
>
> As does the current code; this is highly intentional behaviour since
> there ar
Chuck Ebbert wrote:
>> Have fun, this code:
>> - do not open the fast A20 gate before checking if the slow A20 gate is
>> open or closed.
As does the current code; this is highly intentional behaviour since
there are machines (in particular a whole series of machines made by
Olivetti) which loc
On 07/13/2007 10:25 AM, Etienne Lorrain wrote:
[ Added back cc:'s]
> On Thu, 12 Jul 2007, Linus Torvalds wrote:
>> On Thu, 12 Jul 2007, Andrew Morton wrote:
>>> This code has been in -mm since 11 May, as git-newsetup.patch. It has
>>> caused (for what it is) astonishingly few problems. Maybe a
Andi wrote:
> The only thing questionable is that .code16gcc is arguably quite
> an abuse of gcc. I even checked with some gcc developers
> and they weren't too happy about it. e.g. it's not regression
> tested at all so we would be basically on our own with it.
On the other hand GCC just produc
On Thu, 12 Jul 2007, Linus Torvalds wrote:
> On Thu, 12 Jul 2007, Andrew Morton wrote:
> >
> > This code has been in -mm since 11 May, as git-newsetup.patch. It has
> > caused (for what it is) astonishingly few problems. Maybe a couple of
> > build glitches and one runtime failure, all quickly f
On Thu, Jul 12, 2007 at 10:24:48AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 11 Jul 2007, H. Peter Anvin wrote:
> >
> > This patch set replaces the x86 setup code, which is currently all in
> > assembly, with a version written in C, using the ".code16gcc" feature
> > of binutils (which has been
On Thu, 12 Jul 2007, Andrew Morton wrote:
>
> This code has been in -mm since 11 May, as git-newsetup.patch. It has
> caused (for what it is) astonishingly few problems. Maybe a couple of
> build glitches and one runtime failure, all quickly fixed.
>
> I'd say it's ready.
Ok. That makes it e
On Thu, 12 Jul 2007 10:24:48 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 11 Jul 2007, H. Peter Anvin wrote:
> >
> > This patch set replaces the x86 setup code, which is currently all in
> > assembly, with a version written in C, using the ".code16gcc" feature
> > of binut
On Wed, 11 Jul 2007, H. Peter Anvin wrote:
>
> This patch set replaces the x86 setup code, which is currently all in
> assembly, with a version written in C, using the ".code16gcc" feature
> of binutils (which has been present since at least 2001.)
>
> 76 files changed, 4606 insertions(+), 5209
> This patch set replaces the x86 setup code, which is currently all in
> assembly, with a version written in C, using the ".code16gcc" feature
> of binutils (which has been present since at least 2001.)
".code16gcc" is useable since a bit earlier than that, in fact since:
http://sourceware.org/m
Jeff Garzik wrote:
>
> I'm sure you know what's changed since the last revision, but nobody
> everybody does :) It would be nice to know what's different from the
> last posting.
>
- Added -fno-toplevel-reorder/-fno-unit-at-a-time to the Makefile; this
is necessary for .code16gcc to be safe o
H. Peter Anvin wrote:
This patch set replaces the x86 setup code, which is currently all in
assembly, with a version written in C, using the ".code16gcc" feature
of binutils (which has been present since at least 2001.)
The new code is vastly easier to read, and, I hope, debug. It should
be not
This patch set replaces the x86 setup code, which is currently all in
assembly, with a version written in C, using the ".code16gcc" feature
of binutils (which has been present since at least 2001.)
The new code is vastly easier to read, and, I hope, debug. It should
be noted that I found a fair n
22 matches
Mail list logo
