... I think I know at least part of the whys and hows.

Apparently, a lot of processing is spent for displaying. I know the "displays after disconnect" syndrome (and, as told above, ) I understand this might get worse by the size of window and maybe other things - I tried to put it here under stress by setting the font to a proportional font of big size, which resulted in lot of scrolling, and things got worse. I could imagine that this also depends on the particular graphics adapter of the PC, the driver for the same, and a zillion of other stuff, all adding its small influence.

That I was not able to achieve dropped characters at 1200 can be attributed to the fact that I tried only one laptop without a real COM port, and the driver of the FTDI chip I am using may have (and most probably has) several orders of magnitude bigger buffer(s) than what's used for the standard "real" 16Cx50 - which is what I guess at your place.

I'd say that a terminal program capable of flawless logging at any rate shall be written with this particular requirement in mind, and give this task a paramount priority even at the cost of garbled display. As I said above, the only terminal emulator I know which seems to perform satisfactorily in this respect, is realterm (and at least one DOS terminal emulator, but that's an another story). Oh yes, the point is very simple: the display is off during logging (you CAN enable simultaneous display using a tickbox, but you are warned not to do so... :-) )

I know it sounds weird, in today's times of gigabit ethernet, to have troubles with 1200 bits per seconds...

JW