I'm having problems with a game that seems to defy all attempts for me to get it to detect ANSI.
It actually wants to communicate through COM1:. I setup a virtual serial port connection with socat and two tty devices. It was giving me "lost carrier" when running but I worked with the dosemu2 author and now got past that issue.
The software appears to be sending ^[6n to get the cursor position and using that to determine if ANSI is present. Of course, since it's sending out the serial port, it isn't getting a response.
I'm not sure how I would go about telling sbbs that anything out of the serial port should to go the tcp/ip connection. I thought that Synchronet was supposed to deal with taking the com trafic and shuffling to the user's tcp/ip connection.
Am I misunderstanding? Can someone maybe shed some light on the issue? This is the first time I've had a door act in this manner.
The game is zwordz if anyone is interested...and already comes with a few challenges in itself.
Oh, there's a /FD options to make it use the fossil driver.
Right now, open to suggestions.
Most doors (especially those developed using a door development kit) read BBS drop files (e.g. door.sys) to determine the terminal type (e.g. ANSI or not). I'd certaily look/hope for such a option with this door.
I'm not sure how I would go about telling sbbs that anything out of the serial port should to go the tcp/ip connection. I thought that Synchronet was supposed to deal with taking the com trafic and shuffling to the user's tcp/ip connection.
Synchronet for Windows does include a virtual UART driver for that purpose (only for 16-bit DOS programs), but nothing like that for Synchornet for *nix.
Oh, there's a /FD options to make it use the fossil driver.
And when you use that option, it still writes to a UART?
dosemu does the interception of DOS program I/O in your case, so unless this is a native/32-bit door, that's where you'd need to look I suppose.
Re: How Synchronet interacts with DOSEMU?
By: Digital Man to nelgin on Wed Jul 24 2024 17:49:54
Most doors (especially those developed using a door development kit) read BBS drop files (e.g. door.sys) to determine the terminal type (e.g. ANSI or not). I'd certaily look/hope for such a option with this door.
It does support door.sys but where do I find the terminal type in it? Assuming this is an old game and only supports the original 31 lines?
I'm not sure how I would go about telling sbbs that anything out of the serial port should to go the tcp/ip connection. I thought that Synchronet was supposed to deal with taking the com trafic and shuffling to the user's tcp/ip connection.
Synchronet for Windows does include a virtual UART driver for that purpose (only for 16-bit DOS programs), but nothing like that for Synchornet for *nix.
Could there be something for Linux in SBBS to do this? I guess it would need some sort of virtual com driver in sbbs to take the com1 output and route it elsewhere?
Oh, there's a /FD options to make it use the fossil driver.
And when you use that option, it still writes to a UART?
Yes. It seems to.
dosemu does the interception of DOS program I/O in your case, so unless this is a native/32-bit door, that's where you'd need to look I suppose.
No, this is a 16 bit DOS program running on DOSEMU so ...I dunno.
Line 20 of door.sys = GR when the user's terminal supports color and ANSI "graphics" (CP437 characters).
Right, so in that case dosemu is the thing that would need to do any UART redirection to stdio (which SBBS then redirection to socket I/O).
I got it working, thank you again.
I got it working, thank you again.
Care to share how?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 410 |
Nodes: | 16 (3 / 13) |
Uptime: | 91:55:58 |
Calls: | 8,585 |
Calls today: | 9 |
Files: | 13,228 |
Messages: | 5,933,585 |