how@milhow1.UUCP (Mike Howard) (09/21/88)
I was recently writing some graphics software for my SCO 386 2.2.3
and ran into a `bug' in ioctl(). The sequence:
fd = open("/dev/mono", O_RDWR);
ioctl(fd, MCAMODE, (char *)0);
anthing
leaves the screen screwed up. Text is displayed, but end-of-line processing
is perminently damaged. Only a reboot seems to fix it.
The same thing happens when I type `stty MCAMODE </dev/mono' (actually
the `</dev/mono' may be optional - memory fails).
Anybody else have this problem? Is it a known (and fixed) bug?
Equipment:
Mylex Mother
Brand X Herc clone
SCO Xenix 386 2.2.3
more stuff.
(p.s. I have seen this also on a Brand Y Herc clone)
--
Mike Howard
uunet!milhow1!howdavid@infopro.UUCP (David Fiedler) (09/21/88)
From article <221@milhow1.UUCP>, by how@milhow1.UUCP (Mike Howard): > I was recently writing some graphics software for my SCO 386 2.2.3 > and ran into a `bug' in ioctl(). > Equipment: > Mylex Mother > Brand X Herc clone > SCO Xenix 386 2.2.3 > more stuff. > > (p.s. I have seen this also on a Brand Y Herc clone) XEnix seems to be sensitive to Hercules clones. The only time I have ever seen any graphics software running on SCO Xenix was at Uniforum. When I asked them how they did it (since I couldn't get my clone to do squat either -- this was VP/ix), they said "use a Hercules card". I gave up and got a MultiSync GS (mono) monitor, with which I can run CGA, EGA, and VGA software with no problems, and am now waiting for the X-Windows on VGA from SCO so I can buy a VGA board... David Fiedler {ames,attmail,hoptoad,pyramid}!infopro!david USMail: InfoPro Systems, PO Box 220, Rescue CA 95672 Phone: 916/677-5870 -- David Fiedler {ames,attmail,hoptoad,pyramid}!infopro!david USMail: InfoPro Systems, PO Box 220, Rescue CA 95672 Phone: 916/677-5870
daveh@marob.MASA.COM (Dave Hammond) (09/22/88)
In article <221@milhow1.UUCP> how@milhow1.UUCP (Mike Howard) writes: >I was recently writing some graphics software for my SCO 386 2.2.3 >and ran into a `bug' in ioctl(). The sequence: > fd = open("/dev/mono", O_RDWR); > ioctl(fd, MCAMODE, (char *)0); > anthing > >leaves the screen screwed up. Text is displayed, but end-of-line processing >is perminently damaged. Only a reboot seems to fix it. I've experienced similar problems with /dev/console (mono or color). Sending the `attributes off' ( \033[m ) sequence has helped in the past. Dave Hammond UUCP: uunet!masa.com!{marob,dsix2}!daveh DOMAIN: daveh@marob.masa.com ------------------------------------------------------------------------------
jim@applix.UUCP (Jim Morton) (09/22/88)
In article <221@milhow1.UUCP>, how@milhow1.UUCP (Mike Howard) writes: | I was recently writing some graphics software for my SCO 386 2.2.3 | and ran into a `bug' in ioctl(). The sequence: | fd = open("/dev/mono", O_RDWR); | ioctl(fd, MCAMODE, (char *)0); | anthing | | leaves the screen screwed up. Text is displayed, but end-of-line processing | is perminently damaged. Only a reboot seems to fix it. | The same thing happens when I type `stty MCAMODE </dev/mono' (actually Yup, I found this too. Brian at SCO acknowledged that this could a problem. (I tried it on a real Herc and a real Herc-Plus card). Beats me how this ever made it through even trivial QA, though. It's fixed in 2.3. The fact that Herc was only supported in 2.2.2 and 2.2.3, not 2.2.1, and this bug, means if you intend to use your machine with a Hercules card and expect a graphics application to work, get Xenix 2.3. If anyone comes up with an ingenious way to reset the console driver's notion of where a line ends when it gets into this wierd mode, please let the rest of us know! -- Jim Morton, APPLiX Inc., Westboro, MA UUCP: ...harvard!m2c!applix!jim jim@applix.m2c.org
jim@applix.UUCP (Jim Morton) (09/30/88)
The following patch can be applied to 386 2.2.2 and 2.2.3 kernels
to fix the Hercules graphics mode reset bug. The cause of the bug
was that the reset values for Nrow and Ncol were swapped. (Nrow
should be 0x19 = 25 decimal, Ncol should be 0x50 = 80 decimal).
# adb -w /xenix -
* cnioctl+0x522?x
_cnioctl+0x522: 0x50
* cnioctl+0x522?w 0x19
_cnioctl+0x522: 0x50= 0x19
* cnioctl+0x52c?x
_cnioctl+0x52c: 0x19
* cnioctl+0x52c?w 0x50
_cnioctl+0x52c: 0x19= 0x50
* $q
# cd /
# sync;sync;reboot
Disclaimer: this is my fix, not SCO's. SCO's is called release 2.3.1.
--
Jim Morton, APPLiX Inc., Westboro, MA
UUCP: ...harvard!m2c!applix!jim
jim@applix.m2c.org