[comp.os.minix] MINIX 1.2 on a clone...

coleman@watson.seas.ucla.edu (Kenneth Coleman) (02/01/91)

	I have a small problem running MINIX 1.2 on an IBM compatible...  
Everything works fine, but about every 100 lines or so, the output stops
echoing to the screen, and when the first line that didn't echo reaches
the top of the screen, it all immediately comes back.  I can live with it,
but I would prefer not to have it.  The computer is a 286 clone with VGA,
if that helps.  Any help would be greatly appreciated...

Thanks in advance...
- Ken.

peter@pa3ebv.nl.mugnet.org (Peter J. de Vrijer) (02/04/91)

In article <1734@lee.SEAS.UCLA.EDU>, coleman@watson.seas.ucla.edu (Kenneth Coleman) wrote:
> 
> 	I have a small problem running MINIX 1.2 on an IBM compatible...  
> Everything works fine, but about every 100 lines or so, the output stops
> echoing to the screen, and when the first line that didn't echo reaches
> the top of the screen, it all immediately comes back.  I can live with it,
> but I would prefer not to have it.  The computer is a 286 clone with VGA,
> if that helps.  Any help would be greatly appreciated...

Whell the answer is not a short one I fear.
I had the same problem when using MINIX 1.2 on a 286 clone. The easiest
solution is getting hold of 1.3 or better still 1.5.10. In these versions
the problem is solved.

If you want to solve it yourself I have some clues for you.
Firstly I have hear part of the header of the new console.c of 1.5.10

--- from console.c ---

 * The video controller chip (6845) has a register that points to the address
 * in memory of the first line of the screen.  By increasing the value of this
 * register the screen can be moved up a line.  This means that the screen can
 * be made to scroll very fast since it is not necessary to move the entire
 * screen about in memory.  Eventually the last line of the screen will exceed
 * the video RAM.  Depending on the controller the memory may wrap around to
 * the start of video RAM, or it may be necessary to copy the screen back up to
 * the start of video RAM.  Scrolling the virtual console is performed in a
 * similar fashion - the data is contained in a cyclic buffer, and a pointer
 * to the first character is maintained.  The current video RAM contents
 * reflect the foreground virtual console memory.
 *
 * The IBM display is memory mapped, so outputing characters such as line
 * feed, backspace and bell are tricky.  Each character on the screen is
 * described by a pair of adjacent bytes.  The first byte contains character
 * attribute information, such as the display colors.  The second byte contains
 * the code of the character to be displayed.  Accessing the display memory is
 * expensive since it typically is not dual ported, this means that the CPU has
 * to perform wait states if it tries to access it while the video controller
 * is.  A block copy operation to the video memory might run at one tenth of
 * the speed of a block copy to normal memory.  On the CGA card the CPU is not
 * forced to wait, instead the video controller is locked out while the CPU
 * accesses memory.  This however causes snow to appear on the screen (small

---
The video memory size on a EGA/VGA board isn't 0x0800 but something like
0x2000 words. What happens is that when you exceed 0x0800 in the video
memory the software starts wrapping but the video controller expects
the memory to go on to 0x2000, and that part is empty. When the start
of the screen exceeds 0x0800 the software resets the video controler
to the start of the video memory and back is your screen.

I had to solve two problems to get it correct.

1) The video memory size on my EGA/VGA board wasn't 0x0800 but 0x2000 words.
   This is easy to solve, just changing a #define in console.c

2) The video controler must be set in the automatic wrap. Which wasn't the
   case with my clone. I didn't solve it so I had to double all characters
   exceeding 0x0800. They where written to addresses higher than 0x0800 
   and to addresses at the start of the video memory (i.e. a character
   written to 0x0020 was written to 0x0820 as well). You must do this
   _always_ since sometimes you use backscroll. The part that does this
   function is somewhere in the assembler part of the kernel.

I hope with this information you can solve your problems.

Regards from Peter.