|
|
|
|
|
|
by iforgotpassword
1534 days ago
|
|
|
A few years ago I revived my xt clone. It was pretty much in the original state from the 80s, but since I got a nice isa 10mbit nic, I thought i should get this sucker online. But how to get the drivers on there? Copy via netw- oh wait. 5.25" floppy? Doesn't seem my laptop has a matching drive for that. I had a core2duo running as my home server which actually had a serial port, so win? Not so much, I had no success getting Linux to talk to the xt clone in any way. No idea if the port was bad, or the controller, or linux, or minicom/screen. So I dug out a Pentium 200 from the basement which had nt40 on it and visual basic 6. So I googled how to set up the serial port with it, wrote a simple sending tool, then googled some more to figure out how to write the receiving counterpart in gwbasic. At first the received file got corrupted since I didn't immediately grasp the whole flow control crap and just ignored it. But that lead to dropped data when the receive buffer filled up while the xt clone flushed the data to its massive 20mb drive. So I lowered the baud rate further and further until the clone could finally keep up. After transferring the driver plus htget sucessfully, I could finally download and upload everything else directly. All in all, that was a fun little exercise for a rainy Saturday, plus a few more weekends trying stuff out on the xt clone, like 8088mph which just hit the webs, and might have been what inspired me to go on this journey in the first place. |
|
|
1) The old XT clones used 8250 UARTs which had no internal FIFO buffer and triggered an interrupt each time received data became available (RDA). (That is, assuming your software used interrupt-driven queues vs. polling.) Either way, the maximum usable baud rate was determined by the inter-character timing vs. the system latency + ISR/polling timing. Assuming the 8250 is socket-ed, replacing it with a 16550 series UART would greatly improve your ability to operate at higher baud rates.
2) You mentioned flow control, but there are many variants of that in both hardware and software (such as ENQ/ACK, XON/XOFF, RTS/CTS). A common problem when dealing with serial ports is that hardware handshaking is enabled by default so the OS will not send/receive data without asserting CD/RTS/CTS/DTR/DSR to the proper levels. So you can either use a cable that correctly connects the hardware handshake signals at each end (assuming the OS on each end properly uses them), or disable hardware handshaking (via software).