It's all about finding time to re-write code that's already written in the bios, and
space tradeoffs in the 64k codeseg limit for the kernel... Not to mention
portability issues.
On Wednesday, May 12, 1999 7:27 AM, Ansel [SMTP:[EMAIL PROTECTED]] wrote:
easily handle. Personally I'm of the
On Wed, 12 May 1999, Ansel wrote:
easily handle. Personally I'm of the opinion that using the BIOS for
everything possible is a great shortcut. Lots of device drivers talk to
Shouldn't ELKS ultimately be able to run on systems without a BIOS?
If you write the code... :-)
Jakob
--
Van: Dan Olson [EMAIL PROTECTED]
Aan: Diversia [EMAIL PROTECTED]
CC: Linux 8086 Mailinglist [EMAIL PROTECTED]
Onderwerp: Re: NanoX version 0.3 released (Pretty much off-topic)
Datum: donderdag 13 mei 1999 23:19
I (Erik Smit, AKA Diversia)'m new to this list.
I don't
Well - for the first version, there's nothing from preventing a program
from issuing the int10 without making the ioctl().
At some point on an 8086 we have to trust programmers not to break the
rules. Without some sort of device driver lock for video, even if it's
an unenforceable
I don't think you understand, the whole point of having a BIOS file is
because different systems *aren't* the same, instead of having to
re-write
or re-compile the OS for each system, a BIOS file is used instead which
has the correct information for that given system. Like you said, all
--
Van: Dan Olson [EMAIL PROTECTED]
Aan: Diversia [EMAIL PROTECTED]
CC: Linux 8086 Mailinglist [EMAIL PROTECTED]
Onderwerp: Re: NanoX version 0.3 released (Pretty much off-topic)
Datum: vrijdag 14 mei 1999 1:54
I don't think you understand, the whole point of having a BIOS
it somehow, and point Elks at it.
3) get a bios for whatever it is (usually the vendor of a single-board can
come up with something, here.)
-Original Message-
From: Dan Olson [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 13, 1999 1:43 AM
To: Ansel
Cc: Mailing List
Subject: Re: NanoX v
On Wed, 12 May 1999, Greg Haerr wrote:
The point about ELKS being currently limited to 64k code is a very good
one. I think we're kind of nearing that limit, aren't we?
Depending on how you look at it, it's already been crossed. If you
compile in all of the options on the kernel (serial,
On Wed, 12 May 1999, Greg Haerr wrote:
The point about ELKS being currently limited to 64k code is a very good one.
I think we're kind of nearing that limit, aren't we?
We've been over this issue many times.
There are many reasons to limiting the size like this, and that is simply
the fact
The point about ELKS being currently limited to 64k code is a very good one.
I think we're kind of nearing that limit, aren't we?
Greg
On Tuesday, May 11, 1999 4:18 PM, Shane Kerr [SMTP:[EMAIL PROTECTED]] wrote:
On Tue, 11 May 1999, Eric J. Korpela wrote:
Does anyone else agree with me
Louis - you have the right idea. Take a look at nanoX's server/drivers/scr_dos.c for
the int10 driver. The pixel drawing can be considerably optimized if we know that
the int10 framebuffer is at segment 0xa000 and we're running in 4 or 8 bpp mode...
FP_OFF(ScreenBuffer) = y*linesize +
Overall, I don't think its a good idea to bring graphics stuff into the ELKS
kernel, yet.
Especially since the plan is there'll be only one graphics server running per
ELKS system, ever.
Okay, we can rely on the ioctl made to initially request graphics access to
lock the graphics
o MSDOS driver support. I wrote a 640x480x16 color driver in about 45 minutes.
NanoX now runs on DOS! (OK, I did this only to see how portable nanoX
is, and the
mouse driver still isn't written) This still uses MSC graphics library.
I'll have the bios
int10 version driver done
Does anyone else agree with me that direct int 10 access is a mistake?
Wouldn't access through a device driver be a bit more unixy? It would
be able to prevent multiple processes from trying to access int 10
services.
I totally agree with this. An int 0x10 solution is *so* DOS, with the main
On Tue, 11 May 1999, Eric J. Korpela wrote:
o MSDOS driver support. I wrote a 640x480x16 color driver in about 45 minutes.
NanoX now runs on DOS! (OK, I did this only to see how portable nanoX
is, and the
mouse driver still isn't written) This still uses MSC graphics library.
Eric J. Korpela writes:
o MSDOS driver support. I wrote a 640x480x16 color driver in about 45 minutes.
NanoX now runs on DOS! (OK, I did this only to see how portable nanoX
is, and the
mouse driver still isn't written) This still uses MSC graphics library.
I'll have the bios
On Tue, 11 May 1999, Eric J. Korpela wrote:
Does anyone else agree with me that direct int 10 access is a mistake?
Wouldn't access through a device driver be a bit more unixy? It would
be able to prevent multiple processes from trying to access int 10
services.
Using the BIOS certainly
On Tuesday, May 11, 1999 12:19 PM, Luke (boo) Farrar
[SMTP:[EMAIL PROTECTED]] wrote:
On Tue, 11 May 1999, Eric J. Korpela wrote:
o MSDOS driver support. I wrote a 640x480x16 color driver in about 45 minutes.
NanoX now runs on DOS! (OK, I did this only to see how portable
Fellow NanoX interested parties:
I have today finished work on nanoX version 0.3, which includes the following features:
o completely seperate driver api and drivers for screen, mouse and keyboard.
All drivers are in a drivers/ subdirectory. It's really easy to write a driver set
for
COOL!!! Where can I find the source? I checked LHO but it only has
0.2 for dl...
Thanks
Louis
On Mon, 10 May 1999, Greg Haerr wrote:
Fellow NanoX interested parties:
I have today finished work on nanoX version 0.3, which includes the following
features:
o completely seperate
The nanoX site is:
http://www.linuxhacker.org/pub/nanogui/nano-X/
It should be up there in a little bit.
Greg
21 matches
Mail list logo
