RE: ELKS bugs fixed
On Wed, 14 Jul 1999, Luke (boo) Farrar wrote: bcc -0 -O -ansi -s -ansi fsck.c -o fsck -H undefined symbol: _S_ISSOCK It would be nice as a hard disk filing system is fairly useless without it. Well, ISSOCK is checking if stat() was done on a socket. Not much use at all until the OS supports sockets :) It'll go in sys/stat.h. Davey
doa.org
Just a quick note to let everyone know that doa.org has returned, so elks.doa.org now works again for CVS and web. Also, the [EMAIL PROTECTED] kernel mailing list is now back online. Davey
Re: doa.org
On Thu, 15 Jul 1999, David Murn wrote: Just a quick note to let everyone know that doa.org has returned, so elks.doa.org now works again for CVS and web. Also, the [EMAIL PROTECTED] kernel mailing list is now back online. The web message is not very friendly though! *shocked amusement* WEB PAGE CONTENT: GO AWAY, Your bugging me. Regards, Jakob Eriksson
Microwindows for Hercules
: I am not realy up to writing the driver myself because I have never writen a : driver before, but I will test it for you. I have 2 8086's with herc cards : in. Well, last night I took Jacob's hercules code samples and wrote a complete hercules graphics driver for MicroWindows and Nano-X. I wrote all the driver entry points, but since I don't have a hercules card, I can't test it. Basically, the hercules card appears to use 32k of graphics ram for 720x350 mono pixels starting at segment b000. Each "screen ram line" corresponds to 4 physical scan lines, and there's one bit per pixel. There's a sequence of OUT instructions to turn the card from text to graphics modes and back, and I use int10 to get the bios rom's character set map. The files mwin/src/drivers/scr_herc.c are the hercules driver and mwin/src/drivers/elksutil.c are some support functions to read/write far data, etc. I'm looking for volunteers to test, I think this baby should run pretty quickly. It will be slow, since I've implemented hline by calling drawpixel. This needs to be sped up by drawing a scan line directly. I didn't want to do that until I knew drawpixel() works. The files are all incorporated in microwindows 0.83, due on my site in about fifteen minutes... Greg
Re: doa.org
On Thu, 15 Jul 1999, Jakob Eriksson wrote: On Thu, 15 Jul 1999, David Murn wrote: Just a quick note to let everyone know that doa.org has returned, so elks.doa.org now works again for CVS and web. The web message is not very friendly though! I know, I stuck a rocket up him yesterday, hopefully that will be fixed today. I've got a feeling he changed machines recently and hasn't setup the virtual host stuff properly yet. Simon? Davey
Microwindows 0.83 released
MicroWindows version 0.83 is released at ftp://microwindows.censoft.com/pub/microwindows This version of MicroWindows is released in tandem with Al Riddoch's ELKS v0.78, which fixes a kernel select() bug with certain mice. The ChangeLog for this version is: Version 0.83 - 14th July 1999 - [EMAIL PROTECTED] * wrote sample untested hercules driver for ELKS * tweaked window repaint code to paint child windows last for ELKS * fixed code for pass-by-structure for bcc/ELKS * added TEST= for select() code in ELKS I'm looking for test volunteers for the new hercules graphics driver. This version runs well with ELKS and the window move problem in ELKS is also fixed. Please send comments and bug reports go [EMAIL PROTECTED] or the ELKS mailing list. Greg
Re: Microwindows for Hercules
On Thu, 15 Jul 1999, Greg Haerr wrote: : I am not really up to writing the driver myself because I have never writen a : driver before, but I will test it for you. I have 2 8086's with herc cards : in. Well, last night I took Jacob's hercules code samples and wrote k :-) a complete hercules graphics driver for MicroWindows and Nano-X. I wrote all the driver entry points, but since I don't have a hercules card, I can't test it. Basically, the hercules card appears to use 32k of graphics ram for 720x350 mono pixels starting at segment b000. Each "screen ram line" corresponds to 4 physical scan lines, and there's one bit per pixel. There's a sequence of OUT instructions to turn the card from text to graphics modes and back, and I use int10 to get the bios rom's character set map. The files mwin/src/drivers/scr_herc.c are the hercules driver and mwin/src/drivers/elksutil.c are some support functions to read/write far data, etc. I'm looking for volunteers to test, I think this baby should run pretty quickly. It will be slow, since I've implemented hline by calling drawpixel. This needs to be sped up by drawing a scan line directly. I didn't want to do that until I knew drawpixel() works. Excellent! I have examples on how to draw fast lines horizontal, vertical and (x1, y1) - (x2, y2) using Bresenham. These are in a book in asm. so I don't know about their copyright but I think they are intended to be used, ie public domain. Bresenham on Hercules is a little tricky. If I don't remember wrong, there are two buffers on a Hercules (2 * 32k mem) so you can even doublebuffer changes. Now that would be cool to work into the driver. If you other people fix it into working order, I can fix double buffering. Jakob
RE: Microwindows for Hercules
: I have examples on how to draw fast lines horizontal, vertical and : (x1, y1) - (x2, y2) using Bresenham. : These are in a book in asm. so I don't know about their copyright but : I think they are intended to be used, ie public domain. : Bresenham on Hercules is a little tricky. No need. MicroWindows handles the Bresenham algorithm in the mid level code in devdraw.c. It uses successive calls to drawpixel to make it work. In this way, people like you and me don't have to rewrite bresenham for every card someone wants The fast line draw that we need is the one that calculates the *bit* starting position in a starting scan line byte, and the end *bit* position. The bits in between the begin and end are then filled with ones. For the bytes inbetween, this is ridculously easy, just set them to 0xff. For the begin and end, use a mask to set those bits... : If I don't remember wrong, there are two buffers on a Hercules (2 * 32k mem) : so you can even doublebuffer changes. Now that would be cool to work into : the driver. : If you other people fix it into working order, I can fix double buffering. Neither nano-X or microwindows require or use double buffering currently, This might be useful when bitblt is implemented though... Greg
Re: Microwindows 0.83 released
On Thu, 15 Jul 1999, Greg Haerr wrote: MicroWindows version 0.83 is released at ftp://microwindows.censoft.com/pub/microwindows Do we need your bcc fixes to make it work? I don't suppose there's any chance of a pre-built disk image, is there? Matthew.
RE: Microwindows 0.83 released
: Do we need your bcc fixes to make it work? No, I haven't published my ansi bcc or cross compilation stuff yet. : : I don't suppose there's any chance of a pre-built disk : image, is there? : Sure - would you like the binaries for microwindows and nano-X? I can't create them until tomorrow, but I could build an images.zip I suppose. Greg
RE: Microwindows 0.83 released
On Thu, 15 Jul 1999, Greg Haerr wrote: : Do we need your bcc fixes to make it work? No, I haven't published my ansi bcc or cross compilation stuff yet. That's kind of what I thought. Cheers. : I don't suppose there's any chance of a pre-built disk : image, is there? Sure - would you like the binaries for microwindows and nano-X? I can't create them until tomorrow, but I could build an images.zip I suppose. That would be cool. Thanks for the great work. Matthew.
RE: Microwindows for Hercules
On Thu, 15 Jul 1999, Greg Haerr wrote: : I have examples on how to draw fast lines horizontal, vertical and : (x1, y1) - (x2, y2) using Bresenham. : These are in a book in asm. so I don't know about their copyright but : I think they are intended to be used, ie public domain. : Bresenham on Hercules is a little tricky. No need. MicroWindows handles the Bresenham algorithm in the mid level code in devdraw.c. It uses successive calls to drawpixel to make it work. In this way, people like you and me don't have to rewrite bresenham for every card someone wants That is fine for normal cards, but since Hercules cards are so ... strange... the algo is very optimized for the Hercules. Example: If using writepixel, there need be 16 writes to videomemory. When using the native HGC linedraw, there need be only 4 writes to videomem. BYTEBYTE 7654321076543210 The benefit increases the more horizontal the line is. Also, the algo. uses an incrementing form of bresenham. Very standard, yes. But the incrementing scheme takes into account the bizarre HGC memory layout. Calculating a byte address and bit offset for a given X, Y is rather costly, whatever way you do it. But when drawing a line you know a lot of stuff already, so you are not solving the problem (X, Y) --- (byte address, bit offset), you are only drawing a line. If someone wants asm code I can write it down from the book. The fast line draw that we need is the one that calculates the *bit* starting position in a starting scan line byte, and the end *bit* position. The bits in between the begin and end are then filled with ones. For the bytes inbetween, this is ridculously easy, just set them to 0xff. For the begin and end, use a mask to set those bits... I am not sure about what you mean here. You mean we need an algo that returns BYTEADDRESS, BITSTART and BITEND? : If I don't remember wrong, there are two buffers on a Hercules (2 * 32k mem) : so you can even doublebuffer changes. Now that would be cool to work into : the driver. : If you other people fix it into working order, I can fix double buffering. Neither nano-X or microwindows require or use double buffering currently, This might be useful when bitblt is implemented though... I was rather thinking of a solution not visible to above layers, but maybe that was not a good idea... :-) (A hack.) Regards, Jakob Eriksson
RE: Microwindows for Hercules
: That is fine for normal cards, but since Hercules cards are so ... strange... The VGA is *far* stranger, believe me, because of it's requiring more than 64k of video memory... : the algo is very optimized for the Hercules. : Example: : : : : : : If using writepixel, there need be 16 writes to videomemory. : When using the native HGC linedraw, there need be only 4 writes to videomem. : : BYTEBYTE : 7654321076543210 : : : : : : The benefit increases the more horizontal the line is. : : Also, the algo. uses an incrementing form of bresenham. Very standard, : yes. But the incrementing scheme takes into account the bizarre : HGC memory layout. : Calculating a byte address and bit offset for a given X, Y is rather : costly, whatever way you do it. : But when drawing a line you know a lot of stuff already, so you are : not solving the problem (X, Y) --- (byte address, bit offset), : you are only drawing a line. Yep, you're right. But currently, very few applications require bresenham, so it's still in the mid level. Far more often is drawing rectangles, which consist mostly of horizontal lines. This is the code that *must* be fast. The bresenham code doesn't have to be fast, since it's rarely called for non-scientic apps (the graphd3d demo code that I've written for microwindows for instance is too large for ELKS...) : The fast line draw that we need is the one that calculates the : *bit* starting position in a starting scan line byte, and the end *bit* position. : The bits in between the begin and end are then filled with ones. For the bytes : inbetween, this is ridculously easy, just set them to 0xff. For the begin and : end, use a mask to set those bits... : : I am not sure about what you mean here. : You mean we need an algo that returns BYTEADDRESS, BITSTART and BITEND? Yes, it's already done in HERC_drawpixel. The HERC_drawhline code will want to precalc each of those for one line, rather than pixel-by-pixel. Take a look at the hercules driver, and you'll see what I mean. : I was rather thinking of a solution not visible to above layers, but : maybe that was not a good idea... :-) : (A hack.) : Nothing wrong with that, except that the low level code for nano-X and microwindows is only interfaced (currently by design) thru a very few entry points: readpixel drawpixel drawhline drawvline fillrect This was purposely designed so that I or someone else could actually write a working driver for a new card in one evening... We can add speed stuff later, once we find people who actually use it and want the improvement. Later, I plan on adding a fast text out primitive for Al's work on scrolling text for ELKS. Greg : Regards, : Jakob Eriksson : :
Re: Microwindows for Hercules
If using writepixel, there need be 16 writes to videomemory.
When using the native HGC linedraw, there need be only 4 writes to videomem.
Also, the algo. uses an incrementing form of bresenham. Very standard,
yes. But the incrementing scheme takes into account the bizarre
HGC memory layout.
Regards,
Jakob Eriksson
Why not take the approach that Linux takes with the module:
Create the driver structure, have the primitives referenced in the
driver structure. If the driver doesn't implement a primitive, set
the structure member to NULL, and the driver loader will take care
to use the builtin function. EG:
struct driver {
ptr_t hline
ptr_t vline
ptr_t bline
...
} DRIVER;
struct driver herc_card[]={
herc_hline,
herc_vline,
NULL
};
That way you can have driver optimized primitives or rely on the default,
which just calls write_pixel.
--Perry
--
Perry Harrington Linux rules all OSes.APSoft ()
email: [EMAIL PROTECTED] Think Blue. /\
Re: Microwindows for Hercules
On Thu, 15 Jul 1999, Perry Harrington wrote:
Why not take the approach that Linux takes with the module:
Create the driver structure, have the primitives referenced in the
driver structure. If the driver doesn't implement a primitive, set
the structure member to NULL, and the driver loader will take care
to use the builtin function. EG:
struct driver {
ptr_t hline
ptr_t vline
ptr_t bline
...
} DRIVER;
struct driver herc_card[]={
herc_hline,
herc_vline,
NULL
};
That way you can have driver optimized primitives or rely on the default,
which just calls write_pixel.
sounds good.
how much would it take to change/add microwin?
Jakob
Re: ELKS 0.0.78 released
The drive light never goes off on my system either, but ELKS 0.77 runs fine. Is your problem that ELKS doesn't work, or with the drive light? Greg Hello to everybody. I've been following the list from June. It's the first time I write. I have high hopes about ELKS because I have an old 286 and I'd like to make it work for maintenance purposes: looking inside routers and so on via serial port, or even getting the mail via slip from the "big brother" linux, in the future. ( Am I asking too much ? ) I have the same problem reported above: I boot my laptop with the "boot" diskette and when I get the "VFS: Inser root floppy and press ENTER" I do it, but my PC hangs. But if I insert the "root" floppy when ELKS is still detecting the hardware, and it finds the right one without asking, it completes the init. Yes, the floppy drive keeps on spinning until I log in and issue a command (sometimes). I got warnings and errors also compiling elkscmd but I suspect that's my fault. Cheerio, Marco. [Hope my english isn't that awful]
Re: Microwindows for Hercules
sounds good.
how much would it take to change/add microwin?
That, I don't know, Greg?
If someone's really going to take that approach (I assumed something
like this was already being done), then I recommend modifying it a
little for speed. Instead of leaving NULL in the table and having to
test it each time the function is being called, replace the NULL with
a function pointer. This can either be done in the device driver
directly:
Obviously it would be smart to fill it in. However you must set it to NULL
in the driver because of symbol resolution.
As long as the device driver header file version matches with the one that
the microwin server uses, the offsets are known.
Locating the symbols inside the driver is the hard part.
Perhaps a separate file, created via an external program, which contains
this structure, is the better way to go. This way when the structure changes,
you don't have to go around recompiling all the drivers that have been
distributed, you just need a program to fixup your jumptable files.
Does anyone know if code exists to hunt for symbols inside a binary? Does
bcc generate any symbol information?
If bcc doesn't generate any symbol info, then I would suggest that each driver
be an archive of object files, with a manifest. You would need the code from
the linker to search the archive and something to read the manifest.
struct driver herc_card[]={
herc_hline,
herc_vline,
generic_line,
};
or it can be done in a function that examines the structure at load
time and patches up any NULLs with real function pointers. This is a
good way to reduce the special cases.
--
"...dans ce pays-ci il est bon de tuer de temps en temps un amiral
pour encourager les autres."
--Voltaire, _Candide_
--Perry
--
Perry Harrington Linux rules all OSes.APSoft ()
email: [EMAIL PROTECTED] Think Blue. /\
RE: Microwindows for Hercules
: Why not take the approach that Linux takes with the module: : : Create the driver structure, have the primitives referenced in the : driver structure. If the driver doesn't implement a primitive, set : the structure member to NULL, and the driver loader will take care : to use the builtin function. EG: : : That way you can have driver optimized primitives or rely on the default, : which just calls write_pixel. : Yes, that's the general idea I was going to use. However, my plan was to add required functionality first, and optimize later. So far, the only driver speed issue identified is that the text output may be too slow. Otherwise, most speed issues are the 8086 itself. The other factor is keeping the code size very small, so that there's room for applications to be linked with the library... Greg
RE: Microwindows for Hercules
:
: If someone's really going to take that approach (I assumed something
: like this was already being done), then I recommend modifying it a
: little for speed. Instead of leaving NULL in the table and having to
: test it each time the function is being called, replace the NULL with
: a function pointer. This can either be done in the device driver
: directly:
:
: struct driver herc_card[]={
: herc_hline,
: herc_vline,
: generic_line,
: };
:
Good idea, Ben. We certainly take that approach now, if the sources
are checked out.
Before everybody gets the idea that this all needs rewriting, please look
at device.h, devdraw.c, and the drivers subdirectory. The current design has
had a lot of thought put into it, and is preparing for the day when bitblt will be
added. For instance, the mid level performs *all* clipping, not the low level. Thus,
the low level can't replace the upper level, because there's no access to the
clipping functions. Certain drivers, namely scr_bogl and scr_bios have commented
out generic functions that will come online in the way above described when
the speed/size tradeoff merits. A close look at devdraw.c will show commented
out functions, like low level bresenham, that will also come to play.
Greg
RE: Microwindows for Hercules
: Obviously it would be smart to fill it in. However you must set it to NULL
: in the driver because of symbol resolution.
:
: As long as the device driver header file version matches with the one that
: the microwin server uses, the offsets are known.
:
: Locating the symbols inside the driver is the hard part.
:
: Perhaps a separate file, created via an external program, which contains
: this structure, is the better way to go. This way when the structure changes,
: you don't have to go around recompiling all the drivers that have been
: distributed, you just need a program to fixup your jumptable files.
Currently this is all overkill, since the drivers are compiled into the
microwin binary. Also, due to inkd of a neat design, we don't have the problems
that require the driver symbol to be NULL.
:
: Does anyone know if code exists to hunt for symbols inside a binary? Does
: bcc generate any symbol information?
Sure, you can run nm86 on .o and a.out files.
:
: If bcc doesn't generate any symbol info, then I would suggest that each driver
: be an archive of object files, with a manifest. You would need the code from
: the linker to search the archive and something to read the manifest.
:
:
: struct driver herc_card[]={
: herc_hline,
: herc_vline,
: generic_line,
: };
:
: or it can be done in a function that examines the structure at load
: time and patches up any NULLs with real function pointers. This is a
: good way to reduce the special cases.
All this would be solved with Al's DLL stuff, which he's working on.
Then we'd having dynamically linked libraries, of which each driver would be one.
Greg
:
