the older versions are faster
: than the newer. The starting is the same but the shell is slower.
: Mods to tty stuff shouldn't give any sort of noticeable difference, or fs
: stuff. There is mention of changes to timer code, but I don't see why any
: stuff like that should make any noticable
: For ELKS it isnt worth it. For real Linux it would be (and in fact it does
: it all with lists)
Although these suggestions about making extendable sleep structs
are laudable, I, for one, agree with Alan. I think ELKS is a great
learning tool, and should function simply. I've found that in
:Hacking. I have a Swedish/Finnish keymap if you're interested. I've
:been meaning to share for a while, but it's on a machine I can't get
:to at the moment. I haven't verified that it works on anything but my
:T1200 though.
FWIW, I'm still looking for technical data on how the T1200
power
: 1) I'm not going to get any code written any time
: soon unless I quit school and quit my job and devote
: all my time to "fun" coding like this.
Well?? Which is it going to be??
Ooops! The correct download url for Microwindows 0.87 is:
ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.87.tar.gz
Regards,
Greg
Microwindows version 0.87 is (finally) released. Source code is available at:
ftp://microwindows.censoft.com/pub/microwindows-0.87.tar.gz
Version 0.87 is fairly stable and seems to work well. It's been a long time
in coming since the 0.86 release at the end of October, 1999. The 0.87
release
: Basically, its simply a binary format handler, which simply processes the
: exe header from a file, and claims that its valid or not. It was more an
: excercise for me learning how to parse exe headers.
Yes. I'm quite familiar with MSDOS EXE format and the current
code doesn't do anything
Al,
I happended to see this bug come across the CVS, and just wanted
to make sure that you've double checked it. This was the exact area that
had to be changed relating to ELK's sys_brk() bug that disallowed
data segments 32k... I can't quite remember the original code.
Regards,
Greg
:
: I think you may be mis-remembering the bug. IIRC the 32K bug was in
sys_brk()
: and was related to the type of the argument being signed instead of
unsigned.
I think you're right. The original bug can be reproduced by having
a small ELKS program that malloc's memory. We should be able
to
: while trying to get KA9Q NOS to run under elks (*) i stumbled accross the
KA9Q NOS... Now there's a neat little [64k..., sorry] package
that might be useable as a user-mode ELKS implmentation
of IP, UDP and TCP. And it supports alot of different cards
as well as serial.
Let me know if you
that might be useable as a user-mode ELKS implmentation
: of IP, UDP and TCP. And it supports alot of different cards
:
: Not directly tho
True. However, it supports the original Packet Driver spec. This
has a pretty well defined interface, and all the drivers run in 16 bit
real mode.
: I have spent considerable effort trying to make sure that the
Microwindows
: system will run on 16 bit systems, and it should continue to do so,
: although currently the application must be bound with the server
: since we lack UNIX sockets. This limits the application size.
:
:
: Could
: If you have any suggestions for this readme send your comments to
: [EMAIL PROTECTED]
: or
: [EMAIL PROTECTED]
:
: --Phillip J Rhoades
Fantastic job! You're definitely hired for a writing position!!
Greg
: So I decided I need to put a README and an INSTALL file with the distribution
: in future releases, but that I am not really qualified to write them.
Al,
Not to disagree with you, but I think that it's important that the actually
useful Real Technical Information (tm) be included in an
: Hi!
:
: I just heard about the elks project;
:
: Does anybody know about an X-Window R11 Server running
: on 16 bit systems ?
: I want to transform my old 286 to an X-terminal.
: Is it possible ?
:
If you want to run a terminal program, we have that running
A hopefully last prerelease to Microwindows 0.87 is available at:
ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.87pre3.tar.gz
This prelease covers most all issues discussed on this list
in the last couple weeks. Following are some major items:
o Directory reorganization
: assert ( "drivers/vgaplan4.c", line=173,
:msg=0x129403 "y2 = 0 y2 psd-yres")
Rosimildo -
The reason that asserts aren't working is because
the vga driver has only been tested on the ELKS system,
which lacks an assert() macro. Thus, the assert()'s have
never been compiled
: Preferably I would like the hex dump to be in the form below, but I am
: flexible on that..
: 00a500:a9f20854c...90
: 00a510:2c51234..ff
If you're going to build a hex format, you should use the well-known
Intel hex format. It's similar to yours, but has a checksum associated
with it. As
On Monday, December 06, 1999 7:28 AM, Scott Dudley wrote:
:
: Has anyone attempted to compile bcc with itself (8086 target)? I did so
but
: attempts to execute the binary on ELKS cause lock-ups. Stumbled across a
psion
: page some time back where author indicated that he had compiled bcc with
On Wednesday, November 24, 1999 6:36 AM, Simon Wood wrote:
: Unless your hardware provides BIOS for driving it like a vga/svga you will
: probably need to write (get some else to write) a display driver
: specifically for it.
No - first we can assume MDA as the lowest common denominator, not
: Personally I would like to see ELKS branch out over many processors (just
: like it's big brother), and hopefully conquer the 16bit world.
Could someone give a paragraph describing the Palm Pilot's CPU/memory architecture?
I thought it was a 32 bit processor, not 16 bit...
Greg
I'm happy to announce that I've just heard that Opera Software has
just ported their fully functional web browser to Microwindows!
They have sent me a screen shot, which I will post. The port
uses the Nano-X API, and runs in client/server mode. Full
color support, palette mapping, jpeg and
A big thanks to Tony Rogvall for writing Microwindows mouse,
screen and keyboard drivers for X11. This means that X11
users can now develop Microwindows applications from within
the X environment, running them as another X Window. Currently
the size of the Microwindows application window is
On Wednesday, November 10, 1999 10:45 AM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]]
wrote:
: ELKS 0.0.81 has been released and is available from:-
Al,
Does the 0.81 release have the /dev/pty's created on the root
and comb images automatically so that the microwindows graphical
terminal
On Wednesday, November 03, 1999 9:12 AM, Scott Dudley [SMTP:[EMAIL PROTECTED]] wrote:
:
: I tried setting up elksemu last night on my Red Hat 6.0 PC to no avail. It's
: running the "canned" 2.2.5-15 kernel. I insmod'ed binfmt_misc and did the echo
: to proc filesystem per the README in the
: No error on echo and I don't have a binfmt.o module, just binfmt_aout.o,
: binfmt_java.o, and binfmt_misc.o. I insmod'ed binfmt_misc.o. elksemu is
: located in /lib. ???
I;ve got it to work on 2.2.6. IIRC I forgot to insmod binfmt_misc.
Make sure you're trying to run a small hello world
Ok, Halloween's over, I tried to scare all the kids with my Jason mask, but I
don't think it worked.
Anyway, I've finished the full documentation on Microwindows's engine, API, and
the Nano-X API.
It's available off the main Microwindows' web site at
http://microwindows.censoft.com/ or
directly
I've finally got down and created a web site for Microwindows, complete with
FAQ.
Thanks to Brad LaRonde for getting me going on this. Anyway, I've got the site
up and running at:
http://microwindows.censoft.com
I am currently writing an architecture document to help explain how the whole
I have finished writing my first draft of extensive internal documentation on
how Microwindows is designed and implemented. I've tried to be very complete
and have covered all the device drivers and engine functions, and completed the
Microwindows API as well. I've got it posted at
On Friday, October 29, 1999 1:39 AM, [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] wrote:
: I'm sorry for having caused this confusion: the correct version of my (7) is:
:
: 7) (this is specific to xdos (dosemu)) the cursor keeps blinking at one
: position on the screen, around (0,19). I can do
On Thursday, October 28, 1999 10:33 PM, Scott Dudley [SMTP:[EMAIL PROTECTED]] wrote:
:
: I was unable to build Dev86 on Red Hat 6.0 and saw reference to same in the
: ELKS FAQ. Good news! If you install the following RPM's, you can set
: CC=i386-glibc20-linux-gcc and all is well.
:
:
I have posted an update v0.86 to Microwindows/nano-X at
ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.86.tar.gz
This version completes a major effort, that of implementing off-screen
drawing,
as well as screen-to-screen blitting. The screen driver interface had to
change
to
5) I compiled elvis and it does run. well, this is a bit of an
exaggeration:
undo doesn't work and sometimes I have to kill the process from my root
session. after this, I get no more echo to the console where I was
running
elvis. I can do exit and login again.
elvis is stalled mid
I have checked through this, and added the full Linux features to kill(2),
and the call to getpgid(3) in killpg(3) is not necessary, as calling
kill(0, SIGNAL) automatically kill the current processes pgrp.
Any thoughts on where the best place to put this is?
Well, this stuff is supposed
: Excellent! So, how are we getting on on the stability front? Can you actually
: do anything with it yet? When do you reckon 1.0's coming out?
I'm happy to report that my girlfriend's son (8 years old) came over and played
landmine on ELKS (the only spare computer I wasn't using) for quite
Al,
Good to hear you've got another version of ELKS coming. I've
completed the first round of getting an actual graphical scrolling terminal
emulator running under ELKS. It's done. Except that the code to open
the /dev/ptypX and /dev/ttypX fails. My version of ELKS (0.77)
doesn't have
: Also, on another note, in catching signals in Linux from the terminal
: emulator, I attempt to send them to the process group with killpg().
: This routine under ELKS causes an undefined symbol getgpid() when
: linking. It appears there's an error in linux-8086 libc.
:
: That should be
: Ah. I have a problem building Dev86 where ar is crashing, and was
: going to wait until I had more info (e.g. ar seems to be working
: until the build gets to a certain point, then refuses to work with
: the archive any more). How can I find out more about the problem
: with ar that Greg
Now that I've got a palm PC booting Linux, I've had
a chance to understand alot more about
what's happening with the hardware/software on
these devices. I think the first step for the
graphics engine, MicroWindows, is twofold:
support for the win32 platform needs to be
based around the
I'm no expert here, but following are my $.02:
: What sort of features are required for this type of system? It seems to me
: that a filesystem is not all that important with no storage. Are device
: drivers, interrupt handling and memory management the types of features
: required?
OK,
Thank you everyone for the licensing input, I learned alot. Sitting
in frustration at home last night, I finally wrote a little program that reads
the framebuffer and generates bitmap files. So, I ran through all the cool
demos that I've got going, and we now have screenshot gif
: Speaking of projects .. I have few questions regarding 0.84 release of
: mwin.
:
: 1: nano-x won't compile here with -O switch. It has to be some sort of
: copt error (it does compile actually but doesn't assemble/link). This
: can be solved by calling bcc without -O for nanox/srvfunc.c to be
On Tuesday, October 05, 1999 12:50 PM, Alex Holden [SMTP:[EMAIL PROTECTED]] wrote:
: On Tue, 5 Oct 1999, Alan Cox wrote:
: This is going on far too long and round in circles. Greg and Alex - pick
: something, stick a license on it all , say so publically and be done. It
: does more harm now
* wrote asm version of VGA driver for ELKS
:
: How much faster is this thing? Useable?
It's definitely faster, and it works. I use it for the ELKS port,
which runs on _slow_ systems.
Greg
: As this is an exe file, a windows based disassembler may be the best way to
: work on it. If you would rather work on it under Linux, try ndisasm which
: comes as part of the NASM package. It is a very powerful disassembler, but
: some knowledge of the format of the file you are trying to
: However, it does appear to kill the static model, but ONLY FOR NON-FREE
: ROGRAMS. Free programs could still use the static model just fine, and
: non-free programs could still use the client/server model, since the client
: side is LGPL.
:
Well, we could always have LGPL for static
: Can you say what it is in *GPL that would make it unworkable for Screen
: Media?
:
:: This is an idea, but why? Doesn't MPL completely kill any GPL benefit? Why
: would someone choose to use it under GPL when they can use it under MPL?
:
I think it's clear that we can't go with just
Al,
I've completed the runtime dynamic linking loader
produced by the 8086-based bcc, as86 and ld86 tools. This code
allows the relocatable images produced by as86 to be
loaded as shared libraries if desired. All export and import
symbols are matched, and offsets relocated. Currently,
On Monday, October 04, 1999 4:51 PM, Vidar Hokstad [SMTP:[EMAIL PROTECTED]] wrote:
: the near future I and another developer will be working
: nearly full time on it, and we also sponsor another company to port a major
: software product to NanoGUI.
:
: This is code that we contribute back.
On Monday, October 04, 1999 4:55 PM, Louis P. Santillan [SMTP:[EMAIL PROTECTED]]
wrote:
: Maybe those who have evil
: commercial purposes should be punished, but they should not be completely
: prejudiced against. I think the intent is to make the Nano/Micro series
: a standard for small
Let me try to summarize what we need in a graphics system license:
1. We _must_ have:
a. The ability to have private, proprietary drivers to be used (NDA's,
and other commercial non-control issues)
b. The ability to work with, communicate with, and be
On Tuesday, September 28, 1999 6:25 PM, Gregory Leblanc
[SMTP:[EMAIL PROTECTED]] wrote:
: Just thought I'd see if there was anybody here, since I'm brand new to this.
: I'm hoping to get ELKS on my Toshiba T1200 notebook (8086-10, 640K ram, dual
: 720K floppies) and use it as a serial console
: That part of the process is now problem. The difficulty comes in writing a
: driver which can talk to both cards at the same time.
:
what about using what someone suggested just changing
0xB800 to 0xB000 on the switch and leaving it at that, using exactly the same
driver?
Greg
: Is it as simple as having a VGA card and a herc, and just writing to them
: both separatly? I would have thought there would be problems with
: initialising the hardware, and detecting which was present.
I think it's this easy. the bios in some location states whether
there are one
: We need to turn off the T1200 auto-power-off mechanism, but I don't have
: a HW manual for the unit.
:
: Greg
:
: I have the original manuals that came with it here, if anybody wants
: anything from them.
Find the hardware I/O port to disable auto-power off.
On Wednesday, September 29, 1999 3:25 PM, Thomas Stewart
[SMTP:[EMAIL PROTECTED]] wrote:
: hi
:
: I've got one of those T1200's, prity old, now if I remember right, when I
: got it it had a, (deep breath) ms-dos programm that changed the settings
: that one would usually change in the bois.
: Or is there a better way to use the two cards together? DOS does not do this
: very well (appart from a few utills that switch the screen, and a few apps
: that support it (tcc).)
:
: There is no current support for this in the ELKS code, but it does appeal
: to me. Any idea how it can
On Monday, September 27, 1999 7:40 PM, Michael G Hughes [SMTP:[EMAIL PROTECTED]]
wrote:
: Currently, the biggest
: problem with shared libraries on 8086 and bcc is that the compiler can't
: produce position-independent code (ala -fPIC) so that even the code segment
: requires data relocations,
On Tuesday, September 28, 1999 11:56 AM, Alan Cox [SMTP:[EMAIL PROTECTED]]
wrote:
: : for task switching), can bcc handle that? Or create something like an
: : indirect jump and glue code in the library.
:
: The indirect jump and glue code is exactly what is needed out of bcc.
:
On Tuesday, September 28, 1999 12:26 PM, Alan Cox [SMTP:[EMAIL PROTECTED]]
wrote:
: As I mentioned before, if this were performed with code segments
: only, then they could still be shared with the resulting memory decrease benefit.
:
: But is outweighed by the cost of no swapping or
On Sunday, September 26, 1999 1:02 AM, Paul Khoury [SMTP:[EMAIL PROTECTED]] wrote:
: I haven't really kept up too much on the list, just still recieveing mail for my
: archive. I've seen some posts regarding microwin - is this sorta like a GUI for
:ELKS?
Yes, microwin runs both a Win32
: I am very interested by the
: possibility of loading .o files as modules, both into the kernel and into
: user applications. As a means of loading drivers in nanoGUI and microwin
: this sounds great.
I have very nearly completed the .o loader this weekend. It reads
in any number of .o
: Errm, what's "Introl object file format"? You mean "Intel"? Well as86/ld86
: don't understand that. They use their very own format for *.o files.
The Introl object file format is a format from an older
hardware development system, named Introl. The name is documented
in Bruce Evan's
: 1. I have finished the optimised HERC_drawhline and . it works, its a
: mirical!
Great!
:
: 2. On a 386 16Mhz it takes 60 seconds to load on the original microwin on
: the same pc with the optimized hercwin it takes 20 seconds. Both these times
: include the reading the disk
Al,
I've been doing some serious research in the area of
shared libraries and dynamically linked code/data segments.
About a week ago I presented an idea for MicroWindows/NanoGui
applications that would allow "applications" to be written for
these graphical systems that could be linked
: I have frequently experienced very bizare behavoir whenever the commandline
: for a program gets very long, including hung processes, a hung system, and
: some really messy crashes. I think this is the problem you are having with
: wildcards. Somewhere the length of the commandline is not being
On Thursday, September 16, 1999 2:45 PM, Louis P. Santillan
[SMTP:[EMAIL PROTECTED]] wrote:
: I thought the Z80s were near 8088s or 188s...am I on Dr Pepper again???
:
You've been drinking *way* too much Dr Pepper.
8bitprocessors: 8080 - 8085 - z80
16bitprocessors: 8088
: Bjorn Eriksson's code
: void vert_line(US x1, US x2, US y, const BYTE color)
:
: This confuses me, why does a vert_line func have 2 "x" vals??? Or is a
: general typo, wouldnt that be a horizontal line, like you say??
:
As discussed last week on this list, vert_line is mislabeled,
: 2. How do I write to bytes to memory correctly. The origanal drawpixel uses
: a pixel value c as well as the x and y cords. And therefor the hline uses
: this c as well.
:
: It does:-
: if(c)
: ORBYTE_FP(dst, mask);
: else ANDBYTE_FP(dst, ~mask);
:
: What is the pixelvaue
Gang,
I've been studying a truly interesting piece of code lately, cross-elf v-0.2,
which allows linux, windows and dos programs to load 32 bit ELF code sections
compiled on linux and run them on other platforms. This is realized through
cross-elf implementing an ELF relocatable loader,
On Wednesday, September 08, 1999 5:01 PM, Henrik Sorensen
[SMTP:[EMAIL PROTECTED]] wrote:
: Hello
:
: I got past the FILE *in =sdtin; problem as a result from the input from
this list.
:
: I've gotten a bit further. When compiling elksemu/elks_sys.c
: I get an error in line 557 (and 580?)
: 2. To verify one important thing, cord 0,0 = top left and 720,348 = bottem
: right. Is the CORRECRT???
:
yep
: 5. This is my understanding of the prob, correct me if I have go compleatly
: wrong, or have gotten the wrong idea. So at the moment a draw pixel function
: is called
: There's another advantage with this means of conversion that I forgot
: to mention. By using macros to retain compatibility with as86, it's
: easy to do regression tests to ensure the semantics of the code have not
: changed. As I convert the code to use my macros, I periodically run this
:
snip
: extern int sys_open __P ((char *filename, int flags, int mode));
:
:
: Then the ELKS kernel can be compiled with either GCC or bcc. There
: is *no need* for bcc to use the "-ansi" switch; it will just slow
: things down. And GCC can be used as a form of "lint" by enabling
: various
: Yes, your are correct. The body of the function should still be coded
: in KR style. But ansi headers can be used with the `features.h'
: technique.
:
: Certain ansi compilers revert to older KR style parm checking
: (read: none) when the KR decl style is used, even if the fwd
: decl is
: About "Dev86src-0.14.9.tar.gz" (or what else release) I reach to
: recompile application with a Linux kernel 2.0.x but not with 2.2.x once.
:
Some newer distributions core dump when running /usr/bin/ar with
Dev86-0-14.9. I have rewritten a new /usr/bin/ar that will work for these
in compiling any of those for elks? Lets see.what
: else...
:
: Greg Haerr has been working on getting bcc working under elks, and I
: think he made some progress a while back once the kernel memory allocation
: code was fixed. bash and tcsh and both far too large to build under elks
: 2). PS requires '/proc', but I can't see any code where this 'created'.
ps doesn't require /proc. Are you using the one from elkscmds?
Also, I added the display of program arguments from ps, but I can't remember
if I ever checked it in... In any case, ps just reads /dev/kmem for
: 1). Reduced character size to 8x8 to increase screen size and save
: memory
: (the font is held in Data segment)
:
: Can you not find the Psion font in rom ? Also you could push the font into
: its own segment and 'borrow' ES momentarily with a cli around a single
: char
: render.
:
On Monday, August 16, 1999 5:47 AM, Simon Wood [SMTP:[EMAIL PROTECTED]] wrote:
: Ok my beef (well it was only supposed to be a comment - I'm not steaming at
: the ears) was that the elkcmd package should really be transportable across
: all platforms. (I acknowledge that is basically PC at
: Can't we (you) mark in the process table if the process needs its F-registers saved?
:
On boot, determine if mathco present. If so, all process switches
save/restore the F regs.
gh
On Thursday, July 29, 1999 11:16 AM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
: On Thu, 29 Jul 1999, Perry Harrington wrote:
:
: I brought up a thread a long time ago on this, Borland wasn't interested
: then, but they just released Turbo C for free.
:
: Source, or just free binaries? If
On Thursday, July 29, 1999 12:47 PM, Matt [SMTP:[EMAIL PROTECTED]] wrote:
: I have an old 286 that's just collecting dust, but if I could use ELKS and
: minicom then I'd have a nice little terminal. Can ELKS run minicom? It
: says it has serial IO support.
:
: Matt
:
What's minicom?
: The Problem is that the Tarball has no filename information in it, so
: all the contents just spit put into one large file that I can't use.
:
Sounds like something a typical Apple ][ hacker would do... ;-)
Tell me where it is, I'd like to see this.
gh
: I don't think ELKS has floating point support yet, Alistair would be the best
: person to ask this question to, I think.
:
ELKS doesn't yet support floating point. The bcc compiler libraries have
support for 32 bit floating point though. All ELKS float support will have
to come from
: This is essentially what I have done. The only problem with doing this is
: that when fork() returns to the child, and the child calls exec(), the stack
: will be modified, so when the parent comes to return from fork(), it will
: crash, or at best do something odd.
Ok. When vfork()
:
: : The scheme I am using at the moment, that of copying the bottom 100 bytes
: : of the stack for the child to use, works, but does not really offer any
: : kind of safety net. Is it fair to just accept that if a process vfork()s,
: : and does not exec or exit, but instead carries on, it
On Tuesday, July 20, 1999 2:39 AM, Thomas Stewart [SMTP:[EMAIL PROTECTED]]
wrote:
: I fired up my old beast last night, a v20 640k with a herc card, I ran my
: compiled copy of microwin with herc support, and it worked!
:
: WELL done to greg and whoever helped write that driver!
:
Al,
I just noticed you're cleaning up a bunch of fs code in ELKS.
I have been reviewing the original linux sources, and I think I've noticed an
error in the #ifdef BLOAT_FS stuff in ELKS.
The problem is in elks/fs/buffer.c, 22 lines into the function getblk().
There is a comment
On Sunday, July 18, 1999 4:21 AM, Thomas Stewart [SMTP:[EMAIL PROTECTED]]
wrote:
: How do you enable herc support in microwin? Greg?
:
Find the makefile lines that have scr_bios.o and scr_herc.o in them;
comment out the first one and uncomment the second...
Greg
: The code in devdraw.c is very naiive. It assumes pixel plotting is the underlyin
: op. On many cards line slices are the underlying operation, horizontal or
: vertical. What you probably want to do is generate a series of
:
: draw_horizontal(x,y,l)
:
: or
: draw_vertical(x,y,l)
:
:
:
: I tried to make a 0.0.78 kernel than and got this error:
:
: make[2]: Leaving directory `/usr/local/src/elks/arch/i86/drivers/block'
: bcc -D__KERNEL__ -O -i \
: 2 -nostdinc -Iinclude -c -o boot/crt1.o boot/crt1.c
: boot/crt1.c:5.25: error: cannot find include file arch/segment.h
On Sunday, July 18, 1999 1:13 PM, Thomas Stewart [SMTP:[EMAIL PROTECTED]]
wrote:
: I have got a mouse to work in mirowin at last! dont know if it was me or
: what, I could not for the life of me get any mouse to work. So in dispare I
: tryed my 10 year old genus mouse in 3-button mode in "pc"
: I got things a bit messed up in this release because I did things in the
: wrong order. The etc/issue file is automatically generated from the elks
: Makefile, but I had not updated it when I built the release. Releasing
: elkscmd and elks at the same time is becoming more work than is easy to
: the listing will show two "aa"s!!! Then the fresh
: "aa" will be recognized for the following 'cp', 'mv',
: or 'ln', but is tarnished by that operation again.. I have
: reason to believe the "No such file or directory" is returned by
: namei() which is called in
: The place where nano-X and microwindows spend at *least* 95% of their
: pixel-pushing code is in drawing horizontal lines. All the demos but one
: *never* draw a diagonal line, the only case where bresenham is used. I had
: completed test cases to prove this...
:
: OK, granted.
: 3) The rest of the space is divided up into zones, each containing a maximum of
: 65536 blocks.
:
: 4) The first 8K of each zone is a bitmap of free blocks in the zone, 1 for
: used, 0 for free.
:
: 5) The rest of the zone is used for storing inodes/files.
:
This is basically the
: Actually, I have only studied the extent file systems, which are good for some
: things (like performace on really big files and smaller files). For small
: systems, these are not really suitable because they require too much caching,
: esp for really small files. Under an OS like elks, this
A good idea, almost. The BOGL library performs this for the packed pixel
:modes, but the VGA requires OUT instructions inbetween memory accesses,
:so it can't run on a generalized bit-depth algorithm in planes mode. (The VGA
:design has to be seen/studied to be believed,
: 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
1 - 100 of 184 matches
Mail list logo
