Missing LF
#11
Again, what PROBLEM are you having? This is correct according to the Hayes standard, and if I change anything in this, NONE of the Amiga (and one PC and one Atari ST) BBS programs will connect.

Do you have dip switches on the bottom of your modem?
Reply
#12
OK, no offence. I don't have issues, i don't run a BBS software, is more the verbose results reponse format which annoys me. I'm a nostalgic modem collector, i have more then 25 external modems. And all respond to me in the right way. So i say to myself  that all modem cannot be wrong ?
So I did some research and came across the ITU-T V.250 specification which details the AT commands and section 6.2.6 (DCE response format) which explains the format of the result codes, with the ATV0 / ATV1 command as the header format change. It seems to me that you are using the V0 format and not the recommended V1 format. All my modems are in V1.
(Sorry for my bad english)
Reply
#13
All of my modems were made from 1982 to the latest being a USRobotics 3453B.  All of them respond exactly the same.  I discovered the solution for the Amiga BBS's by using the USR modem and capturing the serial data.  Once I changed the response code to be identical to the USR modem, then AmiExpress and a few other BBS's that I tried immediately worked correctly.  I confirmed with the Hayes standard for response strings as well.  If I switch back to how it was, then all of these BBS's will stop working.

The difference between ATV0 and ATV1 (the result code) is what is actually returned.  For baud rates, there is a hard coded value forcing the actual baud rate following "CONNECT" instead of just "CONNECT" without anything else.  Several other things are returned differently as well.

If you can link me a document that shows the recommended response codes then I can compare to what I have and do some testing on the Amiga BBS's.  That will be my standard though, because if those don't work then the PC and Atari BBS's won't work either - and I need all of those to work.
Reply
#14
https://www.itu.int/rec/T-REC-V.250-200307-I/en
Reply
#15
So, here is the problem - refer to page 27:

Table 3/V.250 – Effect of V parameter on response formats

The WiModem232 supports up to v.32bis, which is circa 1991. This specification changed for ITU over the years, and the Hayes standard did not. If I make the changes to support v.250, it absolutely breaks support for every Amiga and Atari ST BBS (and at least one PC BBS that started working with the v4.0 firmware).
Reply




Users browsing this thread: 1 Guest(s)