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 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