VOGONS

On the subject of modem emulation

Topic actions

First post, by ariqu

Posted on 
User metadata
Rank Newbie
Rank
Newbie

I've been toying around with WWIV 4.30 under DOSBox 0.72 recently in comparison to Synchronet BBS software for compatibility reasons. Mainly, door games, specifically Legend of the Red Dragon(LORD) and its In-Game-Modules (IGMs) are what have been annoying me. Some of these IGMs and doors are written in Turbo Pascal and have that well-known timing issue (Runtime error 200). Although there are fix programs for this, sometimes they just don't work.

I thought the combination of the environment DOSBox creates for DOS software to run and modem emulation would be the answer to my problems. Plus, I've always thought running authentic BBS software with all of the old file transfer protocol programs and doors at the speed they were probably operating at when they were at their peak would make the experience more enjoyable. However, snags are present.

I want to make it clear, I am not complaining. I'm using DOSBox for a purpose it was not originally intended for, nor currently is. I'm impressed and delighted that it does as much as it does. These are simply my findings and questions about some of the operations of the modem emulation system within DOSBox.

One thing I'm running into that Synchronet appears to have pacified is the modem's carrier detect (CD) status. WWIV uses FOSSIL, and from what I've read, it's supposed to operate via BIOS interrupt 14h. I realize DOSBox does not emulate a complete BIOS, nor do the programs run in it have transparent access to the host's BIOS, not that it would be useful in this case. I assume this is the reason the terminal output from DOSBox contains a warning, "BIOS INT14: Unhandled call AH=C0 DX= 14". Note: there are 2 spaces between '=' and '14'. Upon further testing, I found the AT command '&C0' would set the modem to have a positive CD status absolutely. However, in sending that command, I received another error,"Modem: Unhandled command: &C0".

C0 would appear to be causing the problem I'm experiencing with some door games reporting 'no carrier' when they are called by the BBS as well as some LORD IGMs, and why exiting any IGM results in being dropped back to the BBS instead of to LORD's IGM selector.

The other item I have yet to figure out is why Zmodem protocol downloads suffer from constant CRC errors. When using a native Windows terminal that has a built-in protocol (Mtelnet, Qmodem Pro) or a native DOS terminal (Telix, Procomm) in DOSBox using external protocols (CEXYZ, Ice-Zmodem), The programs report almost constant retries due to CRC mismatches and sync issues. I use the same protocol programs on the BBS as I do in the terminals, so there should be no amount of error due to program incompatibilities. DOSBox doesn't report any errors during this process in its terminal, so I have no idea what is causing this. X and Ymodem protocols do not suffer from this problem.

Other than these 2 issues, DOSBox is becoming more and more fit to be used to emulate an old PC for any purpose, not just games.

So, does anyone have any insight into these issues? Are my suspicions correct regarding C0? What may be causing my Zmodem dysfunction?

Thanks.

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

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

The modem doesn't support software handshake, maybe that's the problem with Zmodem?

Maybe the socket inheritance feature could help you? (see readme)

1+1=10

Reply 2 of 5, by ariqu

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Thanks for your quick response, h-a-l-9000. I wasn't aware that software handshaking was involved in the Zmodem protocol. I can't say I know much about the protocol to begin with. I also wasn't aware that the null-modem options applied to the modem. According to the readme, setting 'inhsocket:1' should take the number of the socket to be used from the command line, but does not specify how to label it. I've tried the 'transparent:1' option as well as 'usedtr:1' for testing purposes, but I see no change in behavior from before.

But the lack of software handshaking would be the cause? My modem settings are currently set for hardware handshaking. Does that work?

Reply 3 of 5, by h-a-l-9000

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

Hardware handshake works more or less...

The inhsocket and others do not apply to the modem settings. Might it be possible to use a nullmodem connecion instead and choose "already connected" in the game?

1+1=10

Reply 4 of 5, by ariqu

Posted on 
User metadata
Rank Newbie
Rank
Newbie

It's a door game. It's only intended to be executed by a BBS with a modem connection. Most are hardcoded to look for the COM port status the BBS reports it's using. Null-modem connections were never used for BBS's and this BBS in particular only has settings to pass AT commands to a modem to initialize and accept incoming connections.

I can see how I could use the null-modem connection to run the door game by itself, however, my issue is that I can't get these to work using the modem emulation the BBS requires to work.

I do not intend this question to be condescending, but to ask a fact: Have you ever been on a BBS? Or set one up? Would you be interested in connecting to mine to see how it acts? Or perhaps a copy of the software to have a look at it yourself?

My thanks for your attention, h-a-l-9000.

Reply 5 of 5, by h-a-l-9000

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

I've had some fun with it already while implementing the nullmodem socket inheritance stuff - this was for Windows Synchronet though. The game "Yankee Trader" worked this way. A (little outdated - official DOSBox now has socket inheritance too) manual is here:
http://dosbox.bbsdev.net/
and on my homepage there is some more nullmodem documentation (dosbox.exe -socket <number>).

The modem could use some more programming work, but well...

1+1=10

Go to top of page Go to top of page
Back to DOSBox Games/Apps
Close window
Close window