Re: ELKS NIC that will take a 64K rom
On Tue, 16 Nov 1999, Alistair Riddoch wrote: I am now stuck. I have tried a 3c509B, an SMC Ultra, and SMC 'Western Digital' card, and various older NICS, and none of them take more than 32K. The only remaining options are purpose build cards. How about packing the ROM image with some algorithm and the unpack it to RAM? (LHA is rather small I think.) Jakob
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: Request for comments - Microwindows
On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: 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. But the static model is probably targeted the most at embedded projects. These tend to be non-free, often for practical reasons. I think it is better to get a shoe through the embedded door, rather than not at all. Just my SKR 0.05 Jakob
RE: Re Z80-8088, was: Linux on TI?
On Fri, 17 Sep 1999, Alex Holden wrote: On Fri, 17 Sep 1999, Hessel Schut wrote: IIRC the Zilog was founded by some of the developers of the Intel 8080, and I recall the Z80 resembled that chip. The 8080 is the ancestor of the 8086/ 88. Yep, the Z80 was designed by ex-Intel 8080 engineers, and it was backwards compatible (in code) with the 8080, but was quite a bit faster and had some additional instructions, registers, addressing modes, etc. which let people who had designed a system using an 8080 but who needed more speed to upgrade to it without too much pain. The 8086 is exactly the same as the 8088 except for the fact that the 8088 has an 8 bit external data bus (but 16 bit internal- it does two operations to access each word). ISTR that the 8088 was produced mainly at the request of IBM, who thought that the 8086 was too expensive for a Personal Computer (TM). There were already lots of hardware developed for 8 bit busses, but not that much for 16 bit, so going to 16 bit bus was expensive. Jakob
Hercules on ELKS / Microwindows
Hi everybody and Thomas! Eh... Sorry for crossposting, but I am a little confused regarding which people would like to hear this... Since I have been too lazy/busy to do some hercules coding myself and others have already given it a try, I post here what I know. This is taken from a Microsoft Press book from 1987. It is a book full of asm examples, original title: "Programmers Guide to PC PS/2 VIDEO SYSTEMS" I have the swedish version. The copyright says (from swedish): The contents of this book must not be in part or as a whole copied (xerox etc) or stored on machine-readable media without the copyrightholders (? dont know the legal term in english) written permission. But AFAIK in Sweden it is legal to copy a few pages of a book for educational purposes... (I am doing this in Sweden.) So if this educates someone, I guess it is just fine. :-) Does any of you know how this legal stuff works? Do companies expect to sell books containing source code and then no one typing it into their computers? (Machine readable media...) Or is it a silent agreement? Happy hacking. ByteOffsetShift EQU 3 PixelAddrHGC: HorizLineHGC: mov ax,ARGy1 mov bx,ARGx1 call PixelAddrHGC ; AH:= bitmask ; ES:BX - videobuffer ; CL := number of bits leftshift ; ES:DI - buffer mov di, bx mov dh,ah not dh mov d1,0FFh shl dh,cl not dh mov cx,ARG2x and cl,7 xor cl,7 shl dl,c1 mov cx,ARGx2 and cl,7 xor cl,7 shl dl,cl mov ax,ARGx2 mov bx,ARGx1 mov cl,ByteOffsetShift shr ax,cl shr bx,cl mov cx,ax sub cx,bx mov bx,offset DGROUP:PropagatedPixel mov al,ARGn xlat or dh,dh js L43 cr cx,cx jnz L42 and dl,dh jmp short L44 L42:mov ah,al and ah,dh not dh and es:[di],dh or es:[di],ah inc di dec cx L43:rep stosb ; This instruction does not work on 8088? L44:and al,dl not dl and es:[di],dl or es:[di],al jmp Lexit ... ... ; vertical line draw etc. Lexit: pop di pop si mov sp,bp pop bp ret _PropagatedPixel DBb DBb -- PS One can pageflip (hello doublebuffered microwin here I come!) between the 2 graphics frames on HGC. To write on page 0, use video segment B000H. To write on page 1, use video segment B800H. I have forgotten how to flip between the 2 frames, but I will post later when I have found it out. Oh, and here is PixelAddrHGCPROC near mov cl,bl shr ax,1 rcr bx,1 shr bx,1 mov ah,BytesPerLine(that is, 90 /comment) mul ah add bx,ax add bx,OriginOffset mov ax,VideoBufferSeg (you know, one of the buffers /comment) mov es,ax and cl,7 xor cl,7 mov ah,1 ret -- PS 2 These routines are so _neat_! Small and fast... I am impressed by the person(s) who thougt them out.
Autodetecting video mode and graphics adapter
From the book I mentioned in an earlier message there is code for detecting the presence of one or two cards of type: MDA CGA EGA MCGA VGA Hercules Graphics Card Hercules Graphics Card+ Hercules In Color Card I guess this would be good for the ELKS kernel to autodetect at boot, and then applications could (in a way you kernel people decide on) ask what kind of framebuffer there is, allocate the framebuffer and go on doing graphics. Maybe ELKS already can detect these, if so, please have patience with me. (Should ELKS support two graphics cards, BTW?) (There is also code for detecting which videomode the herc - card is in. Would that be of any use for ELKS?) regards, Jakob Eriksson
Re: Hercules on ELKS / Microwindows
On Wed, 15 Sep 1999, Perry Harrington wrote: I happen to have source in C, C++ and asm available for free use, written by myself. There is also code for 640x480 BW VGA there too. Thanks a lot! This simplifies both coding and legalities. The tar file can be had at: ftp://ftp.apsoft.com/pub/user/perry/source/herc.tar.gz If you look at the VGA code, it demostrates the use of a lookup table for Y coordinate offsets. A lookup table for herc would be a big speed win on slow CPUs, just calculate the Y beginning offset at driver initialization. Hmm... interesting. I never thought of that. Probably the hercules can be really useful. Regards, Jakob
Re: MC68000
On Sat, 21 Aug 1999, thcg wrote: The linux m68k docs are very vague about the hardware that can run that OS port. It says the least is MC68020 which implies that MC68000 is useless. Can ELKS be run in the MC68000? If the MC68020 etc are higher class controllers of the order of 386 etc running 32-bit code... MC68000 must be a slightly lower class of say 8088 etc... I think the same way ELKS was produced from linux... an MC68000 port can be derived from standard linux-m68k .. any ideas? ucLinux runs on the 68832 (or whetever is in the PalmPilots) the 68332 is a processor very much like the 68000. No MMU... What they had to change for ucLinux was for example fork() to copy instead of fiddling with MMU. Jakob
Re: 8051 or Z80 Can run ELKS
On Fri, 20 Aug 1999, Apisith Udompat wrote: Now ... I m Beginner leanning Linux and i terrested ELKS i have any question for ask you ..sir -- How i use MCS-51 uPC or Z80 [Zilog] or 8088 [intel] run on OS ELKS .., Can i DO ? Only IBM PC compatibles can run ELKS at this time. Z80 port was planned and started, but development stopped. Jakob
Re: SIBO/Psion Elks
On Mon, 16 Aug 1999, Alan Cox wrote: 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. Then you will need to do hacking otherwise - unix tools tend to assume disk scratch space exists. And on this line in whinging 'clock' talks directly to hardware (which in my case doesn't exist!) - it should be through a clock driver! No. The clock driver itself would take up valuable permanent space in the kernel. It means you need the right clock binary for the hardware but it saves you kernel space. Linux 386 is a bit different but on an 8086 its best in luser space The same reason graphics (until recently) has not been in Linux 386? Jakob
RE: Apple ][ Unix Revisited
On Thu, 29 Jul 1999, Greg Haerr wrote: : 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 Isn't xinu just a bunch of programs? Jakob
RE: Herc in Microwin
On Tue, 20 Jul 1999, Greg Haerr wrote: : 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. Ok. I'll do it, since I already have code doing the task "optimally", (how can one be sure anything is done optimally?) if I understand it correctly. (I am not the brain behind the algorithm.) (Guess I'll have to put that Herc. card in a machine then... huhm...) Regards, Jakob Eriksson
Re: doa.org
On Thu, 15 Jul 1999, David Murn wrote: Just a quick note to let everyone know that doa.org has returned, so elks.doa.org now works again for CVS and web. Also, the [EMAIL PROTECTED] kernel mailing list is now back online. The web message is not very friendly though! *shocked amusement* WEB PAGE CONTENT: GO AWAY, Your bugging me. Regards, Jakob Eriksson
Re: Microwindows for Hercules
On Thu, 15 Jul 1999, Greg Haerr wrote: : I am not really up to writing the driver myself because I have never writen a : driver before, but I will test it for you. I have 2 8086's with herc cards : in. Well, last night I took Jacob's hercules code samples and wrote k :-) a complete hercules graphics driver for MicroWindows and Nano-X. I wrote all the driver entry points, but since I don't have a hercules card, I can't test it. Basically, the hercules card appears to use 32k of graphics ram for 720x350 mono pixels starting at segment b000. Each "screen ram line" corresponds to 4 physical scan lines, and there's one bit per pixel. There's a sequence of OUT instructions to turn the card from text to graphics modes and back, and I use int10 to get the bios rom's character set map. The files mwin/src/drivers/scr_herc.c are the hercules driver and mwin/src/drivers/elksutil.c are some support functions to read/write far data, etc. I'm looking for volunteers to test, I think this baby should run pretty quickly. It will be slow, since I've implemented hline by calling drawpixel. This needs to be sped up by drawing a scan line directly. I didn't want to do that until I knew drawpixel() works. Excellent! I have examples on how to draw fast lines horizontal, vertical and (x1, y1) - (x2, y2) using Bresenham. These are in a book in asm. so I don't know about their copyright but I think they are intended to be used, ie public domain. Bresenham on Hercules is a little tricky. If I don't remember wrong, there are two buffers on a Hercules (2 * 32k mem) so you can even doublebuffer changes. Now that would be cool to work into the driver. If you other people fix it into working order, I can fix double buffering. Jakob
RE: Microwindows for Hercules
On Thu, 15 Jul 1999, Greg Haerr wrote: : I have examples on how to draw fast lines horizontal, vertical and : (x1, y1) - (x2, y2) using Bresenham. : These are in a book in asm. so I don't know about their copyright but : I think they are intended to be used, ie public domain. : Bresenham on Hercules is a little tricky. No need. MicroWindows handles the Bresenham algorithm in the mid level code in devdraw.c. It uses successive calls to drawpixel to make it work. In this way, people like you and me don't have to rewrite bresenham for every card someone wants That is fine for normal cards, but since Hercules cards are so ... strange... the algo is very optimized for the Hercules. Example: If using writepixel, there need be 16 writes to videomemory. When using the native HGC linedraw, there need be only 4 writes to videomem. BYTEBYTE 7654321076543210 The benefit increases the more horizontal the line is. Also, the algo. uses an incrementing form of bresenham. Very standard, yes. But the incrementing scheme takes into account the bizarre HGC memory layout. Calculating a byte address and bit offset for a given X, Y is rather costly, whatever way you do it. But when drawing a line you know a lot of stuff already, so you are not solving the problem (X, Y) --- (byte address, bit offset), you are only drawing a line. If someone wants asm code I can write it down from the book. The fast line draw that we need is the one that calculates the *bit* starting position in a starting scan line byte, and the end *bit* position. The bits in between the begin and end are then filled with ones. For the bytes inbetween, this is ridculously easy, just set them to 0xff. For the begin and end, use a mask to set those bits... I am not sure about what you mean here. You mean we need an algo that returns BYTEADDRESS, BITSTART and BITEND? : If I don't remember wrong, there are two buffers on a Hercules (2 * 32k mem) : so you can even doublebuffer changes. Now that would be cool to work into : the driver. : If you other people fix it into working order, I can fix double buffering. Neither nano-X or microwindows require or use double buffering currently, This might be useful when bitblt is implemented though... I was rather thinking of a solution not visible to above layers, but maybe that was not a good idea... :-) (A hack.) Regards, Jakob Eriksson
Re: Microwindows for Hercules
On Thu, 15 Jul 1999, Perry Harrington wrote:
Why not take the approach that Linux takes with the module:
Create the driver structure, have the primitives referenced in the
driver structure. If the driver doesn't implement a primitive, set
the structure member to NULL, and the driver loader will take care
to use the builtin function. EG:
struct driver {
ptr_t hline
ptr_t vline
ptr_t bline
...
} DRIVER;
struct driver herc_card[]={
herc_hline,
herc_vline,
NULL
};
That way you can have driver optimized primitives or rely on the default,
which just calls write_pixel.
sounds good.
how much would it take to change/add microwin?
Jakob
RE: herc microwin support
On Tue, 13 Jul 1999, Greg Haerr wrote: On Tuesday, July 13, 1999 12:35 PM, Thomas Stewart [SMTP:[EMAIL PROTECTED]] wrote: : I think it is a good idea to look into herc support for microwin? How many : 8086's do you know with a VGA card? OR is it a bad idea are 8086's too slow : to run microwin? : Well - you've got a good point - an 8086 is probably *way* too slow to run graphics programs of any merit. However, I would like to add a screen driver for hercules. Is hercules only monochrome, or does it support color? Do you know how the screen memory is accessed? Do you think you could write the driver? : If anyone else is interested I have some specs and some assembler examples : of how to control the herc card. Send me the asm examples, I'l take a look. In particular, examples in small model that read and write a pixel, and write a horz and vertical line are all that's needed. In 1997/1998 when my only Linux box was a 386SX with Hercules, I played around with graphics, since I wanted to view pictures. I disturbed a lot of people with questions and could eventually display PCX pictures (I converted all pictures I wanted to PCX using Image Alchemy) on my Hercules screen. I am sending the code to Greg and anyone else asking for it. Almost no asm though (only a couple of instructions) the code is in C. It does not compile, since I messed something up, but the functions shows what and how to do. I am particularly proud of the tightly coded PCX-reader! :-) regards, Jakob Eriksson
RE: new rrd.c ?
On Wed, 7 Jul 1999, Greg Haerr wrote: The pmode ideas are good, but I think you missed the point. A normal, old-fashioned 8086 can be tricked into getting 65535 more bytes of memory than the normal 1 megabyte. This is accomplished by programming the keyboard controller on PC's to hold the A20 line high and then use the 8086's real mode address wrap "feature". I think it would be a good idea, and might even be ok to use it in the ELKS kernel to get another 64k of memory. Of course, whenever the tasks switch, the kernel's got to turn on and off the damned A20 gate. Isn't PC hardware fun 8-) But are there memory cards with the extra 64k? Jakob - puzzled
Re: Technical question boot problem
On Thu, 10 Jun 1999 [EMAIL PROTECTED] wrote: Hi all! I've got a 808[68] maschine with a 40 MB harddisk with MS-DOS 3.3 installed. I want to use this maschine with ELKS in future so I decided to make a backup of the disk first. Can I just move the whole disk with it's adapter card to my Pentium? I noticed that there is a xt disk driver for linux. You may have problems with your BIOS booting from the 40 MB or not making up its mind at all regarding which harddisk to use. This Linux XT driver is intended (AFAIK) for linuxes running only on XT harddrive, no IDE. (Typically som eextremely old 386SX.) Tip: If you end up booting from the 40MB, maybe you can fix things by booting from floppy. My second question is: I have got a problem with running init after ELKS boots under dosemu. It says ,,Loading init'' and just stops. What could be the cause? As a hint: When I start dosemu with xdos -A it complains that sector 1 could not be found. What does this mean? No idea. You ELKSers, please help out. Jakob
Re: Park (Was: Technical question boot problem)
On Fri, 11 Jun 1999, David Murn wrote: On Thu, 10 Jun 1999, Jakob Eriksson wrote: BTW: Do you, Jakob, or somebady else know, whether one has to "park" the xt-disk before shutting down the computer? Is this neccessary, and if, how do I do this with linux and/or ELKS? If no one ports this utility to ELKS, I guess XT drive users just have to be very careful when moving the computer/disk. As long as we're not in protected mode, it's easy. MOV AH,19 MOV DL,80 INT 13 This will park the heads on the first disk (81 for 2nd disk, etc). Very simple little asm program. You could pretty it up if you really wanted though. Ah, great! :-) Somebody smart could add this to the shutdown process in ELKS. Jakob
Re: NanoX version 0.3 released
On Wed, 12 May 1999, Ansel wrote: easily handle. Personally I'm of the opinion that using the BIOS for everything possible is a great shortcut. Lots of device drivers talk to Shouldn't ELKS ultimately be able to run on systems without a BIOS? If you write the code... :-) Jakob
Z80 ELKS and C128 (Was: RE: some questions [OT])
On Mon, 10 May 1999, Klas Axelsson wrote: There was a Z80 add-on chip that could be purchased for a C64 or a C128. I think few people used it, tho... :-) z80 is standard in c128, it's used only by the CP/M mode. I don't know if it's possible to access it at all under normal operation. There is no such thing as "normal" operation on C128. Either you run the built in (always built in) Z80 or the built in 65XX processor. Nothing very magic. Just choose a processor and start executing code. Huh, this is really offtopic... or... c128-elks... There is acctually something called lunix (little UNIX) for the c64 and c128. I don't know very much about it's status but I heard it's able to do some version of multitasking on a c128. And a C64 too. I tried it a few years ago on C64 emulator on an Amiga. Could start three processes, then it hang. :-) http://www.heilbronn.netsurf.de/~dallmann/lunix/lunix.html I've also heard people talking about a TCP/IP implemntation for the c64... "The operating system running on my hardware projects (includes TCP/IP, web server, multitasking and much more) can be found under the OS/A65." http://www.tu-chemnitz.de/~fachat/csa/index.html This guy is a genius IMHO. Jakob
Offtopic!
On Mon, 10 May 1999, Luke (boo) Farrar wrote: If anyone is interested I found some info on wiring a 3" drive to your PC. ie. Amstrad PCW / Spectrum +3 No, But I would like to know how I am supposed to get hold of a "cartridge" or cassette to my Amstrad 8256. Or is it a 3" disk? I can't do anything with it! Jakob
Re: GEM (WAS Re: vgalib)
On Thu, 22 Apr 1999, David Given wrote:
Ahem.
I know two things.
1. It can live on rather small resources in terms RAM and CPU.
[...]
The Graphics Environment Manager was a simple,
but nice GUI for PC ( with 2 floppies
and 512 KB RAM at least ) and for the Atari ST.
Wouldnt it be a good idea to do a port to elks ?
To have the same GUI for DOS, ELKS and the Atari ST
would be a plus.
I've played with GEM. Trust me, you don't want to have anything to do with the
internals of this beast. It's written in a ghastly mixture of C and assembler,
the API is foul and about as non-OO as you can get (and that comes as a
horrible shock to today's generation of programmers), it contains no memory
management code whatsoever (it's a TSR! Honestly! You load the TSR, then you
load an ordinary executable on top of it that uses services provided by the
TSR...) and it's full of arbitrary limits. It also relies on a segmented
architecture a lot.
~
2. It runs on MC68000, (atari) that is not segmented at all.
We'd be a lot better off designing our own very-small-scale windowing system
instead. Then we could backport it to DOS, possibly implementing it on top of
GEM. But porting GEM to ELKS? No way.
Jakob
Re: GEM (WAS Re: vgalib)
On Thu, 22 Apr 1999, David Given wrote:
[...]
Ahem.
I know two things.
1. It can live on rather small resources in terms RAM and CPU.
True; but porting it to ELKS would require an awful lot of developer
resources, that we can't spare.
[...]
TSR...) and it's full of arbitrary limits. It also relies on a segmented
architecture a lot.
~
2. It runs on MC68000, (atari) that is not segmented at all.
But 68k GEM and PC GEM are fundamentally different beasts. Yes, the
*applications* can be source-compatible, if you use the horrific set of
compatability macros provided (and no-one ever does because they are, indeed,
horrific); but the kernels aren't. At all.
Ok.
I read (for the first time actually) how to program the API on Atari, and
thought it was nice.
I'll look into it myself, and since I'm not the one of the resources
you can't spare, no harm's done? :-)
Regards,
Jakob Eriksson
Re: kernel fission was: msdos/umsdos support?
On Wed, 10 Feb 1999, Shane Kerr wrote: On Wed, 10 Feb 1999, Steve Drake wrote: The reason I can see for ELKS is what first lead me to take an interest in it -- the "E" in ELKS stands for "Embeddable." For those looking for a free, open source, embeddable OS, check out: http://www.cygnus.com/ecos/ It does require a 32-bit (or 64-bit) processor, but AFAIK that's not a big deal for real embedded projects. ELKS is for funzies. You can always make an 8086 smaller than 32 bit prcrs., plus it's a known design. I have no problem figuring ELKS running on a wristwatch. Jakob
Re: kernel fission was: msdos/umsdos support?
On Thu, 11 Feb 1999, [big5] ª÷©÷²z wrote: The reason I can see for ELKS is what first lead me to take an interest in it -- the "E" in ELKS stands for "Embeddable." For those looking for a free, open source, embeddable OS, check out: http://www.cygnus.com/ecos/ It does require a 32-bit (or 64-bit) processor, but AFAIK that's not a big deal for real embedded projects. ELKS is for funzies. Hmmm I'm as new as 2 days on this list, and yes, I'm looking ELKS as a possible embedded system also. Real embedded projects we do here are using 186s and that's with 16-bit real mode only. I'm even considering porting ELKS back to 32 bits for 386/486 and ARM. All these are NOT supported by eCos, and I'd think that porting ELKS would be simpler than porting eCos. Yes! Imagine a unix (with memory protection perhaps) running on a Pentium 2-3 whatever running entirely from level 1 cache! :) Jakob
