Some q's
A few q's:- 1. A while back I remember someone talking about driving LCD's, Can Linux drive LCD's well? Where can I get some info on this? 2. I was thinking of writing a support pakage for the herc card (opening, closing, lines, etc) that works on 3 platforms (Linux, ELks, MSDOS). The main reason for doing this is to get some practace at coding in C, and i want to use my herc card more. I started off and have got a lot done. One thing though, I realised that I dont have any routiens to use ports or write to memory. Do I have to make these by hand? Is there a header file I can include to get these functions? Can I just use the "/src/drives/utils.c" out of the microwin project? greg? anyway, sorry if this question is too easy to answer, I am new to linux programing (and programming in general) tom __ Get Your Private, Free Email at http://www.hotmail.com
Re: Some q's
- Original Message - From: Thomas Stewart [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 24, 1999 3:32 AM Subject: Some q's A few q's:- 1. A while back I remember someone talking about driving LCD's, Can Linux drive LCD's well? Where can I get some info on this? Yes,I have questions about this as well. I wish to someday run ELKS on my Tandy HD 1000 laptop (8086 based) and its screen is LCD. Is anyone working on this, or does anyone have any knowledge about it? William Price [EMAIL PROTECTED]
Re: Some q's
On Wed, 24 Nov 1999, William Price wrote: - Original Message - From: Thomas Stewart [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 24, 1999 3:32 AM Subject: Some q's A few q's:- 1. A while back I remember someone talking about driving LCD's, Can Linux drive LCD's well? Where can I get some info on this? Yes,I have questions about this as well. I wish to someday run ELKS on my Tandy HD 1000 laptop (8086 based) and its screen is LCD. Is anyone working on this, or does anyone have any knowledge about it? William Price [EMAIL PROTECTED] I believe we are discussing different things here. Biglinux boxes are by some people attached to LCD displays that use a serial interface. Your Tandy, in contrast, probably treats the display as any graphics card, for instance CGA compatible. (Or at least BIOS must handle text on it.) Thus, you can probably use ELKS right away. Boot it and see what happens. Jakob
RE: Some q's - Driving LCD Display within ELKS.
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. 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). 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. Presumably all our frame buffer would need to do is simple text (console 8*8 ??) and dots lines (micro-windows). Does any one else have any thoughts along these lines? Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. -Original Message- From: Jakov af Wallby [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, November 24, 1999 12:57 PM To: William Price Cc: [EMAIL PROTECTED] Subject: Re: Some q's On Wed, 24 Nov 1999, William Price wrote: Yes,I have questions about this as well. I wish to someday run ELKS on my Tandy HD 1000 laptop (8086 based) and its screen is LCD. Is anyone working on this, or does anyone have any knowledge about it? William Price [EMAIL PROTECTED] I believe we are discussing different things here. Biglinux boxes are by some people attached to LCD displays that use a serial interface. Your Tandy, in contrast, probably treats the display as any graphics card, for instance CGA compatible. (Or at least BIOS must handle text on it.) Thus, you can probably use ELKS right away. Boot it and see what happens. Jakob
Re: Compile help
Giles Russell writes: Alistair Riddoch wrote: Giles Russell writes: OPPS my mistake forgot to make dep after clean, but I get same message as 0.79: -0 -c -o serial.o serial.c 00066 mov word ptr -6[bp],#_divisors[bx] * illegal indirect to indirect^ 00066 mov word ptr -6[bp],#_divisors[bx] * illegal indirect to indirect^ What version of dev86 are you using? Al Dev86bin_0_13_0 Do you think I should goto Dev86_0_14_3 Yes. Some of the optimisation code has been fixed since then. Al
Re: Some q's
Greg Haerr writes: : Yes,I have questions about this as well. I wish to someday run ELKS on my : Tandy HD 1000 : laptop (8086 based) and its screen is LCD. Is anyone working on this, or : does anyone have any knowledge about it? The Tandy HD 1000 undoubtably has the bios wired up to use int 10h to draw characters on the LCD display. I suggest hacking the ELKS console driver to use int 10h. (there may already be a version of this completed, I think, called the bios console driver) Yep, just diable direct console writes, and enable BIOS console writes in the kernel config. The BIOS version is not as good, but it will work on more hardware. Al
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
PS/2 keyboard problem
I tried to run ELKS on my 8086 IBM PS/2 Model 30 and login doesn't seem to respond to the keyboard. I suspect that this has something to do with it having a PS/2 keyboard instead of an XT one. I'm using elks version 0.0.81. Stabi [EMAIL PROTECTED]
