From: Brad Normand <bigbadbrad@gmail.com>
To: linux-8086@vger.kernel.org
Subject: Some words of encouragement
Date: Fri, 24 Feb 2012 11:26:22 -0600 [thread overview]
Message-ID: <CAGc3vb0t9fR+8i-MN=ieerwT2WERDQH9WYdsYbLOR=yMLsr4qw@mail.gmail.com> (raw)
I've been watching this list for a while and I'm happy development is
continuing! The last time I tried playing around with ELKS, I
couldn't even get things to compile, and had I succeeded, I got the
feeling I wouldn't be too impressed.
In case anyone's interested, my wishlist:
Support for 100% BIOS I/O (eventually I'd like to run this on
non-standard hardware, Sanyo MBC-55x, so any in/out opcode and
interrupt hooking will fail to work as intended). Where necessary,
BIOS RAM can be probed and this shouldn't be a big problem.
Support for reserving some low memory area (again due to hardware constraints).
Some method to transfer data to/from FAT12.
And, a question... how feasible would it be to run anything with 256KB
RAM? I was tempted to reply to the EMS code message because to make a
useful ELKS machine out of these, I may have to design a memory
expansion board, and I've got lots of 4MB SIMMs laying around.
Otherwise without kernel bankswitching support (or through EMS calls)
I believe I can do 960KB.
I also have a strange memory management idea that may be
interesting... Since 8086 is a 64KB segment oriented machine and you
are already bumping up against the limitations of that, and there is
talk of changing compilers... how crazy would it be to design a new
segmentation ABI to allow relocation of segments and still allow
programs to use more than 64KB?
I'm thinking something along the lines of, instead of using mov DS,AX
type instructions, these are changed to an OS call, so that the kernel
knows what segments the userspace is using, and when it has to
relocate data, it can simply rewrite the stored CS,DS,ES,SS of the
userspace, and next time the userspace needs to switch segments, it
asks the OS to do the dirty work. Managing >64KB allocations is
possible too but basically the program needs to request a 64KB window
into the data at a time. This would probably be pretty directly
applicable to a bankswitching scheme as a poor man's MMU.
Sorry for the craziness but I've spent many hours pondering this stuff
in the past... if there's interest I'd be happy to put together a
specification of sorts.
next reply other threads:[~2012-02-24 17:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-24 17:26 Brad Normand [this message]
2012-02-24 18:22 ` Some words of encouragement Jody Bruchon
2012-02-25 0:54 ` David Given
2012-02-25 6:27 ` Brad Normand
2012-02-25 12:53 ` David Given
2012-02-25 13:13 ` David Given
2012-02-25 18:04 ` Brad Normand
2012-02-25 19:09 ` David Given
2012-02-25 20:29 ` Brad Normand
2012-02-25 21:04 ` David Given
2012-02-25 23:05 ` Brad Normand
2012-02-26 1:10 ` zkry
2012-02-25 5:12 ` Brad Normand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGc3vb0t9fR+8i-MN=ieerwT2WERDQH9WYdsYbLOR=yMLsr4qw@mail.gmail.com' \
--to=bigbadbrad@gmail.com \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).