At 09:31 AM 4/14/2004 +0200, tom ehlert wrote:
>*** my conclusion ***
>I hate A20 anyway - use always on if found to be on on startup
Good enough for me, I'll move an initial A20 always-on test to front of the method
line on next release.
-
On Wed, 14 Apr 2004, tom ehlert wrote:
> Hello Michael,
>
> MD> Additionally, if any port 92h related
> MD> lockups happen, I'll move "always-on" to top the A20 test list,
> MD> see if they go away.
>
> *** PRO 'always-on' ***
I think "always on" here refers to machines that *boot* with A20 enabl
Hello Bernd,
BB> HIMEM is still under GPL, correct?
HIMEM is under Artistic License.
BB> derived from FDXMS, which is GPL.
derived from FDXMS 0.2, which is free.
tom
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tuto
Hello Michael,
MD> Additionally, if any port 92h related
MD> lockups happen, I'll move "always-on" to top the A20 test list,
MD> see if they go away.
*** PRO 'always-on' ***
not sure, but I seem to remember, that MS MIMEM, when it detects
A20 on on startup, simply leaves it on and disables disab
Hi!
13-Апр-2004 17:43 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
MD> Oh, a final question for you: do you know if any of the Linux code listed
MD> is even remotely tied up with all that SCO garbage? Obviously SCO's case is
MD> utterly bogus, but as you know, unlike IBM we ca
Patrick J. LoPresti schreef:
I believe the Linux A20 code was contributed by the SYSLINUX author,
who definitely never worked for IBM.
It is, however, covered by GPL...
HIMEM is still under GPL, correct?
derived from FDXMS, which is GPL.
so no problem when you want to include other GPL stuff, lik
Michael Devore <[EMAIL PROTECTED]> writes:
> We're still running into a shortage of testers and I think the best
> approach may be to soon release a cleaned-up version of the HIMEM we
> have into the wild, then modify as necessary afterwards.
Sounds perfectly reasonable to me.
> Oh, a final ques
At 04:58 PM 4/8/2004 -0400, Patrick J. LoPresti wrote:
>Michael Devore <[EMAIL PROTECTED]> writes:
>
>> Although the new A20 test code should work, as it does fine in many
>> machines and the logic is sound.
>
>I still think instruction reordering is a potential issue.
It might be, it's hard to be
At 04:47 PM 4/8/2004 -0400, Patrick J. LoPresti wrote:
>It might be reasonable to say that HIMEM64 "owns" the A20 gate, and
>therefore must be the first program to manipulate it. If this fails
>to work under some emulated environment, that environment is arguably
>broken... I just took a peek at
Michael Devore <[EMAIL PROTECTED]> writes:
> Yes, reversion to original A20 test is going to be the final mod
> tried before I declare the BIOS rogue, or possibly a subtle-bugged
> application.
Yuck.
> Although the new A20 test code should work, as it does fine in many
> machines and the logic i
Michael Devore <[EMAIL PROTECTED]> writes:
> Of course, I should say enabled here, rather than disabled.
I think "disabled" is correct, assuming "disabled" is a synonym for
"closed". (As in, the gate is closed, so it does not pass anything,
so the A20 line is "disabled" and fixed at 0.) Actuall
At 03:10 PM 4/8/2004 -0500, Michael Devore wrote:
>I'm not sure FreeDOS can assume HIMEM has the first shot at machine hardware in its
>initial state. It certainly doesn't under VMware, which we have do FreeDOS users
>running under. Does VMware reset A20 back to known disabled state at startu
At 02:46 PM 4/8/2004 -0400, Patrick J. LoPresti wrote:
>Michael Devore <[EMAIL PROTECTED]> writes:
>
>> I added enable/disable test, but the report was that it still fails,
>> after working for the startup test. Which either means the BIOS is
>> bugged and fails under stress, or there is something
Michael Devore <[EMAIL PROTECTED]> writes:
> I added enable/disable test, but the report was that it still fails,
> after working for the startup test. Which either means the BIOS is
> bugged and fails under stress, or there is something very weird
> going on.
Like the test_a20 code failing...
At 10:52 AM 4/8/2004 -0400, Patrick J. LoPresti wrote:
>It sounds like you cannot trust the BIOS status code, so you need to
>test whether it really enabled/disabled the gate. Or, just tell the
>user their BIOS is buggy and to get a new machine. :-)
I added enable/disable test, but the report w
Michael Devore <[EMAIL PROTECTED]> writes:
> Great. Now that HIMEM is getting wider distribution to the eager
> hundreds or thousands, I've additionally collected problem reports
> with buggy BIOS support for BIOS method and a failing A20 always on
> method. It's like a dam busted somewhere upst
Great. Now that HIMEM is getting wider distribution to the eager hundreds or
thousands, I've additionally collected problem reports with buggy BIOS support for
BIOS method and a failing A20 always on method. It's like a dam busted somewhere
upstream.
For all those asking, reverting to the ori
17 matches
Mail list logo
