Path: sparky!uunet!gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux
Subject: Calling the author of the DOS emulator
Keywords: MSDOS, emulator, printer
Message-ID: <77771@hydra.gatech.EDU>
Date: 8 Dec 92 20:10:17 GMT
Organization: Georgia Institute of Technology
Lines: 104
I'm sorry to post this to the newsgroup, but I can't get mail
to his address. If anyone of you CAN and don't mind helping me,
please mail me so we can work something out (I don't want him being
flooded with copies of this).
His address is:
laut...@informatik.uni-wuerzburg.de
Otherwise, I hope he sees this.
-----------------STOP READING HERE IF YOU DON'T CARE-----------------
Matthias,
I must thank you for your MS-DOS emulator for Linux! It's such a fun
program. I got bored last night and hacked in simple LPT printer
support, and I'll try to do some basic serial code tonight (not quite
so easy...). I've also added a command-line bitmask for some of the
status messages (especially the disk READ/WRITE ones), a few video
interrupts (and extensions to extant ones), a few non-working
interrupt stubs to satisfy some programs, (like some keyboard stuff), etc.
The boot problem with DOS 5.0/DR DOS 6.0 I seem to have fixed by
not dying on a general protection error during a boot (bad, I know).
Someone on comp.os.linux suggested this; I just restricted it to boot time.
I've added recognition of the HLT trap, so that the DOS "reboot" command
actually kills the DOS emulator. I've also written a tiny program
that used int 21h, ax=ffffh to stop the emulator. Killing the emulator
any of these ways, or with a SIGHUP (kill -1 xxx) will now flush the
debugging output to stdout so that you don't lose the important info! :-)
The printer stuff now just dumps characters to files dosemulptX,
where X ranges from 1 to 3. Printer status is always returned as
0xd0, which should mean ACK, printer select, not busy, not paper out,
if my interrupt list serves me well. I should make it so that any
file creation errors, write errors, etc. show up in the printer
status.
Just an opinion: do you think the printer initialization call
should erase any existing dosemulptX files so that print jobs don't
run together, just tag a ^L onto the end, or do nothing but test file
status?
I like the "direct-mounting" of my DOS disk (e.g. specifying the
hard disk parameters in emu.c and not using LINUX.EXE), but the
big problem there is that Linux doesn't see disk changes that way
(it seems to me). There probably isn't any way around this.
Should I get _Undocumented_DOS_ ? I've recently "converted" from
the Amiga because of Linux, so I really don't know much about the
whole DOS/BIOS thing. Most of what I know I've gleamed from a
few scattered PC articles, the interrupt list, and your emulator :-).
One thing I really need to know is how the keyboard controller is
accessed. I see DOS programs doing lots of inb's and outb's to
addresses around 0x60, 0x61, etc. Which of these addresses does
what? I'd like to set up better software emulation for the keyboard,
(non int 21h) although some things, like shift states and such, will
probably be impossible.
What's a good book on PC hardware? Something that covers the basics
from floppy to hard disk, video, keyboard, serial, etc. Nothing really
deep, but enough for what I'm doing with what you're doing. :-)
Anyway, I would love for you to include my changes in the DOS emulator,
so just let me know if you want it. Once I get everything done and
working to my satisfaction, I'll send it to you.
And if there's something specific you'd like me to work on, please
ask me. Right now, what I'm probably best suited for is just
implementing BIOS calls (my only data source is the interrupt list).
This is such a great tool. Far in the misty future, when someone
needs to use some PC program that, say, uses PC-NFS for a network
database (or whatever), the DOS emulator could just hand it a
Linux socket. Wow.
thanks,
Robert
gt81...@prism.gatech.edu
pshu...@prism.gatech.edu
P.S. I have an idea for speeding up the screen refresh. While I love
having DOS output converted to termcap stuff, it's just too
painfully slow. Maybe we could fudge the kernel so that we get
one of it's VC buffers? For safety, we can put it somewhere other
than in the kernel with the other VC's, maybe in some page common
to both the kernel and the user address spaces. I haven't really
looked at the memory-management stuff enough to know if this is
possible right now.
For those who are running the DOS emulator on the console, the DOS
screen updates would be "real-time!"
I don't like the idea of adding kernel stuff needlessly, but I'm
thinking of doing some fairly intense console mods anyway, and
re-allocation of a VC buffer at a common address would be NICE,
in my opinion (only for the emulator, or course).
--
Howlin' Bob
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt81...@prism.gatech.edu
Path: sparky!uunet!gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux,comp.unix.bsd,comp.sys.intel,comp.sys.ibm.pc.hardware,
comp.os.msdos.programmer,comp.os.minix,comp.unix.msdos,comp.unix.dos-under-unix
Subject: PC port I/O for Linux MS-DOS emulator (long)
Keywords: emulator, msdos, ms-dos, port I/O, linux, 386bsd, pc
Message-ID: <77873@hydra.gatech.EDU>
Date: 9 Dec 92 16:56:46 GMT
Followup-To: comp.os.linux
Organization: Georgia Institute of Technology
Lines: 102
dear Those in the Know,
A plea for help:
I am currently modifying Linux's (pre-alpha) MS-DOS emulator to
support simulated port I/O; that is, if a program does an in
from I/O address 0x2f8, I'll hand it the next available character
on com2. The author of the dos emulator provided much of the
framework I need for this, which isn't that much anyway. Because it
runs in the 386's vm86 mode with no I/O permissions, all port I/O is
trapped and passed to emulator functions inb() and outb().
For those of you who don't know what Linux is, it's a free
implementation of POSIX UNIX for the 386 architecture (although a few
people are sort of porting it to 680x0 systems like the Amiga and
Atari ST). I won't go into all it's benefits, for they are many and
uncountable :-), but all the kernel source is available and free, so
if you don't have it, look into it. (i.e. read comp.os.linux).
I have implemented a 3-minute subset of com port 2 (i.e. the UART
at 0x2f8) that at least fools Telix into thinking that there
is a UART there. Telix hangs after out'ing something to
port 0x21, which I believe is the interrupt controller. This, along
with the fact that Telix accesses the UART's interrupt enable and
interrupt id registers, has led me to believe that Telix is waiting
for a serial interrupt.
My problem is that I have absolutely NO experience with the PC hardware
(which uniquely qualifies me to work on this project :-), and I've
read about as much as I can from Linux's kernel sources. Trying to
reverse engineer the 8250 UARTs from the serial drivers is kinda like
a caveman trying to figure out fire from a diesel engine. Sure, it's
fire, but the phenomenon of combustion isn't immediately obvious from
the design.
So I come to you, the public, in a plea for help. I desperately
need information on the 8250 UARTs (the 16550's seem to be 8250's with
one extra FIFO control register, correct?), the 8259 interrupt
controller, and the keyboard controller (number?). If you can't give
me information about the chips, at least point me to a useful reference.
I know I should probably get the Intel spec. sheets, but something about
programming PC's would be just as good.
Here is a summary of what I DO know:
- I think I know most of the register names of the 8250 UART, and
many of the bits defined therein. However, I am in the dark about
some of the actual functionality of said bits, especially those
in the control and status registers. (TX and RX are pretty simple :-).
- I know nothing about the 8259 interrupt controllers.
I need a complete summary of this chip.
- I know how to set the keyboard LED's using the keyboard controller.
Also, I can reboot the machine using it and I have code that fetches
scancodes from it (even though I might miss some of the subtleties of
this). Basically, I need a complete summary of this chip.
Again, my aim is writing port I/O emulation, so I need to know
about any port I/O that a program is likely to do. Common
routines/techniques like reading from a certain port for I/O slowdown,
etc., are essential. BIOS call information is, of course,
interesting, but I do have Ralf Brown's interrupt list. BIOS I/O is
fairly simple anyway. Of course, you are most welcome to send
and (legal) BIOS disassemblies :-).
Any other I/O information, such as the floppy controllers, st501/ide
interface, cga/ega/vga/mda information, parallel ports, etc. is
also much desired.
For those in the BSD group, Linus recently posted about the
possibility of porting this to 386BSD. I would certainly be happy to
assist in any such effort, both after the program is done and during
program development (i.e. designing in 386BSD-helpful features). Your
kernel needs some support for vm86 mode and setting a vm86 program's
I/O permission bitmap. The emulator depends upon the ability of vm86
mode to trap privileged instructions (int xx, int 3, hlt, in, out,
etc.), which generates a general protection error. A 386BSD MS-DOS
emulator needs to receive a signal on such a trap, and have access to
the vm86 task's saved registers.
For those in the other groups (msdos, unix & msdos, intel), I really
don't have much to offer but the warm fuzzy of altruism and shared
knowledge.
Please mail me any responses or "me, too" requests. I would be
happy to forward/post/summarize any information sent to me.
Thank you for your time,
Robert Sanders
gt81...@prism.gatech.edu <- preferred
pshu...@prism.gatech.edu
P.S. I can use FTP, so any previously extant documents on ftp sites
are also greatly appreciated.
--
Howlin' Bob
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt81...@prism.gatech.edu