go@orstcs.UUCP (04/04/87)
Minix arrived today (4/3/87)!! I am running Minix on a nameless clone (Made in Taiwan, R.O.C.) brand with 640K, 1 fpy, and a WD1002-WS2 HD controller with ST-238 (used as non-rll (i.e. not 2,7 rll) drive), and (the problem board) a "CT-6040S" Hercules Compatible mono-graphics card. The problem seems to be that the display works fine for 24 lines then has garbage for 24 lines, but displays the correct second 24 lines when the last of the first 24 scrolls off the display: line 1 line 2 ... line 23 line 24 <should be line 24, but garbage..> < goes on for 22 more lines> <when line 24, above, scrolls off the display, lines 25-48 show up> ... <more of the same> In other words, you have to scroll 48 lines instead of 24 for each 24 lines, but all characters seem to be there. Looks line something is botching the "page" register (0 or 1 to select first or second graphics page, I think. The doc with this card is sketchy and I am not up-to-speed on PC-widgets yet.) I didn't realize until I looked in the "manual" that came with the display controller that I don't really know who made it. The only clue is the "CT-6040S." It was obtained recently from one of our local clone-benders. Just as soon as I figure out how to create two partitions (/usr and /user) on my hard disk, I'll go in and mess with the display driver to try some things out. But M(i)S(ery)-DOS 3.2 doesn't want me to have more than one partition. Got to make something up.. ...!hp-pcd!orstcs!go Gary Oliver
go@orstcs.UUCP (04/06/87)
Regarding my previous display-controller "buglet" note involving my problem with Minix on the CT-6040S mono-graphics controller: The problem has been solved with a cheap patch as follows: In tty_init (lines 4480 thru 4483) the mono-graphics setup occurs. The value of M_VID_MASK is 0xFFF in the distribution. I changed it to 0x1FFF for my card. It seems that many (most) mono-compatible cards will ignore addresses generated outside the bottom 4k bytes while in "character" mode. Mine doesn't. And since (it appears) that BIOS simply shuffles characters rather than letting the 6845 do the work, the board works fine under MS-DOS/etc. By changing the 0xFFF to 0x1FFF, I am allowing Minix to address the first 8K bytes, or the first "page" of my card in "character" mode. I know. This isn't exactly intuitive to me either, but it works. If any of you out there experience the problem I mentioned in this base note, you might try playing with this constant. The "patch" is as follows (I haven't tried building Minix yet, so wanted a quick way to test my "thesis"): On MS-DOS, invoke DEBUG. Place the Minix *BOOT* disk (v1.1) in drive A:. Issue the command L 0 0 0 40 ( Reads 32K -- a waste, but works ) If your version of MS-DOS gives a "General ... error", simply enter a "R" for retry. (I am using MS-DOS 3.2 (the buggy version)) Issue the command: E1400 DEBUG should respond by opening 1400 and showing that it contains a 0x0F. Enter 1F (or whatever you want to try.) Now: W 0 0 0 40 ( Write the stuff back out) Again, ignore any "General .." errors -- MS-DOS seems to check to see if this is a valid MS-DOS disk and just complains for good measure. A more general fix would be to somehow determine if the controller has this problem and to adjust the value of vid_mask accordingly. To date, I know of no way to do this. So I am stuck with a non-standard value. Pity. I'll get by, though. I'm having fun! Gary Oliver ...!hp-pcd!orstcs!go
myxm@a.UUCP (04/06/87)
The problem you descibe with hercules display adpaters it the same as that experienced with the ega. probably just a coding bug. anyone with a fix? Mike Mitchell myxm@lanl.arpa