marks@elec.uq.oz (Mark Schulz) (10/03/88)
Sorry, the address to reply to for the new tty driver is hannam@elec.uq.oz I have recieved some mail asking for details on how the EGA fixes work in my new tty driver. A short explanation may be useful. The new code uses the old hardware wrap method except that it takes care when reaching the wrap position in memory. At the moment this is set up as only power of 2 sizes as it is easier to AND an address with a mask than to compare it with an arbitrary memory size. This is a change made purly for convenience and should not be a problem as most people have power of 2 sizes of memory on their video card. If not, a little memory gets wasted - who cares ? The new code works as follows ... It checks for screen wrap on this request If there will be wrap, the section that would wrap gets written in two places - both over the wrap and at the start of memory. The blocks to be written are then broken up into smaller blocks (if necessary) so that there is no glitching on cga screens. If necessary video retrace is waited for before writing each block. There has been an underlying assumption made about the amount of memory on EGA screens. The assumption is that it has the CGA's 16K plus atleast another screen fulls worth of RAM. If this is considered (I don't know how the majority of EGA cards stand on memory) a sever restriction, the easy solution is to change the CGA mask to 8K. This causes inconsequential decreases in performance and may be preferable to allow maximal compatibility. The beauty of the code is that it makes no assumptions on how the video card will wrap and can handle either. The real nitty-gritty of the code is in klib88.as. The calls to vid_write(), vid_bmove(), vid_fmove() and vid_fill() never have to worry about how the video card handles its memory only that it has memory from 0 to vid_mask + 1 + 80*25*2 for cards that will not wrap the memory themselves and 0 to vid_mask + 1 for those that will wrap the memory themselves. I hope this helps those with enquiries on this regard. In regard to having to recompile all ioctl using programs, the reason is that sgtty.h has changed the definition of TIOCGETC etc to include information as to whether the parameter is an in, out or void type parameter. This is the same way UNIX (atleast in the BSD versions) does it and is useful for preprocessing arguments to ioctl. This could possibly be stripped out to make it compatible with the old at the expense of code size. My opinion is that as long as you are going to have to recompile a fair number of the ioctl call using programs you might as well recompile them all and fix a difficency in MINIX. P.S. I too am missing a section of the source code to elle. That is why the new tty sources are all in files small enough to be edited with mined.