From: gt8134b@prism.gatech.edu
Subject: MS-DOS emulator info
Date: Fri, 11 Dec 1992 23:31:07 +0200
Hello, all those who would emulate the ugly beast,
This is another of my habitually long speeches, most of which
can be qualified as "much ado about nothing." And just to get it
straight, I DID NOT WRITE THE DOS EMULATOR. Matthias (Lautner?)
wrote it, and put out dosemu0.4 sometime in the last 2 months. I
never saw word of it, nor have I made contact with him, though I
tried several times. My mailer cannot reach him; someone who knows
him personally (physically! quite a stroke of luck on the net) mailed
me and said he'd pass any info along, but I don't think my mail reached
HIM, either.
So, if you can contact Matthias, please tell him what I'm doing.
I feel very strange, partially because I think people are crediting
me with his work, and partially because I'd hate to be overlapping
anything he's doing.
lautner@informatik.uni-wuerzburg.de
---------------------------- UPDATE --------------------------------
I spent some time last night working on the keyboard functions. Some
programs I have (like the HelpPC 2.1 document/reader that is INVALUABLE)
wouldn't accept any keyboard input but function and arrow keys.
Matthias had written the convKey() function to return the ASCII code
for normal ASCII keys, but true DOS scancodes for the function keys, as there
is no ASCII for them. This is okay for DOS int 21h functions (in fact,
somewhat necessary - see below), but the int 16h keyboard services expect
a two-byte value: AH = scancode, AL = ASCII.
So, I cleverly created a 256-byte table correlating ASCII to scancode,
and after a compile I just happened to notice that command.com wouldn't
accept keyboard input. At all. Oh. Well, back to EMACS, edit here,
touchup there, recompile -- still no keyboard input. Thirty minutes of this
and it occurs to me: how does command.com get keyboard input? int 21h!
And what does it expect? (flip flip through Ralf Browns' interrupt tome)
why, it expects the ASCII in AL. Furthermore, RB's list only tells
what programs ought to be written to expect, not what they DO expect.
For those of you who are curious, int 21h keyboard calls really
want AH to be zeroed. I guess it was too much trouble for the whiz
kids at MicroShaft to actually use register AL instead of AX when
writing their (revolutionary, new, DOS 5.0) pseudo-shell. Anyway,
what's done is done. It all works now, so I can use HelpPC and
it's nifty not-too-hypertext-but-just-enough system in a dos-emulated
task to help write the dos emulator. :-)
The reason I have reported such tedious debugging details is to
show you all how meager my resources (and more importantly, my experiences)
are. I just am not a DOS wizard. I wake up every day with a smile on my
face and a bounce in my step (once I get out of bed) because
of that, but it's kind of a hindrance here. Don't get me started on
Amigas, though...
So, don't expect my complete dos 5.0 - compatible patches to dosemu0.4
by February. I'm just fixing things as I run across them, and as I
need them. I have a very limited "testbed" of software, all of which
pretty much breaks now, so suggestions are welcome.
Another reason I'm posting this is that there are probably many
people who could benefit by having my few simple changes now, and not
have to wait for the whole shebang.
Here's what I've done since I began (this week)
1. Added a couple of BIOS stubs for compatibility. These don't
quite do what they're supposed to, but they keep the programs
happy.
2. Added BIOS LPTx: support. You probably won't need anything else,
unless you want LapLink or something. This should do.
(Right now it just copies the printed char's to a file. I'll
probably add some option that will, after some time of no printing,
spool your job to lpr)
3. Added BIOS COMx: support. This is very spotty, as the drivers
for this are part of the hardware-level-emulation serial drivers
(which are in turn VERY VERY spotty). However, you can run Kermit
under DOS now (why?? :-)
4. Register/hardware-level serial port support. See above. Chuckle.
Smirk. There's a LOT left to do. Programs that use the serial
ports usually also reprogram the 8259 interrupt controller, and
I probably shouldn't have opened this can of worms. But there
it is, squirming away.
Just for reference, my latest achievement has been to get Telix
to recognize the serial port, set it up, check for characters,
send the modem initializing string, wait for an interrupt. It
hangs here. I put the proper value in the IIR (int. ID reg.) and
invoke the proper interrupt routine for servicing com2, but it
just checks it and waits. Oh, well.
Kermit still won't recognize the port, but I just found that out
at 2 A.M. today, and it wasn't THAT vital.
5. Of course, the keyboard routines now return the proper values.
6. Also, the DOS 5.0 boot problem has been fixed (sort of). I just
ignore general protection errors during boot. :-(. If I find
the time to research the exact cause of the GP error, I'll
implement a more sane solution.
7. Several ways to exit from DOS, including a small program that
just invokes int 21h, subfunction AX=0xffff. RB's int. list
lists this as some virus' installation check, so some of your
favorite virus software might break (instead of wiping your
hard disk). Also, the HLT instruction exits the DOS emulator,
which seems logical to me. (DOS's reboot command uses this).
If you know of a valid use for HLT, please tell me. ("Don't
mind him, he's new to the architecture"). Also, if everything
hangs and you can't use my exit program or DOS reboot, then
you can "kill -1 pid" or "kill -HUP pid" (same thing on Linux)
from another VC.
All of these methods close all the open files (like dosemulpt1)
and flush the debugging output to disk. This is important, as
you'll need that output to find out what caused the crash.
8. Some other minor thing, can't remember what it was.
Things I will do soon, if I can:
1. Clean up my code. UGLY. This is what happens when you don't know
what you're writing, why you're doing it, or how it works until
you're half done.
2. Use the Linux console RAW mode to better supply programs
with all the neat shift-states, alt-fkeys, TSR finger-mangling
combos, etc. The current dosemu0.4 (and mine) will run if
used from a vt100. (Matthias did a good job on this!). However,
most users will probably use the console, so I should add the
improved functionality.
One problem with Linux RAW mode is that, to the best of my
knowledge, it DOES NOT allow you to switch Virtual Consoles while
in it. I cannot accept this limitation, although as a
perceptive friend of mine pointed out, XFree86 probably
can :-). As X11 is slightly more important than DOS emulation,
I'll work with the current implementation.
I'll probably define some key that causes the next key to
be processed in normal mode. (say, SysRq then ALT F1-8?)
3. Somehow use the currently unimplemented KDMAPDISP ioctl for
the console so that dosemu can avoid all the nasty periodic
screen updates it has to go through. Again, the termcap
translation will be left untouched (or improved :-).
I think Orest Zborowski (named "obz" in the sources) implemented
all the KD... ioctl's; he says in the source that it would be
easy to implement KDMAPDISP (map the display into user mem).
I'd like someone to do that, so Orest, are you listening?
Since I'm on the topic, how do I get Linux to use the
standard PC character set? I'm pretty sure this isn't
implemented on a per-VC basis, but that's okay for now.
4. Microsoft Windows 3.1 support, eventually with a
Windows->X11 API translation interface. NOT! Never will
I even consider such a thing, ever, ever, because I simply
CAN'T. If you need it, set up some sort of technology licensing
deal with Quarterdeck, because it's just not an option otherwise.
Or buy Desqview/X if that's what you need.
Things I don't plan to do, and probably never will, so please don't ask:
1. Bungee-jumping.
2. Number 4 in the "soon to do" list.
Things I'd like to do, but probably won't for a very long while:
1. Graphics support (NOT UNDER X!) probably using vgalib. This
would allow standard VGA (640x480x16) to work on a Virtual
Console. I'd like to have this under X, as well, but if
you think termcap updates are slow for text screens, wait until
you see X receving a new 150k bitmap to display twice a
second.
2. Sound support.
(after all, most of us just want to run our games under Linux, right?
applications? yuck.)
If I work really hard, I can get my code all done & cleaned up by
next Friday. If any of you would like to volunteer as prealpha
testers, please step forward.
If any of you wish to help out by sending recommendations of "features,"
lists of (in)compatible programs, and debugging output, do so! I'll be
away for a couple or three Christmas weeks, but after that I'm game
again.
[To send me your dosemu0.4 debugging output, just e-mail me the dosdebug file
you normally generate by doing this:
dos c > dosdebug
or if you haven't made your hdimage bootable,
dos a > dosdebug
This output isn't really useful unless I have the program you crashed/hung,
you send it to me, or I can get it fairly easily.]
Thanks for your time,
Robert Sanders
gt8134b@prism.gatech.edu
pshuprs@prism.gatech.edu
From: bir7@leland.stanford.edu
Subject: No more libemu
Date: Thu, 17 Dec 1992 01:04:19 +0200
I just subscirbed to this channel so I don't know what's been
going on. I just tried the dos emulator under .98pl6 and got it to work
by having it ignore the segment violations when it was not in v86 mode.
I also managed to get rid of the extra libemu part which has always
bothered me. I mostly just changed the Makefile and added two small files
to arrange to have the first 1M+64K be in a function called dummy which
just jumps to the real entry-point. The net result is I have an application
called dos which doesn't use any special shared libs. The only real
drawback is linking takes quit a while and the Makefile is dependent
on which gcc you are using (does anyone know how to get gcc to pass on
arbitrary linker command lines?). Are people interested?
Ross Biro bir7@leland.stanford.edu
Member League for Programming Freedom (LPF)
mail lpf@uunet.uu.net to protect your Freedom
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Subject: Re: No more libemu
Date: Fri, 18 Dec 1992 03:47:43 +0200
From: bir7@leland.stanford.edu
Date: Thu, 17 Dec 1992 01:04:19 +0200
I just subscirbed to this channel so I don't know what's been
going on. I just tried the dos emulator under .98pl6 and got it to work
by having it ignore the segment violations when it was not in v86 mode.
I also managed to get rid of the extra libemu part which has always
bothered me. I mostly just changed the Makefile and added two small files
to arrange to have the first 1M+64K be in a function called dummy which
just jumps to the real entry-point. The net result is I have an application
called dos which doesn't use any special shared libs. The only real
drawback is linking takes quit a while and the Makefile is dependent
on which gcc you are using (does anyone know how to get gcc to pass on
arbitrary linker command lines?). Are people interested?
Yes! I've always thought the libemu was a ugly hack; I'm glad you've
figured out a way to get rid of it.
I also had to put in a hack to ignore SIGSEGV signals until after the
boot() subroutine had been called. Fortunately, that's all you have to
do in order to get the dos emulator to work under 0.98pl6.
I would think that there should be a portable way of doing what you need
to do, without depending on how GCC passes things to the linker. One
solution which comes to mind (although it's pretty ugly), would be to
use do "gcc -S emulate.c" to make it generate assembler output, and then
use awk to edit the assembler output to include the necessary jump to
the begininng of the emulation routine, plus the 1M+64K filler. Ugly,
but it should be doable.
- Ted
From: bir7@leland.stanford.edu
Subject: Re: No more libemu
Date: Fri, 18 Dec 1992 04:13:12 +0200
> Yes! I've always thought the libemu was a ugly hack; I'm glad you've
> figured out a way to get rid of it.
>
> I also had to put in a hack to ignore SIGSEGV signals until after the
> boot() subroutine had been called. Fortunately, that's all you have to
> do in order to get the dos emulator to work under 0.98pl6.
>
> I would think that there should be a portable way of doing what you need
> to do, without depending on how GCC passes things to the linker. One
> solution which comes to mind (although it's pretty ugly), would be to
> use do "gcc -S emulate.c" to make it generate assembler output, and then
> use awk to edit the assembler output to include the necessary jump to
> the begininng of the emulation routine, plus the 1M+64K filler. Ugly,
> but it should be doable.
That's not the problem. The problem is that the LIB dirs
searched is depends on the version of gcc. That's the only realy
dependancy other than /lib/crt0.o and -lgcc which I don't think
change. So I have a LIBDIRS= at the top of the makefile and in it is
embedded the version of gcc. I suppose I could get it with gcc -v
with a shell script. The way I did it is with a dummy.s file which
just has a jmp *_startup followed by 1M +64K of filler. The linker
than does ld dummy.o /lib/crt0.o$(LIBDIRS) $(OBJS) startup.o -lgcc -lc.
Then nm is used to look up the starting address of /lib/crt0.o (It shouldn't
ever change, but Just in case.) and then startup.c is fixed, and then
it is relinked (That's why it's slow, too linkings. But I have sped
it up by useing an intermidate file. Here's the relevent stuff.
Don't forget to change the dosemu(argc, argv) function in emu.c to main,
otherwise it won't link. I think this should make dos just a regular
executable, but I`m not sure (Linus?)
Ross Biro bir7@leland.stanford.edu
Member League for Programming Freedom (LPF)
mail lpf@uunet.uu.net to protect your Freedom
----- cut here ---- file Makefile
# define LATIN1 if if you have defined KBD_XX_LATIN1 in your linux Makefile.
# This assumes that < ALT>-X can be read as "\033x" instead of 'x'|0x80
# DEFINES=-DLATIN1
# path to your compilers shared libraries
SHLIBS=-L/usr/lib/gcc-lib/i386-linux/2.2.2d/shared -L/usr/lib/shlib/jump
#
#
#
OBJS=emu.o linuxfs.o termio.o vm86.o
CFLAGS= -fwritable-strings $(DEFINES) -g # -O3 #-Wall
CRT0= /lib/crt0.o
LIBDIRS= -L/usr/lib/shlib/jump -L/usr/lib/gcc-lib/i386-linux/2.2.2d
LIBS= -ltermcap -lgcc -lc -lgcc
all: dos
start.o: start.c
dummy.o: dummy.s
tmp_emu.o: dummy.o $(CRT0) $(OBJS)
ld -r dummy.o $(CRT0) $(LIBDIRS) -o tmp_emu.o $(OBJS) $(LIBS)
start.c: dummy.o $(CRT0) start.dis tmp_emu.o
cp start.dis start.c
echo 0\; >>start.c
gcc -c -o tmpstart.o start.c
ld -o tmpstart tmp_emu.o tmpstart.o
cp start.dis start.c
nm tmpstart | grep $(CRT0) | cut -d " " -f1 >>start.c
echo \; >>start.c
dos: tmp_emu.o start.o
ld -o dos tmp_emu.o start.o
clean:
rm -f $(OBJS) dos.o dos libemu *.s core tm* *~
emu.o: emu.h
linuxfs.o: emu.h
termio.o: emu.h
---- cut here ---- file start.dis
/* start.c */
/* this file exists just to do a jump to the right routine. It is generated
by the make file. */
void (*startup)() = (void *)0x
--- cut here ---- file dummy.s
.text
.align 2
_dummy:
jmp *_startup
.space 0x110000
.comm _startup,4
From: gt8134b@prism.gatech.edu (Howlin' Bob)
Subject: Working together
Date: Fri, 18 Dec 1992 22:47:58 +0200
Hi, all,
It seems that we're all really interested in the MS-DOS emulator, so much
that we're all working separately on it. Everyone seems to be doing neat
things, but we need to make sure these neat things are spread around.
I volunteer to be the co-ordinater/code-merger/version-controller/FAQ-
writre for the emulator. If Matthias ever shows again, I'll defer to him,
but I really really can't reach him.
My current contribution is UART emulation. I'm also working on the
whole hardware->emuware translation (next are the interrupt controller and
timer, etc.). I've implemented a version of the emulator that uses
the VC RAW mode (like X does) to give more natural key sequences. This
is optional, of course.
SO what do you say? Can we co-ordinate and all benefit, or wait until
we've all gone incompatible directions?
Robert Sanders
gt8134b@prism.gatech.edu
I can post my code to ftp.uu.net, but I'm not happy releasing it before
it's clean.
From: bir7@leland.stanford.edu
Subject: Re: Linux-Activists - Channel MSDOS digest. 92-11-18-21:5
Date: Sat, 19 Dec 1992 09:01:57 +0200
> I volunteer to be the co-ordinater/code-merger/version-controller/FAQ-
> writre for the emulator. If Matthias ever shows again, I'll defer to him,
> but I really really can't reach him.
I would suggest breaking the emulator up into many files, one
for each type of function (video, floppy-disk, hard-disk, serial, printer
other bios, ...) and then using something like RCS. Theoretically
RCS has the ability to merge multiple changes to the same version if
they don't conflict too much. (Not all that different than diff/patch.)
And it would atleast keep track of what version you were modifying.
Then keep the RCS files available for anon-ftp and update them as often
as possible. If there arn't too many people working on it, it might be
possible to rig up some sort of remote check-in/check-out for the individual
pieces.
Ross Biro bir7@leland.stanford.edu
Member League for Programming Freedom (LPF)
mail lpf@uunet.uu.net to protect your Freedom
|