ast@cs.vu.nl (Andy Tanenbaum) (07/10/88)
This is an historic moment indeed. This message is being typed on a Z-248 running MINIX attached to a 1200 baud modem connected to a remote SUN 3/60 over a dialup line. In short, the long awaited RS232 driver seems to be working flawlessly at 1200 baud. I have done 'cat file' and it seems to be able to transmit/receive at 1200 baud without losing any characters at all. I don't know whether it works at 2400/4800/9600 because I don't have any modems for those speeds. However, I can promise that it won't work at 19200 (because the 8250 UART used in the PC stops at 9600). Terrence Holm and Edwin Froese recently posted a message starting the discussion of 1.4. To summarize my feelings on this briefly, since the distribution of 1.3 is almost done, I am not about to delay it at this point. However, if we collectively can generate a substantial fraction of the library routines and utilities for POSIX, I am willing to migrate in that direction. I am less enthusiastic about changing the kernel, now that it actually works reliably, but relatively small changes (measured by the number of lines of code added or deleted) are negotiable. I am so happy that this blanketey-blank RS232 driver finally works, that I'm going to go have a drink (apricot juice). I'll repost tty.c as well as the changed login, init, who, stty, and a terminal simulator I just wrote as soon as I have tested them some more. As a final note, if you set /etc/ttys right, you can get a slave terminal running on RS232 port 1 at 9600 baud, and that works fine as terminal. Whether it could do file transfers at that speed as another matter. I have tested MINIX with the console plus the second terminal, and it seems to work fine. Andy Tanenbaum (ast@cs.vu.nl)
ddl@husc6.harvard.edu (Dan Lanciani) (07/12/88)
In article <841@ast.cs.vu.nl|, ast@cs.vu.nl (Andy Tanenbaum) writes: | | This is an historic moment indeed. This message is being typed on a Z-248 | running MINIX attached to a 1200 baud modem connected to a remote SUN 3/60 | over a dialup line. In short, the long awaited RS232 driver seems to be | working flawlessly at 1200 baud. I have done 'cat file' and it seems to be | able to transmit/receive at 1200 baud without losing any characters at all. | I don't know whether it works at 2400/4800/9600 because I don't have any | modems for those speeds. However, I can promise that it won't work at 19200 | (because the 8250 UART used in the PC stops at 9600). Actually, the 8250 in the PC works fine at 19200 and all that I have tried also work at 38400, so you should allow these baud rates. (Some machines might even have fast enough CPUs to use them...) Dan Lanciani ddl@harvard.*
charles@hpcvca.HP.COM (Charles Brown) (07/13/88)
> Actually, the 8250 in the PC works fine at 19200 and all that I > have tried also work at 38400, so you should allow these baud rates. > Dan Lanciani The 8250 had better work at 38400. It was designed to run faster than that. I don't remember the top end. That was 11 years ago when I worked for National Semicompactor :-). Yes folks! The 8250 was originally designed at National, not Int*l. Charles Brown
ast@cs.vu.nl (Andy Tanenbaum) (07/13/88)
In article <4926@husc6.harvard.edu> ddl@husc6.harvard.edu (Dan Lanciani) writes: > Actually, the 8250 in the PC works fine at 19200 ... If Dan has tested it, I believe him. Nevertheless, let us all get out our IBM PC-XT Technical Reference Manuals and read together starting in the middle of page 1-200 where it says: \fBNote:\fR The maximum operating frequency of the baud generator is 3.1 MHz. In no case should the data rate be greater than 9600 baud. It may be that the chip actually works at higher speeds, but this is outside the specification, at the very least. When I was in college I worked at IBM in the summer as a programmer to earn money for my college expenses. At that time I sometimes programmed the IBM 1401, many of whose instructions had the format: Opcode address1 address2. Some of them only had one address, but curious fellow that I was, I tried the two address forms, and they all seemed to do something predictable, and in many cases useful (typically a branch to the second address). I thought it was real neat to fill my programs with undocumented instructions (which may have been model dependent) because it saved a couple of bytes here and there. Nowadays I prefer to stay within the official spec. Andy Tanenbaum (ast@cs.vu.nl)
plipp@tugiig (Lipp Peter) (07/13/88)
In article <841@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > > This is an historic moment indeed. This message is being typed on a Z-248 > running MINIX attached to a 1200 baud modem connected to a remote SUN 3/60 > over a dialup line. In short, the long awaited RS232 driver seems to be > working flawlessly at 1200 baud. I have done 'cat file' and it seems to be > able to transmit/receive at 1200 baud without losing any characters at all. > I don't know whether it works at 2400/4800/9600 because I don't have any > modems for those speeds. However, I can promise that it won't work at 19200 > (because the 8250 UART used in the PC stops at 9600). Not true: its possible to set the speed to more than 100000 baud. 19200 can easily be used - without problems. Peter Lipp - plipp@tugiig.uucp
bruce@hpihoah.HP.COM (Bruce LaVigne) (07/14/88)
> It may be that the chip actually works at higher speeds, but this is outside > the specification, at the very least. It has been a while since I worked on that chip, but I did some stuff for a terminal emulator company back in the XT days. As I remember, the bytes you actually stuff into the chip are divisors of an externally input clock. With the clock that IBM used, if you go above 9600 you start using non-integer divisors. What this means is that since you can really only use integer numbers into the chip as a divisor, you don't get 19200 but something kindof close. If the other side can handle it, fine, but IBM doesn't support it. -bruce Bruce LaVigne ARPA: bruce%hpda@hplabs.hp.com UUCP: {ucbvax,hplabs}!hpda!bruce USnail: c/o Hewlett-Packard m/s 42L8 19447 Pruneridge Avenue Cupertino, CA 95014 Phone: (408)447-6279 work
Dickson@his-phoenix-multics.arpa (Paul Dickson) (07/14/88)
>From Andy Tanenbaum (ast@cs.vu.nl): >...you can get a slave terminal running on RS232 port 1 at 9600 baud, >and that works fine as terminal. Whether it could do file transfers at >that speed as another matter. I have tested MINIX with the console plus >the second terminal, and it seems to work fine. How well did you test your tty.c with the second terminal? I ask because when we were following the design outlined in the original tty.c, we discovered a fairly serious problem. If more than one process does output on a serial port, those processes will hang. It's possible that you totally rewrote the serial part of tty.c to get around this problem, but we haven't seen your code yet. The screen console has the same problem, but it's fortunate to be able to complete output before returning. The problem is that only the last process to do output to the port will be given the wakeup when output in complete. This means that if more than one process does output, all but one will never be re-awakened. We have an idea on how to get around the problem. We'll try it this weekend if time permits. The answer seems to be in buffer management. -Paul Dickson Arpanet: Dickson%pco @ BCO-Multics.ARPA
plipp@tugiig (Lipp Peter) (07/15/88)
In article <845@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > If Dan has tested it, I believe him. Nevertheless, let us all get out our > IBM PC-XT Technical Reference Manuals and read together starting in the > middle of page 1-200 where it says: > > \fBNote:\fR The maximum operating frequency of the baud generator is 3.1 MHz. > In no case should the data rate be greater than 9600 baud. > Right, but lets look at the motivation behind these sentences (at least what I think the motivation might be): a) maximum frequency: default frequency is 1.8432 MHz - and I guess all machines stick to this. If two machines communicate using different frequencies, errors with high speeds are possible. b) 9600 baud: This limitation might be because of the quite slow IBM-PC, which might get into trobles at dealing with interrupts if higher speeds are used. I just tested sending data between PC`s at a rate of 115200 bps, without troubles. They were 10 Mhz- ATs and communication done without interrupts. I have not tested interrupt-driven I/O at this speed. This is not in contrary to the Technical Reference, which says (poor translation, because I have a poor german translation only): The INS8250 contains a programmable baudgenerator ..... and the division by a divisor between 1 and (2 to the power of 16)-1. A divisor of 1 meens 115200 baud (at 1.8432 MHz). I would say: 9600 is a recommendation, not a barrier Peter Lipp (plipp@tugiig.uucp)
TROTH%TAMCBA.bitnet@jade.berkeley.edu (Rick Troth) (07/15/88)
The 8250 does not stop at 9600 baud; the ROM BIOS (or disk-based
BIOS one of the two) stops at 9600 baud. You cannot do an MS-DOS
A> MODE COM1:19200,n,8,1 .
The 8250 has a divisor word, which is set to 000C (twelve) when
you set MODE COMx:9600,etc. If you set that divisor to 1 then you
would be running at 115200 baud, and your 8088 would probably not process
the interrupts fast enough to keep up.
- Rickhwfe@ur-tut (Harlan Feinstein) (07/18/88)
In article <5870002@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >The 8250 had better work at 38400. It was designed to run faster than >that. I don't remember the top end. That was 11 years ago when I >worked for National Semicompactor :-). Yes folks! The 8250 was >originally designed at National, not Int*l. > Charles Brown I have a terminal program for the PC that supports communication at 115,200 baud. I think that's the top end... in all honesty, I've not tried it, simply because I don't have a null-modem adapter. --Harlan hwfe@tut.cc.rochester.edu
ast@cs.vu.nl (Andy Tanenbaum) (07/18/88)
In article <3295@louie.udel.EDU> Dickson@his-phoenix-multics.arpa (Paul Dickson) writes: >How well did you test your tty.c with the second terminal? If you mean "how well did you test MINIX with the console and a terminal attached to port 1?" the answer is: fairly thoroughly. If you mean "how well did you test MINIX with the console and a terminal attached to port 2?" the answer is: enough to see that it addressed the correct I/O ports and basically worked, but not very thoroughly. I have since posted the new tty.c, so try it. If there are problems, please post them rather than mailing them to me, since probably lots of people are interested in RS232. Andy Tanenbaum (ast@cs.vu.nl)
sme@computing-maths.cardiff.ac.uk (Simon Elliott) (07/20/88)
In article <4200004@hpihoah.HP.COM>, bruce@hpihoah.HP.COM (Bruce LaVigne) writes: > > It may be that the chip actually works at higher speeds, but this is outside > > the specification, at the very least. > > As I remember, the bytes you > actually stuff into the chip are divisors of an externally input clock. With > the clock that IBM used, if you go above 9600 you start using non-integer > divisors. What this means is that since you can really only use integer > numbers into the chip as a divisor, you don't get 19200 but something kindof > close. If the other side can handle it, fine, but IBM doesn't support it. > I seem to remember that the baud rate divisor on the PC for 9600 is something like 0x0C; you can go right down to 1 if you want, giving 115200 baud. The Brooklyn Bridge and LapLink programs do just that. There are two problems here, though: 1) can your (worst case) 4.77 MHz PC handle data at that rate? At that speed, interrupt latency is VERY significant; to get anything sensible, you have to poll. Doing handshaken 128 byte block transfers is OK, but in the context of Minix's tty driver, not acceptable :-) ! 2) the low divisor has an adverse affect on the UART's bit sample timing, leading to framing errors. If you want to go at that speed, be prepared to checksum/re-send blocks. I have used PC to PC speeds of 19200 baud (divisor 0x06 ?) without problems. Even 38400 baud (divisor 0x03 ? - looks right, gives 115200 = 0x01) works OK if it's not too far. It all depends on how much work you're doing with the byte once you've got it. -- -------------------------------------------------------------------- Simon Elliott, UCC Computer Centre, 40/41 Park Place, Cardiff, Wales ...!mcvax!ukc!cf-cm!sme sme@v1.cm.cf.ac.uk
plipp@tugiig (Lipp Peter) (07/21/88)
In article <4200004@hpihoah.HP.COM>, bruce@hpihoah.HP.COM (Bruce LaVigne) writes: > divisors. What this means is that since you can really only use integer > numbers into the chip as a divisor, you don't get 19200 but something kindof > close. If the other side can handle it, fine, but IBM doesn't support it. Just what I meant. The 'kindof close' depends on the input-clock to the 8250. As all PC-compatibles will use it, no problem will occur because the 'kindof close' will be the same everywhere. If some fancy machine which claims to be compatible uses a different clock rate, it might not be able to communicate with others, and, more important, many programs won`t work as soon as they program the chip directly (setting the divisor with the same value won`t achieve the same results). In practice, I want to bet the only problem is to handle the high data rate without protocol or delays. Peter Lipp (plipp@tugiig.uucp)