awb@aipna.ed.ac.uk (Alan W Black) (09/04/90)
[ I've just noticed our machine lost news yesterday so maybe this is
already noted -- awb ]
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).
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).
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).
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.
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 :-)
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 ?
thanks
Alan
Alan W Black 80 South Bridge, Edinburgh, UK
Dept of Artificial Intelligence tel: (+44) -31 225 7774 x228 or x223
University of Edinburgh email: awb@ed.ac.ukmeulenbr@cst.philips.nl (Frans Meulenbroeks) (09/05/90)
[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)
archer%segin4.segin.fr@relay.prime.com (Vincent Archer) (09/06/90)
Frans Meulenbroeks <meulenbr@cst.philips.nl> said: (after some explanations on the awful /etc/ttys file) >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) Now, the STe really has different hardware: Its screen base is not constrained by a boundary anymore!!! You still need to use a word-aligned screen base; it's 68000 world we're talking about. But there's an additional screen controller byte (can't remember the exact address, it's somewhere in my notes) to specify the low bytes of screen base. >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. If I get my hands on a STe (there's one at my local computer club), I'll try a STf-working kernel on it. Vincent Vincent Archer | Email:archer%segin4.segin.fr@relay.prime.com "Wrong thing to say, right thing to do; do as I say, not as I do..."
AJB%DLVH.DARESBURY.AC.UK@pucc.princeton.edu (09/07/90)
Vincent Archer is right that on the STE the screen does not have to be aligned on a 256 byte even boundary. I remember mailing this bulletin board about this before. It must be on a word boundary. The relevant addresses are ST ffff8201 & ffff8203 (no lsb because of the boundary limitation) STE ffff8201 & ffff8203 & ffff820D (the last address holds the lsb) Alan Bleasby AJB@UK.AC.DARESBURY.DLVH