Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!mcsun!hp4nl!phigate!prle!prles2!cst!meulenbr From: meulenbr@cst.philips.nl (Frans Meulenbroeks) Newsgroups: comp.os.minix Subject: Re: ST1.5.10 patch2 scrolling problem Message-ID: Date: 5 Sep 90 06:50:21 GMT References: <2965@aipna.ed.ac.uk> Sender: news@prles2.prl.philips.nl Lines: 114 [I've made a net posting of this. partly because other people may encounter the same problem, partly because it explains a little about /dev/ttys; frans] awb@aipna.ed.ac.uk (Alan W Black) writes: >I have a 4Meg STe with one floppy disk drive (I've ordered the hard >disk -- but its not here yet, and it probably wont work anyway). I have no STe, so I couldn't test it on an STe. This also makes it hard for me to diagnose your problem. >However, I have upgraded my version of 1.5.10 with the two patches Frans sent >out recently -- all crcs are as per the postings (except tos.c but >that isn't relevant). Ok. Did 1.5.10.1 work? >When I boot the 1.5.10.2 it comes up ok but when it tries to scroll >the screen it goes into an infinite loop duplicating the last line of >the screen -- rebooting is the only way out. I have left the NR_CONS >variable as defined in the distribution (I originally tried it with 4 >and had the same problem). When set to 2, I do get two virtual >consoles and can switch between them. As long as I don't fill the >screen the system runs. >I have /etc/ttys to be > 100 > 101 >Though I am not sure of the syntax of this file -- I deleted the 0f1 line >assuming it to be something to do with the rs232 line (which still works >on tty2). This is right. The first 1 says you want a login protocol. The second character specifies the initial baud rate of the port. For a console 0 is the proper value. Other values can be: (from tools/init.c) /* 'a': 110 baud, 8 bits, no parity */ /* 'b': 300 baud, 8 bits, no parity */ /* 'c': 1200 baud, 8 bits, no parity */ /* 'd': 2400 baud, 8 bits, no parity */ /* 'e': 4800 baud, 8 bits, no parity */ /* 'f': 9600 baud, 8 bits, no parity */ /* 'g': 110 baud, 7 bits, even parity */ /* 'h': 300 baud, 7 bits, even parity */ /* 'i': 1200 baud, 7 bits, even parity */ /* 'j': 2400 baud, 7 bits, even parity */ /* 'k': 4800 baud, 7 bits, even parity */ /* 'l': 9600 baud, 7 bits, even parity */ /* 'm': 110 baud, 7 bits, odd parity */ /* 'n': 300 baud, 7 bits, odd parity */ /* 'o': 1200 baud, 7 bits, odd parity */ /* 'p': 2400 baud, 7 bits, odd parity */ /* 'q': 4800 baud, 7 bits, odd parity */ /* 'r': 9600 baud, 7 bits, odd parity */ The third digit specifies the port number so 101 applies to tty1. The rs232 line gets number NR_CONS+1. >I had a look at the code (kernel/stvdu.c) and wonder if its something >to do with the virtual console structure not being initialised properly, >though such things will be difficult to debug when you can't print to the >screen at the time the problem happens. >I also wondered about HARD_SCROLL perhaps there is something different in >STe rather than the ST and although Frans said he has removed that >stuff maybe there's a bit left over, I looked (though not very hard) >for anything like that. I couldn't find a reference for HARD_SCROLL. If you've upgraded everything you should also have a makefile which does not mention HARD_SCROLL any more. >The only thing I can think of is that I recompiled the library forgetting >to upgrade lib/minix/config.h and lib/sys/wait.h which have changed >I did have the new ones when I recompiled the kernel (fs and mm). I >looked to see if anything might be relevant, wait.h shouldn't, but this >does mean I compiled the library with C_RS232_INT_HANDLERS set to 0 >but it doesn't seem to be referenced in the library. (Also I see >NR_DRIVES is set to 3, I assume this is because Frans has 3 drives, unlike >the rest of us :-) Both changes are not important with respect to this problem. C_RS232_INT_HANDLERS is only interesting for the kernel. Sorry to have sent out a version with NR_DRIVES set to 3. >So, does anybody else have this problem, virtual consoles would >be good so I don't want to miss out. Anybody guess what I am >doing wrong ? Yes, I'd like to know too if anyone else encountered this problem. I can think of a few things to try to get this running: - try NR_CONS set to 1 - try the following change in kernel/stmain.c line 248. current contents: ad -= 0x7d00L; /* size of VIDEO memory */ Instead of 0x7d00L there used to be 0x8000L. The docs say the screen memory used is 32000 bytes. Therefore I changed the 8000 into 7d00. This saves 768 bytes but puts the screen pointer on a 256 byte boundary, while 8000 puts the screen pointer on a 512 byte boundary. If the STe has different conventions with respect to its screen memory this change may cure it. For virtual consoles there is a similar change required in stvdu.c (around line 950) stvdu has been reworked greatly between 1.5.10 patch 1 and patch 2. I've tested this on my 1040, where it ran without problem. However, since I do not have an STe, it has not been tested on that hardware. Any suggestions/feedback/fixes are greatly appreciated. -- Frans Meulenbroeks (meulenbr@cst.philips.nl) Centre for Software Technology ( or try: ...!mcsun!phigate!prle!cst!meulenbr)