Return to BSD News archive
Xref: sserve comp.os.linux:19431 comp.unix.bsd:9037 comp.sys.intel:3195 comp.sys.ibm.pc.hardware:39091 comp.os.msdos.programmer:17367 comp.os.minix:21016 comp.unix.msdos:1579 comp.unix.dos-under-unix:196
Path: sserve!manuel.anu.edu.au!munnari.oz.au!network.ucsd.edu!swrinde!gatech!prism!gt8134b
From: gt8134b@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
gt8134b@prism.gatech.edu <- preferred
pshuprs@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: gt8134b@prism.gatech.edu