Hi Greg.
> 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 almost need to copy the trick MSDOS used of having the operating
system in two parts. In MSDOS, they were called IO.SYS and MSDOS.SYS
respectivel
load 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: Na
>
> I'm pretty sure that a rom bios file is not THE answers to let ELKs run on
> IBM PCjr, Tandy 1000 because those systems, even though they aren't IBM
> Compatible, still use chipsets and stuff. And AFAIK a BIOS, like I said
> before, is specific for one and only one chipset.
I'm not saying t
--
> 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 d
> > 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 s
> 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 lo
--
> Van: Dan Olson <[EMAIL PROTECTED]>
> Aan: Ansel <[EMAIL PROTECTED]>
> CC: Mailing List <[EMAIL PROTECTED]>
> Onderwerp: Re: NanoX version 0.3 released
> Datum: donderdag 13 mei 1999 7:43
>
> > >easily handle. Personally I'm of t
--
> 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 (E
> I (Erik Smit, AKA Diversia)'m new to this list.
>
> I don't think using a bios file would be very useable. AFAIK a BIOS is
> system-specific and maybe in the time of CP/M al C128 where the same but
> that doesn't work today. I don't think it would be a pretty sight using a
> Amstrad 286 bios in
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
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 op
Greg Haerr writes:
>
> > > 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 requ
> >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?
I was going to suggest this a *long* time ago, but never did. What about
usin
Ansel writes:
>
> >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?
>
Yes, there is nothing inherantly BIOS orientated about ELK
On Wed, 12 May 1999, Ansel wrote:
> Shouldn't ELKS ultimately be able to run on systems without a BIOS?
Yes, in the future it should. Userspace programs should not use BIOS,
however in the kernel it is required sometimes, for example to do some
disk operations and the like. However all of the
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
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,
> > 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
> Does anyone else agree with me that direct int 10 access is a mistake?
Yes
> 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.
You need to fix and recover context, you need to worry about 286 p
Greg Haerr writes:
>
> On Tuesday, May 11, 1999 12:56 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote:
> > 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 h
>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?
-Ansel the Lurker.
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 + x
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
> I think that's a good idea to potentially solve the lock problem,
> but of course lock code would have to be executed. At this point, it's going
> to be *way* too slow for all the graphics primitives to go thru a kernel mode
> transition, however.
I was thinking of only locking the ini
Using INT 0x10 gives a way for the driver to be implemented in very
"portable" code though it would run much slower. Using the Mode 0x13
frame buffer over INT 0x10 usually yields 2x speed improvement
(minimal). However, the portable code look a little like this:
/*
This is not a real method
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
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 certainl
The multiple process access is a good point that I hadn't thought of. Of course,
it would only happen if multple graphics servers were run, which I guess could happen.
On the int10 access, I'm writing that only for the ELKS port to get it off the ground
quickly, since that's the point of the BIO
On Tuesday, May 11, 1999 12:56 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote:
> 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 t
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 t
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 li
>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 mai
> 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 sh
In article <[EMAIL PROTECTED]> you write:
> 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 ha
The nanoX site is:
http://www.linuxhacker.org/pub/nanogui/nano-X/
It should be up there in a little bit.
Greg
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 seperat
36 matches
Mail list logo
