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

[Sorgelig]

Release 20190425 seems to fix the issue

I don't see any CIA changes in that release But I've finally could try on MiST, via an RS232-USB adapter, and with this patch, it worked better:
https://github.com/mist-devel/mist-boar ... 5bfe221220
But maybe it was just a wrong terminal emulator?

Yes, there was no changes in CIA. I've fixed some SDRAM problems. sometimes SDRAM accesses in sequential slots were "glued" together.

[BBond007]

totally fixed? Then it could be a memory access problem.

Seems totally fixed... I ran the test procedure monitoring it several hours last night, overnight and its still going...

Usually the symptom would be the screen/font colors or character set would get changed as shown in Paradroyd's screen captures.

Could it also be metastability problem like you described with earlier versions of the Minimig core? I was getting a warning message about timing requirements not being met.

I don't see any CIA changes in that release But I've finally could try on MiST, via an RS232-USB adapter, and with this patch, it worked better:
https://github.com/mist-devel/mist-boar ... 5bfe221220
But maybe it was just a wrong terminal emulator?

That is the same change I thought I was getting better results with, but then I'd recompile and have totally different results...

I been testing with CCGMS 2017 V6.prg as it load really quickly --> https://csdb.dk/release/?id=156523

[slingshot]

Could it also be metastability problem like you described with earlier versions of the Minimig core? I was getting a warning message about timing requirements not being met.

That is the same change I thought I was getting better results with, but then I'd recompile and have totally different results...

Seems more like timing issues than the SDRAM access (the same bug was present on MiST, but it just affected VIC II during data upload).
Probably a good idea to register the UART input before it reaches any combinatorial logic to make it glitch-free. Helped a lot for me (0 error during PC -> C64 core serial comms at 2400 bps now).

[SHIFT838]

I'm really impressed with the use of this within the few cores.

I specifically have tested with ao486 and CoCo3.

The thought that crossed my mind is someone may want to run a full retro BBS software on it for ao486 core. Something link Vision, VisionX, Emulex, Citidel or Renegade to name a few. I have tried to deploy all of these mentioned and the issue I have found is that it always thinks there is a carrier so it never goes to a 'waiting for caller' mode.

Not sure if it's something i just am doing wrong or the functionality just is not there yet.

Does anyone know?

[BBond007]

Not sure if it's something i just am doing wrong or the functionality just is not there yet.

Does anyone know?

The functionality is not there yet. It looks like changing the status of the DSR might work under ao486.

Not sure about CoCo as I can't see the HDL code...

I'll see if I can implement this when I get a chance.

Of these BBS packages you mention, which one would be the simplest for me to set up and configure to test with?

Thanks for testing...

[BBond007]

I'm really impressed with the use of this within the few cores.
The thought that crossed my mind is someone may want to run a full retro BBS software on it for ao486 core. Something link Vision, VisionX, Emulex, Citidel or Renegade to name a few. I have tried to deploy all of these mentioned and the issue I have found is that it always thinks there is a carrier so it never goes to a 'waiting for caller' mode.

I have updated the MidiLink TCP/Modem emulation (on my Github) and I am currently testing this functionality. Provided it works, and there is interest in this feature I can submit a pull request to Sorgelig to include in the next iteration of the SD installer.

With ao486, It seems that I can control the core DCD bit via the DTR bit on the HPS. I don't really know about CoCo3.

I have not yet tested this functionality with a BBS program, however, I made a quick DOS Turbo Pascal program to test this via the BIOS as well as reading the port directly. I have included the EXE and Pascal source. In theory, it should work...

I did try Renegade, but I was not able to run it due to lack of "Numeric co-processor".

To try, you'll need to update '/sbin/mididilink' manually or by using this script.

https://github.com/bbond007/MiSTer_Midi ... script.zip

[ericgus]

I have updated the MidiLink TCP/Modem emulation (on my Github) and I am currently testing this functionality. Provided it works, and there is interest in this feature I can submit a pull request to Sorgelig to include in the next iteration of the SD installer.

There are more uses for this than just BBS.. I think a lot of old school 2 player games that could use the modem would benefit from this (like populous, battle chess, FirePower on the Amiga, etc)

[BBond007]

There are more uses for this than just BBS.. I think a lot of old school 2 player games that could use the modem would benefit from this (like populous, battle chess, FirePower on the Amiga, etc)

Perhaps it would benefit some of those games, however, I have already gotten all of those games to work so apparently they don't require it.

Thanks!

[ericgus]

There are more uses for this than just BBS.. I think a lot of old school 2 player games that could use the modem would benefit from this (like populous, battle chess, FirePower on the Amiga, etc)

Perhaps it would benefit some of those games, however, I have already gotten all of those games to work so apparently they don't require it.

Thanks!

ok great, I havent personally tested them .. I just recalled that many of those used modems for two player.

[SHIFT838]

I'm really impressed with the use of this within the few cores.
The thought that crossed my mind is someone may want to run a full retro BBS software on it for ao486 core. Something link Vision, VisionX, Emulex, Citidel or Renegade to name a few. I have tried to deploy all of these mentioned and the issue I have found is that it always thinks there is a carrier so it never goes to a 'waiting for caller' mode.

I have updated the MidiLink TCP/Modem emulation (on my Github) and I am currently testing this functionality. Provided it works, and there is interest in this feature I can submit a pull request to Sorgelig to include in the next iteration of the SD installer.

With ao486, It seems that I can control the core DCD bit via the DTR bit on the HPS. I don't really know about CoCo3.

I have not yet tested this functionality with a BBS program, however, I made a quick DOS Turbo Pascal program to test this via the BIOS as well as reading the port directly. I have included the EXE and Pascal source. In theory, it should work...

I did try Renegade, but I was not able to run it due to lack of "Numeric co-processor".

To try, you'll need to update '/sbin/mididilink' manually or by using this script.

https://github.com/bbond007/MiSTer_Midi ... script.zip

I have downloaded and ran your update script.

I have made sure my ao486 core is set to 38400. I have had partial success with bbs software. It seems if the BBS software uses the escape codes to hangup "+++,ATH" there is no issue with it hanging up (Oblivian/2 tested), but other software that use code to drop the DTR like Vision, Vision-x and others the BBS will not hang up.

I have also noticed that when connecting into the BBS' (any of them I have) the response codes that the modem is issuing like 'Ring' and 'Connect' are getting transmitted to the BBS inputs.

Chris

[BBond007]

I have made sure my ao486 core is set to 38400. I have had partial success with bbs software. It seems if the BBS software uses the escape codes to hangup "+++,ATH" there is no issue with it hanging up (Oblivian/2 tested), but other software that use code to drop the DTR like Vision, Vision-x and others the BBS will not hang up.

I have also noticed that when connecting into the BBS' (any of them I have) the response codes that the modem is issuing like 'Ring' and 'Connect' are getting transmitted to the BBS inputs.

Chris

Getting rid of the response codes is easy.

I have not had much luck setting up Vision or Vision-x for testing the DTR hangup.

For Vision-X tried "visx099r.zip" and I'm getting runtime errors. Does this program work with QEMM?

For Vision I tried "v284betb.zip" and that one crashing saying "PDMATRIX.NFO not Found!!!"

Could you supply a link for working versions of these programs?

[SHIFT838]

I have made sure my ao486 core is set to 38400. I have had partial success with bbs software. It seems if the BBS software uses the escape codes to hangup "+++,ATH" there is no issue with it hanging up (Oblivian/2 tested), but other software that use code to drop the DTR like Vision, Vision-x and others the BBS will not hang up.

I have also noticed that when connecting into the BBS' (any of them I have) the response codes that the modem is issuing like 'Ring' and 'Connect' are getting transmitted to the BBS inputs.

Chris

Getting rid of the response codes is easy.

I have not had much luck setting up Vision or Vision-x for testing the DTR hangup.

For Vision-X tried "visx099r.zip" and I'm getting runtime errors. Does this program work with QEMM?

For Vision I tried "v284betb.zip" and that one crashing saying "PDMATRIX.NFO not Found!!!"

Could you supply a link for working versions of these programs?

took me some mucking around, but I did get Vision/2 v284beta working. at least I can connect and verify it hangs up. Vision/2 does not use DTR so it works with the disconnect. Also with Vision/2 I do not seem to have the issue with the result codes getting inputed in the bbs input fields.

I'm not using QEMM, I just use the standard EMM386 memory manager as it just gives me less headaches. Here is a disk image of the ones I am using for VisionX .99r, VisionX2.0, and Vision/2 .84b also the X00 fossil manager if you need it is there too.

I'm a willing tester.

My CONFIG.SYS file is:

Code: Select all

DEVICE=C:\DOS\HIMEM.SYS /testmem:off
REM DEVICE=C:\DOS\EMM386.EXE M9 I=E000-E3FF
DEVICE=C:\DOS\EMM386.EXE 4096 RAM FRAME=e000 d=256 x=a000-c7ff i=c800-efff
DOS=HIGH,UMB
device=c:\dos\ansi.sys
DEVICE=C:\DOS\MOUSE.SYS
DEVICE=C:\X00\X00.SYS T=256
LASTDRIVE=Z
BUFFERS=20
FILES=50

My AUTOEXEC.BAT file is:

Code: Select all

@ECHO OFF
PROMPT $e[1;32;40m$p$g$e[1;36;40m
PATH=C:\;C:\ARC;C:\DN;C:\DOS;C:\TP\BIN;C:\UTILS;C:\X00;
SET GSZWINDOW=23

[SHIFT838]

This version of Midilink also works with LSD 1.35 BBS.

[BBond007]

This version of Midilink also works with LSD 1.35 BBS.

I have pushed a new MidiLink where DTR drop causes the modem to hang up...

I guess it may be a good idea to make that behavior optional via the "AT&D#" commands and MidiLink.INI.

Thanks for testing!

[SHIFT838]

yes, I think making that optional via a AT command is a damn good idea!

[SHIFT838]

This version of Midilink also works with LSD 1.35 BBS.

I have pushed a new MidiLink where DTR drop causes the modem to hang up...

I guess it may be a good idea to make that behavior optional via the "AT&D#" commands and MidiLink.INI.

Thanks for testing!

I updated the midilink but now no modem commands go to the modem. I checked with telemate to see if I can still call out and now telemate tells me that the CTS signal is off and it will be disabling RTS/CTS flow control since it is not present.

I have tried with the new TCP_DTR flag as well, with the same result.

How can I revert back to the previous midilink?

[SHIFT838]

This version of Midilink also works with LSD 1.35 BBS.

I have pushed a new MidiLink where DTR drop causes the modem to hang up...

I guess it may be a good idea to make that behavior optional via the "AT&D#" commands and MidiLink.INI.

Thanks for testing!

I redownloaded the upgrade script and re-ran. now I can access the modem commands again. However the DTR does not hangup. I still have the same behavior as your update prior to the DTR update.

The BBS runs and waits for calls, which before your updating did not do. But still no hangup unless the BBS is issuig the +++, ATH

[SHIFT838]

Getting rid of the response codes is easy.

I have not had much luck setting up Vision or Vision-x for testing the DTR hangup.

For Vision-X tried "visx099r.zip" and I'm getting runtime errors. Does this program work with QEMM?

For Vision I tried "v284betb.zip" and that one crashing saying "PDMATRIX.NFO not Found!!!"

Could you supply a link for working versions of these programs?[/quote]

so when I was doing my testing since it did not drop immediately I thought it was the same as it was on the original midilink. NOPE.

so with the TCP_DTR=2 it will drop the carrier on the VisionX BBS. It just takes a few seconds. no big deal. So the the response codes in the login and password prompt is the only thing I can see as an issue now.

see attached photo.

[BBond007]

so with the TCP_DTR=2 it will drop the carrier on the VisionX BBS. It just takes a few seconds. no big deal.

I can probably tune this up. Right now it for 1 sec of read inactivity (meaning write from core) before checking the DTR line and taking appropriate action.

So the the response codes in the login and password prompt is the only thing I can see as an issue now.

I'm guessing it would like those response codes turned off. I see there is a Hayes AT command to do that - which I implemented.

MidiLink.INI
TCP_QUIET = 1

AT Commands:
ATQ0 - Verbose result codes (default)
ATQ1 - Suppress result codes (such as RING/CONNECT/OK)

You could also set your BBS modem init string:
ATZ&D2&Q1

So far I have not been able to get any of these Vision BBS programs to work for me. They just exit to DOS prompt after I make a remote connection...

Hope that helps...
Thanks for testing

[SHIFT838]

So far I have not been able to get any of these Vision BBS programs to work for me. They just exit to DOS prompt after I make a remote connection...

Hope that helps...
Thanks for testing

I have seen the BBS programs exit to dos, but it's usually because of an error like a file is not found and then it exits.

There are batch files usually with the BBS' (most of them) like KEEPUP.BAT so if it errors out or a user logs out it just resets the BBS and does not exit out to DOS.

[SHIFT838]

so with the TCP_DTR=2 it will drop the carrier on the VisionX BBS. It just takes a few seconds. no big deal.

Downloaded and updated the latest midilink. Seems the Vision-x requires the response codes to know when it connects, or it will just site there at locking port at 38400 bps..

turning off the response codes also jacks with Vision/2, it will work, but it will cycle through every baud rate displaying 'Press Enter' on the connected users side. Once it's readable the user presses enter and they are in. But it starts at 1200bps and takes a few seconds to cycle through each baudrate.

So it appears getting rid of the response codes will not work. Of course Vision/2 works fine with the response codes, it's just Vision-x that has an issue.

Since 38400 is the default for ao486 core and midilink, does midilink for ao486 send a 38400 Connect result code of "28". Or is it just sending Connect of '1' result code?

[BBond007]

Since 38400 is the default for ao486 core and midilink, does midilink for ao486 send a 38400 Connect result code of "28". Or is it just sending Connect of '1' result code?

The default (unless you specify differently in the INI via TCP_BAUD=) for TCP mode is 115200

The result code sends "CONNECT 115200"

If you change the BAUD to 38400, then it says "CONNECT 38400"

What is PDMATRIX.NFO? That is the file it's not finding.

[SHIFT838]

Since 38400 is the default for ao486 core and midilink, does midilink for ao486 send a 38400 Connect result code of "28". Or is it just sending Connect of '1' result code?

The default (unless you specify differently in the INI via TCP_BAUD=) for TCP mode is 115200

The result code sends "CONNECT 115200"

If you change the BAUD to 38400, then it says "CONNECT 38400"

What is PDMATRIX.NFO? That is the file it's not finding.

You should have a TOS_MENU.zip file. unzip it in the MENUS folder. these are all your menus, for ansi, ascii and NFO stuff.

will MIDILINK do 115200?

[BBond007]

You should have a TOS_MENU.zip file. unzip it in the MENUS folder. these are all your menus, for ansi, ascii and NFO stuff.

Unzipping TOS_MENU.zip fixed vis243betab and the BBS works for me now. Thanks!

I have changed all baud rates in the "CONFIG.EXE" program to under "Modem Setup\Config" to 38400 and modem init string to "ATZ&D2&Q1|"
Under "Supported Bauds' I have unchecked every option except 38400.

I'm not sure why 57600 does not work as it gets corruption echoed back which can be seen when it sends the modem INIT string.

The Vision-X program seems to connect if I change "Modem Setup"

Supported BAUD Rate ... 38400 (or 57600)
Download BAUD Rate ... 38400 (or 57600)
Default BAUD Rate ... 38400 (or 57600)
Modem Init String ... ATZ&D2&Q1|

When I conenct I get a "bad command or filename" and some sort of pseudo DOS shell:

Code: Select all

Bad command or file name
C:\ViSiON-X>dir
dir

 Volume in drive C is ViSiON-X .99▒
 Directory of  C:\ViSiON-X

.            <DIR>        09-04-93  3:29p
..           <DIR>        09-04-93  3:29p
LOGIN     EXE      12033  09-04-93  3:41p
SYSTEM2   EXE       9823  09-04-93  3:41p
SYSTEM3   EXE       9823  09-04-93  3:43p
APPLY     COM      24933  09-04-93  3:44p
CHECK     COM      11102  09-04-93  3:46p
LOGOFF    EXE       3002  09-04-93  3:46p
FEEDBACK  COM      13818  09-04-93  3:48p
CHAT      COM       9412  09-04-93  3:48p

10  File(s)  1785136 bytes free

C:\ViSiON-X>logoff
logoff

LOGOFF.EXE 1.00 written for ViSiON-X OS/2 .99▒
 (c) 1992 ViSiON-X Programming Team

I must be missing something? Any ideas there?
Back in the day, I never used DOS-based BBS programs. Just Amiga and OS/2.

will MIDILINK do 115200?

Yes, 115200 is the default speed for TCP/Modem (unless you specify other in the INI) but these BBS programs don't seem to support that rate. For some strange reason, vis243betab does not like 57600 at all. Probably a bug in the program because of other things like procomm+ work at that rate.

MidiLink can't detect baud rate like a normal modem can. Unfortunately, I'm not sure how to implement that or if it is even possible.

Hope that helps...
Thanks for testing!

[SHIFT838]

When I conenct I get a "bad command or filename" and some sort of pseudo DOS shell:

Code: Select all

Bad command or file name
C:\ViSiON-X>dir
dir

 Volume in drive C is ViSiON-X .99▒
 Directory of  C:\ViSiON-X

.            <DIR>        09-04-93  3:29p
..           <DIR>        09-04-93  3:29p
LOGIN     EXE      12033  09-04-93  3:41p
SYSTEM2   EXE       9823  09-04-93  3:41p
SYSTEM3   EXE       9823  09-04-93  3:43p
APPLY     COM      24933  09-04-93  3:44p
CHECK     COM      11102  09-04-93  3:46p
LOGOFF    EXE       3002  09-04-93  3:46p
FEEDBACK  COM      13818  09-04-93  3:48p
CHAT      COM       9412  09-04-93  3:48p

10  File(s)  1785136 bytes free

C:\ViSiON-X>logoff
logoff

LOGOFF.EXE 1.00 written for ViSiON-X OS/2 .99▒
 (c) 1992 ViSiON-X Programming Team

I must be missing something? Any ideas there? Back in the day, I never used DOS-based BBS programs. Just Amiga and OS/2.

What you are seeing here is a "Logon Matrix". Back in the late 80's and early 90's PC based Pirate/Warez boards would run software like Vision/2, VisionX, Emulex/2 and Oblivian/2. There is a selections for Logon Matrix type. If you set it to 0 (zero) for None then you will get a regular logon screen.

I have also found out that Vision/2 will not work with any speed higher than 38400.