Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!lll-tis!ptsfa!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uiucdcsb!schmitz From: schmitz@uiucdcsb.cs.uiuc.edu Newsgroups: comp.os.minix Subject: Re: Bug Fixes to Minix (really abou Message-ID: <180000002@uiucdcsb> Date: Fri, 19-Jun-87 16:00:00 EDT Article-I.D.: uiucdcsb.180000002 Posted: Fri Jun 19 16:00:00 1987 Date-Received: Mon, 22-Jun-87 05:35:44 EDT References: <1213@botter.cs.vu.nl> Lines: 67 Nf-ID: #R:botter.cs.vu.nl:1213:uiucdcsb:180000002:000:3612 Nf-From: uiucdcsb.cs.uiuc.edu!schmitz Jun 19 15:00:00 1987 The 'quick fix' for video scrolling which involves 'cheating the hardware' that there is less memory on the video card then there actually is doesn't work for me either. I have a Paradise Autoswitch in an AT compatable. I'm currently using the patch posted by Gary Oliver. It works but it is *much* slower than the distribution version (which would scroll several pages of text and then several blank screens). So, I've been experimenting with the video myself. I would like to implement scrolling by changing the start address high and start address low registers of the CRT controller chip. The problem is that you have to get wraparound at the end of the video buffer. There are two ways the processor can access the regen buffer. In odd/even mode ascii codes go to bit plane zero and the corresponding attribute bytes go to bit plane one, transparently to the programmer. In this mode, all the odd physical locations in both bit planes are apparently left blank. Alternatively, one can explicitly set the video card so that the ascii codes and the attribute bytes are written separately and the programmer has to explicitly switch bit planes. In this way, odd locations in both bit planes can be written to. The memory address counter is a 16 bit internal register which determines where the character generator will get its next character/attribute byte pair. There are two ways (actually 3) that the memory address counter can be set up. In byte mode it will sequentially access all the byte locations in bit plane 0 and the corresponding attribute bytes in bit plane 1. In word mode it accesses only the even locations in bit plane 0 and the corresponding attribute bytes in bit plane 1. Thus word mode for the memory address counter should be matched with odd/even processor access mode. Now in byte mode and no odd/even I can get video buffer wraparound to work just fine. A 64K buffer is needed, of course, and this can be located at B0000 or A0000. There is a catch in word mode. When the high bit of the memory address counter becomes 1, the ascii codes are fetched from the odd locations in bit plane 0 and the attribute bytes from the corresponding locations in bit plane 1. This sort of destroys wraparound since when the processor accesses are in odd/even mode it seems to be impossible to even write to odd locations. This is what accounts for all those blank screenfuls. The high bit of the memory address counter has become 1 and there is nothing in the corresponding odd locations. You can't mask out high order bits here. Conclusion. It seems you can't have transparent writing of ascii/attribute pairs while keeping video wraparound. I do have a demo program illustrating programming the EGA in byte mode using a 64K buffer and incorporating video wraparound. It's a DOS program written for MASM 4.0. If anyone wants a copy, I'll gladly send it out. Question. Is the byte solution acceptable to implement in MINIX. That is how often will non-normal attribute bytes need to be written? Can writes be buffered on a line by line basis to avoid too much switching of bit planes? This is the only possible source of inefficiency. +=============================================================================+ | Michael Schmitz University of Illinois Dept. of CS (217) 333-6680 | | | | arpa schmitz@b.cs.uiuc.edu | | csnet schmitz@uiuc.csnet | | usenet ihnp4!uiucdcs!schmitz | +=============================================================================+