MidiLink 2.0 looking for testers. (no MIDI devices required)

[ericgus]

One thing I have noticed is when disconnecting from a BBS .. the UART doesnt seem to want to drop the connection, I have to go into F12 and "reset uart connection" .. Maybe it needs a bit of tweaking?

UART works as a bridge between FPGA and HPS. It's completely unaware what's going on with Linux connectivity. So, wathcing ethernet connection or WiFi connection is not the task of UART connection.
And from permanent connectivity there is no difference between temporary disconnection or permanent - they are all temporary. For example on my PC i see sometimes ethernet becomes unavailable for short time - probably something with communication problem on cable. So ethernet disappear and then appear again.

Anyway, with this connection emulation there is no such thing as "carrier lost".

I am comparing the functionality against a wifi modem which works in a similar manner via telnet over the internet.. I presume the Midilink/TCP stack works in a similar manner.. the issue is very likely a problem in the tcpser Modem emulation in the midilink/tcp stack and not the underlying networking .. in this case "carrier lost" is akin to the telnet session between the two "internet modems" terminating the session (gracefully -- not due to any underlying networking issues).... whats specifically happening is, when logging off from a BBS, the MidiLink/TCP stack no longer is responding to "AT" commands at the terminal without having to "reset the uart" which effectively restarts the midilink software stack returning the AT command prompt. Once you reset it, you are then free to contact another BBS with the terminal software... without resetting it, the dialer no longer works due to the lack of the "AT" command response.

[zomgugoff]

I am comparing the functionality against a wifi modem which works in a similar manner via telnet over the internet.. I presume the Midilink/TCP stack works in a similar manner.. the issue is very likely a problem in the tcpser Modem emulation in the midilink/tcp stack and not the underlying networking .. in this case "carrier lost" is akin to the telnet session between the two "internet modems" terminating the session (gracefully -- not due to any underlying networking issues).... whats specifically happening is, when logging off from a BBS, the MidiLink/TCP stack no longer is responding to "AT" commands at the terminal without having to "reset the uart" which effectively restarts the midilink software stack returning the AT command prompt. Once you reset it, you are then free to contact another BBS with the terminal software... without resetting it, the dialer no longer works due to the lack of the "AT" command response.

The documentation for MidiLink shows a +++ATH command is supposed to be used to 'hang-up' the modem, which I assume is supposed to drop the TCP connection and allow the modem emulation to respond to normal AT commands. It doesn't seem to work, though.

[BBond007]

The documentation for MidiLink shows a +++ATH command is supposed to be used to 'hang-up' the modem, which I assume is supposed to drop the TCP connection and allow the modem emulation to respond to normal AT commands. It doesn't seem to work, though.

There needs to be a pause between +++ and ATH.

It does work (for me) with Procomm Plus in ao486 and NCOMM on Minimig.

That was the problem with a lot of cheap modems when dial-up internet became popular. They did not check for the pause so they could be tricked into hanging up the connection by pinging with "+++ATH"

[ericgus]

The documentation for MidiLink shows a +++ATH command is supposed to be used to 'hang-up' the modem, which I assume is supposed to drop the TCP connection and allow the modem emulation to respond to normal AT commands. It doesn't seem to work, though.

There needs to be a pause between +++ and ATH.

It does work (for me) with Procomm Plus in ao486 and NCOMM on Minimig.

That was the problem with a lot of cheap modems when dial-up internet became popular. They did not check for the pause so they could be tricked into hanging up the connection by pinging with "+++ATH"

I think out of all the BBS ive been calling with the c64 core, only one actually works correctly with the +++ and ATH ..

I mean right now its not a huge problem, restarting the UART fixes it .. but didnt know if there was some option that could be added to "tweak" this behavior .. perhaps as part of the "per core" section of the ini file along with defaulted baud rate etc.. maybe a timeout or something IDK .. just a thought.

btw LOVE the sounds now ,, its very nostalgic .. lots of "feels" .. thanks!

[BBond007]

I mean right now its not a huge problem, restarting the UART fixes it ..!

Try and update, I found a problem, not with the hang-up code, but an issue with when the remote disconnects first.

I still can't find a problem with the hang-up, but you don't mention which terminal programs you are having issue with....

with the newest MidiLink an update to the menu is required in order for ao486 MIDI to work

https://github.com/bbond007/Main_MiSTer ... r/releases

[ericgus]

I mean right now its not a huge problem, restarting the UART fixes it ..!

Try and update, I found a problem, not with the hang-up code, but an issue with when the remote disconnects first.

I still can't find a problem with the hang-up, but you don't mention which terminal programs you are having issue with....

with the newest MidiLink an update to the menu is required in order for ao486 MIDI to work

https://github.com/bbond007/Main_MiSTer ... r/releases

Oh its with CCGMS 2019 Ultimate on the c64 core .. https://csdb.dk/release/?id=174485

and it might be most of those BBS do indeed "hang up" first..

[BBond007]

Oh its with CCGMS 2019 Ultimate on the c64 core .. https://csdb.dk/release/?id=174485

Ok, I found that program does not put the delay between +++ and ATH so the hang-up was being rejected.

Anyway,

Update MidiLink again and add this like to your MidiLink.INI

[C64]
TCP_ATH_DELAY = 0

[Paradroyd]

I mean right now its not a huge problem, restarting the UART fixes it ..!

Try and update, I found a problem, not with the hang-up code, but an issue with when the remote disconnects first.

I still can't find a problem with the hang-up, but you don't mention which terminal programs you are having issue with....

with the newest MidiLink an update to the menu is required in order for ao486 MIDI to work

https://github.com/bbond007/Main_MiSTer ... r/releases

I'm not sure what you changed here, but whatever it was, it seemed to completely fix the squirreliness we were seeing with the FXcast / Atari ST core with regard to the modem stuff. I almost never have to reset it any more. Everything is working really well!

[ericgus]

Oh its with CCGMS 2019 Ultimate on the c64 core .. https://csdb.dk/release/?id=174485

Ok, I found that program does not put the delay between +++ and ATH so the hang-up was being rejected.

Anyway,

Update MidiLink again and add this like to your MidiLink.INI

[C64]
TCP_ATH_DELAY = 0

Its all working perfectly now .. thank you very much .. tried under the c64 and ao486 cores .. fantastic .. loving the modem connect sounds too! lots and lots of fuzzy "feels" .. thanks!

[zomgugoff]

Updated version is working great for me on all cores.

[BBond007]

I'm not sure what you changed here, but whatever it was, it seemed to completely fix the squirreliness we were seeing with the FXcast / Atari ST core with regard to the modem stuff. I almost never have to reset it any more. Everything is working really well!

Its all working perfectly now ..

Updated version is working great for me on all cores.

HI,

I have added support for multiple AT commands in one line. I have not found it necessary for any particular modem application so far but, I think it is something that a decent modem emulator should do...

example:

ATZ&M0&DT8675309[Enter]

Is the equivalent to:

ATZ[Enter]
ATM0[Enter]
ATDT8675309[Enter]

Sorgelig has requested that I move the default soundfont and ROM folders to '/media/fat/linux' which I have done. The midilink_updater script and default MidiLink.INI needed to be updated for this change --> https://github.com/bbond007/MiSTer_Midi ... er/INSTALL

I don't think any of these changes adversely effected anything, but it probably is a good idea for others to test before doing a general release.

Thanks

[ericgus]

Sorgelig has requested that I move the default soundfont and ROM folders to '/media/fat/linux' which I have done. The midilink_updater script and default MidiLink.INI needed to be updated for this change --> https://github.com/bbond007/MiSTer_Midi ... er/INSTALL

Do you need to run the midilink updater script and/or manually move the ini file?

[BBond007]

Do you need to run the midilink updater script and/or manually move the ini file?

You need to manually replace the INI file. The (new) midilink_updater script also needs to be run. I did not make updating the INI part of the script.

Thanks

[NML32]

How difficult would it be to add network support to the Atari 800 core?

[BBond007]

How difficult would it be to add network support to the Atari 800 core?

I know very little about the Atari 8-bit computers and their architecture. I'm not even sure what the most common (or preferable) interface would be for connecting the UART. It would seem that some of the options include Atari 850 Interface Module (which uses SIO port?), Atari 835 direct-connect Modem and Atari Telelink cartridge. Given my complete lack of knowledge of the Atari 800 architecture, hardware and terminal emulation, I don't have an answer as to how difficult it would be. It might be better ask the question in the thread for that core.

It is probable that the current modem emulation won't work at all (without tweaks) because of the differences between ASCII and ATASCII. At the very least the [Return] key is 155 (0x9b) vs 13 (0x0d) which will likely present a problem

The C64 also uses a proprietary character set called PETSKII, however it is similar enough (to ASCII) that the modem emulation still works with the most noticeable side-effect being that case of the characters are reversed.

I have refactored a substantial portion of the MidiLink TCP/Modem emulation to allow for optional ASCII<-->PETSKII translation for the C64 core. The translation is limited to the responses from MidiLink itself and not the host once connected. I have proactively added an option for 'ATASCII' but have not actually implemented it yet.

The INI option is:

TCP_TERM_TRANS = NONE/PETSKII/ATASCII

It can also be changed with the following 'AT' commands:

ATTRANS0 = NONE
ATTRANS1 = PETSKII
ATTRANS2 = ATASCII

If someone (with the necessary Atari 8-bit knowledge) would be willing to add UART support to the Atari 800 core than I would certainly finish adding support for ASCII <--> ATASCII translation.

(C64) BEFORE/AFTER:

[NML32]

@BBond007, thank you.

[Paradroyd]

How difficult would it be to add network support to the Atari 800 core?

I know very little about the Atari 8-bit computers and their architecture. I'm not even sure what the most common (or preferable) interface would be for connecting the UART. It would seem that some of the options include Atari 850 Interface Module (which uses SIO port?), Atari 835 direct-connect Modem and Atari Telelink cartridge. Given my complete lack of knowledge of the Atari 800 architecture, hardware and terminal emulation, I don't have an answer as to how difficult it would be. It might be better ask the question in the thread for that core.

It is probable that the current modem emulation won't work at all (without tweaks) because of the differences between ASCII and ATASCII. At the very least the [Return] key is 155 (0x9b) vs 13 (0x0d) which will likely present a problem

The C64 also uses a proprietary character set called PETSKII, however it is similar enough (to ASCII) that the modem emulation still works with the most noticeable side-effect being that case of the characters are reversed.

I have refactored a substantial portion of the MidiLink TCP/Modem emulation to allow for optional ASCII<-->PETSKII translation for the C64 core. The translation is limited to the responses from MidiLink itself and not the host once connected. I have proactively added an option for 'ATASCII' but have not actually implemented it yet.

The INI option is:

TCP_TERM_TRANS = NONE/PETSKII/ATASCII

It can also be changed with the following 'AT' commands:

ATTRANS0 = NONE
ATTRANS1 = PETSKII
ATTRANS2 = ATASCII

If someone (with the necessary Atari 8-bit knowledge) would be willing to add UART support to the Atari 800 core than I would certainly finish adding support for ASCII <--> ATASCII translation.

(C64) BEFORE/AFTER:

This is very cool.

I think...and I'm not really an expert here either..that a lot of Atari programs have an ASCII mode, and the way that this is usually dealt with is to switch the terminal program to ASCII mode, dial, then toggle to ATASCII for the BBS dialog.

There's also another way of dealing with this..and this is how I deal with it on Dual Term Elite on the ST, which also uses ATASCII. When I want to send a standard CR to the modem, instead of hitting RETURN, I just hit CTRL-M, which the modem will see as a valid CR and respond to. It's a pretty simple way of dealing with it without having to toggle modes.

[Paradroyd]

FYI, the flow control AT commands (&K) seem to be broken in the version I have, which I think is the current version. (it has the new translation commands).

20190304_221348.jpg

[BBond007]

FYI, the flow control AT commands (&K) seem to be broken in the version I have, which I think is the current version. (it has the new translation commands).

Yes, apparently I broke that when I added support for multiple AT commands per line. I thought I had fixed it but apparently not...

Try and update to 2.6 which I just pushed.

AT&K was being seen as:

AT[Return]
ATK[Return]

I fixed it by simply making the command ATK, but AT&K will still work as it is now seen as AT(which does nothing) and ATK (which now should work)

Sorry growing pains

[Paradroyd]

FYI, the flow control AT commands (&K) seem to be broken in the version I have, which I think is the current version. (it has the new translation commands).

Yes, apparently I broke that when I added support for multiple AT commands per line. I thought I had fixed it but apparently not...

Try and update to 2.6 which I just pushed.

AT&K was being seen as:

AT[Return]
ATK[Return]

I fixed it by simply making the command ATK, but AT&K will still work as it is now seen as AT(which does nothing) and ATK (which now should work)

Sorry growing pains

No problem. It's working again. Thanks again for all of your work on this.

[BBond007]

No problem. It's working again. Thanks again for all of your work on this.

Also interesting:

NML32 just uploaded a video of Radio Shack CoCo3 computer connecting to a BBS:

CoCo3: Connecting to a BBS [Test] --> http://y2u.be/9cjmG15WOzY

Apparently that core just got UART support

So it seems that core also supports the ALSA Linux sound.

[ericgus]

No problem. It's working again. Thanks again for all of your work on this.

Also interesting:

NML32 just uploaded a video of Radio Shack CoCo3 computer connecting to a BBS:

CoCo3: Connecting to a BBS [Test] --> http://y2u.be/9cjmG15WOzY

Apparently that core just got UART support

So it seems that core also supports the ALSA Linux sound.

Yep! It can now, been trying it out as well .. the video issues are also sorted out now, should work on standard HDMI displays that most cores work on..

[ericgus]

Apparently that core just got UART support

We need to spread this to more cores, like the ZX Spectrum, vic20, plus/4, PET, the Apple II and the PlusToo (Mac Plus), HT1080z and TI994a as well as other cores too! Basically all cores that have serial should really get this enabled.. would be fantastic.

[Paradroyd]

No problem. It's working again. Thanks again for all of your work on this.

Also interesting:

NML32 just uploaded a video of Radio Shack CoCo3 computer connecting to a BBS:

CoCo3: Connecting to a BBS [Test] --> http://y2u.be/9cjmG15WOzY

Apparently that core just got UART support

So it seems that core also supports the ALSA Linux sound.

I saw on Twitter earlier today that the Coco core just got UART support. It is cool, but I know very little about the Coco.

Anyway, the more cores that support it, the better.

[BBond007]

We need to spread this to more cores, like the ZX Spectrum, vic20, plus/4, PET, the Apple II and the PlusToo (Mac Plus), HT1080z and TI994a as well as other cores too! Basically all cores that have serial should really get this enabled.. would be fantastic.

Anyway, the more cores that support it, the better.

Agreed.

Just be careful. I remember this one time back in the early 80s when I almost inadvertently started WW3 trying to impress Ally Sheedy with my modem.