Port and WiModem232

[+9640News]

Tim,

 

I am attaching a file to this message that includes the documentation for the WiModem232 modem. Can you please take a look at page 19 and 20 and advise me whether there are any bridges that need to be cut the way PORT is handling the RS232 interface with the following cable configuration:

 

RS232/1 WiModem232

1 <--------------> 1

2 <--------------> 3

3 <--------------> 2

7 <--------------> 7

5 <--------------> 4

8 <--------------> 20

20 <--------------> 5

 

​I should add with Port that when I am downloading at 4800 baud and get about 1 to 3K above 32K on a file, I then get a bunch of retries and the download aborts. I do not know when your file blocks save, but I have heard no hard drive save attempts prior. With MyTerm, I get an aborted download after the first 8K block tries to save.

​Beery

 

wimodem232_manual.pdf

Edited January 12, 2018 by BeeryMiller

[+Schmitzi]

Mine arrived esterday

[+InsaneMultitasker]

Your problem does not sound like a handshaking problem. It sounds more like a file IO problem given the error seems to happen at the point of saving the file. I suppose there could be a retry issue but that seems unlikely. I would need more information. ​ I misread part of your sentence. What protocol are you using?

 

As for the modem itself, 4800 baud is well below PORT's sustainable transfer rate of 38.4K. I would go with a simple cable and disable hardware handshaking. Set PORT's RS232 to use interrupt mode. Use Xmodem as your baseline and select a file of 16-20 sectors (4-5K) so that you can compare results with both terminal emulators.

Edited January 12, 2018 by InsaneMultitasker

[JimDrew]

Tim,

 

I am attaching a file to this message that includes the documentation for the WiModem232 modem. Can you please take a look at page 19 and 20 and advise me whether there are any bridges that need to be cut the way PORT is handling the RS232 interface with the following cable configuration:

 

Because the manual changes frequently, please provide a link to the manual on my website instead of attaching the manual directly. The manual you have posted is really old, and missing a lot of data. Thanks!

 

Xmodem protocol is not currently supported. So, you can not use it as a flow control method (yet). It's something that I am working on adding.

Edited January 13, 2018 by JimDrew

[+9640News]

 

Because the manual changes frequently, please provide a link to the manual on my website instead of attaching the manual directly. The manual you have posted is really old, and missing a lot of data. Thanks!

 

Xmodem protocol is not currently supported. So, you can not use it as a flow control method (yet). It's something that I am working on adding.

 

Jim,

 

Sorry about that. I was trying to make things as simple as possible for Tim.

 

I just looked at the revision dates and I will trash my 12/24/17 and replace with the newer 12/31/17 from your website.

 

You say Xmodem protocol is not currently supported. Do you mean with the WiModem232 or do you mean with Port? If WiModem232, does this mean no file transfer protocols work? Trying to wrap my head around the context of your statement as I know you are behind the WiModem232 and Tim is behind Port.

 

Beery

[+9640News]

Your problem does not sound like a handshaking problem. It sounds more like a file IO problem given the error seems to happen at the point of saving the file. I suppose there could be a retry issue but that seems unlikely. I would need more information. ​ I misread part of your sentence. What protocol are you using?

 

As for the modem itself, 4800 baud is well below PORT's sustainable transfer rate of 38.4K. I would go with a simple cable and disable hardware handshaking. Set PORT's RS232 to use interrupt mode. Use Xmodem as your baseline and select a file of 16-20 sectors (4-5K) so that you can compare results with both terminal emulators.

 

I was using Xmodem 1K.

 

I will retry.

 

Beery

[Shift838]

Tim,

 

I am attaching a file to this message that includes the documentation for the WiModem232 modem. Can you please take a look at page 19 and 20 and advise me whether there are any bridges that need to be cut the way PORT is handling the RS232 interface with the following cable configuration:

 

RS232/1 WiModem232

1 <--------------> 1

2 <--------------> 3

3 <--------------> 2

7 <--------------> 7

5 <--------------> 4

8 <--------------> 20

20 <--------------> 5

 

​I should add with Port that when I am downloading at 4800 baud and get about 1 to 3K above 32K on a file, I then get a bunch of retries and the download aborts. I do not know when your file blocks save, but I have heard no hard drive save attempts prior. With MyTerm, I get an aborted download after the first 8K block tries to save.

​Beery

 

 

if I can find my cable I used with the Geneve and Port with my WiFi232 modem i'll look at the pinouts. Still digging through boxes though.

[+9640News]

 

I was using Xmodem 1K.

 

I will retry.

 

Beery

 

 

Your problem does not sound like a handshaking problem. It sounds more like a file IO problem given the error seems to happen at the point of saving the file. I suppose there could be a retry issue but that seems unlikely. I would need more information. ​ I misread part of your sentence. What protocol are you using?

 

As for the modem itself, 4800 baud is well below PORT's sustainable transfer rate of 38.4K. I would go with a simple cable and disable hardware handshaking. Set PORT's RS232 to use interrupt mode. Use Xmodem as your baseline and select a file of 16-20 sectors (4-5K) so that you can compare results with both terminal emulators.

 

I tried with a small file < 8k with Port using interrupt mode but my cable mods as listed above as I do not have another cable. After a couple of K transfer with Xmodem 1K, it looks like it loses sync with the blocks and quickly aborts at 4800 baud.

 

At faster baud rates, screen displays are snappy. Just downloads looks like where issues come into play. As I was writing this, someone was posting another message to this group so there may be an answer whether Xmodem is supported with the WiModem232.

 

Just a FYI, I am running on a stock Geneve. No extra 32K fast ram, no Genmod, no PFM.

 

Beery

[Shift838]

 

 

 

I tried with a small file < 8k with Port using interrupt mode but my cable mods as listed above as I do not have another cable. After a couple of K transfer with Xmodem 1K, it looks like it loses sync with the blocks and quickly aborts at 4800 baud.

 

At faster baud rates, screen displays are snappy. Just downloads looks like where issues come into play. As I was writing this, someone was posting another message to this group so there may be an answer whether Xmodem is supported with the WiModem232.

 

Just a FYI, I am running on a stock Geneve. No extra 32K fast ram, no Genmod, no PFM.

 

Beery

 

I am looking at the test results we were documenting with the WiFi232, tcpser and my home grown version of the WiFi232 using the HUZZAH ESP8266 module. The only difference at the time was the Fusion was being ran on emulated hardware where Heatwave is the real deal.

 

Also based on my testing at the time the max baudrate that I could achieve on Heatwave for both uploads and downloads with the WiFi232 was 9600baud, Fusion I could get up to 38400 for uploads/downloads. If I recall correctly also I did this with the ATNET0 issued to the Wifi232 to disable telnet mode.

[+arcadeshopper]

 

Jim,

 

Sorry about that. I was trying to make things as simple as possible for Tim.

 

I just looked at the revision dates and I will trash my 12/24/17 and replace with the newer 12/31/17 from your website.

 

You say Xmodem protocol is not currently supported. Do you mean with the WiModem232 or do you mean with Port? If WiModem232, does this mean no file transfer protocols work? Trying to wrap my head around the context of your statement as I know you are behind the WiModem232 and Tim is behind Port.

 

Beery

 

I have a feeling he's meaning xon-xoff..

[JimDrew]

 

I have a feeling he's meaning xon-xoff..

 

ACK! You are correct! I meant Xon/Xoff flow control. Sheesh... too much cold medicine today!

[+9640News]

 

ACK! You are correct! I meant Xon/Xoff flow control. Sheesh... too much cold medicine today!

 

Whew, you had me concerned. Makes sense now with Xon/Xoff. So far, I have managed to avoid the Flu as I knock on my desk. Wife struggled with it for a month, and several co-workers.

 

I did post a note over on cbmstuff for something I hope you can implement. That is adding the baud rate to the display for the last configuration issued to the WiModem232. Would sure help make sure I keep myself straight as I bounce through testing various programs, etc.

 

Beery

[+9640News]

Did some additional testing.

 

With Fusionbbs, I could download >8K programs with both Port and MyTerm at 4800 baud. Downloading from board, not possible.

[+InsaneMultitasker]

Interesting. Fusion BBS file transfers utilize the S&T BBS assembly code, which comes from (and is the same as) Heatwave. In a perfect world, this should rule out the BBS software as the culprit.

 

What does that leave us. Latency? packet assembly ? Some odd interaction? Hmm. The problem is nearly as perplexing as the Telnet escape code problem which is but shouldn't be a problem. I will start hunting for the pieces to throw together a 2nd Geneve system this weekend. The test results are not making any sense.

[JimDrew]

I will look at adding some info to the display. I am thinking about making multiple pages that alternate or something like that. I really didn't know what to put on the display, and after 2 years it seems that (at least with the C64 crowd) nobody actually looks at the display.

 

I just released a new firmware that correct a hardware flow control issue. After all of these little changes for other systems, I broke the C64 mode for 38400 baud (with inverted polarities), so I am looking into that.

[+9640News]

Interesting. Fusion BBS file transfers utilize the S&T BBS assembly code, which comes from (and is the same as) Heatwave. In a perfect world, this should rule out the BBS software as the culprit.

 

What does that leave us. Latency? packet assembly ? Some odd interaction? Hmm. The problem is nearly as perplexing as the Telnet escape code problem which is but shouldn't be a problem. I will start hunting for the pieces to throw together a 2nd Geneve system this weekend. The test results are not making any sense.

 

As far as latency, etc., keep in mind I am telnetting into BBS through a router. And, my board should be incredibly fast with Windows 10 Pro, 3.2 GH quad core, 16 GB ram, with SSD drives.

 

Beery

[+9640News]

I will look at adding some info to the display. I am thinking about making multiple pages that alternate or something like that. I really didn't know what to put on the display, and after 2 years it seems that (at least with the C64 crowd) nobody actually looks at the display.

 

I just released a new firmware that correct a hardware flow control issue. After all of these little changes for other systems, I broke the C64 mode for 38400 baud (with inverted polarities), so I am looking into that.

 

I will do another update here in a minute.

​Beery

[+InsaneMultitasker]

 

As far as latency, etc., keep in mind I am telnetting into BBS through a router. And, my board should be incredibly fast with Windows 10 Pro, 3.2 GH quad core, 16 GB ram, with SSD drives.

 

Beery

I'm not sure I follow - the testing that I've read about here has been between your Geneve and the two BBSs, Heatwave and Fusion. Both systems use the same underlying communication routines.

[+mizapf]

 

Just a FYI, I am running on a stock Geneve. No extra 32K fast ram, no Genmod, no PFM.

 

Since schmitzi just ran into that issue with MAME: No extra 32K means you have to use an older MDOS. Booting a more recent MDOS like 6.50 definitely locks up the Geneve.

[+9640News]

 

As far as latency, etc., keep in mind I am telnetting into BBS through a router. And, my board should be incredibly fast with Windows 10 Pro, 3.2 GH quad core, 16 GB ram, with SSD drives.

 

Beery

 

Tim, this statement should have included a bit more information. I was able to download from Fusion BBS a file > 8K at 4800 baud. Trying to make the same connection from my Geneve through the WiModem232 to 9640News, I was not able to download anything at 4800 baud.

 

I'm going to do some testing here in a few minutes between Fusion, Heatwave, and 9640News with Xmodem and begin at 2400 baud and work my way up.

 

Beery

[+9640News]

Tim,

 

I did a bunch of testing this morning with Port.

 

With 9640News BBS keeping in mind I am telnetting through the router the BBS is connected which should have the minimum of latency, I could not download anything < 8K even at 1200 baud. This was either with Hardware #1 Flow control setting or with interrupts.

 

On Heatwave, I downloaded up to 38.4K with >64K files. with either Hardware #1 Flow control setting or with interrupts. I did not test below 19.2K, but I saw at 19.2K and above with port that I had to have interrupts in order to not drop any characters on the menus.

 

On FusionBBS, same thing as Heatwave.

 

Now, separately from Port, I tested Myterm successfully at 19.2K on FusionBBS downloading. At 38.4K, no luck downloading. There were issues with Myterm dropping characters from display screens.

 

This was all done with the latest firmware upgrade on the WiModem232 as of last night.

 

I do have a question regarding the section on Hardware Flow Control for the WiModem232 which is on page 19 of the manual at the beginning of this thread.

 

It has the text below. Would the bridging as detailed below be an issue for selection of Jeff's hardware cable configuration?

 

The WiModem232 can be configured for hardware handshaking. Typically this will be RTS/CTS, but some devices (like printers) may need DTR or DSR instead. By default, RTS/CTS handshaking is enabled and there is a bridge between DTR and DSR.

There are a series of jumper pads on the bottom of the WiModem232 board. If the device you are using the WiModem232 with can't have a DTR/DSR bridge you can cut the connection point shown with the red arrow in Figure 3. If you need to set the hardware handshaking to use either DTR or DSR then you MUST cut the connections between the IN and RTS, and/or OUT and CTS, and then solder across the proper pads. See Figure 4.
NOTE: You can not have the DSR/DTR bridged if you are using either for handshaking.

[+InsaneMultitasker]

Wow, much better results.

1. For 9640News BBS,was the translation mode of the wimodem232 turned on or off? You may be experiencing the same problem that prompted me to turn Telnet mode off on Heatwave's UDS. I am still investigating the root cause from my side. Try turning flipping the translation mode on or off (AT*T?).

2, For Heatwave, I assume you were using monochrome not color mode, and that the translation mode was turned off? Fusion results matching Heatwave is a good thing. Was the testing success a result of a firmware update or a configuration change you made?

3. From past review of MyTerm operation, I believe it is using direct polling. The results match what I would expect for the Geneve and Myterm.

4. PORT was written to use RTS/CTS flow control. Keep in mind these designations are for the signals at the modem side, not the TI RS232. As for DTR/DSR and the bridging mentioned in the documentation, I am not sure how or if it affects handshaking without looking into it further. I'm not in a position to do that right now.

 

As a side note, I seem to recall that Michael and I determined long ago that PORT's file transfers operate primarily on interrupt mode regardless of the menu setting. If this is still true in the 2010 version, everything but Ymodem-g should operate successfully in both directions.

 

If you need to inspect what you are receiving in terminal mode, there is hex-dump option (FCTN-10 IIRC) that will display the incoming characters in hex in the upper window.

[+9640News]

Wow, much better results.

1. For 9640News BBS,was the translation mode of the wimodem232 turned on or off? You may be experiencing the same problem that prompted me to turn Telnet mode off on Heatwave's UDS. I am still investigating the root cause from my side. Try turning flipping the translation mode on or off (AT*T?).

2, For Heatwave, I assume you were using monochrome not color mode, and that the translation mode was turned off? Fusion results matching Heatwave is a good thing. Was the testing success a result of a firmware update or a configuration change you made?

3. From past review of MyTerm operation, I believe it is using direct polling. The results match what I would expect for the Geneve and Myterm.

4. PORT was written to use RTS/CTS flow control. Keep in mind these designations are for the signals at the modem side, not the TI RS232. As for DTR/DSR and the bridging mentioned in the documentation, I am not sure how or if it affects handshaking without looking into it further. I'm not in a position to do that right now.

 

As a side note, I seem to recall that Michael and I determined long ago that PORT's file transfers operate primarily on interrupt mode regardless of the menu setting. If this is still true in the 2010 version, everything but Ymodem-g should operate successfully in both directions.

 

If you need to inspect what you are receiving in terminal mode, there is hex-dump option (FCTN-10 IIRC) that will display the incoming characters in hex in the upper window.

 

I've tried translation mode both ways with 9640News without success. However, thinking it was potentially a speed issue, I went into Telnet with cosmicdebris.ddns.net:2323 and was able to download with Myterm at 9600 baud. At 19200, it never got the first record transmitted. Cosmicdebris is using the same Mystic software I am using. So, my guess is I am too close to my computer. I guess I need to run a longer cable maybe half way across the US. <chuckle>. He is also running his board on a Raspberry PI.

 

I've not been running color mode.

 

As far as connecting with Heatwave/Fusion, that was with the upgrade following last night's note there had been an update. Whether that played a role or not, I do not know.

 

I'm going to need to grab a terminal program for my other Win PC and see what happens with transferring files to it

 

Beery

[+InsaneMultitasker]

Is cosmicdebris using port 23 or port 2323? Maybe flip your port number to match and retest just to rule that out?

[+9640News]

 

I've tried translation mode both ways with 9640News without success. However, thinking it was potentially a speed issue, I went into Telnet with cosmicdebris.ddns.net:2323 and was able to download with Myterm at 9600 baud. At 19200, it never got the first record transmitted. Cosmicdebris is using the same Mystic software I am using. So, my guess is I am too close to my computer. I guess I need to run a longer cable maybe half way across the US. <chuckle>. He is also running his board on a Raspberry PI.

 

I've not been running color mode.

 

As far as connecting with Heatwave/Fusion, that was with the upgrade following last night's note there had been an update. Whether that played a role or not, I do not know.

 

I'm going to need to grab a terminal program for my other Win PC and see what happens with transferring files to it

 

Beery

 

Did some more playing trying to transfer a file from 9640news to my Geneve. Both Port and Myterm if I was running at 9600 baud or lower would abort the file transfer after 3200 bytes had been transferred via Xmodem CRC. Both were aborting on a file called BINHEX.ARK at the same place. Trying to transfer another file, C99BIO.ARK, and they both would abort after 256 bytes had been transferred.

 

Not making sense why the abort is not consistent across different files............

Beery