• Please review our updated Terms and Rules here

8250 serial port speeds on XT, AT

Twospruces said:
I am imagining a buffer circuit to sit between the 8250 and the bus to manage this
Click to expand...

I'm not sure how that would add up; you would need a state machine sophisticated enough to actually do the fetch against the 8250's receive buffer, store it in a FIFO or ring buffer, and then somehow get the CPU up to speed after it's going through however many cycles that are in play without breaking software compatibility. (It'd have to generate a bunch of synthetic interrupts for each character in the FIFO?)

If the chip is socketed in the machine you could try replacing it with a 16550D, they're "pretty much" pin compatible; that will give you a 16 character deep FIFO. Downside is that the software you're using has to enable it, it's not "transparent".

It would be interesting to know *why* this machine might possibly need to generate an NMI to update the screen. I found a copy of the schematics online, but it's low res enough that I wasn't able to make out a lot of the labeling, especially on the keyboard controller sheet. The video hardware itself doesn't seem to point to any reason for needing an NMI, it looks like it's just a pair of 8K SRAMs for video RAM and otherwise mostly a slightly weird CGA implementation.
 
There was at least one multi-port comms card with buffers for each port, but for the life of me, I don't recall the details. In theory, you wouldn't need much more than a FIFO.
But that would be stupid for a modern design. There are plenty of chips with built-in FIFOs, say, a 28L201A.
 
Last edited:
I think it can work pretty easily.

Yes you'd need a circular 8 byte buffer.
Yes you'd need a state machine.

Fill the buffer when 8250 says a byte is ready.

Signal the host when there is a byte in the buffer.

Eudimorphodon said:
I'm not sure how that would add up; you would need a state machine sophisticated enough to actually do the fetch against the 8250's receive buffer, store it in a FIFO or ring buffer, and then somehow get the CPU up to speed after it's going through however many cycles that are in play without breaking software compatibility. (It'd have to generate a bunch of synthetic interrupts for each character in the FIFO?)

If the chip is socketed in the machine you could try replacing it with a 16550D, they're "pretty much" pin compatible; that will give you a 16 character deep FIFO. Downside is that the software you're using has to enable it, it's not "transparent".

It would be interesting to know *why* this machine might possibly need to generate an NMI to update the screen. I found a copy of the schematics online, but it's low res enough that I wasn't able to make out a lot of the labeling, especially on the keyboard controller sheet. The video hardware itself doesn't seem to point to any reason for needing an NMI, it looks like it's just a pair of 8K SRAMs for video RAM and otherwise mostly a slightly weird CGA implementation.
Click to expand...
 
Twospruces said:
I think it can work pretty easily.

Yes you'd need a circular 8 byte buffer.
Yes you'd need a state machine.

Fill the buffer when 8250 says a byte is ready.

Signal the host when there is a byte in the buffer.
Click to expand...

I'm sure it's possible, but, handwaving aside about how "hard" it'll be... will it even solve anything? If this time-consuming NMI happens regularly when ingesting serial traffic and the overhead from said NMI reliably disrupts communications at speeds over "X", won't adding all these moving parts just create an interrupt-handling death spiral anyway?

The 16550 when it's in FIFO mode allows you to set a threshold for how full/empty the receive/transmit buffers are allowed to get before they fire an interrupt; this feature is specifically designed to allow you to lower the interrupt load on the host machine. (Possible settings range from an interrupt on every byte to every 4, 8, or 14 bytes.) I could see how having this sort of thing available to you might possibly be of some use but, again, it does rely to some degree on the software you're using to understand it to really leverage it.

(That said, it *may* be possible to enable FIFO mode with the interrupt threshold set to "one" and gain some benefit from otherwise ignorant software because the FIFO will still catch additional characters if there's a latency issue? Not an expert on that, but I may have a vague false memory of some kind of shareware "FIFO-enabler" existing for it?)
 
I think there is time to catch up. The NMI creates a short delay at 13 msec in this application. Maybe there is a case where NMI can happen even faster though. In which case you might still overrun. So no absolute solution.

At least for use with Laplink I think even 115kbaud will work... because I think the time to service the actual serial interrupt is pretty short.
 
If the theory is that the NMI is triggered by screen updates, then what happens if you use a terminal program to just receive a file into a memory or disk buffer? Is Laplink spamming the screen with a progress bar or something?

Ultimately this seems like a broader problem/slash/fundamental design limitation of the machine. Is there any documentation that sheds light on what this NMI is for? Does, for instance, the machine lack a 6545 CRTC and it’s using the NMI to intercept, say, updates to the cursor position register?
 
The CTTY COM1 experiment confirms that no NMI is triggered when sending display characters to the serial port.

If only I had a 2nd serial port on the Z171 so I could run console as COM1 and Laplink as COM2.
 
OK, so! I monkeyed around with the hardware to prove I could transfer at 115600 baud. I've confirmed that it is truly the NMI that is hosing things.
Here's what I did:

Boot up mods:
* I changed autoexec to (1) not need any keyboard inputs to complete boot up and (2) boot directly into laplink.

Hardware mods:
* at the NMI source on the 80C39 controller, I pulled pin 36 from the socket.
* at the CPU, I jumpered the NMI input to ground

This hardware change has the effect of disabling the keyboard. But, I have a "keyboardless" boot up.

Now, when I boot the Z-171, I have lapdos running but no NMI and no keyboard. Now, I can connect remotely and transfer files back and forth at whatever speed - no errors.

So, ... I think the only practical fix here is to create a buffer circuit, or figure out if I can swap and 8250 for a 16550 in buffer mode.

If I had a 2nd serial port, I could have used CTTY COM2 to redirect the console, but alas. No other way I could think of to use CTTY.
 
I really don't know what the NMI function is.

I think it might be possible to write a little program to enable the fifo mode.

- laplink allows one to exit to dos
- first set up the com port for use
- then exit to dos and run a program that sets the rx fifo on.
- back into laplink and carry on...not changing the serial port...
 
Do you have a parallel port? Maybe you could use that for the file transfer instead and then the serial port could be used for the console.
 
Yes of course 115200.
Could it be possible that Laplink already attempts to configure the 16550 registers?
I assume here that there are not machine specific BIOS calls that are used by applications to set up the serial port.
the 16550 was introduced in 1987 - similar time frame.
 
It's been suggested a couple of times here to use parallel.
Laplink II did not support parallel, but Laplink 3 (which you can find at Minuszerodegrees) does support parallel.
Turns out both of my old machines work just fine with parallel.

BUT - DOSBOX does not support parallel ports!

I have a feeling that Laplink 3 will recognize a 16550 and configure it correctly. I ordered a 16c550 and will see if that "just drops in and works" with either flavor of Laplink.
 
I guess the question is what are you doing with the character you are looking at. If you display them one at a time in windows, I'm not surprised that it is not keeping up.
Dwight
 
Twospruces said:
It's been suggested a couple of times here to use parallel.
Laplink II did not support parallel, but Laplink 3 (which you can find at Minuszerodegrees) does support parallel.
Turns out both of my old machines work just fine with parallel.

BUT - DOSBOX does not support parallel ports!

I have a feeling that Laplink 3 will recognize a 16550 and configure it correctly. I ordered a 16c550 and will see if that "just drops in and works" with either flavor of Laplink.
Click to expand...
Just to complete this thread, yes Laplink did set up the 16550 correctly on the Z-171. So a 16C550 chip is a nice simple upgrade to boost speeds. I have found 57600 baud works reliably.
 
You must log in or register to reply here.
Back
Top