chasm@killer.DALLAS.TX.US (Charles Marslett) (10/16/88)
Hello world,
I have finally brought up 1.3 (1.2 worked nicely, but I made most of the
possible mistakes updating my sources for 1.3, . . . next time I will
pay better attention to what I am doing!). But my EGA with CGA monitor
stopped working. To bring it back to life, I had to make the following
changes to "console.c". It seems the value written to CRTC register 7
when in a normal text mode differs depending on whether you are in a 350
scan line mode or a 200 scan line mode (seems reasonable).
(Pardon the kludgy notation, I do not have cdiff up and running yet.)
To make EGAs work with 200 line monitors, add the following two lines
after the declarations for vid_retrace, vid_base and esc:
+ PRIVATE unsigned char high_compare;
+ PRIVATE unsigned char low_compare;
then change the 0x0f and 0x1f in the code ending ega_int():
if (ega_line > 255)
! setb6845(OVRFL_REG, 0x1f); /* high order bit is in overflow reg */
else
! setb6845(OVRFL_REG, 0x0f); /* high order bit 0 */
setb6845(LINE_CMP, ega_line & 0xff); /* now set line compare reg */
restore(old_state);
need_ega_int = 0;
to low_compare and high_compare respectively:
if (ega_line > 255)
! setb6845(OVRFL_REG, high_compare); /* high order bit is in overflow reg */
else
! setb6845(OVRFL_REG, low_compare); /* high order bit 0 */
setb6845(LINE_CMP, ega_line & 0xff); /* now set line compare reg */
restore(old_state);
need_ega_int = 0;
and add setup code for low_compare and high_compare to the ega code in
tty_init():
char_height = get_byte(0x40, 0x85);
+ if (char_height > 10) {
+ low_compare = 0x0F;
+ high_compare = 0x1F;
+ }
+ else {
+ low_compare = 0x01;
+ high_compare = 0x11;
+ }
and finally, make the same change to the subroutine func_key():
! setb6845(OVRFL_REG, 0x1f);
setb6845(LINE_CMP, 0xff);
to
! setb6845(OVRFL_REG, high_compare);
setb6845(LINE_CMP, 0xff);
---
This will handle EGA cards with 200 line color monitors, monochrome
monitors and 350 line EGA or multisync monitors when run in 25 line
modes (it gets more complicated from there ;-).
I have also "repaired" the build utility for cross compiling MINIX
under MSDOS so it does not require a freshly formatted diskette each
time MINIX is built -- I just moved some of the disk I/O code from
the 1.3 boot and other parts from fsck, and now it works all the time.
It seems that MSDOS looks at the boot sector for information as to
how many sectors are on a track and the MINIX boot has the "wrong"
value there.
Is anyone interested in it? -- The changes are rather large for such
a small program.
Charles Marslett
STB Systems, Inc. <-- apply all standard disclaimers
chasm@killer.dallas.tx.us