forrest@blia.UUCP (06/03/87)
I've been reading this group with great interest but I haven't acquired the software yet because I don't have the patience to put up with the kinds of problems a version 1 product of this complexity is bound to have. Some people enjoy this kind of hacking. I don't. I have been saving most of the bug reports/fixes thinking that when they will be useful when I do get around to using Minix. I'm wondering if this is worthwhile. I would think that since Tannenbaum reads this group he'll incorporate the fixes posted here. Therefore, some future version of Mi,ix will contain the fixes, or will it? Will there be a Minix 2.0 (or any other number) that will contain fixes to all the problems we've heard about? (I'm especially concerned about the winchester driver problems.) Or, will Minix truely emulate Unix, including the problems of getting fixes into some kind of standard distribution. Jon Forrest ucbvax!mtxinu!blia!forrest
ast@botter.UUCP (06/04/87)
In article <2750@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >I would think that since Tannenbaum (sic) >reads this group he'll incorporate the fixes posted here. Probably a good idea to comment on this. 1. I will certainly attempt to correct things that are indisputably bugs. However, many of the postings relate to enhancements, rather than bugs. A few of these are things that are true V7 and were left out of MINIX for one reason or another. I may or may not include them. Others are attempts to use the 286 MMU, be more Berkeley like, etc. I doubt that I can find the time to carefully check out and include these. 2. Part of the value of the system is that the book and software correspond. Major changes of any kind reduce this value, and since issuing a revised book is out of the question before 1992, I am hesitant to make major structural changes. 3. Conclusion: There is much to be said for monitoring this group and saving all the things that you consider interesting because there is no guarantee they will ever be included in an official release, even if they are valid improvements. Andy Tanenbaum (ast@cs.vu.nl)
peter@sugar.UUCP (06/11/87)
Re: "what will and won't appear in MINIX"... I don't know how well you get along with Brian Kernighan, but I have this feeling that you could benefit by collaboration on a couple of tools for minix, mainly the software tools editor. This is a wonderful program that is almost isomorphic (wonderful word) to UNIX "ed". Since the tools sources are not included in the book, you wouldn't be causing much in the way of incompatibilities... and the lack of "ed" is a sore point among us hard-core UNIX fanatics. I would type it in myself, but I have already done that exercise (on behalf of RSX-11M) once and I feel it's perhaps someone else's turn.
ast@botter.UUCP (06/17/87)
In article <156@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) suggests:
Why doesn't somebody type in the Software Tools editor (ed like).
I believe there are two versions of it, one in Pascal and one it Ratfor.
If anyone has it in Pascal, I can translate it here to a MINIX binary
and post it, but first be sure it works on V7 (i.e., find a PDP-11 with
V7 to test it, and be sure it isn't using library routines MINIX does not
have, or write them yourself).
Another useful project for someone to do is to see if mined can be modified
to handle files > 40K. At present it holds the file being edited entirely
in core. To handle larger files, it would have to use a scratch file,
which is a nontrivial modification to the editor. The design decision to
keep the edited file in core had to do with (1) lack of anywhere to put
the scratch file on nearly full floppy only systems, (2) performance of
floppy only systems.
I asked this before but got no response so I will ask again. Has anyone
tried the 2 line EGA board fix from Der-Ru Sheu (Georgia Tech). I can't
seem to get it to work.
Andy Tanenbaum (ast@cs.vu.nl)schmitz@uiucdcsb.cs.uiuc.edu (06/19/87)
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 | +=============================================================================+