Port and WiModem232

[+9640News]

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

 

They are using 2323.

 

I set my port to 23 on the WiModem232 and called my BBS. Another abort at 3200 bytes on that one file.

 

Beery

Edited January 13, 2018 by BeeryMiller

[+InsaneMultitasker]

 

They are using 2323.

 

I set my port to 23 on the WiModem232 and called my BBS. Another abort at 3200 bytes on that one file.

 

Beery

Did you set 9640news BBS to port 2323?

[+9640News]

Did you set 9640news BBS to port 2323?

 

In the process of copying the board to a flash drive and then I will copy those files to the other computer. Then, I can use my router to point to that computer from port 2323 without taking 9640News offline.

 

Beery

[+9640News]

Port 2323 responds just the same as port 9640.

 

Beery

Edited January 14, 2018 by BeeryMiller

[JimDrew]

Some clarification on flow control.... the WiModem232 is shipped with RTS/CTS handshaking configured and DTS/DSR tied together. This is the most common method used by all computers. When DTR is brought high by the computer, it also is brought high on the DSR side and the computer knows the modem is attached and ready for use. There is one thing that many people forget about, and that is actually turning on the hardware flow control. You enabled it with AT&K1. If you have it set to AT&K0 then it won't matter if you have RTS/CTS jumpered on the board as no flow control will be used. So, remember to enable hardware flow control if you need it.

[+InsaneMultitasker]

Some clarification on flow control.... the WiModem232 is shipped with RTS/CTS handshaking configured and DTS/DSR tied together. This is the most common method used by all computers. When DTR is brought high by the computer, it also is brought high on the DSR side and the computer knows the modem is attached and ready for use. There is one thing that many people forget about, and that is actually turning on the hardware flow control. You enabled it with AT&K1. If you have it set to AT&K0 then it won't matter if you have RTS/CTS jumpered on the board as no flow control will be used. So, remember to enable hardware flow control if you need it.

Hi Jim, quick question - is there an equivalent setting for the &Dx command? With &D0 DTR is always assumed high; with &D2, a drop in DTR disconnects the current session and returns to command mode. My BBS software uses the &D2 mode and a few of the terminal emulators at our disposal do the same, to drop connection without resorting to the "+++" escape sequence. Also I appreciate your calling attention to &K1, as I found myself using &K3 out of force of habit while trying to set up my system today | I'm close to getting my wimodem232 online. (Edit: I located the wimodem232 forum and will read through that information as well; I somehow got directed to lemon64's wimodem topic and got a bit confused in the process. doh!)

Edited January 14, 2018 by InsaneMultitasker

[+9640News]

Hi Jim, quick question - is there an equivalent setting for the &Dx command? With &D0 DTR is always assumed high; with &D2, a drop in DTR disconnects the current session and returns to command mode. My BBS software uses the &D2 mode and a few of the terminal emulators at our disposal do the same, to drop connection without resorting to the "+++" escape sequence. Also I appreciate your calling attention to &K1, as I found myself using &K3 out of force of habit while trying to set up my system today | I'm close to getting my wimodem232 online. (Edit: I located the wimodem232 forum and will read through that information as well; I somehow got directed to lemon64's wimodem topic and got a bit confused in the process. doh!)

 

I believe I finally found a combination that works with Port and I have been able to download at 38,400.

 

I have to send an AT&K1 then follow it up with an AT*T1 with the Cable 1 configuration of 1 for Jeff's cable to download from 9640News since it is a Telnet BBS.

 

MyTerm chokes, but Port seems be ok.

 

Now, to successfully download from Heatwave at 38,400, I used AT&K1 and had to revert back to AT*T0 instead of AT*T1. This may be because you disabled Telnet.

 

Beery

Edited January 14, 2018 by BeeryMiller

[+InsaneMultitasker]

 

I believe I finally found a combination that works with Port and I have been able to download at 38,400.

 

I have to send an AT&K1 then follow it up with an AT*T1 with the Cable 1 configuration of 1 for Jeff's cable to download from 9640News since it is a Telnet BBS.

 

MyTerm chokes, but Port seems be ok.

 

Now, to successfully download from Heatwave at 38,400, I used AT&K1 and had to revert back to AT*T0 instead of AT*T1. This may be because you disabled Telnet.

 

Beery

Posted Today, 10:25 PM

InsaneMultitasker, on 13 Jan 2018 - 8:53 PM, said:

PS - I took Heatwave offline briefly to test the BBS cable and it allowed me to get online. In color mode Port's handshaking seemed to work, until I realized I had not turned it on at the modem side, meaning Port 0.60 is using interrupts in Color Ansi mode and is waiting for the transmission to end before displaying anything.

 

Yeah, I saw some of that with Port in not non-color mode which was a bit more irritating at the lower baud rates wondering if a keypress was accepted when all of a sudden, the screen "popped" up with menu.

Beery

The telnet change makes sense and I believe that is working as expected now. PORT's file transfers are primarily interrupt driven, so even though you have handshaking enabled, the file transfers may not utilize it at all times. Michael and I reviewed this a few years ago when he was working on his serial port bridge.

 

I copied our comment re: color mode from the other thread. There is a handshaking debounce that was originally tweaked for modem use. I think what we are seeing is a result of receiving data too quickly (i.e., a PC funneling a whole boatload of data down to 38.4), and the terminal never has a chance to properly pause the stream. You can fiddle with the settings for handshaking in PORT, I don't know how well tuned the current version will handle. Sadly, if the V9938 had a color text mode in hardware, instead of plotted in software, it wouldn't be so slow. Ah well.

[JimDrew]

I am surprised that AT*T1 works, however, I did make a change recently to the telnet escaping so maybe I fixed the issue we were having with Heatwave when telnet escaping was enabled.

 

There is AT&Dx supported so it doesn't generate a ERROR response, but this does nothing. You would have to disable RTS/CTS in order to use DTS/DSR. They are mutually exclusive, but dropping DTR will not hang up the modem. I can look into supporting this, but no systems so far require this. What exact computer are you using?

[+OLD CS1]

Jim,

 

ISTR several C64 BBSes have the option to drop DTR to hang up, as well (C-Net and Color64 specifically stand out in my memory, whatever my memory is worth these days.) I did in my own BBS program. Do you know of anyone running a C64 BBS on the wimodem?

[+InsaneMultitasker]

There is AT&Dx supported so it doesn't generate a ERROR response, but this does nothing. You would have to disable RTS/CTS in order to use DTS/DSR. They are mutually exclusive, but dropping DTR will not hang up the modem. I can look into supporting this, but no systems so far require this. What exact computer are you using?

I am using the TI-99/4A and its 'big brother' the Geneve. Both systems utilize the same RS232 hardware/cards.

 

There are a number of TI cable variants, some more compatible than others depending on the needed signals. Here are the pinouts for my BBS software and terminal emulation software. Both use RTS/CTS and DTR functionality.

 

RS232 -- Modem Name

1 -- 1 Protective Ground [required]

2 <-- 3 Receive Data [required]

3 --> 2 Transmit Data [required]

5 --> 4 Request to Send [emulator only; hardware handshaking,optional]

6 - No connection

7 -- 7 Logical Ground [required]

8 --> 20 Data Terminal Ready [emulator only. &D2 required for this functionality,optional]

5 --> 20 Data Terminal Ready [bBS only]

19 <-- 8 carrier detect [bBS only]

20 <-- 5 Clear to Send [hardware handshaking,optional]

 

TI labeled the connector as if it was a DCE (modem), which often makes for a lot of confusion. There are simpler cables that may be wired for modem connectivity when handshaking and DTR functionality are not desired.

 

Both programs drop DTR low for a short period of time, which (with option &D2) causes the modem to disconnect and return to the command interface. DSR does not come into play for in this configuration. Hopefully this makes sense, and with luck I made no mistakes.

[JimDrew]

Jim,

 

ISTR several C64 BBSes have the option to drop DTR to hang up, as well (C-Net and Color64 specifically stand out in my memory, whatever my memory is worth these days.) I did in my own BBS program. Do you know of anyone running a C64 BBS on the wimodem?

Yes, there are several people using the WiModem (not the WiModem232) for running a BBS. These people are using BBS software that looks at the DCD line to determine if the modem is connected. There is no DTR on a C64, so you have to use "+++" and ATH to hang up the modem with the C64. This is also used for the Amiga BBS's.

 

With the WiModem232 you can have either RTS or DTR, or CTS or DSR. There is no way to have RTS/CTS and DTR (or DSR) at the same time. I didn't think this was necessary based on the C64, Amiga, and PC. If this is the case, I could change the hardware but we would lose the LED or the display because there are no extra pins on the CPU. I am almost out of WiMmodem232 boards so I can look at this.

Edited January 15, 2018 by JimDrew

[+OLD CS1]

Yes, there are several people using the WiModem (not the WiModem232) for running a BBS. These people are using BBS software that looks at the DCD line to determine if the modem is connected. There is no DTR on a C64, so you have to use "+++" and ATH to hang up the modem with the C64. This is also used for the Amiga BBS's.

 

With the WiModem232 you can have either RTS or DTR, or CTS or DSR. There is no way to have RTS/CTS and DTR (or DSR) at the same time. I didn't think this was necessary based on the C64, Amiga, and PC. If this is the case, I could change the hardware but we would lose the LED or the display because there are no extra pins on the CPU. I am almost out of WiMmodem232 boards so I can look at this.

 

I have no dog in the race as I only have 5GHz wireless so I cannot make use of these devices, so I have nothing to say ultimately about usage or design. I just looked back through my dev notes and cross-referenced with the Programmers Reference Guide to make sure: CIA #2 port B bit 2 is labeled as "DTR" and bit 1 as "RTS" which go to the User Port pins E and D, respectively. But if no one is using it and it has not become a problem no big deal.

[+InsaneMultitasker]

DTR is a nice-to-have feature with limited application outside of BBSs (for me). Thanks for explaining the challenge with implementing it.

[+9640News]

I think I found myself a good reference that helps explain the operation of the 9902 in the RS232 card much better and in simpler terms with the link below than what I was dealing with trying to comprehend the 9902 manual. I'm posting the link here as whoever put it together, I say "Thank you" and maybe others will find some benefit from it.

 

http://www.unige.ch/medecine/nouspikel/ti99/rs232c.htm#SerPinout

 

 

Beery

[+9640News]

Tim,

 

I believe the WiModem232's latest update may have corrected the handshaking issue with downloading and Port at 38400 baud. I initiated the firmware update last night, and I am pretty sure I was running at 38400 baud with the AT&K1 and AT*T1 commands on 9640News BBS with PORT and had no issues with the download. I would need to double check.

 

Last few nights, not much sleep and programming time between watching UofK basketball, cutting up meat from last Monday's deer kill, and then taking the wife out to dinner. This evening, I've got about 30 lbs of venison to grind turning it into summer sausage, brats, breakfast sausage, and any left overs into "burger meat".

[+InsaneMultitasker]

Hi Beery,

I haven't had a chance to test with PORT or the BBS system, but I did flash my wimodem232 to v2.31 tonight. I was able to download from Heatwave to my PC (wimodem on com1) at 38.4K without any problem. I also was able to upload without a problem! That is a first! Let's both do a little more testing between various systems and compare notes.

 

Oh, my test was with &K1 and *T0 since Heatwave currently has telnet mode turned off. I found what I think is my most recent BBS serial IO routines and plan to add a switch to the send/receive routines to enable/disable telnet escaping. This is more for compatibility with other devices, since Jim's device is configurable.

[+9640News]

 

Oh, my test was with &K1 and *T0 since Heatwave currently has telnet mode turned off. I found what I think is my most recent BBS serial IO routines and plan to add a switch to the send/receive routines to enable/disable telnet escaping. This is more for compatibility with other devices, since Jim's device is configurable.

 

That would be nice, one set of commands and one configuration for everyone at least on the TI side of the world.

 

Beery

[+InsaneMultitasker]

Yes. I've been thinking about the other problem - where some Telnet sessions send the CRLF or CR<NULL> combination when the user presses ENTER/RETURN. My BBS software currently uses a routine to poll the serial port for a character, but it returns control to XB for other things. When this happens, it is more likely than not for the second character (the LF or NULL) to be in the RS232 single-byte receive buffer. The only way to combat this problem is to keep the routine from bouncing between XB and assembly, so that when the CR is received it is captured. Most terminal emulators just ignore the NULL so it doesn't show as an issue. I could still 'fix' this by turning Telnet mode back on, but I want to keep working through this to understand what is happening behind the scenes

[Swim]

I'm curious to know after a few weeks of BBS users running the wimodem232 if we have come to a generic cable and settings for the TI/Geneve real hardware BBSes? Has anyone replaced their UDS-10 with the wimodem232?

[Shift838]

I just ordered me one of these...

[+InsaneMultitasker]

I haven't replaced anything yet...but my intent is to try running Heatwave from it at some point. Right now I am using it to play around with some BBS code.

[Shift838]

My WiModem232 is on it's way...

[+9640News]

Tim,

 

I was playing with Port and Ymodem-Batch uploading of files. I think I got the protocol right. Anyways, it is the option where I tag the files I want to upload, and then tell it to go.

 

I noticed a behavior I do not know if it has a solution.

 

I had three DV80 files; SUB1, SUB2, and SUB3. When I looked on my software on the files it received, I would have expected three separate files. Rather, I was missing a file. I had SUB.SNT and $UB.SNT. I am assuming the protocol(s) are smart enough to discover the first filename that is the same, but not the second and a file was overwritten???

 

Do you recall what is supposed to happen?

 

I know I can rename the files so everything has separate filenames since they are source files, but thought about the cases where there is XPORT, XPORU, XPORV, etc.

 

What I do not know is if this kind of issue can be resolved with PORT's use of the Ymodem-batch protocol or if it is on the BBS end of things.

 

What I was actually hoping to do was to tag a directory of files, and upload them to the BBS as backups for safekeeping when I saw the issue. I did look with Notepad at the individual files and saw where the original filename was embedded in the first block of the file. Not sure what happens if the file gets downloaded by another protocol instead of Ymodem-batch within Port as I have not tried that option yet.

 

Beery

[+InsaneMultitasker]

I'm not sure if it is a BBS or PORT issue, though the latter wouldn't necessarily surprise me. The Ymodem header, record 0, is sent with the filename. At one time all of the emulators I 'touched' were restricted to the DOS 8.3 file configuration, and the Ymodem header was crafted as such. It was expected that the receiving end would fix the filenames as needed - perhaps short-sighted at the time. Seeing the SNT extension tells me the version you have is limited in this regard. I removed that 8.3 restriction (and addition of an extension) at some point for almost exactly the reason you state You'll see the same removal of restrictions on Heatwave if you download Ymodem-Batch from there. The only challenge is adding an extension on the PC back end which was/is left to the user. When you download to Port, I believe the TIFILES header takes precedence. I can't tell you much more without locating and digging through the most recent code.

 

If you are in Port, you can sit in terminal mode and ACKnowledge the records manually. Ctrl-F is an ACK, if I remember correctly. You'll be able to see the Ymodem header that way. You might also need to provide the "C" to kick off the CRC handshake.