RS232 (MFP) and DCD line

[Count]

Does Hatari's RS232 (MFP) emulation handle the status lines of a serial port correctly?

I am running Hatari 2.4.0 on a Raspberry Pi with a WiModem connected to /dev/ttyUSB0. When I start my BBS software and log in from another machine, a hang-up is not recognized. It seems as if the DCD signal is not available on the Atari side.

[DarkLord]

You've probably already done it, but do you have AT&D2 set in your WiModem232?

If I don't have mine set like this, DarkForce! won't hang up correctly.

From the WiModem232/Pro manual:

AT&D[x] – Get/Set DTR operating mode [0-3]
This command enables monitoring of the DTR line and will do different
actions based on the setting:
0 - Status of DTR signal is ignored. Default mode.
1 - DTR signal is monitored. The modem enters command state after an onto-off transition of DTR signal. If the connection is established, the ATO
command returns to the on-line state.
2 - DTR signal is monitored. The modem hangs up and enters command
state after an on-to-off transition of DTR signal.
3 - DTR signal is monitored. The modem hangs up and resets after an on-tooff transition of DTR signal.

PS And don't forget to save your settings with AT&W...

[Count]

The WiModem works as expected on a real Mega STE. I am using the same settings with Hatari.

[DarkLord]

Oh well, it was just a thought...

[donapple]

I am running Hatari 2.4.0 on a Raspberry Pi with a WiModem connected to /dev/ttyUSB0.

You might want to try the current development version of Hatari (2.5.x) instead, because I think there have been some changes with regards to support for the serial ports.

[Count]

I am running Hatari 2.4.0 on a Raspberry Pi with a WiModem connected to /dev/ttyUSB0.

You might want to try the current development version of Hatari (2.5.x) instead, because I think there have been some changes with regards to support for the serial ports.

Good suggestion. I already compiled a snapshot from this week.

[czietz]

At first glance at the source code, there seems to be DCD handling for the SCC emulation (SCC: serial port IC in MegaSTE, TT and Falcon), but not for the MFP emulation. Maybe a Hatari dev could confirm that?

[Count]

At first glance at the source code, there seems to be DCD handling for the SCC emulation (SCC: serial port IC in MegaSTE, TT and Falcon), but not for the MFP emulation. Maybe a Hatari dev could confirm that?

With SCC B (Modem 2) it actually works.

It was a bit tricky to make the settings in the configuration file because the names have to be specified without a prefix ("EnableSccB" instead of "bEnableSccB", "SccOutFileName" instead of "szSccOutFileName" etc.). Fortunately, I found the correct names in configuration.c. This should be changed for naming consistency.

What doesn't seem to work yet are speeds above 19200 baud. With 38400 baud (TOS 3.06 and HsModem) only garbage comes out.

The hardware handshaking doesn't seem to be working yet either. ZModem transmissions are not possible, there are only error messages.

But the whole thing looks quite promising.

[Eero Tamminen]

What doesn't seem to work yet are speeds above 19200 baud. With 38400 baud (TOS 3.06 and HsModem) only garbage comes out.

The hardware handshaking doesn't seem to be working yet either. ZModem transmissions are not possible, there are only error messages.

I don't see any updates to Hatari SCC code since your last comment, but I'm asking just in case...

Have you gotten these working, or are they still an issue?

[Count]

Thank you for your assistance. I will try the lastest Git version today and then report back.

[Count]

What doesn't seem to work yet are speeds above 19200 baud. With 38400 baud (TOS 3.06 and HsModem) only garbage comes out.
The hardware handshaking doesn't seem to be working yet either. ZModem transmissions are not possible, there are only error messages.

I don't see any updates to Hatari SCC code since your last comment, but I'm asking just in case...
Have you gotten these working, or are they still an issue?

I compiled the Sep-5 Git of 2.6.0 today and handshaking is still an issue, but 38400 baud now works (for whatever reason).

[Eero Tamminen]

I compiled the Sep-5 Git of 2.6.0 today and handshaking is still an issue, but 38400 baud now works (for whatever reason).

Thanks for checking!

Regarding your earlier comment on DCD ("With SCC B it actually works"), is this remaining (handshake) issue with MFP, SCC or both, and with which port(s)?

[Count]

After some testing today I can say that handshaking with SCC (I am using Modem 2) is not an issue any more. On my first tests three days ago I missed to check the baud rate of the host device which was still set to 19200 baud. After raising this to 38400 baud, downloads ZModem completed without error. The 19200 baud setup likely caused buffer overruns and thereby loss of data.

Since SCC is very satisfying, MFP is not an option for me any more.

[npomarede]

Hi, thanks for your tests, it's very useful to validate SCC behaviour as I don't have a "real" modem to check things, dev was made using unix/linux and some program simulating a modem overs a socket. Good to know that SCC works correctly

Even if you're not using MFP port, can you elaborate on what settings were not working as expected ? If SCC works correctly it should be possible to do the same for MFP.

Nicolas

[Count]

Even if you're not using MFP port, can you elaborate on what settings were not working as expected ? If SCC works correctly it should be possible to do the same for MFP.

I just tested MFP in ST mode running TOS 1.04 and can still confirm that hang-ups are still not recognized on the DCD line.

[npomarede]

Hi

I added support for the DCD and CTS signals (as reported by the underlying OS) when using the MFP's RS232 port.
Can you get today's git source tree and compile it to check in ST mode with TOS 1.04 or STE mode with TOS 2.06 ?

Nicolas

[Count]

Unfortunately it doesn't work. It looks like you are passing the status the wrong way round. The BBS hangs up immediately as if the connection had been lost, but it hasn't.

[npomarede]

Does your BBS use both DCD and CTS signals or only DCD ?

EDIT : it would look like DCD signal is inverted before going into MFP GPIP bit1, but I couldn't find any doc about this and I can't see this on STF/STE schematics either. But I found another thread https://www.atari-forum.com/viewtopic.p ... 91#p453591 where you posted a "isonline" function from Mint that suggests that DCD is inverted in MFP (0=DCD ON), unlike in bit 3 of SCC (1=DCD ON)
Is that sthg you were able to confirm on real HW ?

[Count]

Does your BBS use both DCD and CTS signals or only DCD ?

It uses DCD, RI, DTR, RTS, CTS.

it would look like DCD signal is inverted before going into MFP GPIP bit1, but I couldn't find any doc about this and I can't see this on STF/STE schematics either. But I found another thread https://www.atari-forum.com/viewtopic.p ... 91#p453591 where you posted a "isonline" function from Mint that suggests that DCD is inverted in MFP (0=DCD ON), unlike in bit 3 of SCC (1=DCD ON)
Is that sthg you were able to confirm on real HW ?

That is correct. In MFP 0 means on, in SCC 1 means on:

Code: Select all

#define LSTMFP_GPIP (*((volatile byte*)0xfffa01L))
dcd_on = ((LSTMFP_GPIP & 0x02) == 0);
ri_on = ((LSTMFP_GPIP & 0x40) == 0);
...

[npomarede]

This inverted signal is weird, I don't see where it's done ... Do you know if CTS is inverted too (ie bit 1=0 means CTS OK) ?

Anyway, in the latest Hatari sources you compiled, can you try changing line 1948 in src/mfp.c
from
if ( dcd )
to
if ( !dcd )

This will invert the meaning and should give better results in your test.

Nicolas

[Count]

All signals mapped to LSTMFP_GPIP are inverted.

[npomarede]

All signals mapped to LSTMFP_GPIP are inverted.

Before I update Hatari, could you check with the above patch on "!dcd" if this works better in your case ?
Nicolas

[Count]

Checked right now. With this particular change, DCD still isn't handled correctly. When I close the connection on the client side, DCD still signals a connection.

[npomarede]

So at least it doesn't hang immediately at start, it's just at the end if I understand correctly ?

How do you check DCD ? Do you poll $fffa01 on a regular basis or do you expect an MFP interrupt to trigger when DCD state changes ? At the moment the later is not supported, only polling will update DCD state based on the connected device.

[Count]

I don't use the interrupt:

Code: Select all

static long get_mfp_gpip(void);

int dcd_mfp()
{
    /** Status of DCD line
     *
     *  Returns 1 when carrier detected.
     *  Low (0) means active!
     */
    return ((Supexec(get_mfp_gpip) & 0x02L) == 0);
}

int ri_mfp()
{
    /** Status of RI line
     *
     *  Returns 1 when ring indicated.
     *  Low (0) means active!
     */
    return ((Supexec(get_mfp_gpip) & 0x40L) == 0);
}

long get_mfp_gpip()
{
    return (long)(*((volatile unsigned char*)0xfffa01L));
}