H. Peter Anvin wrote:
Now, I think there is a specific reason to believe that EGA/VGA (but
perhaps not CGA/MDA) didn't need these kinds of hacks: the video cards
of the day was touched, directly, by an interminable number of DOS
applications. CGA/MDA generally *were not*, due to the unsynchronized
memory of the original versions (writing could cause snow), so most
applications tended to fall back to using the BIOS access methods for
CGA and MDA.
A little history... not that it really matters, but some might be
interested in a 55-year-old hacker's sentimental recollections...As
someone who actually wrote drivers for CGA and MDA on the original IBM
PC, I can tell you that back to back I/O *port* writes and reads were
perfectly fine. The "snow" problem had nothing to do with I/O ports.
It had to do with the memory on the CGA adapter card not being dual
ported, and in high-res (80x25) character mode (only!) a CPU read or
write access caused a read of the adapter memory by the
character-generator to fail, causing one character-position of the
current scanline being output to get all random bits, which was then put
through the character-generator and generated whatever the character
generator did with 8 random bits of character or attributes as an index
into the character generator's font table.
In particular, the solution in both the BIOS and in Visicalc, 1-2-3, and
other products that did NOT use the BIOS or DOS for I/O to the CGA or
MDA because they were Dog Slow, was to detect the CGA, and do a *very*
tight loop doing "inb" instructions from one of the CGA status
registers, looking for a 0-1 transition on the horizontal retrace flag.
It would then do a write to display memory with all interrupts locked
out, because that was all it could do during the horizontal retrace,
given the speed of the processor. One of the hacks I did in those days
(I wrote the CGA driver for Visicalc Advanced Version and several other
Software Arts programs, some of which were sold to Lotus when they
bought our assets, and hired me, in 1985) was to measure the "horizontal
retrace time" and the "vertical blanking interval" when the program
started, and compile screen-writing code that squeezed as many writes as
possible into both horizontal retraces and vertical retraces. That was
actually a "selling point" for spreadsheets - the reviewers actually
measured whether you could use the down-arrow key in auto-repeat mode
and keep the screen scrolling at the relevant rate! That was hard on an
8088 or 80286 processor, with a CGA card.
It was great when EGA and VGA came out, but we still had to support the
CGA long after. Which is why I fully understand the need not to break
old machines. We had to run on every machine that was claimed to be "PC
compatible" - many of which were hardly so compatible (the PS/2 model
50 had a completely erroneous serial chip that claimed to emulate the
original 8250, but had an immense pile of bugs, for example, that IBM
begged ISVs to call a software problem and fix so they didn't get sued).
The IBM PC bus (predecessor of the current ISA bus, which came from the
PC-AT's 16-bit bus), did just fine electrically - any I/O port-specific
timing problems had to do with the timing of the chips attached to the
bus. For example, if a bus write to a port was routed into a particular
chip, the timing of that chip's subsequent processing might be such that
it was not ready to respond to another read or write.) That's not a
"signalling" problem - it has nothing to do with capacitance on the bus,
e.g., but a functional speed problem in the chip (if on the motherboard)
or the adapter card.
Rant off. This has nothing, of course, to do with present issues.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
