A few nits:
> ..... In the original pc there was no physical memory at this
> address sinces it is above 640k, later the memory was 'reserved' so
> a pc couldn't use all the installed ram, today the address is
> relocated, called 'shadowed', so ram appears contiguous to the
> operating system.
In the original PC, video RAM (at B000:0000 on a monochrome adapter
and/or B800:0000 on a color graphics adapter) was ON THE VIDEO CARD.
It was physical memory, just not "planar" (on the motherboard).
IBM's design reserved addresses above 512K (quickly upped to 640K)
for use by ROMs and adapters. There was a period, more or less in
the 80286 (PC/AT) era when relatively high-capacity RAM became cheap,
but CPUs did not yet have the memory remapping capabilities of the
80386; during this era, it was not uncommon to find systems with 1MB
of system board RAM present, but only 640K accessible -- higher
addresses were rerouted to ROMs and adapters for compatibility.
The 80386 introduced CPU features to map between "virtual
addresses" and real physical addresses. (Actually, the 286
foreshadowed this with it's "16-bit protected mode"; the 386
introduced a similar "32-bit protected mode" and, more importantly to
this thread, "V86 mode" in which 16-bit DOS code could run with the
advantages of memory re-mapping.) It became practical to remap
contiguous motherboard memory so that it no longer conflicted with
the "ROMs and adapters" reserved addresses.
"Shadowing", by the way, is a whole different technique, where ROM
code provided on adapters (such as the video card) is copied to
fast/wide system RAM (which is then mapped into the address space in
place of the original ROM). The CPU can (or often *could*, in the
days of 8- and 16-bit ISA adapters) retrieve code to be executed
somewhat faster from such RAM than from the original ROM.
[The PC design just turned 20 years old, and most of these "growing
pains" were dealt with in the first ten years. Most users these days
don't need to know any of this, except when it helps explain really
weird problems like the one this poster has encountered.]
In a "graphics" mode, the video RAM actually contains colour
information for every pixel on the screen. But in a "text" mode --
which all of the places this problem is appearing are emulating! --
the video RAM contains two bytes per character, one with the
"extended ASCII" character code, and one with colour/blink
attributes. The display circuitry has to look up the pixel pattern
for each character as it draws it to the screen.
On the original monochrome adapter, these pixel patterns came from
ROM; you could change the font or character set by replacing the ROM,
if it wasn't soldered to the adapter. (And I did that a lot between
about 1985 and 1988....)
On the colour graphics adapter -- which is what most VGAs and more
recent designs emulate for text mode -- the contents of this ROM was
copied to RAM at boot time, and although you *could* change the ROM,
it was simpler and cheaper for a program that needed a special font
to rewrite that RAM area, and force a reload from ROM when it
finished. (Programs that know about VGA features can play some
additional tricks with this, but I don't think that applies to the
BIOS code or most DOS stuff.)
Since the problem is only appearing in text mode emulations, my
belief is that it is this process of retrieving pixel patterns for
each character that is failing. Either the "ROM" (in a modern
laptop, this may not be an identifiable single chip) which contains
those patters is corrupted, or the RAM that they get loaded to has
some problem. (If both r's and s's show as s's, and both t's and u's
show as u's, that sounds to me like the least-significant bit of the
character code -- used as an "index" into the pixel-pattern RAM, is
being ignored, perhaps due to a broken or shorted address line.)
> If the problem persists, I would suspect a bad video card.
Essentially, this is my conclusion too, except that as a laptop, it
probably isn't designed for the video card to be removed and replaced
by a user.
David Gillett
On 19 Aug 2001, at 14:20, Tom Turak wrote:
> When did this start? Let's assume its not a virus, not a safe assumption,
> but let's assume it anyway.
> Dos uses a fixed memory address for the text data displayed to the screen.
> I'm afraid my 'dos' memory is fading but text starts at B000:0000 and is
> 4000 bytes, just enough to show the characters in an 80x25 array and a few
> simple attributes, blinking, bold, and underline. In the original pc there
> was no physical memory at this address sinces it is above 640k, later the
> memory was 'reserved' so a pc couldn't use all the installed ram, today the
> address is relocated, called 'shadowed', so ram appears contiguous to the
> operating system.
> Notebooks don't have much in the way of CMOS settings, but I would attempt
> to turn off video and BIOS shadowing, and disable any ram caching, if your
> notebook will allow it. It is worthwhile to try this because you can't be
> certain where B000:0000 is on your system, so you want to stop it from being
> moved if possible.
> If the problem persists, I would suspect a bad video card.
> If you can't do much with cmos, I would try using one ram simm at a time to
> see if it clears up. Bad ram can be a culprit, but it is suspicious that
> windows works. Graphics are in another area of ram, and windows is entirely
> a graphics app, but the chance that a bug with ram could not spill over and
> effect the graphics data is remote.
> video cards use completely different addresses and ram for graphics. Text
> has to have legacy support because lots of apps addressed the ram address
> B000:0000 directly, bypassing dos, so the industry can't do anything
> creative, but graphics has evolved considerably because windows apps are not
> supposed to address ram directly. With that in mind, the text functions of
> the video card could fail separately from the graphics portion.
>
> Having said all that, this sort of 'targeted' failure also looks like a
> virus attack, however. A virus may have only the capability to mess with
> the text functions, because of size, or the hacker's inexperience.
> Tom Turak
>
> -----Original Message-----
> From: james martiny [mailto:[log in to unmask]]
> Sent: Saturday, August 18, 2001 7:18 PM
>
>
> I have a lexbook se10 notebook running win 3.11. Text characters that
> appear on the screen at bootup, all dos text, and text in the cmos setup
> screens have garbled charaecters. Most characters that are bad have the
> next ascii value. t's are u's, r's are s's etc. The cmos screens also have
> many exclamation marks (!) all over the screen. win 3.11 seems to run ok.
> The initial cmos screen has the date and time changing wildly. I have run
> virus checks for dos and 3.11 and they have been clean. Is this just a cmos
> battery issue? or a MB problem? I was leaning towards the cmos battery idea
> , but even a dos prompt and typing in dos commands have changed charecters.
> Whwy would the cmos battery have anything to do with the system after bootup
> and OS load?
>
> The NOSPIN Group provides a monthly newsletter with great
> tips, information and ideas: NOSPIN-L, The NOSPIN Magazine
> Visit our web site to signup: http://freepctech.com
>
PCBUILD maintains hundreds of useful files for download
visit our download web page at:
http://freepctech.com/downloads.shtml
|
