JimDrew

Technically, you don't need escaping at all. None of the Apple II, C64, or Amiga BBS's use any type of escaping and operate normally, including file transfers. Escaping only appears to be necessary if you are accessing a portal or BBS that specifically uses Telnet commands (like tty.sdf.org:23). I can run two terminal programs, one on my C64 and one on my Amiga and connect together (via ATDT) and chat with myself and transfer files. However, Telnet escaping with the WiModems must be OFF or the file transfers will not work. Edit: this just made me realize that if both WiModem's have escaping ON it should still work, but it doesn't - and that's because I am not escaping the outgoing data, just the received data. I need to fix that. Have you tried just disabling all Telnet stuff?

LOL! So much for "smart devices" correcting spelling...

You can connect any 5v CPU with a serial port directly to the WiModem for the C64 - it has 5v TTL logic. The WiModem has proper level shitters (not simple resistors that draw excessive current) and a power supply circuit, besides the RF module.

One other thing... the DTR/DSR lines are tied together on the WiModem232 by default. So, your terminal program may require that you enable DTR in order for communications to occur. Ok, just read the Telco manual. The cable they recommend has CTS is connected to DTR. That will be a problem since DTR/DSR are tied together. CTS would probably need to have its signal inverted (AT*C) or you would get no data. The easiest thing to do would be disconnect this line in the cable. This is not for flow control - it's used to hang up the modem, which is bizzare as that is not the way you are suppose to do it based on the Hayes specifications.

Ok, try changing the DCD polarity. You can try AT*D0. You would need to make changes of course in the terminal program works. You might look for options in the terminal program about how it handles DCD. Also, I am not sure if Rx/Tx can be reversed in software, but I have seen that option in some terminals.

Check to see how DCD is handled. Unlike other WiFi devices, the WiModem232 handles ALL of the RS232 lines, so the terminal program needs have its response to DCD setup correctly. You could try using AT&C0 to always enable the DCD line to see if that fixes the issue.

Yeah, I believe that this has something to do with the UDS-10. It is definitely doing Telnet escaping - otherwise the Telnet test program you have would always fail. From reading through some history it seems that this has been a problem for other WiFi type devices and your BBS's? Is there a way to completely disable Telnet escaping on the UDS-10 itself?

Suppressing the GA makes sense, but it still seems that Telnet escaping is still being done. I need to get Hypertem.. it's not included with Windows 10. I could look at the data stream and see what's going on that way. I can see why no BBS's for the Apple, Mac, Amiga, and PC use Telnet escaping!

I don't think the problem is the GA command. That seems to just allow/disallow traffic, much like a flow control. That would have to be called before/after transfer or something. You said that it only happens once when the system connects, right?

It looks like nobody likes the command: https://tools.ietf.org/html/rfc596 I would like to try a file transfer with the command turned off to see if that's the issue or if it's related to something else.

Well, I went to your Game Door and tried the TELNET test. With the translation mode set to ON, the TELNET test passes perfectly with all lines being correct, including 255. If I turn off the translation, then all lines are correct *except* 255 (which I would expect). So, it seems that my Telnet translation is correct. Maybe there is some other issue, like with the packet size or speed. I will try using a really low baud rate to see if that changes anything.

Standard Telnet requires that 0xFF is used as a the escape sequence start byte. Two consecutive 0xFF bytes are treated as a normal 0xFF. I tried with both the escaping on and off and got the same results. I have not seen a single BBS (so far) that actually does Telnet escaping, so it's definitely not required. Only portals (like tty.sdf.org:23) that are Telnet specific require the Telnet translation with the WiModem. The first thing that these portals do is send a Telnet command to obtain the supported Telnet features. I return only a couple of features. Before I did that, none of these portals would actually proceed to the login point. I will get Hyperterminal and see if I can transfer files correctly myself. If so, then I can dumb the serial stream via a sniffer to look at the data and try to figure out what's going on. The hardware works, so this is just a firmware issue that I should be able to resolve.

Well, I was able to log on to Heatwave and FUSION with no issues, however, I was not able to transfer files. That is very odd as I can upload/download files with dozens of other BBS's with zero issues. Can you explain what you mean by "the telnet connection mode is required for negotiation?" I am not a Telnet guru. I just learned a few months ago that some portals require Telnet escaping to even connect and added support for that to the original WiModem (C64/128 version) that's been out for a few years. The WiModem/WiModem232 share the same code with some minors differences between the two (like the WiModem232 supports the RI, DTR, and DSR lines, whereas the WiModem doesn't). I would like to figure out whatever is causing the download errors and correct it. Thanks! What is a "UDS device"? I don't know about the TI-99/4A computers. edit - so it seems that the UDS-10 is an Ethernet to serial bridge. That really shouldn't matter. I am stumped why I can connect, but can not download. I have downloaded at 115200 with zero errors in various protocols with other BBS's and using the WiBridge software for the PC. I tried every protocol that Heatwave has and all resulted in errors after the first block (or 1K). This is exactly what should happen if you have Telnet escaping turned ON while trying to download, but it is turned off in my testing.

I forgot to mention that in normal translation mode (default), Telnet filtering is not done so file transfers work perfectly. You *can* enable Telnet escaping if you need it (for portals like TTY.SDF.ORG:23).

We already have a great program (WiBridge) for the PC that lets you browse your PC's files from the WiModem or WiModem232 and do bidirectional Zmodem or Xmodem file transfers.

Well, if you made the C64 user port (edge card fingers) wired correctly to your TI system, you could then just plug in my WiModem (C64 version). It's 5vdc so it would work. The WiModem232 requires RS-232 levels (+/-12vdc), so it won't work directly with the 1284P. The WiModem for the C64 has Rx/Tx/RTS/CTS/DCD lines. It's missing RI (Ring Indicator), but it seems that most programs just look for "RING" to appear and then answer (like for a BBS).

The WiModems use telnet for the connection, and there is a setting you can do to make it handle the special telnet commands, required for connections to tty.sdf.org:23 and others that use telnet command sequencing. Regular BBS's don't require this. Doesn't the TI-99/4A have a serial port? I only make dedicated devices for the C64/128/SX-64/Plus4 and now one that works with standard RS-232 (typical +12v/-12v). The WiModem for the C64 uses 5v signal levels, and has true level converters on the board to handle the 3.3v requirement of the RF module. I had to write the firmware from scratch. I did this a few years ago before any code started popping up for a basic WiFi bridge.

The WiModem232 will work with any computer that has a standard RS-232 port. It won't matter what software you use with it. Serial is serial. The WiModem232 emulates a Hayes modem, so if you could plug a Hayes modem into your computer and use it, then you can use this device! Some computers might require a gender changer or special cable - but the same would be true if using a real dial-up modem as well. The WiModem232 is not the same modem that this thread is about. I have had the WiModem for the C64/128 for nearly 2 years and people asked me to make a universal (RS-232) version, so I did and just now released it for the first time. The WiModem232 offers many advantages over the WiFi232 modem that this thread is about, such as: it's FCC/CE approved, ALL of the RS-232 lines (Rx/Tx/RTS/CTS/DTR/DSR/DCD/RI) are supported so you can run a BBS with it, there is 3MB of on board storage that will be used for emulating a micro hard drive, there is a OLED screen option, it uses all surface mount components for small size and low power requirements, and more! This will be a normally stocked item at CBMSTUFF.COM, along with my other products. There won't be a problem getting them.

We have increased the size of the venue to accommodate the sheer number of people who will be attending!

Here is the flyer that is be distributed all over Las Vegas.

If you are coming to just attend, there is no registration necessary. Admission is free. You only need to register if you need to reserve a table. You can do that via the event website: http://www.commodoreretroexpo.com

Sort of... CommVEx was moved to a different location without asking any of the sponsors or vendors for input - which provide the majority of the funding for the event. The new location was horrible, and when a group of us tried to get the event moved back to the original location we were met with extreme resistance (my personal account on commodore.ca was actually banned, etc.) So, all of those funding the event, along with the vast majority of normal participants decided to create an all new event - Commodore Retro eXpo (CRX). CRX will feature a star studded line up for presentations and special guests. We fully expect this to be the largest gathering of Commodore enthusiasts in the U.S. this year. The Kickstarter project "The Commodore Story" will be filming the event and conducting interviews for their DVD/book. Because many people had already booked their hotels and flights for the last weekend in July to attend CommVEx we really had to make CRX the same weekend so people could attend it. Next year's CRX will not be in July - that is the wrong month to have any type of event in the desert! It's just two weeks away now!

CRX is only two weeks away! There are numerous and renowned guest speakers coming to CRX. This may be your only chance in life to meet some of the more famous and influential people in the history of Commodore! Come be part of history, with Wavemstudios on hand to film this event for part of their Kickstarter project "The Commodore story". See yourself in this video when released!

I have made the CRX website live: www.commodoreretroexpo.com

Not sure how I missed this post... so sorry for the late response. As I stated previously, the e586DX upgrade chip replaced a custom logic chip (PEEL) on the EMPLANT board and unlocked two of the VIAs. These were used for the heart of the timing for the PC emulation (and it's odd ball IRQ rate), as well as the BIOS register storage and bus control. Without the chip, the emulation would not run. When PCx was released, it could use the Amiga's timers to emulate what the EMPLANT hardware was doing but that stole CPU time from the emulation to do it. You could optionally select to use the EMPLANT hardware with PCx to make it faster. The "modules" we referred to were the various emulations themselves. The e586DX "module" was the PC emulation, and that came with software and a replacement chip for the EMPLANT hardware. I think you are confused. People have stolen my hardware and software designs, and tried to pass them off as their own products. As a result I have successfully sued (or settled with) several people in the U.S. and overseas for copyright infringement over the last 30 years.