lisa@phs.UUCP (Jeffrey William Gillette) (10/11/85)
[] After spending a week pouring over fifty pages of disassembled object code, I think I finally have some understanding of how Xenix is handling the screen of my AT. For those who have been following this discussion, I will attempt to summarize my theories. This is my first serious attempt at understanding a *NIX device driver, so if I misinterpret the code, someone please correct me. The Santa Clara Operations console driver supports four display cards: the mca (monochrome adapter), cga (color graphics adapter), ega (enhanced graphics adapter), and hga (Hercules graphics card?). Each of these cards have separate initialization and set cursor routines. Mca, cga, and hga have separate routines for scroll, copy, pchar, clear, and something abbreviated "sgr". The ega appears to use either the cga or hga routines for these functions. The _egainit procedure assumes a color monitor, and thus sets the register addresses for the 3d0h - 3dfh range. As Robin Cutshaw has kindly pointed out, a simple patch to the initCRTC routine will avoid reinitializing the ega running in enhanced color mode, thus preserving the high resolution color character set. Alas my simple and cheap monochrome monitor will not allow such a simple and elegant solution. My ega running in monochrome mode has declared war on Xenix. It is impossible to boot Xenix with the ega in any monochrome mode without significant modifications to the console driver. The three options are to rewrite the driver (something I've never done, and would have preferred not to start just now), trick Xenix into thinking I have a monochrome card, or let it initialize the ega, but change the port addresses and video ram segment number. Making Xenix think I have a monochrome card is a simple procedure - just a patch to the crtinit routine. This (plus the initCRTC patch) allows my machine to boot Xenix, and to write the screen perfectly. Alas, the differences between the mca and the ega. The monochrome card appears to have 2048 bytes memory, and a register that allows one to start the screen display at any arbitrary byte. SCO decided to scroll the mca by changing the start address, and blanking only those lines that need to be blanked. At the end of mca memory, both the pchar routine and the 6845 controller wrap around to the beginning, and the screen display appears perfectly normal. The ega, with much more RAM, refuses to oblige. The console device wraps back to the beginning of video memory, but the ega screen simply slides off the end. The result is a progressively empty screen, until the whole display is blank and the mcascroll routine moves the beginning back to the top of memory - the next carriage return produces a full screen of text! The amount of patching that would have to be done to fix this glitch would probably be no worse than writing an entire driver from scratch - and doing it *right*! Patching the actual ega/cga/hga routines appears to hold greater promise. It is not too difficult to change all the '2d0's (the base address of the color registers) into '2b0's (monochrome base address). I think I have caught all of these. Rather more difficult for me has been attempting to discover in what routine the es register is set to the video memory segment, and changing the 0B800h color segment into an 0B000h. If anyone has any ideas, please let me know. At any rate, xenix thus patched appears to be less stable - sometimes it boots acceptably (the cursor moves fine but there are no characters on the screen). At other times it initiates a hardware reset. At this point my experience has taught me much about Xenix (and a little about the ega), but has not allowed me to run Xenix with my ega in anything approaching normal operations. I hope this information is of help and/or interest to someone else - and that someone might have some ideas that will help me reconcile these two mortal enemies - Xenix and the Enhanced Graphics Adapter. Jeffrey William Gillette uucp: duke!phys!lisa The Divinity School bitnet: DYBBUK @ TUCCVM Duke University