VOGONS

Common searches


First post, by pishposh

User metadata
Rank Newbie
Rank
Newbie

This one has me beat.

I recently thought I'd give Procomm Plus 2.01 a try under DOSBox. It's a terminal emulator from ~1990 for serial modems.

Dug up my old U.S. Robotics 56K Sportster external modem, connected it to COM1 on my PC, and set that port in Windows' Device Manager for 115200/N81/hardware flow control. Then started Procomm Plus under DOSBox, configured it for COM1 (serial1=directserial realport:COM1 was in my DOSBox config file BTW), set its terminal baud rate to 115200/N81/hardware flow control, and ... INSTANT GRATIFICATION! 😀 I could talk to my modem via its AT command set just fine.

First thing I did was check how quickly Procomm Plus was able to communicate with the modem. My particular modem model has an proprietary AT command that causes the modem to spew a full list of all the other AT commands it supports -- a rather long list, about 50 lines or so worth. So, I used that command just to visually gauge about how quickly Procomm Plus was able to receive data from my true hardware modem with DOSBox as middleman. Result? Only word I can use to describe what I saw would be: "BAM!" Or put another way, DOXBox was not slowing Procomm Plus down much if at all -- looked like I was getting a full 115200 bps between Procomm Plus and the modem itself. The entire output of the modem's long help screen finished displaying damned near instantaneously. Just for fun, I then changed Procomm Plus' terminal baud rate to 300 baud, and repeated the same command. Result? Excruciating slowness! Just like in the bad old days of real 300 baud modems. The thing was truly running at 300 baud. 😀 So, right back to 115200 I went.

Next test was finding a BBS that still had a dial-in number. I managed to connect just fine at 52000 bps, and the on-screen text display speed looked exactly correct for what I remembered of those speeds in the BBS'ing days.

Anyway: That's where my fast speeds stopped, however.

The next thing I tried was switching DOSBox to its internal modem emulator (serial1=directserial realport:COM1 -> serial1=modem). Unfortunately, as soon as I did that, everything became slooooow. Absolutely every server I connected to ... whether a telnet BBS (e.g. "ATDT vert.synchro.net:23"), or my usenet server ("ATDT cnews.newsguy.com:119"), seemed be running at a speed reminiscent of 2400 or maybe 4800 baud. (I could literally watch the cursor move across the screen as each line of text came through.) Sure enough, the DOSBox console window was indicating "CONNECT 57600", and Procomm Plus' terminal baud rate was still set at 115200. Yet somehow, it was as if the "terminal baud rate" for DOSBox's emulated modem wasn't any faster than 2400-4800.

Stranger still, when I changed Procomm Plus' terminal baud rate to 300 just to see what happen, it DID NOT slow anything down -- same exact 2400-4800 baud apparent (to the eye) speed.

Bottom line: I suspect DOSBox has some obscure setting, somewhere, that controls the DTR baud rate of its internal modem -- perhaps set at a default in the range of 2400-4800 so older games can cope with the speed of incoming data? Perhaps this default rate is even configurable with one of the emulated modem's AT commands. I dunno. Problem is, no matter how much documentation I read, I cannot find any such setting. 🙁

Background information:

* This is a brand new DOSBox installation (for this computer). Nothing was changed in the configuration file except the serial1= line (as indicated above), and also, under [CPU], I set cputype=pentium_slow.
* Motherboard = Dell OEM (2003 "Precision M60" laptop)
* Processor type and speed = Intel 2.0 GHz single core
* Amount and type of RAM = 2 GB (no other programs running, no disk swap activity at the time I was using DOSBox)
* Video board w/ RAM amount and type = NVIDIA QuatroFX Go1000
* Sound board = (irrelevant?)
* Operating system = XP SP2
* Reproducibility of problem = always
* I am on 3.0/768 DSL, and its pipe was/is wide open and not saturated

Attached is a video I made with CamStudio (MSVIDEO codec, but plays fine in VLC) illustrating the problem. This video demonstrates three things (in this order):
* Me starting Procomm Plus and connecting to a telnet BBS. Notice the 2400/4800 baud like speed. Gah!
* Me disconnecting from the BBS and connecting to my ISP's SMTP server. Here, I type EHLO a few times in a row (because it spits out a medium-sized chunk of text in response). Reason: just to demonstrate that the same slowness occurs with a totally different server. (Note: the SMTP server seems faster, but only because it's not bogged down by ANSI color codes. If you look carefully though, you'll see that the screen output speed is still regrettably slow -- nowhere near what 115200 looks like (the maximum terminal rate Procomm Plus just happens to be capable of and which I lust after! 😉)
* Finally, I set DOSBox aside and start a generic Windows telnet client and connect it to that same SMTP server, and again run the EHLO command a few times in a row. This, I just did for A/B comparison purposes. As can be seen, in my Windows telnet client, the SMTP server's responses to EHLO are instantaneous, unlike when I saw them via DOSBox's emulator modem.

So. Yup. Something about DOSBox's emulated modem is throttling me.

Help? Please? 🤣

Attachments

  • Filename
    dosbox_video.rar
    File size
    231.09 KiB
    Downloads
    422 downloads
    File license
    Fair use/fair dealing exception

Reply 1 of 14, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

1+1=10

Reply 2 of 14, by pishposh

User metadata
Rank Newbie
Rank
Newbie

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.)

Reply 4 of 14, by pishposh

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 5 of 14, by pishposh

User metadata
Rank Newbie
Rank
Newbie

(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.

Reply 6 of 14, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

1+1=10

Reply 7 of 14, by pishposh

User metadata
Rank Newbie
Rank
Newbie

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.

?? 😀

Reply 10 of 14, by garrynichol

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 11 of 14, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Water flows down the stream
How to ask questions the smart way!

Reply 12 of 14, by garrynichol

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 14 of 14, by garrynichol

User metadata
Rank Newbie
Rank
Newbie
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?