New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACIA DTR state isn't passed to COM port. #386

Closed
geneb opened this Issue Feb 26, 2017 · 23 comments

Comments

Projects
None yet
2 participants
@geneb

geneb commented Feb 26, 2017

I'm working on a how-to on connecting vintage bbs programs to the internet. Part of the writeup is on emulated hardware.
For my example I'm using GBBS Pro.

As far as I can tell, the emulated ACIA in AppleWin is not propagating the DTR high/low state to the selected COM port. I discovered this when trying to identify why when a caller logged out, the telnet connection in tcpser wasn't dropped. After logging the bbs start/user login/user logout process via tcpser, I found that the real hardware was properly toggling the DTR state and the emulator was not.
I'd be happy to work with any of the devs to get this resolved. Thanks!

g.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 4, 2017

Contributor

Here's the AppleWin code to handle writes to the SSC's command register for DTR:

	if (m_uCommandByte	& 0x01)	// Data Terminal Ready (DTR) setting [0=set DTR high (indicates 'not ready')]
	{
		// Note that, although the DTR is generally not used in the SSC (it may actually not
		// be connected!), it must be set to 'low' in order for the 6551 to function correctly.
	}

So basically it's currently ignored by AppleWin.

And those AppleWin comments are identical to these from Aaron Heiss:
http://www.applefritter.com/content/ssc-commands [from 2016]
http://www.verycomputer.com/20_6ab6a6686aa7b3ba_1.htm [from 2001!}

NB. I have no idea how accurate they are.

In UpdateCommState(), the DCB structure is zeroed and then a subset of the struct's members are set up.

DCB contains this member

    DWORD fDtrControl:2;  /* DTR Flow control                */

But it never gets changed from the initial zeroed state. And from WinBase.h, the 0 value is defined as:

#define DTR_CONTROL_DISABLE    0x00

I found that the real hardware was properly toggling the DTR state and the emulator was not.

The values for DCB.fDtrControl are: (WinBase.h)

//
// DTR Control Flow Values.
//
#define DTR_CONTROL_DISABLE    0x00
#define DTR_CONTROL_ENABLE     0x01
#define DTR_CONTROL_HANDSHAKE  0x02

Do you know how these map to the SSC's DTR bit?

Contributor

tomcw commented Mar 4, 2017

Here's the AppleWin code to handle writes to the SSC's command register for DTR:

	if (m_uCommandByte	& 0x01)	// Data Terminal Ready (DTR) setting [0=set DTR high (indicates 'not ready')]
	{
		// Note that, although the DTR is generally not used in the SSC (it may actually not
		// be connected!), it must be set to 'low' in order for the 6551 to function correctly.
	}

So basically it's currently ignored by AppleWin.

And those AppleWin comments are identical to these from Aaron Heiss:
http://www.applefritter.com/content/ssc-commands [from 2016]
http://www.verycomputer.com/20_6ab6a6686aa7b3ba_1.htm [from 2001!}

NB. I have no idea how accurate they are.

In UpdateCommState(), the DCB structure is zeroed and then a subset of the struct's members are set up.

DCB contains this member

    DWORD fDtrControl:2;  /* DTR Flow control                */

But it never gets changed from the initial zeroed state. And from WinBase.h, the 0 value is defined as:

#define DTR_CONTROL_DISABLE    0x00

I found that the real hardware was properly toggling the DTR state and the emulator was not.

The values for DCB.fDtrControl are: (WinBase.h)

//
// DTR Control Flow Values.
//
#define DTR_CONTROL_DISABLE    0x00
#define DTR_CONTROL_ENABLE     0x01
#define DTR_CONTROL_HANDSHAKE  0x02

Do you know how these map to the SSC's DTR bit?

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 4, 2017

Contributor

NB. I've reconstructed the doc "Key Super Serial Card (SSC) Memory Locations for Programmers" (Aaron Heiss) from what I could find remaining on the internet.
Added at adfb48c into the AppleWin\docs folder.

Contributor

tomcw commented Mar 4, 2017

NB. I've reconstructed the doc "Key Super Serial Card (SSC) Memory Locations for Programmers" (Aaron Heiss) from what I could find remaining on the internet.
Added at adfb48c into the AppleWin\docs folder.

@geneb

This comment has been minimized.

Show comment
Hide comment
@geneb

geneb Mar 4, 2017

On real hardware connected to tcpser via a null modem cable, GBBS Pro properly toggles the DTR line to disconnect the session.

On AppleWin connected to tcpser via the same null modem cable, GBBS Pro has no effect on the DTR line, thus the session is never disconnected.

Please fix AppleWin so that it passes the DTR state to the underlying hardware.

Tnx.

g.

geneb commented Mar 4, 2017

On real hardware connected to tcpser via a null modem cable, GBBS Pro properly toggles the DTR line to disconnect the session.

On AppleWin connected to tcpser via the same null modem cable, GBBS Pro has no effect on the DTR line, thus the session is never disconnected.

Please fix AppleWin so that it passes the DTR state to the underlying hardware.

Tnx.

g.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 5, 2017

Contributor

TCPSER by Jim Brain

TCPSER is a utility that turns a PC/workstation Serial port into an
emulated Hayes(tm) compatible modem, with the phone connection replaced
by TCP/IP.

DTR (wikipedia)

The DTR signal is an important call control signal for a data modem. According to the RS232 standard, dropping DTR from active to inactive for at least two seconds tells the modem to disconnect (end) a call or data connection.

SSC's DTR:
Command register, bit 0 : Data Terminal Ready (DTR) setting

  • 0=set DTR high (indicates 'not ready'),
  • 1=set DTR low (indicates 'ready')

So given the above, then TCPSER is looking for "dropping DTR from active to inactive for at least two seconds tells the modem to disconnect".

I assume:

  • "DTR active" = SSC's Command.bit0 := 1 "DTR low (indicates 'ready')"
  • "DTR inactive" = SSC's Command.bit0 := 0 "DTR high (indicates 'not ready')"

Is this understanding too?

If so, then I can create a build for you to test.

Contributor

tomcw commented Mar 5, 2017

TCPSER by Jim Brain

TCPSER is a utility that turns a PC/workstation Serial port into an
emulated Hayes(tm) compatible modem, with the phone connection replaced
by TCP/IP.

DTR (wikipedia)

The DTR signal is an important call control signal for a data modem. According to the RS232 standard, dropping DTR from active to inactive for at least two seconds tells the modem to disconnect (end) a call or data connection.

SSC's DTR:
Command register, bit 0 : Data Terminal Ready (DTR) setting

  • 0=set DTR high (indicates 'not ready'),
  • 1=set DTR low (indicates 'ready')

So given the above, then TCPSER is looking for "dropping DTR from active to inactive for at least two seconds tells the modem to disconnect".

I assume:

  • "DTR active" = SSC's Command.bit0 := 1 "DTR low (indicates 'ready')"
  • "DTR inactive" = SSC's Command.bit0 := 0 "DTR high (indicates 'not ready')"

Is this understanding too?

If so, then I can create a build for you to test.

@geneb

This comment has been minimized.

Show comment
Hide comment
@geneb

geneb Mar 5, 2017

[much stupid snipped]
My apologies - it's been too many years since I dug that deep into the nuts & bolts of serial comms. DTR is indeed active low.

I'm going to go polish my dunce cap now.

g.

geneb commented Mar 5, 2017

[much stupid snipped]
My apologies - it's been too many years since I dug that deep into the nuts & bolts of serial comms. DTR is indeed active low.

I'm going to go polish my dunce cap now.

g.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 18, 2017

Contributor

I've built an experiment (pre-release) 1.26.2.0 version here.

I've added two new experiment command lines arguments: -dtr and -dtr-invert.
By default DTR is still unsupported, but if you pass one of these switches, then AppleWin will use DTR:

applewin.exe -dtr

or

applewin.exe -dtr-invert

Let me know how you get on, and which of these correctly drives DTR.

Contributor

tomcw commented Mar 18, 2017

I've built an experiment (pre-release) 1.26.2.0 version here.

I've added two new experiment command lines arguments: -dtr and -dtr-invert.
By default DTR is still unsupported, but if you pass one of these switches, then AppleWin will use DTR:

applewin.exe -dtr

or

applewin.exe -dtr-invert

Let me know how you get on, and which of these correctly drives DTR.

@geneb

This comment has been minimized.

Show comment
Hide comment
@geneb

geneb Mar 18, 2017

Many thanks!
I tested the build and -dtr seems to be the correct flag. I now see the DTR being set in the tcpser log. However, it doesn't seem to be lowered until AFTER I disconnect the telnet session. Here's the log:

2017-03-18 15:01:16:536884688:INFO:DTR has gone high
[the bbs is now waiting for a call...]
2017-03-18 15:01:31:536883864:INFO:Connection accepted from 127.0.0.1
2017-03-18 15:01:31:536883864:INFO:taking modem off hook
2017-03-18 15:01:31:536883864:INFO:Control Lines: DSR:1 DCD:1 CTS:1
2017-03-18 15:01:31:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

[this is the point where I've logged off via the menu option and the bbs program is sending a modem init string. I then forcibly disconnect the session through the client.]

2017-03-18 15:02:05:536884840:INFO:No socket data read, assume closed peer
2017-03-18 15:02:05:536883864:INFO:Disconnecting modem
2017-03-18 15:02:05:536883864:INFO:Disconnecting
2017-03-18 15:02:05:536883864:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-18 15:02:05:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

2017-03-18 15:02:06:536884688:INFO:DTR has gone low
[NOW it brings DTR low? I wonder if this is a failure in how GBBS Pro manipulates the DTR on a disconnect, but not knowing how it's handled in AppleWin, I'm not sure.]

2017-03-18 15:02:06:536883864:INFO:Disconnecting modem
2017-03-18 15:02:06:536883864:INFO:Disconnecting
2017-03-18 15:02:06:536883864:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-18 15:02:06:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)
[BBS recycles and awaits the next call...]
2017-03-18 15:02:07:536884688:INFO:DTR has gone high
2017-03-18 15:02:07:536883864:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-18 15:02:07:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

Thanks!

g.

geneb commented Mar 18, 2017

Many thanks!
I tested the build and -dtr seems to be the correct flag. I now see the DTR being set in the tcpser log. However, it doesn't seem to be lowered until AFTER I disconnect the telnet session. Here's the log:

2017-03-18 15:01:16:536884688:INFO:DTR has gone high
[the bbs is now waiting for a call...]
2017-03-18 15:01:31:536883864:INFO:Connection accepted from 127.0.0.1
2017-03-18 15:01:31:536883864:INFO:taking modem off hook
2017-03-18 15:01:31:536883864:INFO:Control Lines: DSR:1 DCD:1 CTS:1
2017-03-18 15:01:31:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

[this is the point where I've logged off via the menu option and the bbs program is sending a modem init string. I then forcibly disconnect the session through the client.]

2017-03-18 15:02:05:536884840:INFO:No socket data read, assume closed peer
2017-03-18 15:02:05:536883864:INFO:Disconnecting modem
2017-03-18 15:02:05:536883864:INFO:Disconnecting
2017-03-18 15:02:05:536883864:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-18 15:02:05:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

2017-03-18 15:02:06:536884688:INFO:DTR has gone low
[NOW it brings DTR low? I wonder if this is a failure in how GBBS Pro manipulates the DTR on a disconnect, but not knowing how it's handled in AppleWin, I'm not sure.]

2017-03-18 15:02:06:536883864:INFO:Disconnecting modem
2017-03-18 15:02:06:536883864:INFO:Disconnecting
2017-03-18 15:02:06:536883864:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-18 15:02:06:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)
[BBS recycles and awaits the next call...]
2017-03-18 15:02:07:536884688:INFO:DTR has gone high
2017-03-18 15:02:07:536883864:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-18 15:02:07:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

Thanks!

g.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 19, 2017

Contributor

I tested the build and -dtr seems to be the correct flag.

For completeness, could you try the -dtr-invert flag? Then we can rule this out.

Above you said:

On real hardware connected to tcpser via a null modem cable, GBBS Pro properly toggles the DTR line to disconnect the session.
On AppleWin connected to tcpser via the same null modem cable, GBBS Pro has no effect on the DTR line, thus the session is never disconnected.

AppleWin+PC's serial port should (in theory) be able to replace this real Apple II+SSC. So if DTR is still not working 100%, then maybe there's still something wrong with AppleWin.

WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

Do you think this is anything to worry about?

Contributor

tomcw commented Mar 19, 2017

I tested the build and -dtr seems to be the correct flag.

For completeness, could you try the -dtr-invert flag? Then we can rule this out.

Above you said:

On real hardware connected to tcpser via a null modem cable, GBBS Pro properly toggles the DTR line to disconnect the session.
On AppleWin connected to tcpser via the same null modem cable, GBBS Pro has no effect on the DTR line, thus the session is never disconnected.

AppleWin+PC's serial port should (in theory) be able to replace this real Apple II+SSC. So if DTR is still not working 100%, then maybe there's still something wrong with AppleWin.

WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

Do you think this is anything to worry about?

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 19, 2017

Contributor

Also, I wonder how this part of the log compares when using a real Apple II and SSC?
Can you capture the log for a real Apple II and attach it here.

2017-03-18 15:01:31:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

[this is the point where I've logged off via the menu option and the bbs program is sending a modem init string. I then forcibly disconnect the session through the client.]

2017-03-18 15:02:05:536884840:INFO:No socket data read, assume closed peer
2017-03-18 15:02:05:536883864:INFO:Disconnecting modem
2017-03-18 15:02:05:536883864:INFO:Disconnecting
2017-03-18 15:02:05:536883864:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-18 15:02:05:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

2017-03-18 15:02:06:536884688:INFO:DTR has gone low
[NOW it brings DTR low? I wonder if this is a failure in how GBBS Pro manipulates the DTR on a disconnect, but not knowing how it's handled in AppleWin, I'm not sure.]

Contributor

tomcw commented Mar 19, 2017

Also, I wonder how this part of the log compares when using a real Apple II and SSC?
Can you capture the log for a real Apple II and attach it here.

2017-03-18 15:01:31:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

[this is the point where I've logged off via the menu option and the bbs program is sending a modem init string. I then forcibly disconnect the session through the client.]

2017-03-18 15:02:05:536884840:INFO:No socket data read, assume closed peer
2017-03-18 15:02:05:536883864:INFO:Disconnecting modem
2017-03-18 15:02:05:536883864:INFO:Disconnecting
2017-03-18 15:02:05:536883864:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-18 15:02:05:536883864:WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

2017-03-18 15:02:06:536884688:INFO:DTR has gone low
[NOW it brings DTR low? I wonder if this is a failure in how GBBS Pro manipulates the DTR on a disconnect, but not knowing how it's handled in AppleWin, I'm not sure.]

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 19, 2017

Contributor

Some observations / thoughts:

  1. There's exactly 1 second between these 2 TCPSER log events:
    . 2017-03-18 15:02:05:536884840:INFO:No socket data read, assume closed peer
    . 2017-03-18 15:02:06:536884688:INFO:DTR has gone low
    Is there a 1s timeout in TCPSER?
    (I looked for a timeout in AppleWin, but found nothing. NB. AppleWin's CommUpdate() looks like a timeout, but is redundant. I need to remove this.)

  2. At this log event, TCPSER sets DCD=0:
    . 2017-03-18 15:02:05:536883864:INFO:Control Lines: DSR:1 DCD:0 CTS:1
    . But AppleWin is not monitoring the PC serial port's DCD status. So GBBS will only ever read SSC Status Register with DCD=0 (0 means Data Carrier Detect = Detected).
    NB. When AppleWin has a serial port open, then SSC's Status.DCD=0 (=detected). Only when there's no serial port open does it set SSC's Status.DCD=1 (=not detected).

From Wikipedia's DCD description:

This signal is a simple "high/low" status bit that is sent "from DCE to DTE", or in a typical scenario, from the peripheral to the computer.
Its purpose varies depending on the device connected, but the most typical meaning is to indicate when a modem is connected to another remote modem via telephone lines.

Contributor

tomcw commented Mar 19, 2017

Some observations / thoughts:

  1. There's exactly 1 second between these 2 TCPSER log events:
    . 2017-03-18 15:02:05:536884840:INFO:No socket data read, assume closed peer
    . 2017-03-18 15:02:06:536884688:INFO:DTR has gone low
    Is there a 1s timeout in TCPSER?
    (I looked for a timeout in AppleWin, but found nothing. NB. AppleWin's CommUpdate() looks like a timeout, but is redundant. I need to remove this.)

  2. At this log event, TCPSER sets DCD=0:
    . 2017-03-18 15:02:05:536883864:INFO:Control Lines: DSR:1 DCD:0 CTS:1
    . But AppleWin is not monitoring the PC serial port's DCD status. So GBBS will only ever read SSC Status Register with DCD=0 (0 means Data Carrier Detect = Detected).
    NB. When AppleWin has a serial port open, then SSC's Status.DCD=0 (=detected). Only when there's no serial port open does it set SSC's Status.DCD=1 (=not detected).

From Wikipedia's DCD description:

This signal is a simple "high/low" status bit that is sent "from DCE to DTE", or in a typical scenario, from the peripheral to the computer.
Its purpose varies depending on the device connected, but the most typical meaning is to indicate when a modem is connected to another remote modem via telephone lines.

tomcw added a commit that referenced this issue Mar 19, 2017

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 19, 2017

Contributor

OK, I've built a new experiment (pre-release) 1.26.2.1 version here.

I think the status bit DCD and possibly DSR need to be supported.

So I've added experimental support for 6551's status bits: DCD and DSR via -dcd[-invert] and -dsr[-invert] args, eg:

applewin.exe -dcd

or

applewin.exe -dcd-invert

and

applewin.exe -dsr

or

applewin.exe -dsr-invert

You can specify any combination of these args, eg:

applewin.exe -dtr -dcd -dsr-invert

Again, let me know how you get on.

Contributor

tomcw commented Mar 19, 2017

OK, I've built a new experiment (pre-release) 1.26.2.1 version here.

I think the status bit DCD and possibly DSR need to be supported.

So I've added experimental support for 6551's status bits: DCD and DSR via -dcd[-invert] and -dsr[-invert] args, eg:

applewin.exe -dcd

or

applewin.exe -dcd-invert

and

applewin.exe -dsr

or

applewin.exe -dsr-invert

You can specify any combination of these args, eg:

applewin.exe -dtr -dcd -dsr-invert

Again, let me know how you get on.

@geneb

This comment has been minimized.

Show comment
Hide comment
@geneb

geneb Mar 22, 2017

There may be an issue with the Cygwin-built tcpser. I ran tests on both the real hardware and with AppleWin v1.26.2.0.

==========================
Log from tcpser on a Raspberry Pi, connected to a real IIe:

Connected:
2017-03-22 06:02:25:-1227484064:INFO:Connection accepted from 10.1.10.59
2017-03-22 06:02:25:-1227484064:INFO:taking modem off hook
2017-03-22 06:02:25:-1227484064:INFO:Control Lines: DSR:1 DCD:1 CTS:1

Disconnected:
2017-03-22 06:03:32:-1235872672:INFO:DTR has gone low
2017-03-22 06:03:32:-1227484064:INFO:Disconnecting modem
2017-03-22 06:03:32:-1227484064:INFO:Disconnecting
2017-03-22 06:03:32:-1227484064:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:03:34:-1235872672:INFO:DTR has gone high
2017-03-22 06:03:35:-1227484064:INFO:Control Lines: DSR:1 DCD:0 CTS:1

Log from tcpser on a Raspberry Pi, connected to AppleWin1.26.2.0, -dtr

Connected:
2017-03-22 06:29:53:-1227082656:INFO:Connection accepted from 75.145.20.100
2017-03-22 06:29:53:-1227082656:INFO:taking modem off hook
2017-03-22 06:29:53:-1227082656:INFO:Control Lines: DSR:1 DCD:1 CTS:1

Disconnected:
2017-03-22 06:30:19:-1235471264:INFO:DTR has gone low
2017-03-22 06:30:19:-1227082656:INFO:Disconnecting modem
2017-03-22 06:30:19:-1227082656:INFO:Disconnecting
2017-03-22 06:30:19:-1227082656:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:30:21:-1235471264:INFO:DTR has gone high
2017-03-22 06:30:23:-1227082656:INFO:Control Lines: DSR:1 DCD:0 CTS:1

Log from tcpser on a Rasberry Pi, connected to AppleWin1.26.2.0, -dtr-invert
BBS Startup:
2017-03-22 06:34:41:-1235291040:INFO:DTR has gone low
2017-03-22 06:34:41:-1226902432:INFO:Disconnecting modem
2017-03-22 06:34:41:-1226902432:INFO:Disconnecting
2017-03-22 06:34:41:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:34:42:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1

Connected:
2017-03-22 06:35:02:-1226902432:INFO:Connection accepted from 75.145.20.100
2017-03-22 06:35:02:-1226902432:INFO:taking modem off hook
2017-03-22 06:35:02:-1226902432:INFO:Control Lines: DSR:1 DCD:1 CTS:1

Disconnected:
2017-03-22 06:35:24:-1235291040:INFO:DTR has gone high
2017-03-22 06:35:26:-1235291040:INFO:DTR has gone low
2017-03-22 06:35:26:-1226902432:INFO:Disconnecting modem
2017-03-22 06:35:26:-1226902432:INFO:Disconnecting
2017-03-22 06:35:26:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:35:27:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1

=================================================
Throughout the runs above, I was getting garbled output from the BBS. However, with the 1.26.2.1 build, there was no issue with the output. The run below was done with the options -dtr, -dcd, and -dsr.

BBS Startup:
2017-03-22 06:50:30:-1235291040:INFO:DTR has gone high
2017-03-22 06:50:31:-1235291040:INFO:DTR has gone low
2017-03-22 06:50:31:-1226902432:INFO:Disconnecting modem
2017-03-22 06:50:31:-1226902432:INFO:Disconnecting
2017-03-22 06:50:31:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:50:32:-1235291040:INFO:DTR has gone high
2017-03-22 06:50:33:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1

Connected:
2017-03-22 06:51:05:-1226902432:INFO:Connection accepted from 75.145.20.100
2017-03-22 06:51:05:-1226902432:INFO:taking modem off hook
2017-03-22 06:51:05:-1226902432:INFO:Control Lines: DSR:1 DCD:1 CTS:1
Disconnected:
2017-03-22 06:51:58:-1235291040:INFO:DTR has gone low
2017-03-22 06:51:58:-1226902432:INFO:Disconnecting modem
2017-03-22 06:51:58:-1226902432:INFO:Disconnecting
2017-03-22 06:51:58:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:52:00:-1235291040:INFO:DTR has gone high
2017-03-22 06:52:02:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1

Just for completeness sake, I retried testing using the release version of AppleWin with tcpser on the Raspberry Pi and it did not disconnect properly.

For whatever reason, it appears that the Cygwin-built version of tcpser has some issues. However, your -dtr fix cured the issue that I reported, so thank you! The -dsr and -dcd flags may help other packages - I only have GBBS Pro to test with.

g.

geneb commented Mar 22, 2017

There may be an issue with the Cygwin-built tcpser. I ran tests on both the real hardware and with AppleWin v1.26.2.0.

==========================
Log from tcpser on a Raspberry Pi, connected to a real IIe:

Connected:
2017-03-22 06:02:25:-1227484064:INFO:Connection accepted from 10.1.10.59
2017-03-22 06:02:25:-1227484064:INFO:taking modem off hook
2017-03-22 06:02:25:-1227484064:INFO:Control Lines: DSR:1 DCD:1 CTS:1

Disconnected:
2017-03-22 06:03:32:-1235872672:INFO:DTR has gone low
2017-03-22 06:03:32:-1227484064:INFO:Disconnecting modem
2017-03-22 06:03:32:-1227484064:INFO:Disconnecting
2017-03-22 06:03:32:-1227484064:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:03:34:-1235872672:INFO:DTR has gone high
2017-03-22 06:03:35:-1227484064:INFO:Control Lines: DSR:1 DCD:0 CTS:1

Log from tcpser on a Raspberry Pi, connected to AppleWin1.26.2.0, -dtr

Connected:
2017-03-22 06:29:53:-1227082656:INFO:Connection accepted from 75.145.20.100
2017-03-22 06:29:53:-1227082656:INFO:taking modem off hook
2017-03-22 06:29:53:-1227082656:INFO:Control Lines: DSR:1 DCD:1 CTS:1

Disconnected:
2017-03-22 06:30:19:-1235471264:INFO:DTR has gone low
2017-03-22 06:30:19:-1227082656:INFO:Disconnecting modem
2017-03-22 06:30:19:-1227082656:INFO:Disconnecting
2017-03-22 06:30:19:-1227082656:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:30:21:-1235471264:INFO:DTR has gone high
2017-03-22 06:30:23:-1227082656:INFO:Control Lines: DSR:1 DCD:0 CTS:1

Log from tcpser on a Rasberry Pi, connected to AppleWin1.26.2.0, -dtr-invert
BBS Startup:
2017-03-22 06:34:41:-1235291040:INFO:DTR has gone low
2017-03-22 06:34:41:-1226902432:INFO:Disconnecting modem
2017-03-22 06:34:41:-1226902432:INFO:Disconnecting
2017-03-22 06:34:41:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:34:42:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1

Connected:
2017-03-22 06:35:02:-1226902432:INFO:Connection accepted from 75.145.20.100
2017-03-22 06:35:02:-1226902432:INFO:taking modem off hook
2017-03-22 06:35:02:-1226902432:INFO:Control Lines: DSR:1 DCD:1 CTS:1

Disconnected:
2017-03-22 06:35:24:-1235291040:INFO:DTR has gone high
2017-03-22 06:35:26:-1235291040:INFO:DTR has gone low
2017-03-22 06:35:26:-1226902432:INFO:Disconnecting modem
2017-03-22 06:35:26:-1226902432:INFO:Disconnecting
2017-03-22 06:35:26:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:35:27:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1

=================================================
Throughout the runs above, I was getting garbled output from the BBS. However, with the 1.26.2.1 build, there was no issue with the output. The run below was done with the options -dtr, -dcd, and -dsr.

BBS Startup:
2017-03-22 06:50:30:-1235291040:INFO:DTR has gone high
2017-03-22 06:50:31:-1235291040:INFO:DTR has gone low
2017-03-22 06:50:31:-1226902432:INFO:Disconnecting modem
2017-03-22 06:50:31:-1226902432:INFO:Disconnecting
2017-03-22 06:50:31:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:50:32:-1235291040:INFO:DTR has gone high
2017-03-22 06:50:33:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1

Connected:
2017-03-22 06:51:05:-1226902432:INFO:Connection accepted from 75.145.20.100
2017-03-22 06:51:05:-1226902432:INFO:taking modem off hook
2017-03-22 06:51:05:-1226902432:INFO:Control Lines: DSR:1 DCD:1 CTS:1
Disconnected:
2017-03-22 06:51:58:-1235291040:INFO:DTR has gone low
2017-03-22 06:51:58:-1226902432:INFO:Disconnecting modem
2017-03-22 06:51:58:-1226902432:INFO:Disconnecting
2017-03-22 06:51:58:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1
2017-03-22 06:52:00:-1235291040:INFO:DTR has gone high
2017-03-22 06:52:02:-1226902432:INFO:Control Lines: DSR:1 DCD:0 CTS:1

Just for completeness sake, I retried testing using the release version of AppleWin with tcpser on the Raspberry Pi and it did not disconnect properly.

For whatever reason, it appears that the Cygwin-built version of tcpser has some issues. However, your -dtr fix cured the issue that I reported, so thank you! The -dsr and -dcd flags may help other packages - I only have GBBS Pro to test with.

g.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 22, 2017

Contributor

However, with the 1.26.2.1 build, there was no issue with the output. The run below was done with the options -dtr, -dcd, and -dsr.

So it sounds like you only got non-garbled BBS output when you used AppleWin (1.26.2.1) with all 3 switches (-dtr, -dsr, -dcd). IE. it's not clear (from the above logs) which logs relate to the Cygwin-built tcpser (which you think has a problem).

Anyway to finalise this, I will remove all the -xxx-invert switches and just leave the 3 normal switches (-dtr, -dsr, -dcd). And additionally perhaps I should roll these up into a single -modem switch?

Contributor

tomcw commented Mar 22, 2017

However, with the 1.26.2.1 build, there was no issue with the output. The run below was done with the options -dtr, -dcd, and -dsr.

So it sounds like you only got non-garbled BBS output when you used AppleWin (1.26.2.1) with all 3 switches (-dtr, -dsr, -dcd). IE. it's not clear (from the above logs) which logs relate to the Cygwin-built tcpser (which you think has a problem).

Anyway to finalise this, I will remove all the -xxx-invert switches and just leave the 3 normal switches (-dtr, -dsr, -dcd). And additionally perhaps I should roll these up into a single -modem switch?

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Mar 22, 2017

Contributor

IE. it's not clear (from the above logs) which logs relate to the Cygwin-built tcpser (which you think has a problem).

OK, I think I understand: the logs immediately above are on a RPi, so are not Cygwin tcpser.
But the logs from >3 days ago are Cygwin tcpser, as they explicitly output:

WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

Contributor

tomcw commented Mar 22, 2017

IE. it's not clear (from the above logs) which logs relate to the Cygwin-built tcpser (which you think has a problem).

OK, I think I understand: the logs immediately above are on a RPi, so are not Cygwin tcpser.
But the logs from >3 days ago are Cygwin tcpser, as they explicitly output:

WARN:Could not set serial port status, CYGWIN bug? (Invalid argument)

@geneb

This comment has been minimized.

Show comment
Hide comment
@geneb

geneb Mar 22, 2017

Yes, the logs I posted today are all the Linux build of tcpser, sorry for not making that more clear.

A "-modem" switch, or maybe throw a checkbox next to the combobox for picking the COM port?

geneb commented Mar 22, 2017

Yes, the logs I posted today are all the Linux build of tcpser, sorry for not making that more clear.

A "-modem" switch, or maybe throw a checkbox next to the combobox for picking the COM port?

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Apr 15, 2017

Contributor

I've pre-released a new AppleWin 1.26.2.2 version here which has the -modem switch.

Let me know how you get on, and pass on the URL for your "how-to" when it's done.

Contributor

tomcw commented Apr 15, 2017

I've pre-released a new AppleWin 1.26.2.2 version here which has the -modem switch.

Let me know how you get on, and pass on the URL for your "how-to" when it's done.

@tomcw tomcw added the enhancement label Apr 22, 2017

@tomcw tomcw added this to the 1.27 milestone Apr 22, 2017

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Sep 29, 2017

Contributor

@geneb:
I'm looking to close this issue - can you confirm it's working with the -modem switch?
AppleWin 1.26.3.0 is here.

Contributor

tomcw commented Sep 29, 2017

@geneb:
I'm looking to close this issue - can you confirm it's working with the -modem switch?
AppleWin 1.26.3.0 is here.

@geneb

This comment has been minimized.

Show comment
Hide comment
@geneb

geneb Sep 29, 2017

My apologies Tom. I completely forgot about this. As far as I can recall, the switch worked just fine. The HowTo is part of the GBBS Pro v2.2 manual, which is available here: http://www.callapple.org/documentation/books/gbbs-pro-2-2/

geneb commented Sep 29, 2017

My apologies Tom. I completely forgot about this. As far as I can recall, the switch worked just fine. The HowTo is part of the GBBS Pro v2.2 manual, which is available here: http://www.callapple.org/documentation/books/gbbs-pro-2-2/

@geneb geneb closed this Sep 29, 2017

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Sep 30, 2017

Contributor

Thanks for confirming.

btw. Is it possible to attach the HowTo or send it to me privately?
(tomcharlesworth AT blueyonder.co.uk)

The reason is that if there's a reference to AppleWin, then I'd like to ensure that the correct version of AppleWin is available and that the referenced switches are properly maintained. I can also update the AppleWin.chm (help doc) to cross-reference to GBBS Pro.

Contributor

tomcw commented Sep 30, 2017

Thanks for confirming.

btw. Is it possible to attach the HowTo or send it to me privately?
(tomcharlesworth AT blueyonder.co.uk)

The reason is that if there's a reference to AppleWin, then I'd like to ensure that the correct version of AppleWin is available and that the referenced switches are properly maintained. I can also update the AppleWin.chm (help doc) to cross-reference to GBBS Pro.

@geneb

This comment has been minimized.

Show comment
Hide comment
@geneb

geneb Oct 1, 2017

Tom, I've put my original, stand-alone version here: http://www.geneb.org/tcpser/gbbs-tcpser-howto-01Oct17.pdf - I've revised it a little bit to add more info on the AppleWin side. Take a peek and let me know if there's any changes you think should be made.

geneb commented Oct 1, 2017

Tom, I've put my original, stand-alone version here: http://www.geneb.org/tcpser/gbbs-tcpser-howto-01Oct17.pdf - I've revised it a little bit to add more info on the AppleWin side. Take a peek and let me know if there's any changes you think should be made.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Oct 1, 2017

Contributor

Thanks Gene. I've given it a quick read.

Perhaps mention that the minimum version of AppleWin that supports -modem is 1.26.3.0 (there was a version a bit earlier than that, but this version is more up to date).

Also perhaps include a link to AppleWin? Here's the top-level page:
https://github.com/AppleWin/AppleWin

Contributor

tomcw commented Oct 1, 2017

Thanks Gene. I've given it a quick read.

Perhaps mention that the minimum version of AppleWin that supports -modem is 1.26.3.0 (there was a version a bit earlier than that, but this version is more up to date).

Also perhaps include a link to AppleWin? Here's the top-level page:
https://github.com/AppleWin/AppleWin

@geneb

This comment has been minimized.

Show comment
Hide comment
@geneb

geneb Oct 1, 2017

I updated the PDF with the changes. You can grab it and include it in the AppleWin distro if you like.

g.

geneb commented Oct 1, 2017

I updated the PDF with the changes. You can grab it and include it in the AppleWin distro if you like.

g.

@tomcw

This comment has been minimized.

Show comment
Hide comment
@tomcw

tomcw Oct 2, 2017

Contributor

Thanks for the update - I'll certainly add a reference to the docs.
(Reopening...)

Contributor

tomcw commented Oct 2, 2017

Thanks for the update - I'll certainly add a reference to the docs.
(Reopening...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment