From: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
To: qemu-devel@nongnu.org
Cc: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
Subject: [Qemu-devel] [PATCH 3/3] HACKS for vga text mode with Microport UNIX (ca 1987)
Date: Fri, 27 Jul 2012 12:55:57 -0600 [thread overview]
Message-ID: <1343415357-5637-4-git-send-email-mmogilvi_qemu@miniinfo.net> (raw)
In-Reply-To: <1343415357-5637-1-git-send-email-mmogilvi_qemu@miniinfo.net>
========
Background:
========
I don't really think it is appropriate to include this patch in it's
current form, but I'm posting it to illustrate some of the obscure
things that Microport UNIX System V/386 v 2.1 (ca 1987) is trying
to do to the video card.
On real hardware, this version of UNIX could drive an MDA graphics
card (actually an HGC [hurcules graphics card] in text mode only)
just fine. BUT, the VGA card and monitor would always
display snow (timings were out of sync, and/or other problems).
In 1987, I initially had an HGC-only system, and added a VGA
to it later as a second graphics card and monitor. DOS could switch
between them (the "mode" command), but UNIX was only usable on the HGC.
The fact that it couldn't run a real VGA properly suggests that
hacking the emulated VGA isn't really the best solution. A better
approach might be to add specific support for graphics cards
(MDA, HGC, and/or maybe plain-CGA) that UNIX works properly on.
If anyone is interested in examining this UNIX system
directly (for these VGA issues or other issues), let me know and
I can email you at least the first (bootable) installation
floppy image.
========
Visible Problems in Qemu:
========
Running and debugging UNIX in qemu, I see two main VGA-related
problems, and a few associated nits (not counting non-VGA issues
written up separately):
1. (Blank screen): UNIX weirdly writes exactly
one byte to 0x3c0 (VGA_ATT_W). After reading
from 0x3da (which resets 0x3c0 to index mode),
it writes a 0 to 0x3c0, and then doesn't touch the register again.
It doesn't actually modify the contents of the data behind any index.
Writing zero also clears the 0x20 "palette access bit", which forces
qemu vga_update_display() to treat the screen as "GMODE_BLANK".
- My hackish workaround will not blank the screen if the index
register is still 0. Perhaps this hack could be (slightly)
improved to look at the index/data flip-flop as well, under
the theory that until the OS actually starts modifying things,
it is OK for the card to keep using the old palette?
2. (Characters cut in half): UNIX appears to be trying
to program the CRTC under the assumption that the text
mode is using a font that is only 8 pixels high, instead
of 16. I would guess it is trying to treat it like a CGA card.
- (main problem): It changes CRTC register 9 (0x3d4[9]/0x3d5)
from 0x4f to 0x07. The 0xf vs 7 halves the height of
the character, cutting off the bottom halves. The 0x40
bit doesn't seem to hurt, but documentation explains how
it has something to do with split screen scrolling.
- My hackish workaround is to ignore attempts to modify
register 9 if the lock bit in register 0x11 is locked.
- UNIX is also changing the cursor-height-within-a-character
values from (0xe through 0xf) to (6 through 7), effectively
moving the cursor to the middle of the character.
(I haven't tried to work around this, but it would be
trivial to disable these registers under some conditions TBD.
Or perhaps translate the supplied values with scaling logic.)
- UNIX changes register 8 (0x3d4[8]/0x3d5) from 0 to 2, but
this doesn't seem to hurt. (Documentation says it has to
do with smooth text mode scrolling, but UNIX only sets it
once...)
- UNIX also attempts to change registers 0-7 (0x3d4[0-7]/0x3d5), but
these attempts are ignored by qemu because of the lock bit
in register 0x11 (0x3d4[0x11]/0x3d5). (UNIX doesn't seem to
know anything about registers greater than 0xf.)
3. I haven't looked to see if it programming other VGA subsystems
strangely, but it wouldn't surprise me.
========
Possible "Real" Solutions:
========
1. The ideal solution would probably be to implement an emulated plain MDA
adapter, and a way to select it on the command line. (It could also be
extended to optionally be HGC-capable and/or to support a
dual monitor with a CGA/VGA [with two windows for the two
monitors], as well.)
Superficially, emulating an MDA or HGC card itself probably
wouldn't be too hard (mostly just copy, strip down [simplify], and
tweak the VGA support), but I'm still a little vague on the best
way to get it all hooked into the overall system cleanly,
and appropriate configurations options (perhaps options
like "-vga mda", "-vga mda+std", "-vgs cirrus+hgc", etc?).
This seems like a moderate amount of work, but it has the highest
likelyhood of being useful for running other ancient software,
rather than a hackish workaround for one rare OS.
2. Perhaps add some special command line option to enable hacks similar
to what I do in this patch (normally disabled). This is probably
the easiest. Any suggestions for command-line options, etc?
3. I wonder if maybe an alternative approach to these problems would be
to somehow identify that the target is trying to use the VGA like
a CGA, and have the fixups/hacks move it towards CGA functionality
instead of leaving things in VGA mode and disabling the bad
parts? (e.g. use a 8 pixel high font, etc)
- Identify if this is the case, and make a narrow exception
for better CGA support?
- Perhaps add a command line option to have the graphics card be
limited to just CGA functionality?
(Intentionally not signed off; this version of this patch isn't appropriate
for general use.)
---
hw/vga.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/vga.c b/hw/vga.c
index f82ced8..c57d8e2 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -548,7 +548,8 @@ void vga_ioport_write(void *opaque, uint32_t addr, uint32_t val)
#endif
/* handle CR0-7 protection */
if ((s->cr[VGA_CRTC_V_SYNC_END] & VGA_CR11_LOCK_CR0_CR7) &&
- s->cr_index <= VGA_CRTC_OVERFLOW) {
+ (s->cr_index <= VGA_CRTC_OVERFLOW ||
+ s->cr_index == VGA_CRTC_MAX_SCAN)) {
/* can always write bit 4 of CR7 */
if (s->cr_index == VGA_CRTC_OVERFLOW) {
s->cr[VGA_CRTC_OVERFLOW] = (s->cr[VGA_CRTC_OVERFLOW] & ~0x10) |
@@ -1886,7 +1887,7 @@ static void vga_update_display(void *opaque)
/* nothing to do */
} else {
full_update = 0;
- if (!(s->ar_index & 0x20)) {
+ if (!(s->ar_index & 0x20) && s->ar_index != 0) {
graphic_mode = GMODE_BLANK;
} else {
graphic_mode = s->gr[VGA_GFX_MISC] & VGA_GR06_GRAPHICS_MODE;
--
1.7.10.2.484.gcd07cc5
next prev parent reply other threads:[~2012-07-27 18:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-27 18:55 [Qemu-devel] [PATCH 0/3] Attempting to run Microport UNIX (ca 1987) Matthew Ogilvie
2012-07-27 18:55 ` [Qemu-devel] [PATCH 1/3] fix some debug printf 64bit format strings Matthew Ogilvie
2012-07-27 18:55 ` [Qemu-devel] [PATCH 2/3] target-i386/translate.c: mov to/from crN/drN: ignore mod bits Matthew Ogilvie
2012-07-27 20:53 ` malc
2012-07-27 18:55 ` Matthew Ogilvie [this message]
2012-07-28 6:33 ` [Qemu-devel] [PATCH 0/3] Attempting to run Microport UNIX (ca 1987) Markus Armbruster
2012-07-29 0:26 ` Matthew Ogilvie
2012-07-30 12:29 ` Markus Armbruster
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=1343415357-5637-4-git-send-email-mmogilvi_qemu@miniinfo.net \
--to=mmogilvi_qemu@miniinfo.net \
--cc=qemu-devel@nongnu.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 NNTP newsgroup(s).