Wifi modem! Telnet from any computer with a serial port

[+InsaneMultitasker]

I may turn telnet mode back on at some point, I haven't decided. For now this is the best approach to get feedback and better understand the pros/cons, as well as add rudimentary support to the BBS for Telnet clients. TIMXT doesn't use handshaking so it is a good test program for the wimodem232's &K0 option. Use *T0 for now if you test downloading to your system,

[JimDrew]

Have you tried turning telnet mode back on and using AT*T1 to see if it works with Heatwave? It could I guess since the news site and a couple of others seem to work ok now that I changed the telnet escaping. However, I will say that 99.99% of BBS's out there do not use telnet escaping because it cuts the through-put because of all of the escaping required with binary file transfers.

[+InsaneMultitasker]

I haven't tested it yet, I'll probably get to that this coming week. So far the only real downside has been with the PC-based clients, and I've worked around most of those by transmitting a few Telnet options to all terminals on connection. The remaining problem with the CR/Enter character I am close to resolving, or at least minimizing, in software.

[JimDrew]

What CR/Enter problem are you having?

[+InsaneMultitasker]

Some terminals programs (Hyperterminal, Qodem, and others) follow the Telnet specification by transmitting either a CRLF (0x0D 0x0A) or CR<NULL> (0x0D 0x00) 2-byte sequence when the ENTER key (character 0x0D) is pressed. I confirmed this by looking at the tcpip packets. The two characters are transmitted together and in many cases, the BBS catches only the 2nd character (the LF or NULL) when processing a single keypress.

 

The reason for this is that the BBS is written in a mix of BASIC and machine code. By the time the system scans for a keypress, the RS232's single-byte buffer is already overwritten with the second character. My current fix for this is a new input routine that will scan the RS232 until a character is received, without bouncing back and forth between BASIC and machine language.

 

Curiously, when the UDS telnet mode is turned on, the problem goes away. If the UDS was masking the LF or NULL, we'd have other problems. So I'm guessing the UDS is forcing the terminal program to use RAW mode or some other feature, which in turn forces the terminal to send only the Carriage Return. I just need to prove it.

[JimDrew]

New firmware for the WiModem232 is out. This version has a complete re-write of the ESP8266's cilent and server handlers to make them asynchronous. This solved (at least for me) all problems with sending data at high baud rates.

[+9640News]

New firmware for the WiModem232 is out. This version has a complete re-write of the ESP8266's cilent and server handlers to make them asynchronous. This solved (at least for me) all problems with sending data at high baud rates.

 

Thanks Jim. Looking forward to testing it out hopefully this evening.

 

Beery

[+arcadeshopper]

New firmware for the WiModem232 is out. This version has a complete re-write of the ESP8266's cilent and server handlers to make them asynchronous. This solved (at least for me) all problems with sending data at high baud rates.

 

Since upgrading I can't get it to connect to my Ubiquiti AP signal is 73dBm according to the *N command and it was connected before at the same location to do the upgrade (and for the last few weeks)

 

Ok I finally got it to connect by telling the ubiquiti to scan the rf environment and it changed to a less crowded channel..shrug then it worked

 

Greg

[JimDrew]

I can't change anything to do with sensitivity with the firmware. That's a hardware thing. You might have had higher than normal 2.4GHz traffic, or a microwave oven turned on - yes really!

 

Jim

[+9640News]

Jim,

 

Last night did some testing with latest firmware upgrade. With both PORT and a program I am using, MyTerm, uploading at 38.4K was no issue to 9640News BBS.

 

I was also able to download at 38.4K with PORT on 9640News BBS which is being run under a Windows 10 64-bit system with Mystic BBS software. MyTerm was capped at 19.2K downloading on my current non-public version of the software. I can tweak some code and it would download at 38.4K, but I lose (currently) what is occuring with the downloading process. That is a programming issue I am trying to solve on my end.

 

Anyways, things are looking well. Great job!!!

 

Beery

[Shift838]

I updated my WiModem232 to the latest firmware today and I was able to download and upload with a standard cable (no flow control) at 38400 on both FuSiON and Heatwave. I could not do either on 9640News, but that could be because of my cable is standard.

 

I did do this successfully from my real Geneve 9640 with No flow control selected.

[+9640News]

I updated my WiModem232 to the latest firmware today and I was able to download and upload with a standard cable (no flow control) at 38400 on both FuSiON and Heatwave. I could not do either on 9640News, but that could be because of my cable is standard.

 

I did do this successfully from my real Geneve 9640 with No flow control selected.

Please, I mean no disrespect to either Fusion or Heatwave. They are running at Geneve hardware speeds which if you measured actual bytes sent per timeframe, I am sure is lower than what a Windows computer can deliver. PORT as I recall was able to sustain both uploading and downloading at 38.4K on my 9640News with Jeff's cable mod selected. And that was a connection tied directly through my router which would be even faster (by a tad) than the minute delay through routed internet traffic.

 

Just a thought, you need to make sure you are sending the AT*T1 command to your WiModem232 for 9640News BBS before calling if you want to upload or download. This is because it is a Telnet BBS. Fusion and Heatwave have telnet mode turned off presently on their systems.

 

With a proper cable, you should have no difficulty uploading at 38.4K with TI hardware. I know I used to see on MS-DOS terminal emulators a cps transfer rate so one could see their transfer efficiency when uploading or downloading. I do not recall seeing that with any TI or Geneve software. Not recommending it either as it chews up precious CPU cycles at the higher baud rates.

 

The only issue then is can whatever terminal emulator you are using, sustain the download speed. It all depends upon how the data is captured and how much time is spent trying to capture keystrokes or updating information on the screen to what your max download speed/connection rate can handle. I've been downloading to hard drive, so I also do not know how sustainable the download transfer protocols are to saving on floppies.

 

What terminal emulator were you using? Did you use the AT*T1 command earlier? If you did, just make sure you didn't type ATZ afterwards where it would have then reloaded the saved settings in your default profile.

 

Myself, I have started some coding efforts for a "Phone dialer" for My-Term. Basically, it will allow you to specify baud rate for the system calling, domain name URL, port #, and command strings to send to setup the connection.

Beery

[JimDrew]

Thanks for the reports! I am pretty confident that I have solved the transfer issues by going with a fully asynchronous system.

 

I am uploading at 115200 baud with my Amiga to Hyperterm on a PC. I just got a PCI-e serial card that is capable of 1mbps serial, so I am going to see where the limit really is.

Edited February 2, 2018 by JimDrew

[Shift838]

Please, I mean no disrespect to either Fusion or Heatwave. They are running at Geneve hardware speeds which if you measured actual bytes sent per timeframe, I am sure is lower than what a Windows computer can deliver. PORT as I recall was able to sustain both uploading and downloading at 38.4K on my 9640News with Jeff's cable mod selected. And that was a connection tied directly through my router which would be even faster (by a tad) than the minute delay through routed internet traffic.

 

Just a thought, you need to make sure you are sending the AT*T1 command to your WiModem232 for 9640News BBS before calling if you want to upload or download. This is because it is a Telnet BBS. Fusion and Heatwave have telnet mode turned off presently on their systems.

 

With a proper cable, you should have no difficulty uploading at 38.4K with TI hardware. I know I used to see on MS-DOS terminal emulators a cps transfer rate so one could see their transfer efficiency when uploading or downloading. I do not recall seeing that with any TI or Geneve software. Not recommending it either as it chews up precious CPU cycles at the higher baud rates.

 

The only issue then is can whatever terminal emulator you are using, sustain the download speed. It all depends upon how the data is captured and how much time is spent trying to capture keystrokes or updating information on the screen to what your max download speed/connection rate can handle. I've been downloading to hard drive, so I also do not know how sustainable the download transfer protocols are to saving on floppies.

 

What terminal emulator were you using? Did you use the AT*T1 command earlier? If you did, just make sure you didn't type ATZ afterwards where it would have then reloaded the saved settings in your default profile.

 

Myself, I have started some coding efforts for a "Phone dialer" for My-Term. Basically, it will allow you to specify baud rate for the system calling, domain name URL, port #, and command strings to send to setup the connection.

Beery

 

That's right I forgot about the AT*T1 for 9640News.. I'll go back and try that in a few...

 

I would like to see your My-Term

[Shift838]

Winner Winner Chicken Dinner. Success on all 9640News at 38400 for uploads and downloads with Port.

[+9640News]

I'm still tweaking the downloading. The Xmodem code updating buffer space, bytes transferred, errors, time, and other items is just chewing up too many cpu cycles and fails above 19,200. When I start ignoring the screen updates, then I can get 38,400 however the user does not know if the transfer is occuring unless they hear the disk access during a file save.

 

I'm hoping Tim's interrupt code may resolve some of those issues. My attempts last weekend to interface that interrupt routine was less than successful. It seemed to be hung up in the interrupt code. Not sure if that was due to differences in how the RS232 was initialized between MyTerm and PORT, or something else.

 

I do know that if I run PORT, I can not run MyTerm without rebooting the computer as something is different. It appears to not be remnants of the interrupt code, but I am guessing something different in CRU bits causing my code to then choke.

 

When my PCI-e serial card arrives, I hope to be able to interface it with MAME and use the Debugger and do some single stepping through some code to figure stuff out.

 

Beery

[+9640News]

Winner Winner Chicken Dinner. Success on all 9640News at 38400 for uploads and downloads with Port.

 

Great!

[+InsaneMultitasker]

 

I do know that if I run PORT, I can not run MyTerm without rebooting the computer as something is different. It appears to not be remnants of the interrupt code, but I am guessing something different in CRU bits causing my code to then choke.

 

 

That's just my nefarious, anti-competition code kicking in. Seriously, my guess is somehow your RS232 routine or the interrupt routine are getting munged. When you say it doesn't run, to what extent is it failing?

[+InsaneMultitasker]

Winner Winner Chicken Dinner. Success on all 9640News at 38400 for uploads and downloads with Port.

 

With handshaking on using the 'jeff' cable ?

[Shift838]

 

With handshaking on using the 'jeff' cable ?

 

I have it set to 'None' within port

 

Just a standard cable I have wired up and used with my UDS.

[+9640News]

 

That's just my nefarious, anti-competition code kicking in. Seriously, my guess is somehow your RS232 routine or the interrupt routine are getting munged. When you say it doesn't run, to what extent is it failing?

After exiting PORT, I load MyTerm. When I get into Terminal mode, typing any characters results in no response back from the device. In this case, the WiModem232. I have to reboot the computer. Rebooting the WiModem232 is not the issue.

 

I'm assuming your interrupt routine was not installed in the CLI as the CLI would have really acted up.

 

Not sure if I have tried that configuration with the UDS 10 lately.

 

Anyways, more testing this weekend.

 

Beery

[+InsaneMultitasker]

 

I have it set to 'None' within port

 

Just a standard cable I have wired up and used with my UDS.

 

Based on what I know it shouldn't work without handshaking, although maybe if you are using standard xmodem, the protocol's 128 byte packet size coupled with the short delay needed to ACK each xmodem packet result in success. If you decrease the latency I suspect the transfers will fail unless you activate handshaking. Give 1kXmodem a try and see what happens. It's great that it works for you, just be aware you may be seeing an edge condition. Jim may have some better thoughts on this particular situation. Still, very cool that things are working so well.

[Shift838]

I have successfully uploaded with the same settings via port on Heatwave using 1kXmodem.

[Shift838]

is anyone else having issues with the WiModem232 storing phonebook entries?

 

I have tried to enter AT&Z1=FUSIONBBS.DDNS.NET:9640 and I get no response like OK or ERROR. it just returns to the line, querying the phone book entries shows blank entries.

[JimDrew]

Press RETURN a couple of times and try typing on a blank line. AT commands can do this right after you change baud rates. I need to figure out a way to flush the serial buffer after a baud rate change.