MIT provides MULTICS source and documentation (DPS-8 simulation)

It was thus said that the Great Roy J. Tellason once stated: Here's an example, using some old vintage home based computers. The Tandy Color Computer had a serial port, but at the hardware level, it was basically three one-bit ports, one bit for input, one bit for output, and one for carrier detect. The code to transfer a byte looked something like this (I don't have my notes handy at the moment): BSR XMITLOW LDA #byte-we-want-to-transfer LDB #8 * 8 bits LOOP RORA BCS LOOP1 BSR XMITLOW BRA LOOP2 LOOP1 BSR XMITHIGH LOOP2 DECB BNE LOOP BSR SETHIGH RTS XMITLOW PSHS A,X LDA #OUTPORTLOW STA SERIALOUT LDX BAUDPAUSE BSR PAUSE PULS A,X,PC XMITHIGH PSHS A,X LDA #OUTPORTHIGH STA SERIALOUT LDX BAUDPAUSE BSR PAUSE PULS A,X,PC PAUSE LEAX -1,X BNE PAUSE RTS Well, something close to that. Anyways, the upshot is that the CPU has to spend the time serializing all the bits, sending it out the port, and waiting around to make sure the timing is correct. That means that the Color Computer can't be doing anything else while sending (and receiving for that matter) data over the serial port. Add some intelligence (like the 8251 used in PCs (I think I got that right)) and sending now becomes something like: push ax push dx push si mov si,[xmitbuffer] lodsb mov [xmitbuffer],si mov dx,[serialport] out dx,al mov al,$20 out $20,al pop si pop dx pop ax rti Here, the hardware can interrupt the PC when it's ready to send the data, so all the PC has to do is give the UART the data, then signal the end of the interrupt. The UART can then spend the time doing other things, like oh, waiting for you to hit the keyboard. And it's easier to deal with; you just need to write the data to the UART, and it handles all the nasty details. You still might think this is a bit overkill, but it's nice to have. Very nice. The PCjr, unlike every other PC, had to have the CPU handle the serial stream from the keyboard (much like the Color Computer having to deal with the serial port above). Not much of an issue normally, but it did interfear with disk IO, since the CPU had to handle THAT as well. So you couldn't type while the disk was busy. And due to the lack of disk IO, that meant that downloads where a bit slower than on a PC (since the PCjr couldn't save the previous block of data as the next one was coming down). An even better example is the C-64. The disk drives on that are netoriously slow, but were computers in their own right, having a CPU as part of the drive electronics. One trick (assuming you have at least two disk drives) was to program the disk drives to copy a disk, thus leaving the C-64 free for something else, like playing Mule. -spc (Gah! I've forgotten the Return-From-Interrupt mnemonic for Intels ... )