Subject: SVGA-alphanum. modes
Date: Mon, 6 Jan 92 17:43:12 +0100
From: d88-man@nada.kth.se
To: Linux-activists@joker.cs.hut.fi
I have finally had time to finish the SVGA-detector. This patch will
look for clues to determine if/what SVGA-card available. If it finds
a card it will ask (at boottime) if one wants to select from the modes
supported by the current card or just do a 'normal' init without SVGA-modes.
This is not the best thinkable way of doing this, I will work on a version
that can do the modeswitching from 'user-mode', which however is FAR more work
than this straightforward hack. But the detection part of it must still lie
in the kernel (at least that's simplest). But this is good enough to be
usefull/easy to use.
I have uploaded this code to both nic.funet.fi and tsx-11.mit.edu.
I have only been able to test the Trident part of this code. People out
there with different cards could please test this and mail results. And even
the Trident part is not guarateed to work since my card seems a bit strange.
Cards supported: ATI, Ahead, Chips & Tech., Cirrus, Everex, Genoa, Paradise,
Trident, Tseng, Video7. People with code to guess other cards and what modes
they support could mail me, or implement them themselves as long as it
gets spread.
Finally, the patch someone (can't remember who) sent out with the 'standard'
80x50 mode for VGA could be implemented in this code as an extra choice
but I can't remeber how one did it so could please someone send it to me,
and I can tuck it in at the end ...
++++++++++++++++++++++CUT+HERE++++++++++++++++++++++CUT+HERE++++++++++++++++++
Compressed
Subject: Re: SVGA-alphanum. modes
Date: Mon, 6 Jan 92 13:53:39 -0500
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: d88-man@nada.kth.se
Cc: Linux-activists@joker.cs.hut.fi
In-Reply-To: d88-man@nada.kth.se's message of Mon, 6 Jan 92 17:43:12 +0100,
Reply-To: tytso@athena.mit.edu
TSX-11 FTP server update....
d88-man@nada.kth.se's SVGA patches:
~ftp/pub/linux/patches/svga.tar.Z
edpart and pdisk have been uploaded from wuarcive and placed in:
~ftp/pub/msdos
A quick summary of xterm/VT100 escape sequences can be found in
~ftp/pub/linux/info/xterm-seqs.ms
~ftp/pub/linux/info/xterm-seqs2.txt
I uploaded the last because it might be useful for people wanting to
hack on the console driver. In particular, it would be neat if ESC [ ?
3 h switched the screen to 132 column mode, and ESC [ ? 3 l set it back
to 80 columns. hint, hint. :-)
- Ted
Subject: Re: SVGA-alphanum. modes
Date: Mon, 6 Jan 92 11:45:27 PST
From: pmacdona@sanjuan.UVic.CA (Peter MacDonald)
To: d88-man@nada.kth.se
Cc: linux-activists@joker.cs.hut.fi
It was I who sent out the patches to get to 50 line mode.
I also implemented the Virtual Consoles coming in .12.
Note that it would be desirable to run a windowing system in one
VC and be able to switch to other text-mode consoles.
This means not using the bio (yuck) or finding a way
to use V86 mode to do the switching. This would be nice
because it is a step towards DOS under Linux.
Subject: Re: SVGA-alphanum. modes
Date: Mon, 6 Jan 92 16:30:43 -0500
From: tytso@ATHENA.MIT.edu (Theodore Ts'o)
To: pmacdona@sanjuan.UVic.ca
Cc: d88-man@nada.kth.se, linux-activists@joker.cs.hut.fi
In-Reply-To: Peter MacDonald's message of Mon, 6 Jan 92 11:45:27 PST,
<9201061945.AA12593@sanjuan.UVic.CA>
Reply-To: tytso@athena.mit.edu
I suspect that you would want to use the raw I/O instructions to do the
switching, and not try to use BIOS in V86 mode. I really don't know if
I'd want to trust the BIOS, and in any case, if you want real speed, you
will want to be talking to the VGA card directly anyway. The X server
in the X11R5 tape already has code to talk to a couple of Super VGA
cards; it probably shouldn't be that hard the kernel mods integrated
with VC changes so that you can switch around.
I've thought about what it would take to add V86 tasks; since each V86
task requires that it has 0-640k in Virtual space (you can't just give
it a segment), each V86 task would need to have its own set of page
tables that would have to be swapped in when it was running. While this
would be tricky to implement (the task switching code would need to be
changed --- carefully), it has the advantage that we could at the same
time get rid of the 64 process limit. For the 65th through 129th
process, we simply use another set of page tables, and so on.
We'd also want to intercept all of the BIOS and DOS interrupts and
replace them with blocking versions of the calls, so that the MS-DOS
tasks can run efficiently. Yet some programs will try using the raw I/O
instructions, and in order to handle them we would need to trap
attempted I/O instructions and attempt to emulate them. Then's there's
all of the memory-mapped video that would need to be emulating by
putting in hooks to the VM code.
All-in-all a pretty big job....
- Ted
Subject: SVGA-alphanum. modes
Date: Tue, 7 Jan 1992 00:23:45 +0200
From: Ari Lemmke <arl@zen.cs.hut.fi>
To: Linux-activists@joker.cs.hut.fi
In-Reply-To: d88-man@nada.kth.se's message of Mon, 6 Jan 92 17:43:12 +0100
<9201061643.AA21121@dront.nada.kth.se>
d88-man@nada.kth.se:
>I have uploaded this code to both nic.funet.fi and tsx-11.mit.edu.
nic.funet.fi:/pub/OS/Linux/kernel/svga.tar.Z
arl
Subject: VT102 codes
Date: Tue, 7 Jan 1992 00:30:03 +0200
From: Ari Lemmke <arl@zen.cs.hut.fi>
To: Linux-activists@joker.cs.hut.fi
In-Reply-To: Theodore Ts'o's message of Mon, 6 Jan 92 13:53:39 -0500
<9201061853.AA07025@tsx-11.MIT.EDU>
>A quick summary of xterm/VT100 escape sequences can be found in
>
> ~ftp/pub/linux/info/xterm-seqs.ms
> ~ftp/pub/linux/info/xterm-seqs2.txt
Also VT102 codes available at
nic.funet.fi:/pub/doc/HW/terminals/vt102.codes
I'm collecting all hardware documentation I can get ;-)
especially interested in different PC cards and their
dip-settings.
Also I'm going to put available my drivers (sources)
collection (for different PC and non-PC devices/cards).
arl
Subject: Re: SVGA-alphanum. modes
To: tytso@athena.mit.edu
Cc: d88-man@nada.kth.se, linux-activists@joker.cs.hut.fi
In-Reply-To: Your message of Mon, 06 Jan 92 16:30:43 -0500.
Date: Mon, 06 Jan 92 19:47:25 MST
From: drew@hazelrah.cs.Colorado.EDU
--------
I suspect that you would want to use the raw I/O instructions to do the
switching, and not try to use BIOS in V86 mode. I really don't know if
I'd want to trust the BIOS, and in any case, if you want real speed, you
will want to be talking to the VGA card directly anyway. The X server
I disagree. The actual mode setting will be called ONCE when the
Xserver initializes. Initialization code for all different VGA cards is
often radically different - with registers spread all over the place,
with different values and functionality. Saving a few hundred clock cycles
one time on a machine with 20 to 40 million is not a big deal.
in the X11R5 tape already has code to talk to a couple of Super VGA
cards; it probably shouldn't be that hard the kernel mods integrated
with VC changes so that you can switch around.
I've thought about what it would take to add V86 tasks; since each V86
task requires that it has 0-640k in Virtual space (you can't just give
it a segment), each V86 task would need to have its own set of page
tables that would have to be swapped in when it was running. While this
would be tricky to implement (the task switching code would need to be
changed --- carefully), it has the advantage that we could at the same
time get rid of the 64 process limit. For the 65th through 129th
process, we simply use another set of page tables, and so on.
The appropriate CR is stored in the task state structure saved by the 386 -
so switching can be basically automated. You have some inteligence to
share the BIOS and manage the IO bitmaps though - to prevent contention
problems. Also, V86 tasks can only address 1M + ~64K (address carry
present in 286's and above), requiring at most 256 + 16 second level
table entries, meaning a single secone level table (1024 entries
MAX per table) and first table entry. Spares for video memory bank
switching are also desireable.
(Excuse my terminology -= I can't keep tables and directories straight)
We'd also want to intercept all of the BIOS and DOS interrupts and
replace them with blocking versions of the calls, so that the MS-DOS
tasks can run efficiently. Yet some programs will try using the raw I/O
DOS does not need to be trapped. You run one copy of DOS per VM - this saves
MANY reentrancy problems, etc. As far as what needs to be trapped -
1. Disk BIOS should write to the Linux routines, with extraneous routines
trapped - ie no go for format, etc : we want a minimal functionality
first.
2. Video set mode int 10h function 0 should be trapped for mode, and
only allow VALID VGA modes, the setting of which will be sent to
the Linux window program (outputing to X11) All other BIOS
video accesses are OK except perhaps the set palette, which
we would probably only emulate at the register level (eventually)
and let BIOS do it's thing. Also, we need to keep track of
state for text / graphics.
3. Any BIOS routines that talk to registers that are NOT being emulated.
A simple solution would be to block any and all BIOS calls, a better
solution would be to change IOPL once in BIOS and cause all read /
writes to fault -, setting a blocking flag. If the blocking flag is
set, you wait until it is cleared by a ret / iret from the BIOS code.
Video RAM access is handled by having a buffer allocated for each machine.
Text, and CGA are no problem at all - these are not bank switched, and
lack the special EGA / VGA ALU / barell shifter, plane mask, and
bank switching used for 16 color modes. Each task has its own
video memory buffer. You after a refresh alarm expires, you
look at the accessed bits in the page table and update those regions that
have changed.
Trapping interrupts in DOS :
Not overly complicated. When an INT, INT3, or INTO opcode is executed
in a vm task, it creates a general protection violation. When you trap this
fault, you examine the VM flag in the flags on the stack. If it
is set, you use your special DOS handler which looks for one of these or
other IOPL or VM sensitive instructions and perform the appropriate
emulation.
instructions, and in order to handle them we would need to trap
attempted I/O instructions and attempt to emulate them. Then's there's
all of the memory-mapped video that would need to be emulating by
putting in hooks to the VM code.
Other stuff for a complete emulation of real mode :
trapping of EGA / VGA Palette, panning, and palette registers.
trapping of "normal" PIC mask register, timer ports, keyboard
registers (tie to the ttyp of the Linux proram) and eventually maybe
serial / parallel.
It is a nice idea, and would make an incredible summer project
after some one has ported X11R5 to Linux.
Virtual 8086 mode allows you to use almost all of the BIOS and any DOS
or other real mode OS underneath this mess. You have a few interrupts
that need dealing with, the hardware interrupts to simulate, and
some ports to trap, but other than being an exercise in protected and
VM program - it should be not overly difficult, just time consuming.
-----------------------------------------------------------------------------
I'd be more worried about getting X11 up in the first place as distribution
for R5 is around 150 megs. The two possibilities I'm looking at right now
are
1. It is possible to use
NFS servers over serial lines. A direct link, at 38.4K baud
could be made to a machine with disk and build done locally.
I think one such NFS program is PPP - are there others?
How soon until sockets, rpc, etc are implemented on Linux?
2. Large local SCSI disk
I've been offered a 340M SCSI drive real cheap (locally),
and am getting there on my SCSI drivers - after Winter USENIX is a
definite possibility for completion.
For work, we're currently installing X11R5 on our HP 68k Unix boxes -
I'll see how soothly it goes and take a look at the Xserver code
to see what needs changing.
Again, a lot of goodies like X hinge not only on some one having enough
disk space to do a build, but on availability of key Unix networking
related features.......
i
Subject: Re: SVGA-alphanum. modes
Date: Mon, 6 Jan 92 22:25:05 -0500
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: drew@hazelrah.cs.Colorado.EDU
Cc: d88-man@nada.kth.se, linux-activists@joker.cs.hut.fi
In-Reply-To: drew@hazelrah.cs.Colorado.EDU's message of Mon, 06 Jan 92 19:47:25 MST,
Reply-To: tytso@athena.mit.edu
Date: Mon, 06 Jan 92 19:47:25 MST
From: drew@hazelrah.cs.Colorado.EDU
I disagree. The actual mode setting will be called ONCE when the
Xserver initializes.
Well, it would be called when the X server initializes and each time you
switch bach and forth between Virtual Consoles. I suppose you are right
that it won't be called enough to make it worthwhile. I still would be
nervous about the BIOS code doing something funky like messing with the
interrupts and what not, but that's probably just an irrational fear on
my part.
DOS does not need to be trapped. You run one copy of DOS per VM -
this saves MANY reentrancy problems, etc. As far as what needs to be
trapped -
Well, in my conception DOS calls would be trapped and emulated by
calling the appropriate Linux filesystem routine, so that DOS programs
would be able to use Linux filesystems and Linux devices. Once we get
the MS-DOS filesystem working in Linux, it could even get to MS-DOS
filesystems that way. (!)
The first cut implementation probably would just run native DOS in each
task, though, since that is much easier.
It is a nice idea, and would make an incredible summer project
after some one has ported X11R5 to Linux.
Agreed; this would be a very big project! You actually don't need to
port X11 R5, though. It could just be done on top of Virtual Consoles,
and in fact it may be easier to do it that way, and worry about the X
interface later.
We probably shouldn't worry about it too much until after we get Linux
in a much more polished state, though.
I'd be more worried about getting X11 up in the first place as distribution
for R5 is around 150 megs.
Well, you don't need to grab the whole thing. The X library is 3 meg,
and the Xt toolkit is another 1.1 meg. You may also need the Xmu library
which is ~350k. Then the device dependent portion of the X server is
800k (and you don't need all of it), and the device independent portion
of the X server is 1200k or so. (All of these sizes are source only,
with no RCS directories).
A lot of the X11R5 distribution are big, (somewhat) useless things like
games and demo programs, and then there are the big, slow, and really
useless things like Motif. If you strip out all of those programs, X11
really isn't as big as you might think....
All of this really doesn't matter until we get sockets and networking
running, at which point SLIP, NFS and SCSI support might be in the
kernel already, making the whole space issue moot. My, it's nice to
dream, isn't it! :-)
- Ted