SIO Wifi modem with esp8266

[AtariGeezer]

Hmmm,  this new code implements CMD and MTR_CTRL as a Flow Control Option,  which means RTS / CTS can not be used with this new scheme...

[mozzwald]

5 hours ago, AtariGeezer said:

Hmmm,  this new code implements CMD and MTR_CTRL as a Flow Control Option,  which means RTS / CTS can not be used with this new scheme...

True, and I did think about this after the fact. It should be possible to move the command/motor control code out of the flow control options.

[tschak909]

Is the goal to have functional RTS/CTS flow control? (please dear god say yes)

 

-Thom

[AtariGeezer]

That's my goal

[tschak909]

So, I've now got my ESP01 development rig working (I found a great little programmer dongle that has a switch which shunts/opens GPIO0 for programming or uart mode, which is VERY handy!), and @mr-atari sent me an ESP01 with a little SIO connector rig (with motor connect/disconnect line), so that I can help him with the R:VERTER RS232 routines.

 

With this, I am going to experiment a bit with writing some new firmware, and have been doing a differential code analysis of two codebases:

 

 

https://github.com/dhansel/WifiModem

https://github.com/bozimmerman/Zimodem

 

These two were chosen because of the overlap of desired features versus relative complexity of the code, to see what parts are truly important for a WIFI modem.

 

Ideally, for maximal compatibility impact, the firmware should take advantage of Atari specific bits, can we, for example:

 

* Power the wifi modem on to have the same handler loader behavior as an 850 (respond to D1 poll, respond to type 3 poll), and when received, send @mr-atari's enhanced R-ESP handler (which works _REALLY_ well at high speeds and allocates a larger receive buffer), and then disconnect into R:Verter mode, while:

* also having RTS/CTS when in R:VERTER mode?

This would be a solid goal, and would provide maximum compatibility with every terminal program, while providing the needed path to keeping things stable at higher speeds.

 

One of the nice aspects of dhansel's firmware, is that when it is first powered on (and the configuration data is empty), it asks to be configured.

 

"I need to be configured, press C to configure." <repeat every 2 secs>

 

Once you press C...

 

"I have found the following networks:"
"Bob"
"SamsHouse"

"AtariCasa"

"1541StillLoading"

 

Enter the SSID you want to connect to: AtariCasa
Enter the password: *********

 

Connected.

 

Now you can enter modem commands.

I have a list of things I want to add to make this a very nice out of the box experience, including prompts to indicate your IP and MAC address,

as well as indicating that you can open a web browser to tweak things,

as well as having commands to turn on/off TELNET IAC processing. (and to have IAC processing off by default)

 

I'll be slowly working through this to get my head familiar with writing this firmware, and am glad I finally got to this in my project pile, I had been meaning to work on this for over a year, since I started working on IRATA.ONLINE (but was _way_ too busy writing terminals!)

 

I also have been talking with @mozzwald to get one of his rigs, as well.

 

@mozzwald Hopefully with this, I can help cross-pollinate and make the firmware better, and we can come up with something that will work REALLY well for Atari users.

 

-Thom

Edited October 22, 2019 by tschak909

[mozzwald]

55 minutes ago, tschak909 said:

I also have been talking with @mozzwald to get one of his rigs, as well.

 

@mozzwald Hopefully with this, I can help cross-pollinate and make the firmware better, and we can come up with something that will work REALLY well for Atari users.

 

-Thom

I'm currently experimenting with the gpio's on the nodemcu (esp12e/f) to include connection with the proceed and interrupt SIO lines. I think those are what someone was going to use for a new Rhandler. 

 

It's a bit tricky picking the gpios to use as some are used for bootloader / flashing.

[manterola]

Hi Thom,

I am very glad that yo get involved in this, and that this topic is getting a lot of attention and hours of work by several members. That is great!

Now, The problem with esp01 is the number of IOs available (but it is very convinient and cheap otherwise). You can maybe have 1 (if you repurpose the i/o used to start the esp) , and I am not sure if that's possible. 

That's why I did the mtrctrl signal thing via hardware.

So the hardware solution was using the mtrctrl to "lift" the esp from the sio bus to allow the other devices to talk, leaving the sio "spinning the wheels" in the air. 

The software version of this is to use one esp input to read the mtrctrl signal and do whatever you have to do by software. 

The good thing about doing it by software is that the esp still can talk when mtrctrl is not asserted, that way the esp can respond to type 0 and maybe other polling. That feature is not possible with my current configuration: the hardware solution. 

I repurposed the input use for the esp01 to start, as an output to turn on a LED. So maybe, if the esp01 start quick enough, it can be ready to answer to polling, and then read the mtr ctrl signal by using that input pin.

ps: Check esp-modem and some of the forks in github, as well

Edited October 22, 2019 by manterola

[Dropcheck]

On 10/18/2019 at 9:26 PM, mozzwald said:

I've been fiddling around with my nodemcu (esp8266) board, Zimodem firmware and the atari and have been successful with using the modem while allowing the atari to still use the sio bus with minimal parts. I have a simple fet based level shifter (wiring diagram below, amazon part) that adds the motor control and command lines to nodemcu inputs. When either line is asserted, the Zimodem firmware allows other devices to communicate on the bus and ignores the transmission. 

 

The modified firmware adds a new Flow Control type (FCT_AMTRCTL) which must be enabled for it to work. If you wish to flash the firmware to a previously used zimodem/esp board you should format the SPIFFS before flashing so that the new flow control will be selected by default, otherwise you will have issues with it not communicating as it will be set for some other flow control scheme (this issue bit me a couple times during testing). 

 

The modified Zimodem (v3.5) firmware is in my github (atari branch) at https://github.com/mozzwald/Zimodem/tree/atari

How did you get the Arduino IDE to recognize this board?

 

I've got one in my parts bin and a four channel level shifter, but I don't see the board listed in the Arduino IDE v1.8 to choose from.

[mozzwald]

38 minutes ago, Dropcheck said:

How did you get the Arduino IDE to recognize this board?

 

I've got one in my parts bin and a four channel level shifter, but I don't see the board listed in the Arduino IDE v1.8 to choose from.

I can't check for sure til later when I get home. If you have the esp8266 board defs installed, its one of them. Iirc, it does have nodemcu in the name, likely the latest version number.

[tschak909]

If it's a ESP-12E/12F then use NodeMCU 1.0

 

-Thom

[AtariGeezer]

1 hour ago, Dropcheck said:

How did you get the Arduino IDE to recognize this board?

 

I've got one in my parts bin and a four channel level shifter, but I don't see the board listed in the Arduino IDE v1.8 to choose from.

Check out page 4 on how to do this...

esp8266-V10.pdf

[mozzwald]

10 hours ago, mozzwald said:

I'm currently experimenting with the gpio's on the nodemcu (esp12e/f) to include connection with the proceed and interrupt SIO lines. I think those are what someone was going to use for a new Rhandler. 

 

It's a bit tricky picking the gpios to use as some are used for bootloader / flashing.

Here is my fixed and updated wiring diagram. I tried shifting some of the SIO lines to different GPIO's but had problems with the Nodemcu booting. This setup boots every time. Note, you must disconnect it from SIO to use the USB for programming (with interrupt/proceed connected). I could not get it to boot into programming mode when connected to SIO (Atari on or off). Some of the flash chip pins are shared with GPIO's and are likely being pulled down preventing programming mode. I don't really know if the Interrupt or Proceed lines work without pull up/down resistors, they are currently always high. Is there a way to toggle those from BASIC for testing?

Is this a good plan: use the Nodemcu board as-is and create a carrier board with the level shifting and SIO connections? Basically have a plug in SIO Modem dongle.

Edited October 23, 2019 by mozzwald
typos

[Dropcheck]

8 minutes ago, mozzwald said:

Here is my fixed and updated wiring diagram. I tried shifting some of the SIO lines to different GPIO's but had problems with the Nodemcu booting. This setup boots every time. Note, you must disconnect it from SIO to use the USB for programming (with interrupt/proceed connected). I could not get it to boot into programming mode when connected to SIO (Atari on or off). Some of the flash chip pins are shared with GPIO's and are likely being pulled down preventing programming mode. I don't really know if the Interrupt or Proceed lines work without pull up/down resistors, they are currently always high. Is there a way to toggle those from BASIC for testing?

Is this a good plan: use the Nodemcu board as-is and create a carrier board with the level shifting and SIO connections? Basically have a plug in SIO Modem dongle.

That's what I'm considering.......

[tschak909]

hopefully can be made small enough to cram into a box with a cart and manual.

-Thom

[Dropcheck]

11 hours ago, mozzwald said:

Here is my fixed and updated wiring diagram. I tried shifting some of the SIO lines to different GPIO's but had problems with the Nodemcu booting. This setup boots every time. Note, you must disconnect it from SIO to use the USB for programming (with interrupt/proceed connected). I could not get it to boot into programming mode when connected to SIO (Atari on or off). Some of the flash chip pins are shared with GPIO's and are likely being pulled down preventing programming mode. I don't really know if the Interrupt or Proceed lines work without pull up/down resistors, they are currently always high. Is there a way to toggle those from BASIC for testing?

Is this a good plan: use the Nodemcu board as-is and create a carrier board with the level shifting and SIO connections? Basically have a plug in SIO Modem dongle.

I would like to make a carrier adapter for the level shifter board.  Can you tell me the over all dimensions and the width between the two rows of holes.  I'm assuming the hole spacing is 2.54mm(.1")

[mozzwald]

7 minutes ago, Dropcheck said:

I would like to make a carrier adapter for the level shifter board.  Can you tell me the over all dimensions and the width between the two rows of holes.  I'm assuming the hole spacing is 2.54mm(.1")

The 8 channel one I have is 14mmx28mm, 2.54mm spacing. Rows are roughly 10.25mm spacing (uses up 5 rows on a breadboard)

[Dropcheck]

5 minutes ago, mozzwald said:

The 8 channel one I have is 14mmx28mm, 2.54mm spacing. Rows are roughly 10.25mm spacing (uses up 5 rows on a breadboard)

Thanks,

 

Working on a combined carrier board for the level shifter and NodeMCU.  Should have a schematic and 3d model up in an hour or so.  ?

[AtariGeezer]

This is the layout I'll use.  The 2 level shifters mount right under the NodeMCU

 

 

And the updated schematic

 

 

Edited October 23, 2019 by AtariGeezer

[manterola]

I might be wrong but what I see from the schematics is that Atari control esp8266 tranmission and reception. But As I mentioned in my late post, the idea of MtrCtrl dictating when the TX and RX esp8266 lines are connected to the SIO bus won't allow us to make this SIO-Wifi device to answer (at least) Type 0 polls.

The device itself (the esp8266) should be able to "lift" TX and RX from the sio bus, not the Atari.

just my 2 cents

Edited October 23, 2019 by manterola

[Dropcheck]

Okay here's two versions:

 

Mozzwald if you could check the schematic and see if I missed something.  The NodeMCU sits in the female sockets with the usb towards the bottom.

 

TH

 

And SMT

 

NodeMCU2SIOTH.pdf NodeMCU2SIOSMT.pdf

Edited October 23, 2019 by Dropcheck

[a8isa1]

On 10/21/2019 at 9:00 AM, mozzwald said:

 

If you could try doing a file transfer and report your results it would be much appreciated. I can do small files ~15k or less but anything larger never starts and just times out using Bob Term.

.

No success at all at file transfers.   A few blocks and a lot of NAKed responses.   I feel I'm doing something wrong, like something forgotten since the '80s.

 

I'ved tried between the Atari and a BBS (Darkforce BBS), between Atari and Altirra, between Atari and minicom (linux terminal emulator and using an unmodified Zimodem).  I used ICE-T and Bobterm on the Atari side.   I found the S45 register.  Setting this to 0 would seem to enable pure binary transfers.

 

-SteveS

Edited October 23, 2019 by a8isa1

[tschak909]

Many BBSes do NOT do TELNET IAC negotiations. They talk to the raw socket.

 

This means that any time you receive an $FF, if another $FF is not received, then it is assumed that the next few bytes are part of an IAC sequence, and your MODEM will try to negotiate it. This typically happens at the BEGINNING of a connection, however, since there ARE IAC commands that can happen AFTER the initial negotiation, there is no way to tell the other end to ignore further IAC responses.

 

The side effect of this is, if you're using a raw connection, any $FF's will cause your modem's IAC interpreter to engage.

 

To get around this, you HAVE to turn on your modem's RAW mode.

 

The firmware I am piecing together does this, by default, as unless you are jumping into e.g. a UNIX system, you'll never run into this.

 

-Thom

[mozzwald]

17 minutes ago, Dropcheck said:

Okay here's two versions:

 

Mozzwald if you could check the schematic and see if I missed something.  The NodeMCU sits in the female sockets with the usb towards the bottom.

 

TH

 

And SMT

 

NodeMCU2SIOTH.pdf 39.82 kB · 3 downloads NodeMCU2SIOSMT.pdf 25.3 kB · 2 downloads

Looked at the thru hole schematic and I think you have the mtr ctrl and cmd lines swapped like in my first wiring diagram. I'll hafta verify again with my actual hardware again when I get home.

 

30 minutes ago, manterola said:

I might be wrong but what I see from the schematics is that Atari control esp8266 tranmission and reception. But As I mentioned in my late post, the idea of MtrCtrl dictating when the TX and RX esp8266 lines are connected to the SIO bus won't allow us to make this SIO-Wifi device to answer (at least) Type 0 polls.

The device itself (the esp8266) should be able to "lift" TX and RX from the sio bus, not the Atari.

just my 2 cents

As long as the esp8266 can see what is happening on the motor control and command lines, it can decide when to write or read the datain/dataout pins. So, if the esp8266 is supposed to be D1 and it reads a command for D2, it can ignore it. Likewise, it can respond to a D1 command. It's just a matter of making the code do that. Atarigeezer's hardware version which uses motor control to physically disconnect the tx/rx lines will not work like this.

[manterola]

Adding to what Thom said, depending on the firmware you might be able to start a raw connection without TELNET IAC negotiation. That way you will be able to do file transfers. For zimodem, for example, you need to "dial" with ATD xyz.zzz.xy   (without the T) to create a raw connection.

Or create and address book entry and configure it , with "telnet" support.

[manterola]

2 minutes ago, mozzwald said:

As long as the esp8266 can see what is happening on the motor control and command lines, it can decide when to write or read the datain/dataout pins. So, if the esp8266 is supposed to be D1 and it reads a command for D2, it can ignore it. Likewise, it can respond to a D1 command. It's just a matter of making the code do that. Atarigeezer's hardware version which uses motor control to physically disconnect the tx/rx lines will not work like this.

I agree, AtariGeezer schematics implements the hardware version: it uses mtr ctrl to disconnect tx rx (and proceed and interrupt). I thought it was a coordinated effort... sorry