Re: ELKS 0.0.81 slower than the 0.0.76
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 difference. What do you mean, "the shell is slower"? You mean the tty output is slower? The prompt is displayed after some delay when no input is typed? Or applications are read from disk and are slower to start?
Re: A question
: 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 many cases even ELKS code is too complicated. Alan has pointed this out with the #ifdef madness and other very little used options. The ELKS project should function as simple as possible, IMHO; various extended features (which few use) can then be easily added on a personal basis. I doubt that ELKS has ever run more than 15 processes, for instance. Regards, Greg
RE: Toshiba T1x00
: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 manangement gets disabled. I tried booting ELKS on my trusty old T1200 and it worked until the "power manangement" kicked in - and turned off the power! Greg
Re: microchannel for ELKS update
: 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??
Corrected download address for Microwindows
Ooops! The correct download url for Microwindows 0.87 is: ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.87.tar.gz Regards, Greg
Microwindows 0.87 released
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 now runs on Linux framebuffer, Linux SVGAlib, X11, Solaris, RTEMS, ELKS, MSDOS 32 bit with DJGPP, and MSDOS 16 bit with MSC and PACIFIC C (free). The X11 screen driver supports emulating a target screen driver in 1, 2, 4, 8, 16, 24, and 32bpp, without having to cross-compile and run the application on the target device. The framebuffer screen drivers have been tested well, and now offer support for 1 through 32 bits per pixel, as well as high speed (software) blitting, and alpha blending. 1 though 8 bpp palettized modes, as well as 16, 24 and 32bpp truecolor modes are supported. The framebuffer drivers have been tuned for speed, although more enhancements are planned. The new make system is completed, and a config file now controls all options for specifying target architecture and features options. Cross- compilation support for x86, MIPS, ARM Linux, Solaris, ELKS, DJGPP and RTEMS is included. All demos and libraries are built at once, so it's much easier to link Microwindows when developing an application. A C++ object frameworks has been added. Support for displaying JPEG and BMP file types has been added. Thanks to everyone for the contributions - it was getting overwhelming for a bit there, but almost all contributions have been added to this release. I will now start work on getting the tree into CVS, as well as merging contributions for Truetype font support, as well as some cleanups with the screen device structure for speed. In addition, as a result of the press we've been getting, a number of folks are interested getting Microwindows running with their hardware and software. Following is the detailed ChangeLog: Version 0.87 - 13th February 2000 - [EMAIL PROTECTED] * added VTSWITCH in config to include virtual terminal switch code * added support for 24bpp, wrote 24bpp fb driver * fixed 8/8/8 color macros: RGB2PIXEL888, COLOR2PIXEL888, PIXEL888RED * fixed 32bpp fb bug with psd-ncolors, 32bpp alpha blit bugs * added fb driver support for FB_VISUAL_DIRECTCOLOR cards (ATI) * sped up 16, 32bpp blitters by using memcpy * added large font patches from Kyle * added PACIFIC C compiler support from Victor * default UPDATEREGIONS=N in config file for alpha blend demo * removed XORMOVE from config, requires only ERASEMOVE=N * wrote alpha blending demo (requires UPDATEREGIONS=N) * rewrote void *pixels in devdraw.c, won't compile on ansi compilers * fixed PF_TRUECOLOR0888 bug in GdArea * added DJGPP as config ARCH option, Victor's patches for DJGPP * finalized alpha blending blit routines for 8, 16, and 32bpp * added SetTimer/KillTimer api (single timer only) * added Chris' SetSysColor api, C++ object frameworks patch to mwin/ * added Rosimildo's make patches for RTEMS * added Martin's make/configure patches Greg
Re: Dos Binary Compatibility WAS Re: elksfs status
: 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 near what's required. And even if it did, there's the problem of having linking with a Linux8086 libc but producing .exe files... Greg
Fw: cvs commit: elks/arch/i86/kernel process.c
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
: +/*
: + * We only need to do this as long as we support old format binaries
: + * that grow stack and heap towards each other
: + */
:void stack_check()
:{
:register __ptask currentp = current;
: - if (currentp-t_regs.sp currentp-t_endbrk)
: - {
: + if ((currentp-t_begstack currentp-t_enddata)
: + (currentp-t_regs.sp currentp-t_endbrk)) {
:printk("STACK (%d) ENTERED BSS (%ld) - PROCESS TERMINATING\n",
currentp-t_regs.sp, currentp-t_endbrk);
:do_exit(SIGSEGV);
:}
:
:
:
RE: Fw: cvs commit: elks/arch/i86/kernel process.c
: 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 malloc almost 64k. The previous version would fail whenever
the DS offset 32k.
Greg
:
: Thanks for keeping a look out. I am glad someone reads the cvs commit
messages.
:
: Al
:
: int sys_brk(len)
: __pptr len;
: {
: register __ptask currentp = current;
:
: if (len currentp-t_enddata ||
: (len (currentp-t_endseg - HEAP_LIMIT))) {
: return -ENOMEM;
: }
:
: currentp-t_endbrk = len;
: return 0;
: }
:
:
:
: Regards,
:
: Greg
:
: : +/*
: : + * We only need to do this as long as we support old format
binaries
: : + * that grow stack and heap towards each other
: : + */
: :void stack_check()
: :{
: :register __ptask currentp = current;
: : - if (currentp-t_regs.sp currentp-t_endbrk)
: : - {
: : + if ((currentp-t_begstack currentp-t_enddata)
: : + (currentp-t_regs.sp currentp-t_endbrk)) {
: :printk("STACK (%d) ENTERED BSS (%ld) - PROCESS TERMINATING\n",
: currentp-t_regs.sp, currentp-t_endbrk);
: :do_exit(SIGSEGV);
: :}
: :
: :
: :
KA9Q
: 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 need some help. Regards, Greg
RE: KA9Q
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. There are source drivers available for almost every original card, most as antiquated as the systems ELKS is running on... : KA9Q net was the earlier package, it ran on CP/M once so may fit The KA9Q package is modular, and many items can be dropped initially, in order to make it fit. Perhaps even just IP and ICMP on top of SLIP first, and try to get ELKS to respond to a ping! ;-) Greg
RE: Lots of questions from someone.
: 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 you please explain what you mean by the above statement? (bound?...UNIX sockets?) Thank you. In the current implementation, we allow Nano-X clients (otherwise known as graphics applications) to run as separate, normal UNIX/ELKS programs. They perform a network connection to another program, known as the graphics server (X server, Nano-X server, etc). When the connection is on a local machine, a fast limited form known as UNIX sockets can be used for the network connection. If the operating system doesn't support networking (like ELKS), then we also allow the graphics application to be linked with the server directly, and execute a single program. Regards, Greg
RE: Call for a README
: 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
Re: Call for a README file
: 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 INSTALL. This information should state exactly what a user should do to get from images.zip to a running ELKS installation. Brief technical descriptions of what root, comb etc are are necessary, IMHO, and you're the perfect person to write that. Having said that, then, someone less technical might massage the message to help users less technical... My $.02 Greg
RE: X-Server
: 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 with ELKS' graphical applications development system, known as Microwindows. It's fairly easy to write new graphics applications, but of course we've got the 128k code/data limitations... If, OTOH, you're looking to run unmodifed X applications on 286's in real mode, I would say that, unless you've got a lot of time on your hands, it's not available. Greg
Microwindows 0.87pre3 released
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 started. The microwindows and nanox specific source code, as well as the common engine routines are now in their own directories. Include files are placed in a common directory, etc. Although the source file rearrangement is nearly complete, I still haven't added Martin's new Makefile system (that will be coming, next cut). Thus, there still aren't separate bin and lib directories, but the source organization should make learning easier. o GrArea() modified to allow different types of pixel data to be displayed. Most of this is discussed in previous email lists. It all works and should be enough for Morten to use as a base for his work. This involved quite a bit of work, but is worth it since Nano-X now supports drawing in device dependent and device-independent manners. o Quite a few bug fixes, including the Nano-X 64k request packet fix, the GrMoveWindow fix for Nano-X allowing windows to be moved and clipped properly, fixing portrait mode in Microwindows offscreen blitting, and the assert() fix that caused Microwindows to exit sometimes. For the next cut I plan on adding Martin's make system, which allows for much better configurability, as well as all demos and libraries to be made at once. In addition, I'm probably going to take a swipe at creating a window manager base for Nano-X, so that it's windows can look as cool as Microwindows API, if desired. (No, this won't add much code) Let me know if there are any issues found, I want to make sure that 0.87 is a bug-free as 0.86 is. Following is the detailed ChangeLog: Version 0.87pre3 - 19th December 1999 - [EMAIL PROTECTED] * started directory reorganization * changed LINUX meaning in Makefile, added UNIX for SOLARIS * fix negative blit index bug found under X11 by Piotr * set rootwp-parent = NULL for nano-X, fixes GrMoveWindow clip bug * added COLORVAL-PIXELVAL conversion macros * modified GrArea to take packed pixel values of 8, 16 and 24 bits * modified GrArea to take RGB COLORVALs as well as PIXELVALs * renamed PF_TRUECOLOR24 to PF_TRUECOLOR888 * added tunable MAXREQUESTSZ to limit max request length * modified Nano-X demo.c to GrArea() 64k pixelvals for testing * fix client/server 64k length bug (request can be 24 bits in length) * fixed portrait mode in CreateCompatibleBitmap Regards, Greg
why asserts are failing
: 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 in ;-) I've never been able to get my system running vga16 framebuffer, so I can't test the damn driver without running ELKS. Greg
RE: a.out - memory hex dump??
: 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 well, many tools support this format. It's described at: http://www.wotsit.org/cgi-bin/search.cgi?binary Look for HEX or Intel HEX on that page. Regards, Greg
RE: self-compile bcc?
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 an : 8086 compiler and it worked(?). I've been working on this and have bcc, as86, ld86 and ar86 running cross-compiled. But there's a bunch of memory limitation problems. bcc needs to be compiled with a special model, which I forget. It also has some built-in asm language stuff that needs hacking out. Would very much like to have a native : development environment on ELKS to avoid sneaker net. I fully support that idea. I've also got versions of libc-8086 and the minix libraries cross compiled, but the libc.a is too large for the ELKS file system, since ELKS has a filesystem implementation problem for any file 512k Greg
RE: Some q's - Driving LCD Display within ELKS.
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 VGA. Currently, the most-used ELKS console drivers assumes a memory- mapped text screen at B800 or B000 (this is read from the BIOS at startup). There is, however, a BIOS console (which needs updating) that uses BIOS calls for character display. We could very easily enhance this BIOS console driver even to the point that the VT100 escape sequences emitted by the upper level console driver (that I rewrote to run a cooler vi) would work. In order to do this, we need the following low level calls (all provided by the BIOS, but could also be provided by a programmer for ELKS on non-BIOS systems:) o move cursor o put character o put character and attribute o scroll screen o clear screen (if none, for loop putting spaces) : : For the Psion stuff the screen is just memory mapped and I wrote a simple : driver to render text (all 8bit wide) directly onto it. This unfortunately : requires a font to be held somewhere in the memory (in the kernel code : segment for the psion though I'm thinking of moving this). Ideally, the Psion specific stuff could just have the above entry points and run under the standard console driver. In fact, it may be that way already. Thus, the Psion console port is just an implemention of the above interface only, not another console driver. : : I was thinking that it would be better to abstract a little from this and : try and get a 'framebuffer' style interface going. This would help : development on various platforms that don't have a vga/svga plug in card. Certain previous discussions on nanogui suggested strongly that the kernel not take on responsibility for any graphics operations. The only system call that Microwindows makes, for instance, is two ioctl()'s to tell ELKS that the VC is going into/out of graphics mode, but Microwindows handles the graphics mode conversions. ELKS on receiveing the ioctl's just prohibits a VT switch, since there aren't any mechanisms to tell Microwindows to redraw the window on switch yet, and not much memory. : Presumably all our frame buffer would need to do is simple text (console 8*8 : ??) and dots lines (micro-windows). The problem with the framebuffer abstraction is that all that it really provides is an mmap()'d linear address for the physical video memory. Mmap() is not supported and never will be under ELKS, so really all you'd get from this would be that ELKS would return the address of the physical display, and all the graphics drivers would still have to be present in MIcrowindows, just like they are now for regular Linux and X11. Greg
RE: Palm Pilot ELKS.
: 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
Web browser ported to Microwindows
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 gif image and font support is working, as well as transparent images. It actually works! I will be rearchitecting the client/server networking code shortly, as the browser is running a bit slower than it should. I'm sure this is because of the extreme handshaking occuring for each parameter, which causes excessive context switches for any i/o. The total size of the browser codefile is 667k, much, much smaller than most web browsers. This means that it's possible that Opera could port the software to any of the newer palmtop or LinuxCE [MIPS, StrongARM or SH3] devices for browser access, since Microwindows now runs on these processors. For more information on Opera Software, see www.opera.com. Greg
Microwindows runs on X11
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 compile-time fixed, but it might be nice to allow it to be dynamically sized. Also big thanks to Martin Jolicoeur for contributing Makefile and build enhancements including a ./configure program and graphical make xconfig, as well as changes for StrongARM cross-compilation. I will be including these additions in the next cut, as well as getting a CVS repository up. Thanks for the contributions, this project seems to be gaining momentum... Greg
RE: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
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 emulator will run? Greg
RE: elksemu and Red Hat 6.0
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 source tree. When I try to run an : elks binary, I get the error: cannot execute binary file. : : What have I missed? Make sure that the "echo" doesn't return an error when executed. You might need to "insmod binfmt" before it will work. Also make sure that the /lib/elksemu or /usr/lib/elksemu (see source, I forget) is installed. Greg
RE: elksemu and Red Hat 6.0
: 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 executable, and test it with the file command. Also, remake the elksemu and personally check that it's copied to /lib. Look at the source, it's pretty basic. You may even overwrite the elksemu with a usermode echo program to make sure that it's even getting executed. Greg
Nano-X now documented
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 at http://microwindows.censoft.com/microwindows_architecture.html Have fun and let me know anything else that needs to be added. Greg
Microwindows now has a web site
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 thing is designed and implemented, to be used for general knowledge, as well as porting purposes. Give it a look and please send me any comments, good or bad! I'm also especially interested in links to other projects that people may find interesting. Greg
Microwindows architecture explained
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 http://microwindows.censoft.com/microwindows_architecture.html It is halloween over here, and it's getting late, so I don't have the Nano-X stuff documented, but I intend on having that completely documented as well. Take a look, hopefully this will help everyone using or porting Microwindows. Greg
RE: some problems with ELKS 079
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 whatever I want, everything : works but the cursor stays there. [the console version of dosemu does better]. : this problem is not present if I boot MSDOS. : : the first parenthesized sentence was included in the original message, but it : was not clearly linked to problem (7). : : so: ELKS does quite good under the PPC640, this problem comest to light if I : test it (ELKS) under the X version of dosemu (xdos). Perhaps you're running the gpm mouse driver, for X in another virtual console. Kill gpm by typing "gpm -k". It will run a text mode cursor in text mode, and a graphics one in graphics mode. gh
RE: Compiling Dev86 on Red Hat 6.0
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. : : compat-binutils-5.2-2.9.1.0.23.1.i386.rpm : compat-egcs-5.2-1.0.3a.1.i386.rpm : compat-egcs-c++-5.2-1.0.3a.1.i386.rpm : compat-glibc-5.2-2.0.7.1.i386.rpm : compat-libs-5.2-1.i386.rpm It's my understanding that the only problem with compiling Dev86 with the newer libc6 is that the /usr/bin/ar program core dumps and that the FILE * = stdin; statement in one of the directories break. Is that what you've found? Rob has replaced the /usr/bin/ar with my ar86 in the latest dev86, I'm not sure about the FILE * bug. We shouldn't have to install all sorts of rpm's to get the dev86 package running. Greg
Microwindows v0.86
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 accomodate this, and I had to rewrite all the screen drivers. In addition, the blitting routines were written for 1, 2, 4, 8, 16 and 32bpp linear framebuffer devices, as well as the 16 color 4 planes vga (this was a royal pain...) The blitting uses a clipping region traversal algorithm so that blitting is always high speed, even when the destination window is partly obscured. This release also auto-detects most Linux framebuffer implementations, and should have a compiled in driver for it. In addition I have posted Linux, ELKS and MSDOS binaries, as well as screenshots for those that don't have the time: ftp://microwindows.censoft.com/pub/microwindows/SreenShots ftp://microwindows.censoft.com/pub/microwindows/LinuxExamples ftp://microwindows.censoft.com/pub/microwindows/ElksExamples ftp://microwindows.censoft.com/pub/microwindows/DosExamples The standard Microwindows demo is now a graphical terminal emulator, mterm. (No, it doesn't run vi yet, and it doesn't repaint it's screen contents, but it will ;-) This demo requires screen-to-screen blitting for scrolling. The 3d graphics demo now uses offscreen blitting to enhance (read no flicker) the display. Check it out. There is also some experimental full-blown region handling code included, which uses X11's y-x banding region algorithms. (This stuff is truly for those with extra time and brains). It is currently not compiled in, but can be included by replacing devclip.c with devclip2.c. In the next release, arbitrary multi-rectangle clipping regions will be available. I also plan on implementing separate clip regions from update regions for windows, with the system computing the update region as a subset of the clip region. Anyway, this sophisticated region handling is required for smart window painting as well as higher end graphics primitives. Eventually, this will also allow separate source and destination clipping for bitblit operations. Only destination clipping is working now. The next release will have a reorganized directory structure, allowing separate development of nano-X, widgets, core engine, and microwindows. I plan on moving the whole thing to a CVS soon. BTW, Microwindows now supports three processor families, according to reports emailed me. We've got i386, 8086, MIPS Vr41xx, and ARM families running ;-) Following is a summary of the ChangeLog: Version 0.86 - 28th October 1999 - [EMAIL PROTECTED] * merged framebuffer, elks and msdos vga 16 color 4 planes drivers * wrote vga bitbit routines (a herculean effort) * optimized bitblit by traversing window clip region * added experimental multi-rectangle dynamically allocated regions * wrote scrolling terminal emulator demo for microwindows * added WM_FDINPUT msg, WndRegisterFdInput call for terminal emulator * changed SCREENINFO struct, removed black/white, added bpp, planes * added offscreen (memory DC) drawing to microwindows * added BitBlt, CreateCompatibleBitmap, CreateCompatibleDC, DeleteDC * retired BOGL library, must use new interface for blitting * converted framebuffer, svgalib, elks and msdos screen drivers * (we need blit routines for herc and svgalib still) * major screen driver interface change, old drivers not compatible Greg
Re: some problems with ELKS 079
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 port. I got it to the stage where it kind of ran, then released it. The problems could be because elvis is not yet fully ported, or it could be bugs in ELKS. In my last elkscmds submission, makefile changes were made so that the visual editors could be run under elksemu, as well as compiled directly on Linux. In certain cases, the editor's didn't run on Linux either. I ported a couple more visual editors in elkscmd, try them out as well. + seg cs mov ax, stashed_irq or ax,ax jz irq0_bios Al - so this was the floppy disk drive bug? I can see why it changed whenever a few bytes more or less were added to ELKS... Glad you found it! Greg
Re: ELKS 0.0.80
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 to be in Rob's libc code, for kill(2). But you may put up a patch for libc in a root ELKS subdirectory, until Rob patches the devkit. This is what I did for putenv(), which fixed some nasty shell behaviour. Greg
Re: CVS is back!
: 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 some time last night. So ELKS can compete with Sony Playstation at least for a while ;-)
ELKS 0.0.80
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 these /dev/ entries. I need to know the magic numbers. Also, does version 0.77 support pseudo ttys? I wanted to make sure this support is complete in the 0.0.80 version, as Microwindows now supports a terminal emulator. (No it won't quite yet run vi, that's coming) 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. Greg
killpg
: 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 getpgrp() I think Whoops I meant getpgid(), finally.
RE: Dev86
: 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 reported? The /usr/bin/ar is broken with the latest linux releases when used to archive .o files for the dev86 kit. Download my replacement /usr/bin/ar from ftp://microwindows.censoft.com/pub/microwindows/ar I have submitted a new ar86 that Rob uses in his latest cut, 0.14.9, so that /usr/bin/ar is no longer needed... Greg
Microwindows plans
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 Win32 CE subset, which is no problem, and adding Xlib support so that the GTK+/Gdk tools can run on top of it. There's quite a bit of work no matter which way we go, but MicroWindows is alot farther on the win32 CE front. CE drops quite a bit of win32 functionality and we could allow winCE programs to be compiled for the microwindows/linuxCE system and run without too much modification. There are quite a few custom controls to write, however. On the Xlib front, I'm going to start studying the GTK+/Gdk implementation and see how much work would be required to get that to run on top of MicroWindows. Perhaps that should be called MicroX, unless we want to change the nano-X api. I'd be interested in hearing which API's are more interesting, and whether many people have programs already written that would like to be ported. Greg
RE: Embedded and Real-time systems
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? Having a kernel that can be shared with the std source would of course be nice. So I think we need device drivers. The filesystem stuff should be linkable just like the device drivers are. In regards to interrupt handling, most of that should reside in it's own arch-dependent file (much like it is now). If the interrupt controller changes, we don't want to hack much more than one file. : What type of API is the application code going to use? Is the UNIX system : API any use at all? : Of course we'll want to be able to use the same development tools, I would think. So it's quite convenient to have the libc code and the sys vectors that are already built in the dev86 stuff. That also allows the applications programmer to test stuff on linux as well as on the SBC board. : Are embedded applications run as stand-alone binaries, or do they get : linked into the kernel and run as kernel threads? With no filesystem, it's hard to "run" programs without writing a "null" driver (kinda like the one you hacked a while back) but seeing kernel threads would be nice. Then the std ELKS system could also use them Greg
At last - Microwindows/Nano-X Screenshots!!!
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 files for microwindows, as well as nano-X landmine, world, and widget sets running... There still on ftp, but have fun! ftp://microwindows.censoft.com/pub/microwindows/ScreenShots Note: the next release will include the makebmp conversion program, as well as support for screen dumping... Greg
RE: new version of nano-X/microwindows
: 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 : compiled. I'll look into this. It works on my system... ;-) : : 2: where is Al's "terminal emulator" ? nterm ? did you manage to get it : woring ? : It's in there, but you must unset the client/server switch, and link in nterm.o. See the Makefile and INSTALL files. : 3: does world.c and/or nclock.c actually work on any ELKS system ? All the demos run on ELKS, including the nterm. If running world, you must supply the .dat file in the current directory. See world.c for details. Greg
Licensing summary
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 than whichever is picked : : Right, I vote for MPL with a "convert to GPL/LGPL" option, with David's : original code retaining it's current Public Domain license. Vidar has : already said he's happy with that. Greg? Yes. I think I agree. But I want to be completely clear on David's code. His original code retains his original PDL license. The code that's included in nano-X and/or MicroWindows is a derivative work, and is not subject to any terms other than his original terms: leave the copyright notice intact. In addition, the "convert to" would be strictly GPL, not LGPL. What are the semantics of a "conversion", anyway? Greg
RE: new version of nano-X/microwindows (not silly licence thing)
* 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
RE: Anybody using this list?
: 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 disassemble. I : am not sure what the format of a .exe file is. Any pointers anyone? : The format of setup1.exe for the toshiba 1200 is an MZ header DOS executable. This is the original DOS format for .exe files, the other being .com files, raw binary images. Any DOS disassembler will work for MZ header files. The 16 bit windows file format is known as NE (new executable). This format uses a real-mode MZ header with a special value at offset 18h to indicate the location of the new header. Meanwhile, the windows 32 bit exe file is known as PE format, which is a modified COFF file. Following is the format of an MZ header .exe file: MZ EXE Format Intel byte order The old EXE files are the EXE files executed directly by MS-DOS. They were a major improvement over the old 64K COM files, since EXE files can span multiple segments. An EXE file consists of three different parts, the header, the relocation table and the binary code. The header is expanded by a lot of programs to store their copyright information in the executable, some extensions are documented below. The format of the header is as follows : OFFSET Count TYPE Description h 2 char ID='MZ' ID='ZM' 0002h 1 word Number of bytes in last 512-byte page of executable 0004h 1 word Total number of 512-byte pages in executable (including the last page) 0006h 1 word Number of relocation entries 0008h 1 word Header size in paragraphs 000Ah 1 word Minimum paragraphs of memory allocated in addition to the code size 000Ch 1 word Maximum number of paragraphs allocated in addition to the code size 000Eh 1 word Initial SS relative to start of executable 0010h 1 word Initial SP 0012h 1 word Checksum (or 0) of executable 0014h 1 dword CS:IP relative to start of executable (entry point) 0018h 1 word Offset of relocation table; 40h for new-(NE,LE,LX,W3,PE etc.) executable 001Ah 1 word Overlay number (0h = main program) Greg
RE: Request for comments - Microwindows
: 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 model, otherwise GPL for server and LGPL for applications. If someone wants to develop a non-free program, and link it statically, we still let them
RE: Request for comments - Microwindows
: 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 GPL. So the issue now is whether we should go with MPL or LGPL. Both permit proprietary code to be linked with the project. Is there a significant benefit to MPL that LGPL doesn't have?
as86 .o file runtime loader completed
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, it also allows for libc.a and other archive files to be searched, and modules loaded as well. The relocating loader also works for 32-bit object modules produced with the bcc -3 option. However, there remains a very serious problem relating to getting this to work in 16-bit mode. (I finally realized this damn near after completing the whole thing) Although I have it working for both 16 and 32 bit files now, I can't actually execute the code loaded for 16 bit modules. This is because I malloc() the data space for the code segment, but the code has to actually execute relative to the CS segment. Thus, we would need an additional system call, or the ability to write into a new process space in order to allocate code segment space and have it relative to the CS register. So, I'm not sure what's next. (It's been a very informative project, however... I can still run .o files created from bcc -3 in my native linux elf programs...) If we wanted to add some very _new_ design to the ELKS kernel, we could add the abililty for ELKS to load/unload modules, and the same loader code could be used for user processes as well. The reason we'd use the current .o file format is because we'd not have to write new tools. The ELKS kernel could load/unload drivers using the same mechanism that user programs use, which is cooler than the Linux kernel's implementation. Unloading modules is easy if there's a single import, but with multiple imports, it gets harder. Greg
RE: Stupid licensing thread (Was: Request for comments - Microwindows)
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. Correct me if I'm wrong: If we license LGPL _or_ MPL, it is not required to contribute any code back. If the _contributors_ to NanoGUI : regards prefer a restrictive licensing scheme over those contributions, : then fine. In that case we'll spend our time and money improving : another product instead, or license a closed source product instead of : spending or time and money on supporting an open source project. So we need a license that: 1) must or 2) should cause contributors to contribute code back. Which?
RE: Request for comments - Microwindows
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 systems. nano/micro will never be a standard with an attitude against commercial interests. I'm certainly not against commercial interests. I'm very much into commercial interests. However, I'm not necessarily doing microwindows for money. I'm doing it for fun, to give back what I've taken from the community over the past 20 years, and I want to build a graphics system! Greg
Licensing summary
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 linked with, private, proprietary applications. (commercial software shops use our engine with their application; they'll never go open source, but still want/choose our engine) 2. We _would_like_to_have: a. All modifications to original files, whether they're enhancements or bug fixes. It'd be nice to have them back, but not required. b. A community desiring to better the project as a whole, by sending contributions to be included in the whole, whether they're original work, new drivers, or whatever. 3. We _must_not_have: a. The ability to use the graphics engine, lock stock and barrel, for whatever purposes are desired [It is this 3a that I can't quite come to grips with] please debate Greg
RE: Anybody using this list?
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 for all of my nifty serial : devices (hubs, routers, sun boxen, etc.) Anybody tried anything similar : yet? Ah, the T1200. I have one, and booted minix on it a while back, I think I tried ELKS as well. It booted and ran for awhile, until the damned Toshiba auto-power-off mechanism kicked in. then the screen went blank, and I couldn't get anything to happen until a full system reset followed by a reboot, then it repeated. We need to turn off the T1200 auto-power-off mechanism, but I don't have a HW manual for the unit. Greg
RE: your mail
: 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
RE: your mail
: 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 or two monitors... : : If it is this simple, then adding dual monitor as an option to the dircon.c : driver should be quite easy. The only sticking point is that I don't have a : herc card, or a mono monitor. : Hmm.. I think a mono card costs about $7 now... Greg
RE: Anybody using this list?
: 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.
RE: Anybody using this list?
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. God knows where the prog came : from, but if anyone is interested, give me a shout. : I tried it. That program (named test.com) allowed the bios setting to change, but it was only active when MSDOS was running, so it didn't work.
RE: your mail
: 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 be done at a low level anyone? If there is : source code available for the DOS software, then it could be ported. : I think the answer to this is that each virtual console needs to have a pointer to it's screen driver code, where there's multiple screen drivers running. I don't know how you'd want to specify which VC gets VGA vs herc though... Greg
RE: Another ELKS idea for shared libraries
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, and thus can't be shared. So each process has : it's : own copy. : : What about just using DS/CS as they were designed (as I believe is done : 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. currently, it doesn't generate any of that kind of code.
RE: Another ELKS idea for shared libraries
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. : currently, it doesn't generate any of that kind of code. : : It also cant do that on an 8086 without ruining swapping/defrag As I mentioned before, if this were performed with code segments only, then they could still be shared with the resulting memory decrease benefit. It gets increasingly hard to do everything with only 64k of code, especially when the cpu architecture allows for more (albeit in a crappy fashion). Another implementation would have far segment code jumps go through a local smaller table, and this table could be relocated easily on swapping. (That is when we implement swapping...) In fact, with a ridiculous increase in code size, all absolute locations could use a [bx] register offset to get to a small table of hard adresses, just like the ELF .got section is implemented. I'm not recommending this, though, since we're already short on cseg space. Greg
RE: Another ELKS idea for shared libraries
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 defragmentation Yes, but it'd make sense to set a noswap bit for large executables, at least we could run them, which we can't AT ALL now. : : In fact, with a ridiculous increase in code size, all absolute : locations could use a [bx] register offset to get to a small table of hard : adresses, just like the ELF .got section is implemented. I'm not recommending : this, though, since we're already short on cseg space. : : You need to cover call/ret sequences. It is doable but hard I forgot about that, I concede this one to you, noone wants to trace stacks fixing up segments but maybe MS... : :
RE: Elks progress
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 api and an X-like API on ELKS. Both run in quite a bit under 64k. Currently, microwindows runs in about 40k and supports window frames, title bars, buttons, etc and client coordinate drawing areas. : Is there any network support? : I have a 3COM EtherLink (original 8-bit, RJ-45) that I'd like to use to hook up to :my existing : NT/OS/2/Solaris network. : No network support. Al's got a very basic unix sockets built but that's about it. Greg : Paul : :
RE: Another ELKS idea for shared libraries
: 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 and .a files, and builds import/export symbol tables, and then loads any text/data segments that are needed, and relocates all the bits using segment or symbol relative offsets. I am currently working on some severe memory usage issues, relating to reading in libc.a. This is going to be cool! : : I am not sure this could be made to work usefully as a means to build : shared libs. It would still mean that the address space of the process : has to contain all the code and data of the library which eliminates the : possibility of sharing memory between processes, so the only advantage is : the size of binary files on disk, which is not much of a concern. : I've thought this through to some degree, and yeah, I kinda came up with the same thoughts, that we might only get binary file sizes down, which isn't much of a benefit, considering the work. There are several issues, though that need more discussion, because a dynamic loading technology could still considerably enhance the approach to applications development, in a good way. 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, and thus can't be shared. So each process has it's own copy. Well, thats still not all that bad, because it means that ELKS could have different modules (including kernel modules) execute as .dlls rather than having everything always linked together. Portions of the kernel or other programs could be replaced by merely replacing the .dll (.o), rather than recompiling everything. I think this is one of the most basic features of newer, more advanced operating systems. What I'm working toward is adding developmental technologies, so that more advanced programming methodologies could be used in building applications for both linux, windows, and ELKS. This requires shared libs. For instance, the Microwindows goal of loading application code and data works nicely under linux, and it'd be nice to have it under ELKS. It is, however, alot of work rewriting all the tools for each platform. That's why I'm currently designing around bcc and as86, rather than rewriting them. Another big issue is that, in order to load modules, it would be nice to be able to load data and tell ELKS that we want that data to be thought of as a text segment. In addition, there is quite a bit of "temp" data (symbol tables, etc) that would be nice to free and have the image look like a normal text+data+bss. Also, there are issues with _end, etc for the C library. I think I have most of this sorted out, but it still will use alot of process memory. I think the development advantage is still there, however. Greg
RE: Another ELKS idea for shared libraries
: 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 source code to as86 and ld86. I have decoded this format, and it of course has complete information for imported and exported symbols, as well as all code with relocation information. : : How does this fit with your ideas of DLL's on ELKS? : This is all well and good but it doesn't appear to address the real problem : with 16bit DLLs. The fact that you're limited to 64k of text/data. Well, yes, all ELKS binaries are limited to 64k code and data. The cool part about the design I'm proposing is that only the linked-to symbols and their associated code gets loaded. This must still fit into 64k * 2, just like a statically linked version of the same. : : ELF DLLs are very good, and work very well indeed. They even have : facilities for hiding exported global symbols within the DLL so that : they don't interfere with your program (eg you can have an int called : "time" or define your own "tcgetattr" without problems) the ELKS "Introl" DLL will allow this also BUT you need : enough space in your memory map to load the entire library; the current : elks libc.a file is 80k. :-/ The difference between Introl and ELF format is that the latter was developed for modern operating systems that use mmap() mechanisms to map the binary into memory, and then page-fault in the code as required. In the ELKS format, all run-time required DLLs are searched for import symbols needed, and only the code segments with those symbols exported are read into process space memory. No mmap() mechanism is used, the down side is that the entire library may need to be read, but with code file sizes max'ing 64k and the library 80k, this is no big deal... The other difference between ELF and Introl is that the relocation info in ELF is in a separate section, which allows pure code sections to be mmap()ed in without any reads, whereas Introl format encodes code, data and relocatable info in the same section, and it must be read to decode it. The COOL thing about what I'm proposing is that we COULD have full-blown DLL's if we want, with complete automatic symbol resolution and minimal overhead. Dlopen()/dlsym/dlclose could also be implmented, if desired, although it poses a few more problems. We are still limited to the basic 64k segment limititations, and no ELKS kernel mods are required. Greg
RE: Herc in Microwin
: 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 at the beginning. *much better* : : 3. Do I need a #ifndef statment do control the compliation of the optimized : and non optimized version? No - let's use your code : : 4. Once this is done how do I put the code in the microwin source? Greg? Send it to me and I'll include it in the distribution. Thanks. Greg
Another ELKS idea for shared libraries
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 and distributed separately and call the server without requiring the overhead of local unix sockets etc when making api calls. The cross-elf package is an ingenious piece of code that quickly allows linux, DOS and windows applications to load 32-bit relocatable ELF modules into the application's memory space, and allow dynamic linking to the mother application, as well as any other system shared libraries. I have finished a design that would allow identical codefiles for linux, windows and DOS (protected mode) and run identical binary nanoGUI and/or microwindows applications, all created one time using the gcc compiler on linux. The problem that I've been dealing with lately, is that of course, we must have ELKS support for this new scheme, and ELKS doesn't support 32-bit binaries. So, I've been investigating the ELKS 16 bit relocatable formats, and have come up with the following idea, which would allow user mode linking (the same as the ELF format is implemented - they're not actually loaded by the kernel) of dynamic libraries. In fact, properly done, ELKS could have loadable kernel modules and loadable user mode shared libraries that have the same format. Basically, the idea is that we use the Introl object file format as the relocatable format for shared libraries. This format is output directly by as86, and read by ld86. It handles 16 and 32 bit relocations, and completely specifies import and export symbols, required for dynamic linking. Data imports/exports are also handled. I will be writing an ELKS .o file loader that will be part of the microwindows subsystem loader, and I was thinking that this could be used to implement full blown shared libraries for any ELKS executables. An a.out with shared libraries would just link in a piece of libc code that calls this loader I will write and dynamically links the symbols that are required. The libc code would execute on startup and could be dragged in with a single symbol, specified by a new linker switch. I won't bore everyone with additional details, but I've thought this through in quite some detail, and have tested various portions of this concept on Linux and windows. How does this fit with your ideas of DLL's on ELKS? Greg
RE: Two Questions: minix_add_entry man
: 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 checked, : and is overwriting some vital data. I have an entry for this problem in the : BUGS file in the source distribution, and on the website. : This problem is very related to the 64k-2 bug that I fixed in ELKS exec. All commandline argc/argv/envp stuff is copied above the initial SP, initial work by the Rob's libc code, and then by the kernel exec code. I looked through this stuff fairly carefully during that bugfix, and although complicated, it looked ok. I would suggest checking the glob generation code next at this point. Greg : Al :
RE: Linux on TI?
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 - 8086 - 80186 - etc each processor added a few instructions, with the exception of 8085, which I think just had onboard cpu support. gh
RE: Herc in Microwin
: 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, it should be horz_line (exactly how *did* that happen, Bjorn?? ;-) : I have not started the vertline func yet, but as I say the hline is nearly : ready. No need for an optimized vertline, there's nothing that can be done to the existing code to speed it up... : : This may seem like a silly question, please dont get mad, but, what do you : mean "the code you're running now is based on Jacob's code", baring in mind : I have never done a programming task in a group. Is it that I use the : #defines and stuff he has? : No - scr_herc.c was written by me based on Jacob's code. (thanks Jacob) I assume you're starting with scr_herc.c, the working hercules screen driver. Greg
RE: Herc in Microwin
: 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 "c" for? Who gave greg that code? Greg? In the MicroWindows/Nano engine, there are color values (COLORVAL) and pixel values (PIXELVAL). COLORVALs are now always 32 bits, and hold the RGB color we're looking to see. After translation by the palette manager section of devdraw.c, the color value is converted into a device-dependent PIXELVAL that is essentially an index into the video card's palette, *or* the hardware RGB value, if the card is truecolor. Translated, for you the pixelval is either 0 or 1 (black or white), since you're running a monochrome screen. So, if c == 1, then you OR a bit into screen ram, else you AND out (set to 0) a bit. Good luck. Remember, the code you're running now is based on Jacob's code, and we want to add the horizontal byte-filling code that Bjorn sent us. Greg :
new idea for microwindows client architecture
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, and resolving all imported and exported symbols. After having reviewed this great piece of work (highly technical I might add) I've come to the conclusion that it would be *perfect* for the multiple client/single server architecture that we've been discussing on the nanogui list. This solution completely solves the problem of multiple clients on one machine communicating with a graphics server on the same machine. I think that this is where microwindows/nano should be concentrating (let X handle the multiple machine cases for now). In particular, this solution has the following advantages: o high speed o client binaries are *identical* on linux, win32 and DOS! o no network overhead or network needed (even UNIX sockets) o ELF format fully supported by linux tools o all modules seperable into .so shared objects if desired (this means that the nano-X vs microwindows engine could just be separate .so files in the same server...) To get this to run on ELKS, I would have to modify the ELF loader to support 16 bit binaries (small task) and modify the bcc/ld86 tools to support ELF format or add the import/export info (very large task). With the appropriate implementation, this architecture would allow static-linking of clients if desired, which would allow the extremely small binaries microwindows supports today. I plan on building a strawman implementation of this, so that we can move towards separate "applications" in microwindows being loaded/unloaded as desired. Note that we don't have to allocate another process for each application. Ideally, only a thread. Comments? Greg
RE: missin timezone, and a bcc-cc1 error
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?) about the tz size is unknown. : I figured the problem was with the struct timezone. So I copied the /usr/include/time.h to the directory edited the file and added the struct from the elks/include/time.h and removed the reference to extern long int timezone. : This helped. : This is another C Library incompatibility. I thought I fixed this the last time I saw it. : 1) What have I done wrong in my installation since I had to do this. : 2) Wont there be a conflict at link time when there exist a 'struct timezone' and a 'long int timezone' ? : : After doing a 'make all' from linux-86, I tried doing an /elks/make (after doing make config; make dep; make clean.) : : But I get the error bcc: 'exec of bcc-cc1 failed' : bcc -D__KERNEL__ -O -I../include \ : -0 -c -o sched.o sched.c : bcc: exec of bcc-cc1 failed : bcc: error unlinking /tmp/bcc2248 : You must "make install" from linux-86 or the compiler isn't installed. Right now you have it running out of linux-86/ncc Greg
RE: Herc in Microwin
: 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 many times each time altering memory "bit" by "bit". I have to : write a func that writes a byte at a time to memory, (8 bits) and in case of : the herc card 8 pixels. : Just use Bjorn's submission "vert_line" to this list. rename it properly though ;-) gh
RE: [Fwd: syntax doc. about as86]
: 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 : make rule: : : first:first.S : gcc -DUSE_AS86 -E -traditional -o first.s first.S : as86 -0 -b first first.s : cmp first first.ref : Ken - quite cute. I'm glad you posted this, as I have found myself wondering how to cope with the myrad of idiotic assembler source formats, and how to make sure that as I change continually one to another, when to know I've screwed up. God I wish that the NASM guys would have at least allowed some of the more obtuse forms of source input, so at least we could have used a single assembler, then worked on changing source formats... Greg
RE: BCC and ANSI C without pain
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 warnings such as -Wall etc. (You may have to add -fnostdinc
: to the GCC command line and twiddle with the -I switch so as to
: use the proper include paths).
:
If I'm not mistaken, this still requires that the sys_open
procedure be coded as:
int sys_open()
char *filename;
int flags;
int mode;
{ ...}
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 ansi.
Greg
RE: BCC and ANSI C without pain
: 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 ansi. : : Shouldn't be a problem with the more popular compilers such as GCC or : Borland. They won't revert unless explicitly told to, and it's easy enough : to check if someone is unsure. : I'm not crazy about the __P technique, but it does offer a quick benefit, that described by Thomas. ELKS could have all it's prototypes specified using the __P technique, and leave all the function definitions untouched. This would allow parm checking by gcc without modifying much ELKS code, only headers. This would be a good step in the right direction. I still think that we should move to ansi at some point, though. Greg
RE: ELKS-0.0.78 ??
: 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 distributions. This is available at ftp://microwindows.censoft.com/pub/microwindows as ar. I have also written a special ar86 that will run on ELKS, Rob de Bath will include it in a future version. Greg
RE: Getting going
A freind has a 286 laptop he wants Linux on, and will want to program : with it. I saw in the archive that someone had gotten the bcc going : on elks, is that true? How do I go about getting bcc on elks, and : also...I want bash or tcsh or some other decent shell...has anyone : suceeded 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 : at the moment. If you need a shell with advanced interactive features, : then one will be required that does not support the full scripting features : of this shell if it is to fit into elks. : Yeah, I have bcc, bcc-cc1, as86 and ld86 compiled under ELKS, but there's still problems. bcc-cc1 is 63.5 out of 64k, and for some reason spits out garbage instead of assembly. The other programs seem to run, but they're tight also. We do have the ash shell running, as well as a decent vi editor. ELKS currently is quite developmental, not really a good platform to develop other programs on just yet. Greg
RE: SIBO/Psion 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 each process and finds its arguments (just above the initial sp) and prints them out... : 3). What size stack are we supposed to be working with (I had 8K and was : running out of space, so it's now 2K) certain programs (like init, login and getty) have hardcoded stack values in Makefile. The programs were coded specifically to use as little stack as possible, and shouldn't have changed. The -H option was computed based on the program code. I've suggested writing a kernel utility that keeps track of a programs stack and heap use, but no takers yet... Greg
RE: SIBO/Psion Elks
: 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. : [Simon Wood] : I haven't looked and have no idea where and what format it might be. I'm : under the opinion that we should work completely separated from Psion ROM, : that way the code written could be ported to other systems (which might not : have similar steal-able features from ROM). : Yes it could be placed in a separate segment - I need to check how this : might be loaded from a Psion '.img' format executable as that's how the : system is 'booted' at present : Microwindows and nano-X running under ELKS use the rom for all character set data. It's format is one byte or word per scan line times the number of scan lines per character. There's a call in the scr_bios driver that gets the rom font data in es:bx. I disagree that you shouldn't use the rom. You'll usually save a heck of alot of space and find that you're probably using the rom anyway. (Of course, if you've got the time, there's nothing wrong with having a separate version that doesn't use rom) : 1). The current version of Init (in elkscmd) seems to need /var/utcp to : be : exist, what does this do and should this file be writable (which won't : be : possible with a read only file system!)? : : Eventually you are going to need a ram disk. : [Simon Wood] : Why ??? : I agree that in a 'PC' type environment you will need disk storage, but : there are many applications for ELKS that will not... : : In this specific case 'init' would need to create a RAM disk for /var before : it continued booting - seems a suspect way of doing it to me. I suggest you modify init so that it'll run without /var/utmp, but write an error message... : : 2). PS requires '/proc', but I can't see any code where this 'created'. : : The mainstream Linux has a /proc we don't. The intention is to make /proc : dig around in /dev/kmem : [Simon Wood] : So why is this PS in elkscmd if it can't possible work?? ps definitely works, I enhanced it for command argument display... Greg
RE: SIBO/Psion Elks
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 present but with talk : about other platforms we should try to be versatile). I think that's a great idea. I've made the mods so that the elkscmd package can be compiled with gcc or bcc, and run on different platforms. That's how I debugged the elvis editor, for instance. (The idea is that if it won't run on a debugged Linux, how will it run on a developing Linux e.g ELKS) #ifdef __BCC__ can be used for certain critical platform issues. Greg
RE: Turbo C
: 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
RE: Turbo C
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 it's only binaries it's not much use to : us. : : This means we can use it for compiling in the ELKS project. : : You mean 'cross-compiling' (if it's not source). : No source code, binaries only for DOS. We can't use it to compile ELKS on Linux, but it's possible that it could be used on DOS. Rob's dev86 would be the first thing to get going... He already has the devkit compiling using MSC 5.1. Greg
RE: minicom under ELKS?
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? ELKS should have no problem running a terminal emulator. The serial stuff now works fine, and the console supports most ANSI and VT52 escape sequences that are needed to become an emulator. It's a relative no-brainer to write a select() driven terminal emulator for elks that uses pass-thru for the sequences to the ansi console. The only drawback would be no screen refresh after popping a shell. If screen refresh is wanted, the ansi stuff can be pulled from the console code and kept in the emulator to keep vscreen contents current. If someone really wants, I'll write the framework for a serial terminal emulator that will work as an TERM=ansi front end. Greg
RE: Apple ][ Unix Revisited
: 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
RE: Turbo C
: 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 bcc primarily, unless you're talking about OS support of math coprocessors... Greg
RE: Implementing vfork
: 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() is called, save the stack pointer in the kernel. Then, when the child calls exec(), more items are stored on the stack. (at least the return address from the exec call) When the parent is rescheduled, the system can reset the stack pointer to the value it was when vfork was called, providing that it the child never returned from the procedure that called fork, but instead called exec from there... : : 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 may well crash? : It's not acceptable to carry on and crash. Greg
RE: Implementing 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 may well crash? : : : : It's not acceptable to carry on and crash. : : I can't yet work out a way to make sure this can't happen. We could set up : some kind of timer that kills the child if it does not exec, or watch it to : see if it shrinks its stack to much and kill it then. : We need to agree on the semantics of vfork(). If the process calling vfork() isn't allowed to call any other system call after vfork other than exec() or maybe some dup() calls, then you're version could work. If the calling process declares more than 100 bytes of stack and returns from that procedure, you're crashed, even if it later calls exec. I still don't see what's wrong with my first suggestion - don't allow the caller to return from the procedure that it called vfork() from. Then, the stack doesn't need to be copied, and system calls don't need to be monitored. The stack frame will be ok when the parent returns from vfork(). Greg
RE: Herc in Microwin
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! : Unbelievable! That's the *second* time I've written a Microwindows/Nano-X screen driver and it's worked without having any hardware to run it on!!! Also big thanks to Jacob for sending me his sample Hercules code, which was very easy to understand. : On the down side it did take a little long for it to load, try 10 min! : So if it is to be used the code has to be somewhat speeded up. I did not try : to move any windows because I did not have a mouse pluged in and it would : have taken too long. Uh-oh. Scratch the above comment. You mean that it took 10 minutes to *draw* the screen! (laughing in background, peers looking at me very strangely...) Well, we definitely need that HERC_drawhline to be implemented, because now it calls HERC_drawpixel for *every* pixel on the screen, all 252,000 of them. I can take a hack at rewriting that, but It'd be nice if someone with a card did it. The file is mwin/src/drivers/scr_herc.c. : : I am not realy an expert, but a v20 is faster that an 8086/8088 so it might : be worse on those. All that I can think of doing is 1.adding 8087 support : 2.speeding up code 3. anyone else have ideas?? The problem is definitely in HERC_drawhline. Rewrite it to draw the horizontal line directly, rather than call HERC_drawpixel. Greg
fs cleanup in ELKS
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 made by the person creating the BLOAT_FS stuff, and he #ifdef'd out the a repeated find_buffer call, saying he thought it was redundant. Well, Linus says in his 0.01 kernel in the same function: /* NOTE!! while we slept waiting for this block, someone else might already have added this block to the cache, check it */ I think this is a bug, and could cause a major buffers bug if ELKS ever ran multiple tasks that read and wrote the same buffer. I suggest we uncomment it out and leave it in. There's really no harm in leaving it there, considering the comment when commenting it out: /* I think the following check is redundant so I will remove it for now*/ Greg
RE: Herc Support
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
RE: Microwindows for Hercules
: 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) : : calls for most things : That's a good idea. This would certainly speed up diagonal lines on systems with a fast horizontal line draw. The vertical doesn't add much, as most video planes aren't optimized for vertical line drawing. Currently, there aren't any applications that draw diagonal lines though, so the speed issue is mute. : This might be useful when bitblt is implemented though... : : Having 32K of offscreen memory is always useful. : Definitely. I plan on adding offscreen drawing memory, but it requires some big architecture changes. Greg
RE: compiling 0.0.78
: : : 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 : make[1]: Leaving directory `/usr/local/src/elks/arch/i86' : make[1]: *** [boot/crt1.o] Error 1 : make: *** [Image] Error 2 : : : I don't understand why you get this error. WHat version of dev86 are you : using? : Likely the problem is the link -s is missing in the /usr/bcc/include for the arch and linuxmt dirs.
RE: Microwin Mouse
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" mode and it : worked! : : anyway I just thought I would say because there were some people having some : probs and I thought it might help fix them. : This is fixed in ELKS 0.78. The bug was that any mouse that emited NUL bytes won't work. Any mouse that emits ASCII will. Thanks for the info Greg
RE: ELKS v0.78 bugs fixed
: 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 : deal with as elkscmd grows. I think it would be best to switch over to a : different release model. elkscmd updates can be released regularly with : date stamped version MAJOR.MINOR version release don't really have any : meaning for elkscmd as it contains so many packages. I can then release : the kernel on its own with its disk images much more easily. As long as if you have both elks and elkscmd, you can "make comb" etc. We're getting significant enhancements by posting them together though. I know my work depended on it. I don't mind splitting them if it's too much work, but we're finding alot of kernel bugs from elkscmd... : Quite alot of the libc stuff in dev86 is untested. The utent.c file in : elkscmd is just there as a fix until I submit the patch to the version in : dev86. : Send Rob utent, he'll integrate it I'm sure. Greg
RE: filesystem bug
: 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 sys_stat() in ~elks/fs/stat.c, but : that's as far as I've gotten.. : I'm new at this, so my bug squashing is proceeding very slowly.. : If nobody is interested, no problem, I'll eventually figure it : out anyway so don't waste your time. I just thought you guys know : alot more and might know instantly what is the problem. I apologize : if it's a known or unworthy problem. : : I have notes for the experiments I tried if anyone wants : them. There are alot, and many are garbled by printk() output. : Keep going! This kind of work is greatly appreciated! It sounds like you're near a breakthrough. I think the problem may lie in the fact that the fileames *aren't* NUL terminated,and that strncmp may need to be used, or the memcpy_fromfs changed to get the user-name level filename. Greg
RE: Microwindows for Hercules
: 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. Nevertheless, does this mean it has to be slow? Suppose in
: the future someone writes a drawing program for ELKS, using the XOR algo
: to draw lines (and erase them again as the mouse pointer moves).
Yes, microwindows is ready for this, the code is already
commented out, waiting for somebody to add it. I just hadn't heard complaints
about the diagonal line drawing speed yet. (check out devdraw.c, and you'll
see that *if* the clipping routines see that the line can be drawn full speed
with no clipping, then a commented out low level routine can be called
to perform the function at blinding speed.)
: Hmm then that's something that could be checked for in between STOSB
: instructions (or the like). We could for example use something like this
: (just an idea), where ? is a flag that isn't used (maybe the carry flag?):
:
: PUSH flags register
: CLI
(we don't want to draw lines with interrrupts off)
: ...
: {If out needed} ST?
: ...
: {Bresenham}
: ...
: STOSB {or something like that, like OR}
: LOOPN?
: JN? :End
: ...
: {Perform OUT}
: ...
: LOOP
: ...
:
: :End
: ...
: POP flags register
:
: We could of course also use something else than a flag, like a register,
: if Bresenham doesn't already use all of them...
: Just an idea, I never did VGA 4 bit programming, I always used mode 13h.
:
Generally, it would be nice to have everything in asm for blinding
speed. I've already done this with microwindows and nano-X, see the file
asmplan4.s.. I also have everything written in C so that it's easily understandable,
and portable.
Why don't various people play with this code, and maybe
it should be part of the standard make?
Greg
RE: rfs (new filesystem for ELKS)
: 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 BSD filesystem idea, right? : 6) Inodes are stored in exactly the same areas of file data and are 1024 bytes : in size. : : 7) For files 1000 bytes in size (often dirs, symbolic links, many small : files), the data is directly stored after the inode (great performace boost : IMHO) 1K inodes are great for big operating systems, but may not be a good idea for small ones. Nonetheless, this is interesting, and is the same thing that NTFS uses. I presume you've read all the lit on NTFS, because it has some really neat ideas for a new fs design, which is what you're attempting. : 10) Inode numbers are really a combination of the zone and block. (32 bit : number. High 16 bit is zone, low 16 bit is block). This allows file references : to be picked up quickly. : : 11) Directores work like they do under ext2. This allows long fille names :) : : 12) The first inode will be a bad block inode that stores bad blocks. The : second will be the root inode. Why not swap the two and have the first inode be the root inode, just like now? It might be nice to have the 1k inode size configurable. It also would be nice to write a utility that would show what the average file size is on a minix or ext2 filesystem. Greg
RE: rfs (new filesystem for ELKS)
: 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 wastes a lot of space. : I probably should read about NTFS one day, but it sounds really complex (they : use B+ trees to store directory names). Such complexity is hard to do under : ELKS. The NTFS filesystem is documented in a small thin book available at many bookstores in the US. I don't know about down under. : : I choose the 1024 byte block becuase: : : 1) that is the size elks reads AFAIK when you read a buffer. : 2) you have a reasonable area to store small files. For small files, this : removes an expensive seek on the hard drive. Most directories are small files, : and will save much time over separated inode/data fs's. : 3) If i chose a smaller block size, there will be more overhead with the free : block bitmap, and i would probably need double indirect to store really large : files. I think the 1k block size is fine. : : Oh, BTW, the inode numbers i chose for root/bad blocks is abitary and : unimportant to the outside world. (I think (I am still learning)) : The inode number size *is* important, or the sys/stat.h structure has to change, causing all sorts of portability problems. Others may want to comment on this. Greg
RE: Microwindows for Hercules
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've never seen such a complicated :piece of hardware for something kinda-conceptually simple) : : Although it would still require special case code, I believe that a : line-drawing routine for VGA16 would be relatively simple, since each : pixel is the same color. It's been a couple months since I've written : any VGA16 code, but IIRC writing a number of pixels all in one color : can be done with a specialized write mode that makes it easier. This is what we need. This special case code is already in the driver scr_bios.c under VGA_drawhline(). It calls either the C entry point in vgaplan4.c or the asm implementation in asmplan4.s called ega_drawhline. This code isn't optimized for multiple pixels with the same color, yet, and would most likely tremendously increase speed on slow systems like ELKS 8086's. Greg :
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
