Re: ELKSibo - "Return to Witch Mountain"
> > Simon Wood writes: > > > > I've been getting a few emails wanting/offering help with ELKSibo (i.e. on > > the Psion Series 3). These have basically prompted me to get on with doing > > some more. I had a play last night and have a few questions/ideas to throw > > at the group - please bear with me. > > > > 1). I have modified the /arch/psion tree to refer to the /arch/i86 tree > > where there are not changes. This is easy for whole directories > > /arch/i86/lib, but more difficult for thing like /arch/psion/kernel which > > has a mix of new and old. > > I tried just referring to the files as ../../i86/kernel/signal.c but the > > problem came when generating dependencies as the '.c' weren't local to the > > makefile. At present I have used symbolic links to the files to overcome > > this. > > Any suggestions, as I believe sym-links are a no no..? That's what the VPATH variable is for. You set VPATH to the location of your source files and it properly checks dependencies. If you have a single source tree, with ifdefs, and you want to build 2 target platform binaries, you would make a Makefile for each, with the appropriate defines, then run a build, the VPATH will find the source and build the binaries wherever the Makefile is. > > > > (Al I'll send you a copy directly in the next couple of days) > > I am sorry, this is my fault for failing to communicate properly, but I > have re-organised the code so that there is not need for the arch/psion > directory. I have got the code to the point where it compiles cleanly > to produce an 8086 version of the kernel. I have not yet tested the sibo > build. > > I have thought about this alot, and tried various ways of aproaching the > problem, and this is in my opinion the best. It makes it much easier to > make changes to the code, keeping both version in sync. The only files > that are so different that separate version are required for the sibo > kernel are crt0.S, crt1.c and irqtab.c, so these sit in a directory > called arch/i86/sibo. Symlinks are impossible because CVS won't manage them > properlly, and rules which refer to files on other directories make for a > very messy build process, and no devent deps. > > Releasing this code has been delayed because CVS was down, and I could > not face merging the code by hand. I will check the code in today, and do > a snapshot release, then merge it into the main branch if you are happy. > > The work I have put in merging the sibo code with the changes made to the > low level code to accomodate booting from ROM were pretty hairy, and I > am now confident it is stable. > > Al > -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
Re: CONFIG_NOFS???
I assume it's for an embedded ELKS kernel. Whereby you compile your application
in the kernel and it gets run as the init process in the kernel context.
--Perry
>
> I've been looking through all the ROM stuff in 0.0.81 and it looks good.
>
> However what is 'CONFIG_NOFS' supposed to do? (NOTE I may be missing the
> point completely).
>
> in /init/main.c it prevents root being mounted, but the next bit is
> 'sys_execve("/bin/init")'. Where is this (/bin/init) supposed to appear
> from?
>
> Simon Wood
--
Perry Harrington Linux rules all OSes.APSoft ()
email: [EMAIL PROTECTED] Think Blue. /\
Re: Redhat Linux6.o for athlon
Nima, Although your comments are off topic for this list, there is no reason to unload some linux zealoutry on you ;) The Athlon should run Linux fine. It doesn't have any optimizations from a kernel standpoint, but that'll come in time. My personal preference is for Redhat 6.0, not 6.1 (the GUI installer is lame for old timers). If you get an athlon, you're going to be paying for floating point performance, and not neccessarily everyday speed. You can save yourself a tremendous amount of money by purchasing a Celeron 550, that'll whoop a p3 550, sans coppermine. --Perry > > Hi, > > Since I am new to Linux, I have a few questions before I buy myself a PC. > > I bought my self redhat linux 6.0 some time back. Is it possible to install > this on a AMD Athlon processor? or do I have to get the 6.1 version? > > OR is it best to buy a PentiumIII processor with a BX board? > > Thanking you in advance! > > > Nima > -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
Re: Hercules on ELKS / Microwindows
I happen to have source in C, C++ and asm available for free use, written by myself. There is also code for 640x480 B&W VGA there too. 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. > > 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. > --Perry -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
Re: Project Seagull
This is a direct take from Visual BASIC for DOS. I happen to actually have this software and keep it just for the fact that you can write nice UI's with it in DOS. Think QBASIC frontended with Seagull. --Perry > > Hello, > > I don't know if any of you have seen the screenshots of Seagull (a GUI for > FreeDOS currently in development). This GUI is entirely ASCII/ANSI based > and it's incredible what they have been able to do. Check out the screenshots > on the FreeDOS website (http://www.freedos.org). If that was ported to > ELKS it would probably run on anything including a lowly 8086. > > -- > ObiTuarY<[EMAIL PROTECTED]> > UIN: 4507732 http://obituary.linuxbe.org > -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
Re: Turbo C
> > Perry, > > Cool! Thanks for the heads-up on that one. Excellent 16-bit compiler. > > I used Turbo C several years doing firmware development for an embedded > 80c186 processor. > > We did not use DOS nor BIOS; we had the Paradigm "locate" program and > burned the code into eprom. Wrote our own startup stuff. > > We had our own real-time kernel (it was initally written in 8080 assembly > however) and I had to get *real* familiar with the code that Turbo C > generated to get them to play together. > Sounds like the ELKS list has a good resource for using TC. > At the time I had talked to Rick Naro (Paradigm founder) and he said it > was possible to multitask the Turbo C floating point library. The float > context is stored at the base of the stack segment in the first 500 or so > bytes (i.e. SS: -> SS:01FF). I never actually ended up messing with > this however. > > Does elks currently have floating point support? Perhaps this would be > a way to do it? (I just rejoined after being away for a year or so) I don't think ELKS has floating point support yet, Alistair would be the best person to ask this question to, I think. > > Scott > --Perry -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
Turbo C
I brought up a thread a long time ago on this, Borland wasn't interested then, but they just released Turbo C for free. This means we can use it for compiling in the ELKS project. The idea would be to get a real mode compiler that can do the things we want, but it would need a back end linker to produce ELKS executables. Check out slashdot, it's where the news is. --Perry -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
Re: Microwindows for Hercules
>
>sounds good.
>how much would it take to change/add microwin?
That, I don't know, Greg?
>
> If someone's really going to take that approach (I assumed something
> like this was already being done), then I recommend modifying it a
> little for speed. Instead of leaving NULL in the table and having to
> test it each time the function is being called, replace the NULL with
> a function pointer. This can either be done in the device driver
> directly:
Obviously it would be smart to fill it in. However you must set it to NULL
in the driver because of symbol resolution.
As long as the device driver header file version matches with the one that
the microwin server uses, the offsets are known.
Locating the symbols inside the driver is the hard part.
Perhaps a separate file, created via an external program, which contains
this structure, is the better way to go. This way when the structure changes,
you don't have to go around recompiling all the drivers that have been
distributed, you just need a program to fixup your jumptable files.
Does anyone know if code exists to hunt for symbols inside a binary? Does
bcc generate any symbol information?
If bcc doesn't generate any symbol info, then I would suggest that each driver
be an archive of object files, with a manifest. You would need the code from
the linker to search the archive and something to read the manifest.
>
> struct driver herc_card[]={
> herc_hline,
> herc_vline,
> generic_line,
> };
>
> or it can be done in a function that examines the structure at load
> time and patches up any NULLs with real function pointers. This is a
> good way to reduce the special cases.
> --
> "...dans ce pays-ci il est bon de tuer de temps en temps un amiral
> pour encourager les autres."
> --Voltaire, _Candide_
>
--Perry
--
Perry Harrington Linux rules all OSes.APSoft ()
email: [EMAIL PROTECTED] Think Blue. /\
Re: Microwindows for Hercules
> If using writepixel, there need be 16 writes to videomemory.
> When using the native HGC linedraw, there need be only 4 writes to videomem.
>
> Also, the algo. uses an incrementing form of bresenham. Very standard,
> yes. But the incrementing scheme takes into account the bizarre
> HGC memory layout.
>
> Regards,
> Jakob Eriksson
>
>
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.
--Perry
--
Perry Harrington Linux rules all OSes.APSoft ()
email: [EMAIL PROTECTED] Think Blue. /\
Re: Capabilities
Conceptually this is how memory management works on post 8086 processors. The
8086/8 doesn't have any mechanism for trapping memory accesses, thus tables
are not possible.
--Perry
>
> I really don't see where this is a problem. User level processing does not
> need
> hardware memory protection; it could be implemented as a strictly software
> solution. For example, a table defined within the OS giving the user and the
> level. Then, all memory access could interrogate this table and give pseudo
> memory level security.
>
> ==
> Never cross a dragon - for you are crunchy and taste delicious!
> My major interests are:
> Amateur {Ham} Radio - N8MGU | Opera-Jazz-Musical Theater | Sailing | Judaica
>
--
Perry Harrington Linux rules all OSes.APSoft ()
email: [EMAIL PROTECTED] Think Blue. /\
Re: Capabilities
> > > In addition, the user programs could be protected from the kernel and vice > > versa... Note, without memory protection we really have no lower priviledged users, all users are the equivelent of root. Users exist merely to provide some logical division. > > And that would be a big bonus, especially for embeded systems > Luke(Boo) Farrar. > -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
Re: ELKS video drivers...
The MDA was a text only adapter. The HGC was the first to implement any dot addressable graphics with the mono hardware. FWIW, they both used the same CRTC (as does the CGA), they just program it differently. The 6842 I believe was the CRTC. --Perry > > On Mon, 17 May 1999, Greg Haerr wrote: > > > > 1. IBM MDA. > > no graphics support... > > Umm, are you sure? We used to run windows 3.0 on amber monochrome > monitors at college. > > Davey > -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
BIOS get code
I wrote a little C program to fetch the ROM BIOS of a machine.
I wrote it on my Compaq Portable III with TC 2.01. The source
is included, you can get the binary and sample Compaq ROM from
ftp.apsoft.com:/pub/users/perry/tc/
I just writes out 64k at 0xF000:0 to 'bios.rom'.
--Perry
--
Perry Harrington Linux rules all OSes.APSoft ()
email: [EMAIL PROTECTED] Think Blue. /\
---
#include
#include
void main(void)
{
charfar *bios_data;
FILE *out;
bios_data = MK_FP(0xf000, 0x0);
out = fopen("bios.rom","wb");
if (out == NULL) {
printf ("Failed to open bios.rom\n");
exit(1);
}
fwrite(bios_data, 0x, 1L, out);
fclose(out);
exit(0);
}
Re: ELKS on HP200LX
Vector Interrupt images are not compatible from one system to the other. The interrupt vector table has segment:offset pointers to the ROM BIOS routines. These segment:offset values are installed by the BIOS upon bootup of the machine. I don't know how to get a clean 200LX image, but I can tell you that using another machine's VII is a bad idea. --Perry > > Well, I've tried to run ELKS on my palmtop and I don't know if I'm having > success. > I use Steffen Gabel's bootelks which needs a kernel image and a *clean* > vector interrupt image. > The kernel it's ok, I compiled it from last source. The problem is with the > vector interrupt image, because I don't have how to make it. > The bootelks uses a way to get this vii, writing a little program on sector > 0 0 1 of a floppy disk. When you boot the system with this floppy disk, it > gets a clean vii. > The HP has DOS in ROM and I can't boot her from flash card or other device, > so i can't have this image. > I'm trying to make this image through my pentium but i guess that it's not > working because when I run bootelks, it gives the following messages: > BELOW! > Loading interrupts image... > Success. > Loading kernel image... > Success. > > then, if it doesn't crash, it reboots the system... Any idea ? > > .~. > /V\ N[e]xt L[e]v[e]l > // \\ Isaque Galdino > /( )\ Programador C/C++, PL/SQL > ^`~'^ Linux, DOS e Win... ops! :) > -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
Re: Announcing the Development of DOSBell
You can get the source to Novell Dos 7 from Caldera, off their website, it's been GPLd I believe. Anyhow DRDOS 6.0 and Novell Dos 7.0 had 286 task switchers with them as a 'program'. > Hmm.. Is there any code out there that is 8-bit and quite reliable at task > switching. Its a pity I can't get Dosshell's source code (remember, from > MS-DOS 5.0?). I'm going to make a simple task switcher and then add some > timing to it to come up with a pseudo-stable multitasking environment. > > -- > e-mail: [EMAIL PROTECTED] www: http://www.croftj.net/~mstrates -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
Re: Redistributing an ancient version of Dos extender (fwd)
Phar lap appears to be stubborn and clueless. Looks like we need a different product. Anyone know of a good free 286 dos extender? I'm still working on the Borland thing. --Perry > > Hello Perry, > > Unfortunately, we cannot help you here. > We are not prepared to release any of our products under a freeware license. > > If you know of any developers who need to use a DOS-Extender, please feel > free to forward them to us directly. We would be happy to introduce Phar > Lap products to them. > > Phar Lap has always been recognized as the leading dos-extender vendor > because of our expertise in product feature development and our expertise > in technical support. We hope you can continue using Phar Lap under our > standard binary license agreement and run-time license agreement. However, > if you must find another dos-extender to work on this project, I do wish > you luck in your development. > > If you have any additional questions, please contact me at 617-661-1510 > ext.233. > Sincerely, > Maria Giatrelis > > > > > At 05:24 PM 12/8/98 -0800, Perry Harrington wrote: > >Maria, > > > > Is there any possibility that Phar Lap would release their downrev > products under > >a freeware license? Meaning, that a product which is N years old would be > freely > >redistributable? > > > > This product has sat in one of my desk droors for 5 years, unused. I > would like > >to provide it's functionality to developers who could use it. > > > > If Phar Lap does not want to modify their License agreement, then the > project > >must find another DOS extender for development. This project is a Open > Source > >project, so there is no entity that can be dealt with, only a loose > collaboration > >of developers. > > > >Thank you, > > > >--Perry > > > >> > >> Dear Perry, > >> > >> Thank you for your inquiry on Phar Lap's DOS-Extenders. > >> > >> The Lite version of our dos-extender was used as a demo version. > >> One cannot use the lite version to develop applications. > >> > >> The full SDK can be used to develop applications and if you need to > distribute > >> the application, a run time license must be purchased. > >> > >> A full SDK is sold per seat, per developer, per workstation. In other > words, > >> you need to purchase one development SDK for each developer using the > >> dos-extender. > >> If you would like to purchase more development seats, please contact > >> [EMAIL PROTECTED] > >> > >> Our license agreement does not allow the distribution of obsolete versions > >> of the Dos extender into > >> a freeware or Open Source (re)distribution. We cannot amend the contract > >> to do so. > >> > >> If you have any additional questions, please contact me directly at > >> [EMAIL PROTECTED] or > >> 617-661-1510 ext.233. > >> thank you, > >> Maria > > > >-- > >Perry Harrington Linux rules all OSes. APSoft () > >email: [EMAIL PROTECTED] Think Blue. /\ > > > -- > Maria Giatrelis [EMAIL PROTECTED] > Phar Lap Software, Inc. > 60 Aberdeen Ave. phone: +1 617.661.1510 ext.233 > Cambridge, MA 02138 USA fax: +1 617.876.2972 > > > > > http://www.pharlap.comhttp://smallest.pharlap.com >http://webfarm.pharlap.com > -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
Re: ELKS 286pmode
I have the Phar Lap 286 Pmode DOS extender floppies that I can put online if anyone wants them. I can also provide Any Borland C compiler from TC 2.01 to BC 3.1 for anyone wanting to compile with it. I have thought about doing ELKS in pmode, and I think the best way to bootstrap (read, fix the broken code) would be to use a DOS based pmode environment. If anyone wants this stuff, speak up, especially if you really think you can use it. It would be in the form of downloadable floppy images. --Perry > > In message <[EMAIL PROTECTED]>, Nyef > writes: > [...] > >My goal: a running pmode system by January 15th at the absolute latest (I > >really want it done by December 31, but I'm leaving a margin for error). > >"Lead, follow, or get out of the way", Who's with me on this? :-) > > Excellent! I'm afraid I have too much on my plate at the moment to help > with anything, even if I had the necessary knowledge, so I'll go for `get > out of the way'; but I shall remain on the list to offer biased opinions, > comments and/or sarcastic remarks as the need arises. I look forward to > having a look at further developments. > -- Perry Harrington Linux rules all OSes.APSoft () email: [EMAIL PROTECTED] Think Blue. /\
