jallen@netxcom.UUCP (04/08/87)
Well, I just started up Minix on my clone for the first time.
I haven't done anything with the hard disk yet, but it seems
to do fine with my Faraday motherboard and Taiwan floppy controller.
There is some strange behavior on my clone EGA board though. Sure,
I know Minix only runs on CGAs and MDAs, but I was hoping that the
C&T chip set would provide enough CGA compatibility to run. What
happens is that after 50 or 75 lines have been displayed, the next
15 or so aren't painted -- I see the cursor move, but no characters
are displayed. Then after about 15 of these "ghost" lines, the
display begins to paint again, and "as if by magic" the ghost lines
appear on the display.
Has anyone else seen this, or is it just me?
John Allen
=========================================================================
NetExpress Communications, Inc. seismo!{sundc|hadron}!netxcom!jallen
1953 Gallows Road, Suite 300 (703) 749-2238
Vienna, Va., 22180
=========================================================================stuart@bms-at.UUCP (04/11/87)
I have MINIX fired up on my T1100+! To run with 720K diskettes, you need to patch the first entry in the nr_blocks array in floppy.c to 1440 instead of 720. I used Norton utilities to find and patch that word. It is in sector 95 of the boot diskette. Debug will work if you don't have Norton. You should change the source also so that you aren't surprised later. I used CopyIIPC with Snatchit to convert the 8 distribution 5 1/4" floppies to diskette image files. PKARC crunches these into the 600K archive mentioned in a previous article. In article <406@netxcom.UUCP>, jallen@netxcom.UUCP (John Allen) writes: > There is some strange behavior on my clone EGA board though. Sure, > . . . > happens is that after 50 or 75 lines have been displayed, the next > 15 or so aren't painted -- I see the cursor move, but no characters > are displayed. Then after about 15 of these "ghost" lines, the > display begins to paint again, and "as if by magic" the ghost lines > appear on the display. > Has anyone else seen this, or is it just me? This happens on the toshiba LCD display also. In fact, it even happens on my true blue IBM XT, but only rarely. There seems to be a tricky bug in the display driver. -- Stuart D. Gathman <..!seismo!dgis!bms-at!stuart>
diamant@hpfclp.UUCP (04/14/87)
> >What happens is that after 50 or 75 lines have been displayed, the next > >15 or so aren't painted -- I see the cursor move, but no characters > >are displayed. Then after about 15 of these "ghost" lines, the > >display begins to paint again, and "as if by magic" the ghost lines > >appear on the display. > > > >Has anyone else seen this, or is it just me? > > Yes. The Toshiba T1100+, supposedly a real CGA clone, does exactly the > same thing. I haven't figured it out yet... We have seen this on a Leading Edge (don't know the model, but the problem appeared on a Mono. display) as well. However, in that case, I think it was 25 lines on and 25 off. The problem is presumed to be that the display buffer has more memory than a true IBM and that the scrolling algorithm in MINIX assumes that when you get to the bottom, the next line will be the top. If you look in the scroll_screen routine in the tty driver (kernel/tty.c) there are references to a video mask (vid_mask) which is set to 16K for color and 4K for monochrome (line 4000 in the book sources). If the sizes are wrong for your hardware, then the behavior you describe would be likely. We haven't tried fixing the constant yet (haven't found an easy way to find and patch it as opposed to rebuilding the entire system just to test it). Post a note if you try it and it works (also let me know how you patched it if that is what you do). John Diamant SCO UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO
stuart@bms-at.UUCP (Stuart D. Gathman) (04/20/87)
Well, I have gotten to the bottom of the problem with the screen on my T1100+ and Minix. The IBM CGA has 16K of video memory that 'wraps' in text mode. To scroll the screen, Minix simply changes the video origin within this 16K. The toshiba (and other clones, evidently) do not wrap when the video origin is near the end of the 16K. Instead, they display whatever their internal memory subsystem happens to return for those addresses (usually blank and almost always repeating). Minix, meanwhile has been faithfully storing the data at the beginning of the 16K so that when the video origin finally gets to 0 again, the data all reappears! I cannot think of any solution other than to scroll the screen with a big REP MOVSW. Another poster has already offered this solution. It seems a shame. Perhaps this need only be done when the end of video memory is reached (i.e. once every four screens for 1100+). Interesting note - the NORTON utilities show 32K video memory for a true blue CGA. The second 16K is just a mirror image of the first. SYSINFO reports only 16K for the 1100+. Conclusion - this is a compatibility problem with the clones. Unrelated minor complaint. I can't stand all the val&BYTE masking in the MINIX code for parameters passed to port_out (which is defined to take a char anyway)! An optimizing compiler would probably recognize the redundancy and remove it, but I don't have one. -- Stuart D. Gathman <..!seismo!dgis!bms-at!stuart>