CBMSTUFF FORUM

Full Version: UP9600
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
Yes, you just type AT&K1. You can always leave flow control enabled. I should probably make it the default because it won't hurt anything having it on even at 300 baud.

jdryyz

Setting AT&K1 did make a difference with the AT*HELP command. It did not eliminate my download retries completely, however. I realize that is not necessarily the fault of the WiModem or terminal settings though. There is quite possibly something analog still getting in the mix with the BBSes I have been connecting to. Not to mention that they are being run on original hardware in some cases. Many variables are involved, but I have been surprised by the speed of some sites. I will keep trying on the file transfers.

This probably deserves its own thread but it is related somewhat. Aside from the Commodore Server, are you aware of anyone connecting at higher than 9600bps to a site that advertises the use of a 38.4k SwiftLink, for example? Since the UP9600 is the fastest driver available in the two terminal programs I have used so far, will there be a chance of a 38.4k or better driver just for the WiModem? I realize that is a tall order but I only ask because the hardware supports it. I'm really curious to see how far it can be pushed.  Maybe "Alwyz" would be interested. Big Grin

Slight detour-- I remember when I first got my SwiftLink in 1990-ish. I had it paired up with some model of US Robotics modem and while I was doing better than my modems before, it never got to an impressive level. This was with systems that were capable of supporting up to 56k mind you. It didn't help that the 8bit BBSes were fading away by that time and I do not recall anyone actually running their BBS using the SwiftLink. In my local community, more and more people had switched to Amigas by then. They had their own serial port limitations but not as bad as the 8bitters. At some point in the mid 90s, I got a GVP I/O extender for my new USR V.Everything modem to use in my A3000. At that time, I do not believe any of the Amiga boards I called were active anymore. They had all moved on to the internet and so did I. I still wasn't always getting good connections with my dial-up ISP but at least I could say it wasn't something on my end.

It hasn't happened yet that I have discovered, but there could also be the possibility of someone running their internet-connected BBS using the WiModem. I realize that will require that their BBS also support UP9600/WiModem if they want to do better than 2400bps.
Don't forget that some BBS's require telnet escaping enabled for binary transfers to work.  These would need AT*T1 sent to the WiModem before you started the connection.  You can already use 38.4K baud with the V1541 disk for Commodore Server.

jdryyz

(02-25-2018, 12:30 PM)admin Wrote: [ -> ]Don't forget that some BBS's require telnet escaping enabled for binary transfers to work.  These would need AT*T1 sent to the WiModem before you started the connection.  You can already use 38.4K baud with the V1541 disk for Commodore Server.

Thanks for the tip.

I'm not sure I fully understand though. Can you give an example of a C= BBS that requires telnet escaping? So far, I have been calling sites that are running 8bit C= BBS software, not true telnet sites. Some are running in emulation and some on real hardware but wouldn't they both be considered telnet sites since they have telnet addresses instead of a phone line? Here is an example of what I would call a true telnet site: amigacity.xyz, port 23. This is running Synchronet under Linux. I really only intend to connect to 8bit Commodore BBSes with the WiModem.

As for Commodore Server, I'm aware you can connect at 38.4k with the WiModem (I've not yet tried it myself. I'm not even sure what the Comm Server IS outside of the website). My question is, are you aware of how I can connect the WiModem at something faster than 9600bps on a C= BBS that supports it? I'm sure this requires a driver just like the SwiftLink requires its driver for Novaterm/StrikeTerm and the best WiModem driver support we have at the moment for the available terminal software is UP9600. Unless I am mistaken, UP9600 maxes out at 9600bps as the name implies.
There are several CBM based websites that use a portal that is telnet specific and therefore, you would have to use AT*T1 to enable telnet escaping. You will know right away because an upload or download will not work.

There are no terminal programs that support 38400 baud that can use the USER PORT. Commodore Server has a driver specifically for it's V1541 application that lets you keep 1541 disks stored in the cloud and access them via standard LOAD and SAVE commands, using device 2 (instead of 8,9,10, or 11).... ie LOAD"$",2 gives you the directory.

jdryyz

(02-25-2018, 06:47 PM)admin Wrote: [ -> ]There are several  CBM based websites that use a portal that is telnet specific and therefore, you would have to use AT*T1 to enable telnet escaping.  You will know right away because an upload or download will not work.

There are no terminal programs that support 38400 baud that can use the USER PORT.  Commodore Server has a driver specifically for it's V1541 application that lets you keep 1541 disks stored in the cloud and access them via standard LOAD and SAVE commands, using device 2 (instead of 8,9,10, or 11).... ie LOAD"$",2 gives you the directory.

Thanks! Since connecting to these sites will be done using the WiModem from this point forward, is there any reason I would NOT want to switch on AT*T1 and just leave it that way?

Still confused on the User Port and 38.4k. The manual mentions that setting speeds beyond 9600 are possible using the AT*B command:

14400, 19200, 38400, 57600, 115200, and 230400

If the WiModem can connect to the Commodore Server at 38.4k using a specific driver, doesn't that mean the user port can handle speeds greater than 9600? Is the C= terminal program limitation just a "software" problem??
You can't do binary transfers to non-escaped sites with escaping turned on!

From a technical stand point here is what happens:

BBS sends 0xFF for a telnet escape start sequence, unless 0xFF is the actual character to send in which case 0xFF is sent twice.  The terminal program with telnet escaping turned on sees two 0xFF's in a row and ignores one of them, passing just 0xFF.  Now, if you have escaping enabled in your terminal program (and the BBS is not using telnet escaping) and you go to upload, it will be sending 0xFF twice every time 0xFF is encountered.

So, you must have the escaping set correctly.

jdryyz

(02-25-2018, 07:41 PM)admin Wrote: [ -> ]You can't do binary transfers to non-escaped sites with escaping turned on!

From a technical stand point here is what happens:

BBS sends 0xFF for a telnet escape start sequence, unless 0xFF is the actual character to send in which case 0xFF is sent twice.  The terminal program with telnet escaping turned on sees two 0xFF's in a row and ignores one of them, passing just 0xFF.  Now, if you have escaping enabled in your terminal program (and the BBS is not using telnet escaping) and you go to upload, it will be sending 0xFF twice every time 0xFF is encountered.

So, you must have the escaping set correctly.

Well I have finally completed a successful transfer without changing the setting so I guess this particular BBS didn't need it. However, this same BBS also failed out of the gate with continuous retries so it is inconsistent so far. I will have to keep testing it, and on different sites too.
Yes, the user port can handle more than 38400 baud (actually over 100000 baud), but you need to have specific code to do it. There will never be a terminal program that does more than 9600 baud using the user port because there is not enough time to process incoming AND outgoing data at the same time AND handle the ANSCII/graphics display requirements. I got 19200 working fairly well with a modified version of CCGMS, but it still had hiccups.

jdryyz

(02-26-2018, 04:20 PM)admin Wrote: [ -> ]Yes, the user port can handle more than 38400 baud (actually over 100000 baud), but you need to have specific code to do it.  There will never be a terminal program that does more than 9600 baud using the user port because there is not enough time to process incoming AND outgoing data at the same time AND handle the ANSCII/graphics display requirements.  I got 19200 working fairly well with a modified version of CCGMS, but it still had hiccups.

Ahhh. Since the Commodore Server connection does not have to handle graphics display requirements, 38.4k is fine.
Pages: 1 2 3 4