💾 Archived View for uscoffings.net › retro-computing › systems › Tandy › oldskool › egat1k.txt captured on 2023-09-28 at 18:59:01.
⬅️ Previous capture (2023-07-10)
-=-=-=-=-=-=-
Edited TandyPro message concerning the original Tandy 1000's and EGA
#: 121055 S5/T1000/1400/3000/4K
(through message number)
#: 121060 S5/T1000/1400/3000/4K
18-Nov-88 02:13:33
Sb: EGA & Tandy 1000
Fm: H. Brothers <OLT/PCR> 70007,1150
Bill (and others who said they were interested),
As I said earlier, Matthew Electronics is no longer manufacturing an EGA
card for the Tandy 1000 and 1000A. The technologies used in that card were
and are protected as trade secrets, but they have graciously agreed that I can
release the following information and answer questions about it.
I need to be a little cautious here. We found wide diversity among various
EGA cards used as described below. Some worked well for 90% or more of the
applications we tried, some didn't. In general, the simpler the EGA card was,
the better it worked (there are good reasons for that). If you try the
following, neither I nor Matthew Electronics can assume any responsibility for
any results, positive or negative. If you do something like try to run the
EGA output through a CGA monitor, you can damage the monitor. There may be
other dangers lurking, although we found none with the boards we used. Be
that as it may, the following produced good results for us with the boards we
tested (within the limitations I'll explain in a minute) and caused no damage
to the computers we used, the EGA boards nor the monitors, but we can't
guarantee that you will have the same results. If you try it, you are on your
own. I don't mean to either scare you off and the lawyers say I can't
encourage you (does that make sense)?
With all that aside, we need to start with a little technical background.
On the Tandy 1000, 1000A, and 1000 HD, in their various incarnations, the
motherboard contains hardwired enhanced CGA circuitry that normally cannot be
disabled. Almost the very first thing the computer does during boot up is to
initialize the video circuitry so that the memory test meesages, any error
messages, etc. can appear on the screen.
Later during the boot up stuff, the computer performs what is known as a
ROM Scan, looking for boards that you have added which contain their own ROM
BIOS and which need to be initialized. In most PC/XT/AT computers, the ROM
Scan starts at absolute address 0C0000 hex; on the T1K/1KA, the scan begins at
address 0C8000 hex. The reason for the difference is that add-on video boards
traditionally have their BIOS addressed starting at C0000 and the T1K
specifically wants to avoid installing an additional video card. So it will
install a hard disk (normally the hard disk controller is at C8000) but not a
video card. If you simply plug an EGA card into a T1K, it won't work at all
because its on-board BIOS never gets a chance to initialize the board or hook
itself into the video service interrupt (INT 10h).
Now, the adventurous will immediately say to themselves, "What happens if
I simply call the EGA BIOS and let it install itself?" The code to do so an be
written with Debug or an assembler and is very simple:
CALL 0C000:3
INT 20h 'return to DOS
If you put an EGA card into your Tandy 1000, write the above program with
Debug and save it as a .COM file and then run it, an interesting thing
happens: the EGA card starts working and your CGA display goes crazy
(assuming you have set the EGA switches to say you have high resolution color
monitor).
Here's what has happened: In color modes, the EGA uses some CGA-specific
ports. The EGA initialization routines have written values to those ports,
and those values have gone to both the CGA and EGA cards simultaneously. You
have set sync timings that are correct for the EGA but wildly incorrect for
the CGA. (Just the opposite happened during bootup when the computer
initialized the CGA and sent "wrong" values to the EGA ports while it was
writing to the CGA).
Will those "wrong" values hurt the CGA or EGA electronics? Most likely
not -- they never did for us, but I'm required to hedge here. Will they hurt
your monitor? Quite possibly, if you let them. If the sync values are far
from what a monitor can accept, you can destroy the monitor. Someone on
another forum told me how he once blew up 3 NEC Multisyncs in one day while
trying to get the sync timings right on some specialized hardware.
However, IF you have a multi-sync monitor like the NEC Multisync, Sony
Multiscan, etc., and if you are careful, you can do the following: boot up the
computer with the monitor attached to the Tandy video output and do whatever
you want. When you want to install the EGA, disconnect the monitor, run the
program above, and then (and only then) plug the monitor into the EGA card's
output. If you have an EGA-only monitor, do NOT plug it into Tandy's video
output. Just leave it powered off until after you initialize the EGA card
(but turn off your CGA monitor before you run the program).
Okay, so now we have the EGA initialized. what happens? Any port writes
to the EGA video controller (which generally occur to set the cursor position
or change video modes) will go to both the CGA (which we have disconnected)
and the EGA. The CGA chip may be confused, but with no monitor attached to
it, so what? Also, all memory writes in EGA text modes will also go to the
CGA. The same addressing problem occurs followed by the same so what?
But there are problems. The only readable registers that can cause
conflicts are those that tell the BIOS or a program where the cursor is. Both
the CGA and EGA will answer with the same information because the same
information was written to each. And anytime a program or the BIOS tries to
read text memory, it will get the identical information that was stored in
both. This is decidedly sloppy engineering, but it does work in many cases,
because the access speeds are approximately the same and are mediated by the
T1K's slow bus.
But there are some problems and here is where you may find the above will
not work correctly. Any program that tries to read the status port -that is,
which tries to time itself according to the sync rates -- will get strange
results. 2 kinds of programs do this: CGA-type programs that avoid "snow" and
EGA graphics programs that do panning. Also, the EGA BIOS itself reads the
sync status when you change character sets on the fly, if I remember
correctly.
Generally, what you will see is jerkyness. An EGA demo called
Panscreen, for example, runs faster than it should and looks jerky because the
sync status it reads is uneven.
Second, if you try touse an auto-sensing board -- one that configures
itself automatically to Monochrome, CGA or EGA -- there will be real problems.
Such boards often use the NMI line to adjust themselves. To do so, they have
to write to Port 0A0 hex, which is the NMI gate. In the Tandy 1000, that port
also controls memory mapping. Such writes destroy the memory map, lock up the
computer, and cause all sorts of headaches.
Tird, if an EGA text program tries to use more than 4 pages, you will have
problems (but very very few do). The problems will probably result in a
garbled screen and PrtScreen that throws garbage at your printer.
But the vast majority of EGA programs don't do any of these things and
will run normally. So will almost all text-based programs, at least in our
experience. If you have or can borrow an EGA card, it is worth a try, in my
own opinion, but be careful to connect (or turn on) and disconnect (or turn
off) your monitors at the correct time.
One further note. This is NOT how the Matthew EGA board worked. They
added software-controllable electronics that completely disabled either the
EGA or CGA, as appropriate, so none of these conflicts occurred. However, we
began with the "what if" question above and, for several months, ran many EGA
graphics and text programs as I described above before deciding to prototype,
build, and market a specialized and well-engineered board. The reasons they
stopped making them are several, but I'm not free to discuss them except to
say that those who bought the boards were very happy with them.
I'll be happy to answer questions about the techniques above, but I can't
discuss how MEI's additional electronics enabled and disabled the CGA and EGA
(easy on the 1000, more difficult on the 1000A).
1. I'd be _very_ reluctant to try any of the above with a VGA.
2. If very large programs start acting strange, or programs written in
Basic (almost any flavor) or Turbo Pascal, it is because of memory conflicts
(remember that the T1K uses the top of normal memory as video memory). We
didn't find any such problems, but if you do, my last articles in 80 Micro
showed how to lower DOS's perception of the top of memory and avoid such
conflicts.
-- hardin