Re: Microwindows v0.86
I saw one slight bug in MicroWin microblt program...when dragging a window, the windows w/o focus do not seem to have their window updated. Maybe this is just a bug in micrblt as I see that microwin does not have this problem. -- "If a frog had wings, he wouldn't bump his a$$ when he hopped!" - Red Foreman of That '70s Show On Thu, 28 Oct 1999, Greg Haerr wrote: > 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 > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Stability
On Thu, 28 Oct 1999, Alan Cox wrote: > > The only reason I suggested using 0.1 as the stable tree is because we are > > currently heading towards making 0.1.0 a stable version. > > Well we've never applied any idea of stable/not before 1.0 to mainstream > Linux. I think tradition is 0.x = unfinished I thougt the opposite (I saw linux first time around 2.0.1x), but that sounds fine to me. Jakob
Re: some problems with ELKS 079
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). -- Original Text -- From: "Alistair Riddoch" <[EMAIL PROTECTED]>, on 28-10-1999 20.26: Chris Starling writes: > > > > 7) 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. > > > > Sounds as though this is a problem caused by some slight difference in the > > Amstrad hardware. Anyone know why this might happen? > > I'll see if I can reproduct it on my Amstrad PPC640. Is there a > specific thing that you can do to cause it to happen? I've booted > ELKS on my PPC640 and it seemd ok, but I've never used it very > much on there, since it doesn't have a hard drive and my Compaq > SLT/286 does. I probably won't get to play with it until this > weekend, though. > > However, the PPC640 is cool indeed. It's the only PC-compatable > portable that I know of that runs off of stock "comodity" batteries > (10 C cells). I've been thinking it'd be cool to build a solar panel for > it. > I have just realised I used to use one of these as my ELKS test machine. Don't remember there being a problem with the cursor then. I have lent mine to someone at the moment. If it is confirmed to be a problem on that machine, I will get it back while the problem is sorted. Al
Re: some problems with ELKS 079
Greg Haerr writes: > > > > > > 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! > Before the seg cs line was added, the code was fetching the variable stashed_irq from whatever data segment was set when the timer interrupt occured. I guess this was most often the kernel data segment. It appears that whether this value was 0 or non-zero depended on where in the data segment it was, so if the data was shifted slightly by adding a byte to the right place it ended up pointing at a different value. Sometime this value was 0, so the code worked, sometimes it wasn't, and it didn't. Al
Re: Stability
Alan Cox writes: > > > The only reason I suggested using 0.1 as the stable tree is because we are > > currently heading towards making 0.1.0 a stable version. > > Well we've never applied any idea of stable/not before 1.0 to mainstream > Linux. I think tradition is 0.x = unfinished > The problem with this model is that ELKS is going to be stable long before it is finished. :-) Its probably best to just stick to one development tree for now, and set milestones at 0.2 0.3 etc. Al
Re: some problems with ELKS 079
[EMAIL PROTECTED] writes: > > 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). > Okay, that sounds easier to solve. I have witnessed a similar problem with pcemu. In this case the cursor hangs on the far left of the screen about half way up, flashing but totally stationary. Al
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
HD Boot Loader for ELKS
Well, as I've had no bites on my boot loader inquiry, I can only assume it's not yet been done(?). To reiterate, I'm interested in being able to boot ELKS from an MFM or RLL HD without having to boot from floppy. I'm not afraid to roll up my sleeves and get dirty if someone will point me in the right direction. My assembler skills are rusty (well, actually severely deteriorated) but I'll get the job done provided some direction... Any takers? Thanks. -- Regards, Scott Dudley
Re: HD Boot Loader for ELKS
>Well, as I've had no bites on my boot loader inquiry, I can only assume >it's >not yet been done(?). To reiterate, I'm interested in being able to boot >ELKS from an MFM or RLL HD without having to boot from floppy. I'm not >afraid >to roll up my sleeves and get dirty if someone will point me in the right >direction. My assembler skills are rusty (well, actually severely >deteriorated) but I'll get the job done provided some direction... Any >takers? I dont realy know jack about it, but could you use the comb image to write a kernel to the boot sector of the hd, and tell the kernel to look for the root on the hd? tom __ Get Your Private, Free Email at http://www.hotmail.com
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
