The modem emulation is flagged for rewrite (as other serial port units). Try the nullmodem too, it has some special settings for BBS purposes and might perform better.

Found http://www.google.com/search?q=cache:home.arc … -9000/dbdl.html and tried it's recommendation of serial1 nullmodem server:vert.synchro.net usedtr:1 telnet:1. Is this what you were talking about? Because in deed, upon trying this approach, things appeared about 5x-6x faster than before. However, speeds were still visibly slower than 115200, so I reckon things like Zmodem transfers still wouldn't achieve their true potentials. Plus other drawbacks: can't drop DTR to hang-up on a BBS this way, no possibility of using AT commands to dial on-the-fly, etc., etc.

Did you have something better in mind when you mentioned nullmodem, or is this in deed "it" -- the very approach you were talking about?

Well, whatever the case, I appreciate the reply. (Also, considering whom it is I see I'm writing to here, I guess I'll use the opportunity to grovel and worship. Your, and the other contributors', coding kung fu is just flat out plain amazing. Even if I can't get speedy Procomm Plus sessions at the moment, DOSBox is simply a work of art. I'm truly, seriously impressed with this thing. Thank you for this contribution to the DOS world ... for making it possible for so much great old software to live again.)

Yes, the serial1=nullmodem is what I was talking about.
Have you tried without the 'telnet:1' ?

Here's what I tried (one at a time, in separate DOSBox sessions, in this order):

(1) serial1=nullmodem server:vert.synchro.net usedtr:1
(2) serial1=nullmodem server:vert.synchro.net usedtr:1 telnet:1
(3) serial1=nullmodem server:vert.synchro.net usedtr:1 telnet:1 rxdelay:0 txdelay:0

Downloading the same 750K file from the same BBS (vert.synchro.net) with the same protocol (Zmodem) with each method, speed varied hardly at all (12100 CPS, 12150 CPS, and 12120 CPS, respectively).

12100 to 12150 CPS * 8 = 96800 to 97200 bps = 18000 to 18400 bps short of 115200 bps. So, yeah, for regular interactivity it's way better, only subtly slower to the eye than full 115200. But file transfers don't reach their full potential, and over time those lost 18000 to 18400 bps compound.

The thing is: I don't know whether these 18000-184000 bps are being denied me by DOSBox, by Procomm Plus, or by the BBS. So for now I'm not going to call this even an issue. serial1=modem giving 4800-ish speeds is the issue for me. Because as far as I'm aware, "modem" is the only way to dial out with ATDx commands and make my old BBS software answer ("RING" result codes).

Thanks again for your help so far. If anything else comes to mind, from you or anyone else, I'm all ears.

P.S. One interesting note: with serial1=nullmodem, changing the DTR baud rate in Procomm Plus from 115200 down to slower ones (e.g. 300, 2400, whatever) did affect my connection speed with the BBS. So, nullmodem does obey terminal baud rates. It's only modem that ignores terminal baud rates and seems "fixed" at 2400-4800-ish baud.

(Apologies for the double-post. But:)

Something that just caught my eye (which should have caught it before):

From http://www.google.com/search?q=cache:home.arc … -9000/dbdl.html:

Serial port general: * Fix a bug in UART interrupt logic that caused several applications to stop serial traffic when data […]
Show full quote

Serial port general:

* Fix a bug in UART interrupt logic that caused several applications to stop serial traffic when data was transmitted and received simultaneously. This makes a lot of stuff work that acted up previously.
* Simplyfy the serial port code a lot by using CommandLine class. As a result parameters like listenport:123 must now be lowercase and there may not be a space before or after the : .
* Add the COMx file access. This makes Qbasic work with serial port and "echo text > com1" will work (limited, see TODO).
* Make the INT14 BIOS interface more like a real implementation.
* add serial port timing emulation: It is now important to set the same baudrate on both sides of a modem connection. When using low baud rates on a terminl you can watch the characters come in.
* better LOG output: There will only be one warning when the game tries to activate the FIFO (good for settlers mouse). Serial errors are reduced to one comprehensive message per second.
* read / write STDAUX (Int21) - used in the very old "Empire" game.

I would guess this might be a reference to what I'm experiencing. Problem is, while I can set the terminal baudrate on one "side" of the modem (to 115200 in Procomm Plus for instance), I don't know where to set the baud rate on the "other side" of the modem. In the .conf file with a switch I can't find documentation for? In the emulated modem itself with an AT command? Etc.

There's a flaw in your calculation: 115200 baud doesn't mean 115200 bits per second. The start- and stopbits also count in there, so with 1 startbit, 1 stopbit and no parity (total 10 bits) you get 11520 bytes per second maximum raw serial connection speed.

Bah! You're right. In that case, my nullmodem connections are perfectly fine.

Anyway, as far as the emulated modem itself: I did a test Zmodem transfer with it. Average speed was 957 CPS. That's 9600 baud territory (9600 / 10 = 960 CPS). (Guess time has made me forget how slow 2400-4800 really were; forget all past references to them, then, as it seems my real bottleneck is 9600.)

So, knowing 9600 lock-in was my issue, I did some more experimentation, trying (one at a time) core=normal, "serial1=modem startbps:115200" (just to see if it would have any effect), FreeDOS mode.com with "COM1: BAUD=115200" before starting Procomm Plus, and raising/lowering DOSBox cycles. None of these things affected my speeds (except lowering cycles to near-nothing, which did in deed slow it down further).

Looked through the source code, found two apparently relevant references to 9600:

* src/ints/bios.cpp = 9600, apparently(?), is as fast as int 14h ah=00 allows a serial port to be set.

* src/hardware/serialport/serialport.cpp = "initbps" is set to 9600, and several lines later in the same function(), there's an "if (initbps>0) baudresult = (115200 / initbps); else baudresult = 12", both of which (assuming initbps still = 9600 by the time this IF statement runs) result in baudresult being 12, a.k.a. 9600.

Unfortunately my knowledge the C++ language is pitiful, so I'm powerless to read the code in depth and find out if either of these are truly responsible for my bandwidth bottleneck. They just look like they might be. 😀

Since I think you wrote this, can you say whether either are responsible? I don't know enough to modify the bios.cpp stuff, but as far as serialport.cpp, I suppose I could try re-compiling so baudrate would always get set to 1 (for 115200) -- i.e. change "initbps = 9600" -> "initbps = 115200", and change "else baudrate = 12" -> "else baudrate = 1". But I don't know if I'd be wasting my time if I did this.

?? 😀

The problem is that the modem only checks for a new byte every millisecond. I don't remember right now but latest SVN might have a change there.

I am looking for 115200 baud speed too. This DosBox program is great and a fix for this would be the icing on the cake! Please help!

h-a-l-9000 wrote:

The modem emulation is flagged for rewrite (as other serial port units). Try the nullmodem too, it has some special settings for BBS purposes and might perform better.

Do you know approximately when the serial ports will be rewritten?
I'm having a rough time with a serial mouse in autocad 10. Very sluggish.

I have a post titled "Mouse sluggish in autcad 10 dos" in the dosbox games/apps forum that explains my mouse problems and attempted solutions.

So after mailing me often and moving to the forum, when I didn't answer within the hour, you are now spamming the forum ?

DOSBox is for games. Fixing autocad is low priority.

Qbix wrote:

So after mailing me often and moving to the forum, when I didn't answer within the hour, you are now spamming the forum ?

DOSBox is for games. Fixing autocad is low priority.

I'm not trying to spam. I just wondered when the serial port fixes might be coming out since you mentioned they are to be rewritten.

Why do you think this modem problem has something to do with directserial, and that the actual problem is in directserial?

h-a-l-9000 wrote:

Why do you think this modem problem has something to do with directserial, and that the actual problem is in directserial?

I never thought it had anythiong to do with a mouse except you mentioned that a rewrite was coming out for all the serial ports. Are you saying there won't be any improvements to the serial ports as far as direct serial or mice?