Suggestion to aid Videotex users.
#1
Hi

I have been using the WiModem232 with OLED to access the UK'sTELSTAR videotext system and it works very well. However, one thing that would help enormously when setting up a call to a system such as this, is to interpret the character 0x5F as a CR when in command mode.

Videotext systems do not use <CR> as a line terminator but use 0x5F (#) instead. This means that it is often not possible to establish a call using something like ATDS=2<CR> when using a viewdata terminal. This means that a call has to be established using a traditional terminal before connecting/reloading the viewdata terminal. Interpreting a 0x5F as a <CR> when in command mode would solve this.

If you wanted to go a stage further, what about an AT setting that configures the modem to auto-connect to the first stored number when first turned on.

Just a suggestion for your consideration. Great work on the device.

Details of TELSTAR are at https://glasstty.com/wiki/index.php/The_...tex_System
Reply
#2
::edit:: Well... it seems that although I do support the S-Registers to change CR, LF, etc. I don't actually use the S-Reg value itself - it's still hard coded from the original firmware.  I will look at changing that and updating the manual to show the various S-Registers.

Thanks for the feedback.  I actually have ALL of the various functions (CR, LF, BEL, etc.) as standard Hayes variables like a real Hayes modem.  You can change these with S-registers.  See the manual for more details. 

To change CR to 0x5F you would use this command:

ATS3=95<RETURN>

I have thought about the auto-connect feature.  I will look into this.
Reply
#3
(01-22-2019, 10:03 AM)admin Wrote: ::edit:: Well... it seems that although I do support the S-Registers to change CR, LF, etc. I don't actually use the S-Reg value itself - it's still hard coded from the original firmware.  I will look at changing that and updating the manual to show the various S-Registers.

Thats great, it's good to be able to change these things. The only thing I would add is that by supporting both rather than one or the other means that the modem can be configured with normal terminal software or videotex client without a change. Could I politely suggest that an 'ALT CR' S register be added and checked for so that an alternative CR can be supported.

I am the developer of TELSTAR and always recommend your modem as one of the solutions. To be able to configure the device from either comms client without a change would be awesome.

Like I said, just a suggestion. Keep up the good work.
Reply
#4
The WiModem's emulate the Hayes specification, which allows for a single character for CR, LF, and BS.  I am not sure what you mean by an alternate CR?  Do you mean supporting both 0x0D (normal CR) and 0x5F?  The problem with that of course is that 0x5F is a valid ASCII character (the underscore "_" symbol), which is used during BBS'ing.

Is this an input only thing that you need to the WiModem to understand, or also an output?
Reply
#5
(01-22-2019, 03:22 PM)admin Wrote: The WiModem's emulate the Hayes specification, which allows for a single character for CR, LF, and BS.  I am not sure what you mean by an alternate CR?  Do you mean supporting both 0x0D (normal CR) and 0x5F?  The problem with that of course is that 0x5F is a valid ASCII character (the underscore "_" symbol), which is used during BBS'ing.

Is this an input only thing that you need to the WiModem to understand, or also an output?

What I mean is that you use 2 S registers, one for a normal CR (with 0D) and an 'alternative one' (with 5F). Both the normal and alternative ones are valid when in command mode i.e. when issuing AT commands. However, when online, the 'alternative' CR is ignored and 5F is treated as a normal underscore. There are many unused S registers that could be utilised for this. This only needs to be an input as it's simply to configure the modem using AT commands and videotex software displays normal CR/LF correctly.

By doing this, it saves the user having to load terminal software to change the CR S reg before using videotex software, and then having to do the reverse when wanting to access a BBS.
Reply
#6
OK, so let me get this right.  You need 0x5F to also function as the standard CR (0x0D), but only in COMMAND mode?  I don't need an alternate CR for doing this, and I would never make any new S-Register that was not a valid Hayes standard.  Instead, I could make a WiModem specific ('*' command) that enabled/disabled the feature.  Something like AT*TS1 to enable it and AT*TS0 to disable it.  What I don't know is if you need 0x0D output to the terminal (from the WiModem) or 0x5F, or both?

I am adding the Autodial feature.  A new WiModem specific command (AT*Ax) will be created.   Where 'x' is 0 for disabled (default), or 1 for enabled.  So, when you power up the modem and the router is found, it will attempt to connect to the first phone book entry when this feature is enabled.  Once the connection is lost it requires a power-cycle for this to happen again automatically.
Reply
#7
(01-23-2019, 09:28 AM)admin Wrote: OK, so let me get this right.  You need 0x5F to also function as the standard CR (0x0D), but only in COMMAND mode?  I don't need an alternate CR for doing this, and I would never make any new S-Register that was not a valid Hayes standard.  Instead, I could make a WiModem specific ('*' command) that enabled/disabled the feature.  Something like AT*TS1 to enable it and AT*TS0 to disable it.  What I don't know is if you need 0x0D output to the terminal (from the WiModem) or 0x5F, or both?

I am adding the Autodial feature.  A new WiModem specific command (AT*Ax) will be created.   Where 'x' is 0 for disabled (default), or 1 for enabled.  So, when you power up the modem and the router is found, it will attempt to connect to the first phone book entry when this feature is enabled.  Once the connection is lost it requires a power-cycle for this to happen again automatically.

Sounds good. To answer the question only 0x0D needs to be returned to the terminal.

There is one other minor issue that I discovered during testing viewdata. Some viewdata clients e.g. Antelope on the Apple II only work using 7 bits even parity, 1 stop (this was the viewdata standard), currently this prevents them from configuring the modem. I wonder if you could clear the high bit on any chars received when in command mode. This will allow these applications to configure the modem and make calls/connections etc.

Please don't take any of these comments as any kind of criticism, the WiModem is a great product, well done.
Reply
#8
OK, thanks for confirming the response by the WiModem only needs to send 0x0D.

The problem with stripping the high bit in command mode is that you might have a router name or password that has the high bit set, at which point you could not connect to your router. I would think the parity issue would be more of a problem. Standard Hayes modems all used 8N1, not 7E1. I suppose I could add stripping the high bit if TELSTAR mode was enabled. Would that work for you? This would mean that users would have to make sure that their router name/password was using the lower 128 characters.

I am not taking anything as criticism. I try to add all user requests when there is a valid reason for doing so.
Reply
#9
(01-24-2019, 10:21 AM)admin Wrote: OK, thanks for confirming the response by the WiModem only needs to send 0x0D.

The problem with stripping the high bit in command mode is that you might have a router name or password that has the high bit set, at which point you could not connect to your router.  I would think the parity issue would be more of a problem.  Standard Hayes modems all used 8N1, not 7E1.  I suppose I could add stripping the high bit if TELSTAR mode was enabled.  Would that work for you?  This would mean that users would have to make sure that their router name/password was using the lower 128 characters.

I am not taking anything as criticism.  I try to add all user requests when there is a valid reason for doing so.

Telstar mode would be awesome. I guess the device could be configured before T* mode was invoked? Either way this would work well. Any anomalies in setting a password etc could be documented in the Telstar docs.
Reply
#10
Ok, so I have released an open BETA version (v3.01).  You can try it by typing AT*BETA {RETURN}.  This will download and flash the board with the beta version.  If you want to go back to the previous (v3.00) release, type AT*UPGRADE {RETURN}.   New command summary:

TELSTAR mode:

AT*TSx, where 'x' is either 0 or 1
AT*TS1 - enable TELSTAR mode
AT*TS0 - disable TELSTAR mode

When TELSTAR mode is enabled the WiModem's COMMAND mode will accept either 0x0D or 0x5F as the CR character for incoming bytes, and strip the upper most bit of every incoming byte.

Autodial:

AT*Ax, where 'x' is either 0 or 1
AT*A1 - enable Autodial
AT*A0 - disable Autodial

When Autodial is enabled the WiModem will attempt to connect to the first phonebook entry on power up.

Let me know if the TELSTAR mode works correctly.  If not, let me know what needs to change.  If so, I will make this an official release.

Note... if for some reason you are stuck in the connected mode when powering up and the keyboard does not appear to work (like in the wrong baud rate!), you can always do a RESET as described in the manual.  That will turn off the Autodial feature.  I ran into this until I figured out my code worked fine and the WiModem was set to a different baud rate than my terminal program!
Reply




Users browsing this thread: 1 Guest(s)