SIO Wifi modem with esp8266

[_The Doctor__]

That's okay it takes me the entire edit window sometimes these days and I still might mix something up.

Welcome to the brave new world. Hopefully we can get it out and edited before others jump on things like this.

 

as far as the case choice goes... if it's made of non metallic plastic... The signal really shouldn't have much problem...

 

Edited October 1, 2019 by _The Doctor__

[Kyle22]

What about this: http://www.summitdata.com/blog/uart-flow-control-rtscts-necessary-proper-operation-wireless-modules/

 

How about sending inverted motor control to CTS and using a delay circuit to allow the small amount of remaining data to come in before doing disk I/O? RTS could easily use interrupt or proceed SIO lines. This should be a simple mod to the R: handler and possibly some software to allow for the slight delay before SIO use.

 

Edit: In other words: Halt the MODEM, wait a half second for any remaining data to come in, get MODEM off of SIO for disk access.

The computer will also check RTS before sending data in case the net is slow.

 

Edited October 2, 2019 by Kyle22

[AtariGeezer]

That's why I bought these:

They have RTS/CTS lines available.  Lately I've been scrounging through my spare parts getting ready to build my SIO2Wifi v2  board that will use Proceed and Interrupt control lines...

 

[Kyle22]

Use the spare (interrupt or proceed) (if you have a spare in your design) to:

 

Detect both ring and carrier detect (if provided by module).

 

How about using an input interrupt to set a couple bits in the R: handler. If no carrier (CD), then ring indicator trips this interrupt to set the ring bit for the status command to read. If there is already active CD then set the other bit. The R: handler would need to reset those bits on open/close. This input can serve dual purpose, as can motor control.

 

 

 

 

 

Edited October 2, 2019 by Kyle22
typo

[AtariGeezer]

18 hours ago, Kyle22 said:

Use the spare (interrupt or proceed) (if you have a spare in your design) to:

 

Detect both ring and carrier detect (if provided by module).

 

How about using an input interrupt to set a couple bits in the R: handler. If no carrier (CD), then ring indicator trips this interrupt to set the ring bit for the status command to read. If there is already active CD then set the other bit. The R: handler would need to reset those bits on open/close. This input can serve dual purpose, as can motor control.

 

My idea is to use proceed for CTS and interrupt for either CD or RI.  The SIO2Wifi v2 board will have a jumper to select which one and the software will have to be manually set since there isn't a spare output on the SIO port to configure that on the SIO2Wifi v2 board (unless I can configure CLOCK OUT for that).

 

Motor Control will also be used for RTS.

 

My 2nd NodeMCU board will be used in a Complete RS-232 WiFi Modem setup...

[Dropcheck]

On 9/30/2019 at 5:03 PM, Dropcheck said:

What I did with the ESP-07 and ESP-01 was to remove and replace the vertical 4pos male headers with RA male headers.

 

The ESP-07 has an external antenna connector.  So using something like this will make it easier to install a ESP device inside a container:

 

IPEX U.FL to SMA jack pin cable and External Antenna

 

As far as a switch between the DB9 and the Wifi that gets a bit harder since when I designed the proto I didn't really think about the conflict problem and my routing meanders haphazardly between the two conjoined circuits.  I'll take a look and see if there is a easy break that can be made in the routing that will allow a SPDT toggle switch to be wired up. 

I haven't found an easy way to insert switch connections on this proto board.  Sorry. ?

 

The easiest method is probably going to be simply leaving the device plugged into DB9 port powered off. 

[AtariGeezer]

Here is the preliminary schematic of my Sio2Wifi v2 using the NodeMCU ESP8266 with RTS / CTS Flow Control...

 

 

 

 

This is the preliminary schematic of my Wifi Modem that I'll be building using the NodeMCU ESP8266 with FULL Handshaking...

 

The final build will be using a single MAX3238 instead of 2 MAX3232's.

 

[Dropcheck]

18 minutes ago, AtariGeezer said:

Here is the preliminary schematic of my Sio2Wifi v2 using the NodeMCU ESP8266 with RTS / CTS Flow Control...

 

 

 

 

This is the preliminary schematic of my Wifi Modem that I'll be building using the NodeMCU ESP8266 with FULL Handshaking...

 

The final build will be using a single MAX3238 instead of 2 MAX3232's.

 

What firmware are you planning on using on the NodeMCU?

[AtariGeezer]

2 minutes ago, Dropcheck said:

What firmware are you planning on using on the NodeMCU?

Zimodem,  it has all the code required for full handshake capabilities.

 

[tschak909]

This would be fantastic to build and ship in the box for PLATOTERM

 

-Thom

[Dropcheck]

Okay, in the first schematic you posted, what handler are you planning to use on the Atari side that will allow control of the interrupt and proceed lines via terminal software?  Rverter I presume, but what version of Rverter handler and Atari terminal software have you tested with?  If you could get the first schematic working, it would be the cheapest and most useful of the two.  ?

 

On the second, I don't see any Atari connection at all, just a physical DB9 port connected through a level shifter to the NodeMCU.  That's fine if the computer it is connected to already has a full blown serial port, but not really useful as a direct connection to the Atari.  I'm not saying it isn't a fine generic Serial2WiFi modem start, but it's not a self contained Atari SIO2Wifi modem.  You'd have to have an 850 or P:R box and change the pinout on the DB9 to be compatible or use a custom cable between to use it on an Atari.  ?

 

A third option would be to have an onboard middleman mcu generating the control signals, handling the response and buffering for the Atari and doing the converting to wifi.  You're almost there with either of the two schematics, but by themselves neither is quite there.  Direct connection to the Atari SIO port, full blown flow control/conversion and WIFI transmission to your router.  ?

 

 

[Dropcheck]

On 9/30/2019 at 2:21 PM, Lastic said:

Today I went to a local electronics store to buy some stuff and noticed they sell these cases also .

Colorwise it's a bit darker than the XE grey but still close enough, it's a tad longer but that is maybe needed for a female SIO connector.

 

 

Still would need a switch to turn off the ESP and the ESP inside a box might not be the best idea for WiFi reception

Just checking to see if you have made any progress on this project.  ?

[Lastic]

54 minutes ago, Dropcheck said:

Just checking to see if you have made any progress on this project.  ?

 

Not much, I have been waiting on parts like Dupont connector and such, finally found a source in the Netherlands which delivers quickly and with cheap shipping so I don't have to wait on a boat coming from China

or pay immense huge import duties.

 

Life has also kept me busy with a broken Windows 10 installation, installing Windows 7 64bit on a 32bit EFI MacPro and resurrecting an Atari ST.

 

 

I would shorten the parallel and serial connectors, cut a piece of their plastic housing (by lack of find angled to PCB connector ones) .

Found a 7 pin Dupont connector for the SIO part but unsure if

 

1. I will have cable to SIO male leave the enclosure at the back 
    
2. or insert a female SIO into the case
   ( could take a female one from a parts only 130XE ? )
   There is still some room in the front for a female SIO connector.

Also need to find a switch to turn off the ESP but unsure how ? 
5V and GND but what about the MotorControl line ?

 

And one more thing waiting on Sleepy to sell me his Star LC10 so I can test the parallel interface and quickly be reminded how much noise printers made.

Edited October 15, 2019 by Lastic

[AtariGeezer]

On 10/14/2019 at 4:37 AM, Dropcheck said:

Okay, in the first schematic you posted, what handler are you planning to use on the Atari side that will allow control of the interrupt and proceed lines via terminal software?  Rverter I presume, but what version of Rverter handler and Atari terminal software have you tested with?  If you could get the first schematic working, it would be the cheapest and most useful of the two.  ?

 

On the second, I don't see any Atari connection at all, just a physical DB9 port connected through a level shifter to the NodeMCU.  That's fine if the computer it is connected to already has a full blown serial port, but not really useful as a direct connection to the Atari.  I'm not saying it isn't a fine generic Serial2WiFi modem start, but it's not a self contained Atari SIO2Wifi modem.  You'd have to have an 850 or P:R box and change the pinout on the DB9 to be compatible or use a custom cable between to use it on an Atari.  ?

 

A third option would be to have an onboard middleman mcu generating the control signals, handling the response and buffering for the Atari and doing the converting to wifi.  You're almost there with either of the two schematics, but by themselves neither is quite there.  Direct connection to the Atari SIO port, full blown flow control/conversion and WIFI transmission to your router.  ?

 

 

1.  The Handler will be using a modified Rverter with the additional code to handle
    the PROCEED and INTERRUPT Interrupts.  Similar to the Pocket Modem software.

 

    PROCEED:    LDA #$01
                STA SH_PROCEED  ; Shadow Register
                PLA
                RTI

    INTERUPT:   LDA #$01
                STA SH_INTRPT  ; Shadow Register
                PLA
                RTI

 

    For starters,  I'll use AModem and modify the M/L routines to handle RTS / CTS
    and Carrier Detect / Ring Indicator.  Later we can modify existing or create
    a whole new terminal program that encompasses the Zimodem API's.

 

2.  Yep, for now it will just be a replacement for Jim Drews' WinModem interface.
    For the atari we have the 850, PRC, MIO, Black Box and ATR-8000 to interface
    to for FULL Flow Control.

 

3.  Yes I agree.   Ideally,  the best SIO solution would incorporate an Intelligent
    Device / Modem that can process XIO Calls for setting up and Detection of the various
    RS-232 signals.  In this case it would support ALL A8's ?

 

 

[a8isa1]

On 10/13/2019 at 11:23 PM, AtariGeezer said:

Zimodem,  it has all the code required for full handshake capabilities.

 

Hi, I don't want to divert long from the topic of this thread but I was wondering if you have successully used the latest v3.5 Zimodem sketch?

 

I've successfully compiled and uploaded it to the Nodemcu dev board (v0.9).  I can see the boot message but it doesn't accept any keystrokes.

 

When I upload the included .bin it works fine, but that's v3.4. 

 

I'd like to try to add RVerter logic right in the firmware.

 

Regards,

 

-SteveS

 

[EDIT]

And of course I plug it in and now it works.  Yesterday it didn't. 

 

Well, I can make connections.  AT&U (update firmware) generates some sort of exception error. AT&H (help) returns only "ERROR"

 

 

Edited October 16, 2019 by a8isa1

[Kyle22]

I can't do RTS/CTS on the 850. R:Verter handler and hardware that does flow control would be great.

 

[AtariGeezer]

42 minutes ago, Kyle22 said:

I can't do RTS/CTS on the 850.

 

Why not?, RTS uses XIO 34 and CTS is read by the STATUS query.

[AtariGeezer]

1 hour ago, a8isa1 said:

Hi, I don't want to divert long from the topic of this thread but I was wondering if you have successfully used the latest v3.5 Zimodem sketch?

 

I'm still using one from last year. Not sure of the version at the moment.

[Kyle22]

4 minutes ago, AtariGeezer said:

Why not?, RTS uses XIO 34 and CTS is read by the STATUS query.

You must first drop out concurrent mode on the 850. It causes dropped characters. I am thinking about a delay circuit that when /MC raises, it keeps the level shifters active until the last byte has been received.

Only then does it release SIO for other operations.

This would require a creative modification to the R:Verter handler.

 

I believe this is do-able.

 

[AtariGeezer]

Ah, okay...

 

Edit: to add to that, PROCEED and INTERRUPT Interrupts could be used with an 850 to signal when to go out of concurrent mode...

Edited October 16, 2019 by AtariGeezer

[a8isa1]

Found the reason to some of my problems with the Zimodem.    My simplistic cable left CTS (on the NodeMCU dev board) unconnected.  The ESP8266 build, when compiling v3.5, has CTS-RTS as the default flow control.  The firmware didn't like CTS unconnected and didn't always recognize keystrokes from the Atari. 

 

I changed the default in the source to flow control disabled.  Now the Atari will always communicate with the Zimodem and the AT&H command now works.

 

AT&U and AT&U6502 still don't allow OTA updates and cause an exception error and restart of the Zimodem.

 

I think I'll change the source (locally) again and enable XON-XOFF handshaking as the default.

 

One other problem I ran into is configuration changes weren't permanent.  Most annoying of these is the SSID and Password for my router.

 

Here's a tip.  If you use the Arduino IDE to compile and upload Zimodem firmware to the ESP8266 don't forget to enable SPIFFS (SPI Flash File System).  The option is under Tools --> Flash Size.  You won't be able to write the config, AT&W, without SPIFFS.

 

-SteveS

Edited October 17, 2019 by a8isa1

[Dropcheck]

2 hours ago, a8isa1 said:

Found the reason to some of my problems with the Zimodem.    My simplistic cable left CTS (on the NodeMCU dev board) unconnected.  The ESP8266 build, when compiling v3.5, has CTS-RTS as the default flow control.  The firmware didn't like CTS unconnected and didn't always recognize keystrokes from the Atari. 

 

I changed the default in the source to flow control disabled.  Now the Atari will always communicate with the Zimodem and the AT&H command now works.

 

AT&U and AT&U6502 still don't allow OTA updates and cause an exception error and restart of the Zimodem.

 

I think I'll change the source (locally) again and enable XON-XOFF handshaking as the default.

 

One other problem I ran into is configuration changes weren't permanent.  Most annoying of these is the SSID and Password for my router.

 

Here's a tip.  If you use the Arduino IDE to compile and upload Zimodem firmware to the ESP8266 don't forget to enable SPIFFS (SPI Flash File System).  The option is under Tools --> Flash Size.  You won't be able to write the config, AT&W, without SPIFFS.

 

-SteveS

As far as the configuration changes are concerned.....

 

I'm not having an issue with the SSID and Password be saved.  Currently using version 3.4.  Are you using the menu system or the AT..... commands?

[a8isa1]

14 minutes ago, Dropcheck said:

As far as the configuration changes are concerned.....

 

I'm not having an issue with the SSID and Password be saved.  Currently using version 3.4.  Are you using the menu system or the AT..... commands?

This was me not understanding the need for enabling SPIFFS in the Arduino IDE.  I don't know if it was the default or if I inadvertently set it to "4MB (no SPIFFS)".  No file system means no place to store the config.  This is not a problem for someone programming the ESP8266 using the supplied .bin.

 

-SteveS

Edited October 18, 2019 by a8isa1

[Dropcheck]

1 minute ago, a8isa1 said:

This was me not understanding the need for enabling SPIFFS in the Arduino IDE.  I don't know if it was the default or if I inadvertently set it to "4MB (no SPIFFS)".  No file system means no place to store the config.  This is not a problem for some programming the ESP8266 using the supplied .bin.

 

-SteveS

Ok ?

[manterola]

My esp01 and esp-07 generic boards crash with a watchdog timer reset error, when I use the 3.5 version. 

My guest is that it has something to do with pin configuration section which is not generic enough, and all those #define are NOT totally correct to be compatible with my model. 

So I am stuck with an old version.. I guess middle August 2017 from guthub if my memory served me well. 

So now I have switched to esp-modem a less ambitious implementation, which it is more simple to modify and still very usable but it does not have all the goddies of Zimodem. 

 

 

 

 

Edited October 18, 2019 by manterola