On Thu, 13 Jul 2000, Greg Haerr wrote:
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
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
for(i=0; i6; ++i)
;
nosound();
}
which is way too long (5 seconds) for any 8086 I've ever used (or my
Tandy's V-20). Is there something akin to bogomips that is tested by ELKS
that can be used to set the loop to some processor speed dependent value?
Use the bogomips
Risking getting another message from Topica ..
port of the ELKS machine. It seems to work fine both ways at the 9600 bps
that is the default using 'cat /dev/ttyS0' though cat seems awfully
slow. How do I set the ports to other speeds, other than modifying the
kernel source?
There is a
is out there and ported to a micro or two. Only does PPP though.
It appears to be derived from KA9Q, BSD and Linux code. I think the site
is http://www.ucos-ii.com/
KA9Q is $50 a copy of non education/non amateur radio users
Alan
--- "W.L. van der Poel" [EMAIL PROTECTED] escreveu:
for you guys to look up old XINU again. If somebody still wants a
copy of XINU, please send me an email and I will see to it that
Hey, thank you, I have the book but I don't have the sources!
With the still lowering prices of PC's it sounds
FullTurtle
a heart (OS) transplant. I want a RDBMS running there. I want a X system
running there.
I'm not sure I would want to run X on the HP200lx. Ok, I know it's a nice
palmtop (I have one) but I dont think it would be fast enough or have enough
system ram (you only get 640k) to run X
From: "[EMAIL PROTECTED]" FullTurtle
a heart (OS) transplant. I want a RDBMS running there. I want a X system
running there.
I'm not sure I would want to run X on the HP200lx. Ok, I know it's a nice
palmtop (I have one) but I dont think it would be fast enough or have
enough
system ram (you
Is the TCP/IP project totally dead, or is someone still working on it? I
have an ATT PC6300 just waiting for me to install ELKS on it, but
without a TCP/IP stack, it is of limited use to me. I **really** want to
put it back into service!! Thanks - Larry
AFAIK nobody's doing anything. I saw
Then I am missing quite a bit of recognition of the early work in
porting UNIX in the form of Minix by the group of Andy Tanenbaum.
We still have the minix format around, but Andy was one of the
first the throw open the full source code for Minix in his book:
Operating Systems, Design
Hi,
I've been doing the Psion stuff, and also have an interest in an ARM port.
Particularly with the embedded versions that contain a whole load of
peripherals (serial/dram controllers/LCD etc. etc.).
What platform/processor are you starting with? and (the big question) how
far have you got?
I have started porting ELKS for ARM.
Is is somebody working similar project?
I believe there is a ucLinux ARM project for the 7500T. (ucLinux is full
Linux without an MMU)
Alan
I'm sorry for late response. I have to sleep a little :).
Hi,
I've been doing the Psion stuff, and also have an interest in an ARM port.
I've known your great work. And I would like to assitant your work for ARM.
Particularly with the embedded versions that contain a whole load of
Hi David.
All you have to do is to insure your ROM image uses correct
format (utils in netboot package create correct images from
executable binaries) and BIOS will do the rest of the job
Actually, 'format' simply means 0x55aa at the start of the
image, and the 3rd byte contains the
On Tue, 23 Nov 1999, Riley Williams wrote:
Hi Ed.
I am a programmer and would like to help out I can. I have a 4
computer ethernet local area network at home I would be happy to
test out any network drivers you come up with. I would also be
willing to help on the coding if needed.
Hi Alistair.
Not really--All I know is that PCs and XTs fell back on cassette
BASIC when the disk boot failed--AMI BIOS still makes a call to
it when it fails, but the BASIC roms don't exist in post-8088s.
It does seem intriguing, though. I'll see what I can come up with.
I have
Riley Williams writes:
The original setup was actually quite simple, and worked as follows:
1. On power-up, the CPU switches itself into Real mode and
starts running the BIOS POST routines.
2. After completing the POST, the BIOS scans through the rest
of the BIOS area looking
How do Video BIOS make sure they are executed before everything else?
Video BIOSes are looked for as a special case. They are normally located
from C to C8000.
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
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.
Another possibility is two NICs with a 32kB ROM each.
Gregory Leblanc writes:
-Original Message-
From: Alistair Riddoch [mailto:[EMAIL PROTECTED]]
Sent: Sunday, November 14, 1999 4:19 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: ELKS 0.0.81 available from
I have a 3c905 in my desktop machine which can take 64K or 128K, but it is
not clearly documented anywhere I can find which end of the socket I am
supposed to put the ROM, and I could not get it to work in either end when
I tried it in both. The other problem is that this card is PCI, so wont go
Ken Yap writes:
I have a 3c905 in my desktop machine which can take 64K or 128K, but it is
not clearly documented anywhere I can find which end of the socket I am
supposed to put the ROM, and I could not get it to work in either end when
I tried it in both. The other problem is that this
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.
Have you considered using a compressed ROM image like Etherboot does? With
that you could get
Ken Yap writes:
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.
Have you considered using a compressed ROM image like Etherboot does?
On 13-Nov-99 David Murn wrote:
On Sat, 13 Nov 1999, Stefan Pettersson wrote:
So we are back to the usual problem, where in the 640 kB should we put
or own EPROM.
Sorry, my fingers wasn't syncronized with my brain. What I meant was:
So we are back to the usual problem, where in the
Stefan Pettersson writes:
On 13-Nov-99 David Murn wrote:
On Sat, 13 Nov 1999, Stefan Pettersson wrote:
So we are back to the usual problem, where in the 640 kB should we put
or own EPROM.
Sorry, my fingers wasn't syncronized with my brain. What I meant was:
So we are back to the
The code Christian has contributed does just this, though I have not yet
been able to get it to work as I am still tracking down a network card that
will take a 64K ROM. I have the plans for a flashcard, but have not yet
been able to get thte parts to build one.
I've seen some NE2000 clones that
Sorry, my fingers wasn't syncronized with my brain. What I meant was:
So we are back to the usual problem, where in the 640kB..1024kB range should
we
put or own EPROM.
Somewhere free from C8000 to F.
BTW, neither BIOS nor cassette ROM map to low memory--BIOS starts in the
0E range for PS2s, 0F for normal ATs, cassette Basic having a
start of about 0F6000. This might provide some interesting
consequences, as the Linux Kernel maps BIOS with all zeros, the
BIOS being unnecessary to the
On Sat, 13 Nov 1999, Stefan Pettersson wrote:
So we are back to the usual problem, where in the 640 kB should we put
or own EPROM.
On x86 you've got 20 address lines, this is 0-1mb. What do you think the
space is reserved for from 640k-1024k? ROMs. When the system boots, it
will probe
This is unverified, but
I think the Basic-hook is still there, untouched.
But some of the EPROM area reserved for Basic has been used for the setup
subprograms.
So we are back to the usual problem, where in the 640 kB should we put or own
EPROM.
Nowhere. There is a memory area meant for
On Sat, 13 Nov 1999, Blaz Antonic wrote:
All you have to do is to insure your ROM image uses correct format
(utils in netboot package create correct images from executable
binaries) and BIOS will do the rest of the job
Actually, 'format' simply means 0x55aa at the start of the image, and the
Actually, 'format' simply means 0x55aa at the start of the image, and the
3rd byte contains the number of 256 byte pages in the ROM. Nothing else
is involved in the 'format'.
0x55aa
number of 256 word = 512 byte pages
entry point, entered with long jump and cs = segment of ROM
All the bytes in
I have come across a few old machies that had sockets like this, but
never
one that actually had a BASIC rom in it. I don't know what the ROM in
this
socket needs to contain in order for the BIOS to recognise it as a BASIC
ROM and run it if boot fails.
I think the BASIC ROM has a
ber 11, 1999 9:14 AM
Subject: Re: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
Thomas Stewart writes:
Not really--All I know is that PCs and XTs fell back on
cassette BASIC when the disk boot failed--AMI BIOS still
makes a call to it when it fails, but the BASIC roms don't
exist in
On 12-Nov-99 Sam Steele wrote:
My PCjr has a BASIC ROM (a slightly modified version that shows off
the "advanced grahpics/sound" of the PCjr when you hit escape as soon
as it starts), and when booted without a harddrive, my AMIBIOS based
K5 says "NO ROM BASIC", so I don't know if the BASIC
John Galt writes:
Not really--All I know is that PCs and XTs fell back on cassette BASIC
when the disk boot failed--AMI BIOS still makes a call to it when it
fails, but the BASIC roms don't exist in post-8088s. It does seem
intriguing, though. I'll see what I can come up with.
I have
Not really--All I know is that PCs and XTs fell back on cassette BASIC
when the disk boot failed--AMI BIOS still makes a call to it when it
fails, but the BASIC roms don't exist in post-8088s. It does seem
intriguing, though. I'll see what I can come up with.
I have come across a few
I have come across a few old machies that had sockets like this, but never
one that actually had a BASIC rom in it. I don't know what the ROM in this
socket needs to contain in order for the BIOS to recognise it as a BASIC
ROM and run it if boot fails.
I think the BASIC ROM has a particular
Nice
Anyone know where I can get a rom blowing thingy?
Have you actually tried this?
Is bios required?
Luke(Boo) Farrar.
Christian Mardmuller ([EMAIL PROTECTED]) has contributed the code required to
build ELKS so that it can be booted from ROM. It is now possible by
specifying an
Luke writes:
Nice
Anyone know where I can get a rom blowing thingy?
Maplin sell them quite cheap. I use one of the ones available in the
University labs.
Have you actually tried this?
I successfully build and programmed an image onto a ROM, but could not get
it to boot as I
Hi Al,
On Mon, Nov 08, 1999 at 06:25:15PM +, Alistair Riddoch wrote:
here you have a working version of init.c, maybe I'll be able to do something more
on it one of these days...
Okay, I will check it out, and if it works I will put it into the next
distribution.
that is nice!
but,
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
one more thing: the `date.c' does nothing about setting the date. can we
use anything else than BIOS calls to do that?
If the machine has a CMOS clock (note XT's dont generally have this) you can
do it in userspace by hitting the I/O ports. Its not really worth putting
in kernel on such a
I guess that you could say that XTs are truly Y2k hardware compliant :)
On Wed, 10 Nov 1999, Alan Cox wrote:
one more thing: the `date.c' does nothing about setting the date. can we
use anything else than BIOS calls to do that?
If the machine has a CMOS clock (note XT's dont generally
Greg Haerr writes:
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.
I have
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
hi
ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.83.tar.gz
Greg
Would it be a good idea to put a link to this on the main ELKS web site?
Greg you must be getting board telling eveyone where it is?
tom
__
Get Your Private,
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
Where can we find the current version of NanoGUI/MicroWin?
--
"It's not about the money...It's about the rules. Without rules,
we might as well be tree climbers flinging crap at each other."
- Red
Yes the start of a port has been done but I kind of got distracted by
various other toys (new distro's, TV card, tiling Kitchen...)
A (not quite up to date) version of the port can be found at:
http://www.mungewell.ndirect.co.uk/linux/index.htm
I'll try and get motivated enough to
Simon Wood wrote:
Yes the start of a port has been done but I kind of got distracted by
various other toys (new distro's, TV card, tiling Kitchen...)
A (not quite up to date) version of the port can be found at:
http://www.mungewell.ndirect.co.uk/linux/index.htm
I'll try
Patrice Kadionik writes:
Hi all,
I intend to reuse very old pcs under linux and discovered ELKS :-)
I'm looking for a howto on ELKS installation more detailled than the FAQ on the
ELKS site ? Has anybody pointers on it (tutorial, howto, manual...) ?
I am afraid there is no more
Denis Brown writes:
Hello.
For what it's worth, I have been able to run ELKS 0.0.79 on an IBM PS/2
without any hassles. I seem to recall discussion on this list a while ago
suggesting that some oddities with the PS/2's keyboard or mouse port
created hassles. Happily that is not the
Hello.
For what it's worth, I have been able to run ELKS 0.0.79 on an IBM PS/2
without any hassles. I seem to recall discussion on this list a while ago
suggesting that some oddities with the PS/2's keyboard or mouse port
created hassles. Happily that is not the case here.
Brief summary:
IBM
Soete Joel writes:
Without knowing exactly to whom have I to send and or request
information, I submit you following remarks; hopping that it will be
helpful:
As I just recompile elks and elkscmd (together referenced -0.0.78) to
create a combine image to try on an old "portable" Toshiba
: 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
On Thu, 19 Aug 1999, Gary Watson wrote:
Hi,
Has anyone put ELKS on an AMD Net186? This is the little Am186 demo board
with 512k flash and 512k ram, no floppy drive or other peripherals, and a PC
Net ISA-II 79C961A network chip. Does ELKS have the capability to run
TCP/IP?
No
On Mon, 19 Jul 1999, Dan Olson wrote:
A few of us had this exact same problem on PS/2 machines, and I believe
the problem ended up not being the disk drive but rather the keyboard not
being detected. A simple test, if you can do it, would be to try the
combo boot/root image, and see if
I just tried it and found the same thing on a ps2. It's the keyboard that
it has a problem with. With the comb image it mounts the root disk fine,
runs init fine, then you can't login because of the keyboard.
I have already suggested to use BIOS console instead of direct one on
PS/2 machines
On Tue, 20 Jul 1999, Blaz Antonic wrote:
I have already suggested to use BIOS console instead of direct one on
PS/2 machines long time ago, but noone tried it.
So, disable dircon and enable bioscon support in config, recompile and
try again. Please let us know whether it works or not (in
At 09:42 AM 7/20/99 +0100, Luke (boo) Farrar wrote:
On Mon, 19 Jul 1999, Dan Olson wrote:
A few of us had this exact same problem on PS/2 machines, and I believe
the problem ended up not being the disk drive but rather the keyboard not
being detected. A simple test, if you can do it, would be
Greg Haerr writes:
Al,
After receiving ELKS v0.78, I compiled Microwindows and Nano-X for
it and found we need one more kernel patch, and have several other items
in elkscmd, some of which were missed. Overall, ELKS 0.78 is a great step
forward for ELKS and MicroWindows.
: 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
A few of us had this exact same problem on PS/2 machines, and I believe
the problem ended up not being the disk drive but rather the keyboard not
being detected. A simple test, if you can do it, would be to try the
combo boot/root image, and see if it hangs or not. Sence you are using
5.25"
On Wed, 14 Jul 1999, Luke (boo) Farrar wrote:
bcc -0 -O -ansi -s -ansi fsck.c -o fsck -H
undefined symbol: _S_ISSOCK
It would be nice as a hard disk filing system is fairly useless without
it.
Well, ISSOCK is checking if stat() was done on a socket. Not much use at
all until the OS
The drive light never goes off on my system either, but ELKS 0.77 runs
fine. Is your problem that ELKS doesn't work, or with the drive light?
Greg
Hello to everybody.
I've been following the list from June. It's the first time I write.
I have high hopes about ELKS because I
: Not quite. I didn't actually know about the 512k limit, but greg says
: it's there. libc is tiny, as all ELKS programs are statically linked, so
: libc+program must be less than 64k.
:
The issue here is that the size of the libc.a file itself is 512k, so
the filesystem won't let
On Wed, 14 Jul 1999, Greg Haerr wrote:
The issue here is that the size of the libc.a file itself is 512k, so
the filesystem won't let ld86 read it...
It is? I dunno where you got your libc.a from, but mine is 82k. libc
under Linux is 512k, but under ELKS, it's tiny.
Davey
On Wednesday, July 14, 1999 10:41 AM, David Murn [SMTP:[EMAIL PROTECTED]]
wrote:
: On Wed, 14 Jul 1999, Greg Haerr wrote:
:
: The issue here is that the size of the libc.a file itself is 512k, so
: the filesystem won't let ld86 read it...
:
: It is? I dunno where you got your libc.a
On Thu, 15 Jul 1999, David Murn wrote:
On Wed, 14 Jul 1999, Greg Haerr wrote:
The issue here is that the size of the libc.a file itself is 512k, so
the filesystem won't let ld86 read it...
It is? I dunno where you got your libc.a from, but mine is 82k. libc
under Linux is
: You killed my baby?? Exactly how has it stopped working? It's not a very
: complete implementation, only half-a-dozen ANSI commands are supported.
Killed your baby? Why, it seems this one died from neglect ;-)
try typing ESC [ H on the console. Nothing happens.
:
: o added
On Mon, 12 Jul 1999, Greg Haerr wrote:
Killed your baby? Why, it seems this one died from neglect ;-)
try typing ESC [ H on the console. Nothing happens.
Yep, it won't do anything. The only commands supported, are: m (color),
s (save location), u (unsave location), A (up), B (down),
email the patches for elks 0.77 and elkscmd 0.77.
:
: o Ported elvis to ELKS
:
: Is this based on the code that was in elkscmd?
Yep.
:
: o changed all elkscmd srcs to use tcsetattr/tcgetattr instead of ioctl
:
: I previously held back from doing this to make the
: Yep, it won't do anything. The only commands supported, are: m (color),
: s (save location), u (unsave location), A (up), B (down), C (right),
: D (left), K (clear EOL). Mainly because these functions were already
: existing in the dircon code so it was very easy to interface to them.
:
:
: I agree, but of late I've had little enthusiasm to try and trim the fat
: off the larger areas of the code. In particular, the inode hashing code
: in fs (or is it specific to minixfs) is basically redundant. Firstly, we
: can do without hashing for a slight speed decrease. Also, the
Al,
In regards to patch #2, are you trying to make almost all the mods I sent in,
including the elkscmd makefile stuff? I would like it if you could.
Also, I have rewritten dircon.c last night (except for the bell()) issue that you just
mentioned). I have attached it. It is better
This is why elvis, as86, and many, many other large programs have never
run. Elks never let programs have 32k data segments!
With this fix, I plan on self-hosting bcc and as86, which now will
run...
The reason bcc wouldn't run was because it was too large ( 64k) to even
link.
On Tue, 13 Jul 1999, Greg Haerr wrote:
: I agree, but of late I've had little enthusiasm to try and trim the fat
: off the larger areas of the code.
Hmm.. I haven't got to that yet. What other areas are bloated?
I basically did an: ls -lS `find -name *.a` to find all the large
On Tue, 13 Jul 1999, Luke (boo) Farrar wrote:
Do we still have the 512k file size limit?
I thought that libc was bigger than this or something, and that was one of
the limiting factors on a self hosted bcc.
Not quite. I didn't actually know about the 512k limit, but greg says
it's there.
Greg Haerr writes:
Al,
I worked on getting up to date this weekend on the linux-86 devkit (v0.14.8)
and ELKS (v0.77). After quite a few compile time problems, I got everything
compiling and working. I'll detail the problems later, and submit a patch.
I can't get
David Murn writes:
On Mon, 28 Jun 1999, Chris Starling wrote:
Is there a better, more stable way to do ELKS emulation?
Is running ELKS in vmware, or dosemu an option? This is how most
development is done I think, and it means that you can test in the real
ELKS rather than an
: Making the contents of images.zip is not fully automatic, but most of the
: work is done by the Makefiles. I change the Makefile a bit between buidlign
: comb and root (modify size etc.)
:
I would *really* like a makefile that automatically makes your
distribution. (its a quality
: I have seen something like this, but it has never frozen on me. In nano-X,
: whenever I stop moving the mouse, the cursor stops moving (as expected),
: but when I start moving it in the oposite direction, it moves a few pixels
: in the same direction as before, then changes to move in the new
This is interesting, I was just getting ready to do this myself. I'm
running 2.2.5.
I would be interested in knowing whether you crash after loading the module, but
never
having run an elks binary. In other words, is it just the loading or rather the
execution
of the emulator
On Monday, June 28, 1999 12:25 PM, Chris Starling [SMTP:[EMAIL PROTECTED]] wrote:
: This is interesting, I was just getting ready to do this myself. I'm
:running 2.2.5.
: I would be interested in knowing whether you crash after loading the module, but
:never
: having run an elks
On Mon, 28 Jun 1999, Greg Haerr wrote:
I can't get Micro-Windows to work with the serial mouse driver.
It appears there's still possibly a bug in select(). Basically, the
mouse works for about 1 second and then freezes.
As I read this, the first thing that pops into my head is that
On Monday, June 28, 1999 1:37 PM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
: On Mon, 28 Jun 1999, Greg Haerr wrote:
:
: I can't get Micro-Windows to work with the serial mouse driver.
: It appears there's still possibly a bug in select(). Basically, the
: mouse works for about 1 second
On Monday, June 28, 1999 1:37 PM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
: On Mon, 28 Jun 1999, Greg Haerr wrote:
:
: I can't get Micro-Windows to work with the serial mouse driver.
: It appears there's still possibly a bug in select(). Basically, the
: mouse works for about 1 second
On Mon, 28 Jun 1999, Greg Haerr wrote:
On Monday, June 28, 1999 1:37 PM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
: On Mon, 28 Jun 1999, Greg Haerr wrote:
:
:I can't get Micro-Windows to work with the serial mouse driver.
: It appears there's still possibly a bug in select().
Greg Haerr writes:
: The fixed size stack would probably be best placed just above the bss with
: the heap above that. This would not require any mods to the linker or
: binary format, just changes to the kernel.
:
What exactly is being gained by making this modification? The
Greg Haerr writes:
: The function stack_check() in arch/i86/kernel/process.c checks to see
: whether the stack pointer is less then the brk pointer, and segfaults if it
: is.
:
stack_check() is used by the kernel to see if the user process
has run out of space, only during a
Chad Page writes:
There is (was?) some stack checking done at the system call level.
However, it's not 100% foolproof - if the program gets sp above the
low-water mark after dipping into bss before the next system call it won't
be detected.
Now, if you had a magic # right
: What exactly is being gained by making this modification? The stack
: is fixed size in both cases. Is it just that we currently pre-reserve the maximum
: combined heap/stack now, and in the future wouldn't require the heap size
: to be known?
:
:
: Thats it exactly. Currently even
: So form of stack check would be nice, every function call seems a little to
: much for a lowly 8086. How about on task switch or even interrupt (or is
: this too late)? If the chosen size for the stack is too small, it can be
: cured by modifying the binary rather than a full recompile.
:
:
Greg Haerr writes:
:What exactly is being gained by making this modification? The stack
: is fixed size in both cases. Is it just that we currently pre-reserve the
maximum
: combined heap/stack now, and in the future wouldn't require the heap size
: to be known?
:
:
:
Greg Haerr writes:
: So form of stack check would be nice, every function call seems a little to
: much for a lowly 8086. How about on task switch or even interrupt (or is
: this too late)? If the chosen size for the stack is too small, it can be
: cured by modifying the binary rather
On Friday, June 25, 1999 2:12 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote:
: Greg Haerr writes:
:
:
: : So form of stack check would be nice, every function call seems a little to
: : much for a lowly 8086. How about on task switch or even interrupt (or is
: : this too late)? If
I know that the code sized is fixed when an application is compiled, as is
the initialised and un-initilised data.
This gives us minimum code and data segment sizes.
Yes
We also need a stack, and maybe some heap space:-
Where does this go and how is it allocated?
Linux 8086 takes a
1 - 100 of 176 matches
Mail list logo
