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.Sorgelig wrote: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.ericgus wrote: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?
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".
MidiLink 2.0 looking for testers. (no MIDI devices required)
Moderators: Mug UK, Zorro 2, spiny, Greenious, Sorgelig, Moderator Team
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
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.ericgus wrote: 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.
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
There needs to be a pause between +++ and ATH.zomgugoff wrote:
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.
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"
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
I think out of all the BBS ive been calling with the c64 core, only one actually works correctly with the +++ and ATH ..BBond007 wrote:There needs to be a pause between +++ and ATH.zomgugoff wrote:
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.
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 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!
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
Try and update, I found a problem, not with the hang-up code, but an issue with when the remote disconnects first.ericgus wrote: I mean right now its not a huge problem, restarting the UART fixes it ..!
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
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
Oh its with CCGMS 2019 Ultimate on the c64 core .. https://csdb.dk/release/?id=174485BBond007 wrote:Try and update, I found a problem, not with the hang-up code, but an issue with when the remote disconnects first.ericgus wrote: I mean right now its not a huge problem, restarting the UART fixes it ..!
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
and it might be most of those BBS do indeed "hang up" first..
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
Ok, I found that program does not put the delay between +++ and ATH so the hang-up was being rejected.ericgus wrote: Oh its with CCGMS 2019 Ultimate on the c64 core .. https://csdb.dk/release/?id=174485
Anyway,
Update MidiLink again and add this like to your MidiLink.INI
[C64]
TCP_ATH_DELAY = 0
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
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!BBond007 wrote:Try and update, I found a problem, not with the hang-up code, but an issue with when the remote disconnects first.ericgus wrote: I mean right now its not a huge problem, restarting the UART fixes it ..!
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
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
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!BBond007 wrote:Ok, I found that program does not put the delay between +++ and ATH so the hang-up was being rejected.ericgus wrote: Oh its with CCGMS 2019 Ultimate on the c64 core .. https://csdb.dk/release/?id=174485
Anyway,
Update MidiLink again and add this like to your MidiLink.INI
[C64]
TCP_ATH_DELAY = 0
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
Updated version is working great for me on all cores.
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
Paradroyd wrote: 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 wrote: Its all working perfectly now ..
HI,zomgugoff wrote: Updated version is working great for me on all cores.
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

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
Do you need to run the midilink updater script and/or manually move the ini file?BBond007 wrote: 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
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
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.ericgus wrote: Do you need to run the midilink updater script and/or manually move the ini file?
Thanks
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
How difficult would it be to add network support to the Atari 800 core? 

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
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.NML32 wrote:How difficult would it be to add network support to the Atari 800 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:
You do not have the required permissions to view the files attached to this post.
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
This is very cool.BBond007 wrote: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.NML32 wrote:How difficult would it be to add network support to the Atari 800 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:
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.
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
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).
You do not have the required permissions to view the files attached to this post.
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
Yes, apparently I broke that when I added support for multiple AT commands per line. I thought I had fixed it but apparently not...Paradroyd wrote: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).
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

Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
No problem. It's working again. Thanks again for all of your work on this.BBond007 wrote:Yes, apparently I broke that when I added support for multiple AT commands per line. I thought I had fixed it but apparently not...Paradroyd wrote: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).
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)
Sorrygrowing pains
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
Also interesting:Paradroyd wrote: No problem. It's working again. Thanks again for all of your work on this.
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.
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
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..BBond007 wrote:Also interesting:Paradroyd wrote: No problem. It's working again. Thanks again for all of your work on this.
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.
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
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.BBond007 wrote: Apparently that core just got UART support![]()
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
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.BBond007 wrote:Also interesting:Paradroyd wrote: No problem. It's working again. Thanks again for all of your work on this.
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.
Anyway, the more cores that support it, the better.
Re: MidiLink 2.0 looking for testers. (no MIDI devices required)
ericgus wrote: 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.
Agreed.Paradroyd wrote: Anyway, the more cores that support it, the better.
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.