AtariGeezer Posted September 15, 2018 Share Posted September 15, 2018 geezer your board has other pins exposed on the reset side of pin rows that might allow for hardware flow control possibly to exist or be added, can you float that idea around in some of it's hobby support experimentation sites and see if a hack and firmware exists already or could be created? Flow control is of no concern to me at the moment. These setups work just fine connecting to BBS's online and other TCP Servers I've tried... Nix it... ... Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 15, 2018 Share Posted September 15, 2018 (edited) try to download last starfighter from resistance cove at different baud rates... 9600 4800 2400 etc. and see if it succeeds with no data ending up on bobterm screen during transfer and then try to run the game after each download.... then try to upload something... see if it works okay on not.... (best to try when interwebs are not overloaded... ) Edited September 15, 2018 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted September 15, 2018 Share Posted September 15, 2018 I've been running Zimodem firmware (now version 3.4beta). I had been trying to get the ASCII animation ("star wars") of towel.blinkenlights.nl (telnet) to run via the esp8266 dev board (nodemcu v0.9 clone). I had assumed my difficulties were that I had been missing some setting or feature of the Zimodem firmware. I had been BBSing using bobverter driver at 19,200. I thought successfully. It didn't occur to me to lower the speed until Yesterday. 9600 improved things greatly but at 4800 the animation runs without getting scrambled (dropped chacters?) until my session times out and disconnects me, at about 1 hr, 40 mins. I love ICE-T (2.80 alpha 7) even more now! No, this is nothing productive. Just one more fun thing to do with the Atari. Sorry, I don't have a suitable video camera to show this in action. -SteveS p.s. to view the video at intended speed just use a modern computer and telnet towel.blinkenlights.nl 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted September 15, 2018 Share Posted September 15, 2018 I know that both uploads and downloads do work correctly on my board. I recommend 9600,8,N,1 using X-Modem 1K or Y-Modem. This was tested using WIRED Lantronix devices. If you're having trouble, try a wired device first to see if it works. 1 Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted September 15, 2018 Share Posted September 15, 2018 I know that both uploads and downloads do work correctly on my board. I recommend 9600,8,N,1 using X-Modem 1K or Y-Modem. This was tested using WIRED Lantronix devices. If you're having trouble, try a wired device first to see if it works. I'm now suspecting it the Rverter driver that's limiting me. The board itself breezes through the ASCII animation at 38.4 when connected to my laptop (running minicom terminal emulator). Animation runs at higher speeds without scrambling but it does become hurky-jerky. I don't own any wired devices for connecting to the internet. -SteveS 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 16, 2018 Share Posted September 16, 2018 (edited) Actually, when downloading from kyles BBS you should select M to mark whatever file you want even if it's a single file... then use Y to download it. This lets the BBS select whatever works best for the download and it works for me every time. using other choices have mixed or worse results... I tried it used hardware flow and it was fine, I tried it with software flow control with pass thru and it worked just fine that way as well... he was locked at 9600 and I was at 2400 to see if it would mess up, it didnt... game plays fine... Edited September 16, 2018 by _The Doctor__ 2 Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted September 16, 2018 Share Posted September 16, 2018 (edited) Have this coming in hopefully by the end of next week. Big thing about this is the ability to add an external Antenna and it is switchable between programable and UART modes. It is a little more expensive, but not much. External antennas run around the same as the module.This is WiFi serial transceiver module, based on ESP8266 SoC.The SOC has Integrated TCP/IP protocol stack.It is TTL serial communication interface and its parameters can be set by AT command. It is widely used in networking, smart home project when it is connected to the wifi router. It can be used for remote monitoring of home appliances, bedroom temperature and humidity, controlling home appliances and smart car by the mobile phone.Arduino UNO R3 and the compatible board can directly connect to this module.Interface logic voltage: 3.3V / 5V compatible(On-board level shift circuit)Working voltage: 4.5V - 5.5V (On-board 3.3v LDO Regulator)Working current: 240mA(MAX)Serial port baud rate: 115200 (default), can be modified to other values by AT commandSerial communication format: 8N1On-board reset buttonOn-board switch to select UART mode or firmware update modeAntenna Type: Built-in ceramic antenna is available, and you can also use an external antenna.Wireless Network Mode: station / softAP / SoftAP + stationWireless criteria: 802.11 b / g / nWIFI @ 2.4 GHz, support for WPA / WPA2 security modeIt is very easy to design projects by AT commandApplications: Home automation, sensor networks, industrial wireless control, smart car.Package Included:1PC*Serial Wifi module Edited September 16, 2018 by Dropcheck Quote Link to comment Share on other sites More sharing options...
Stefan Both Posted September 16, 2018 Share Posted September 16, 2018 Q1 and Q2 are the level shifters. That's a funny thing. This version covers the most of our needs. Please keep us informed. Stefan Quote Link to comment Share on other sites More sharing options...
Stefan Both Posted September 16, 2018 Share Posted September 16, 2018 Actually, when downloading from kyles BBS you should select M to mark whatever file you want even if it's a single file... then use Y to download it. This lets the BBS select whatever works best for the download and it works for me every time. using other choices have mixed or worse results... I tried it used hardware flow and it was fine, I tried it with software flow control with pass thru and it worked just fine that way as well... he was locked at 9600 and I was at 2400 to see if it would mess up, it didnt... game plays fine... I wasn't able to download a file. But now I know how to do it, it should work also. Let me guess: for uploading file you have to select it with "M" too? Stefan Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 16, 2018 Share Posted September 16, 2018 (edited) I used bobterms batch upload and I might have used fmodem once or twice as well. the esp needs to use a firmware that acts on software flow control and pass thru. I can use no flow control only when the interwebs are being fast and with low latency or jitter..... This is a rarity.... remember wireless also may add some latency.... my wired latency is 11ms on average, could be 7 could be 30... go wireless and depending on the neighbor hood it could be 50 could be 160 or more! Flow control evens some of this out and the protocol wont time out. So long as things don't get too far out of hand it works reliably enough... Windowed protocols can get dicey with 4 k (fmodem packets etc.) since it can be almost 3 or more tcp packets to deliver, so an error w/retry can be a mess. This is why I go with Y-modem batch mostly. I hope the explanation of picking the protocol to match the transport makes sense.... We could always do a direct chat you atd, I ata... then try different send and receives.... you are across the ocean, so more latency exists... I been uploading and downloading for some time.. (there is a bit of error correction already in the transport across the internet) time for a new upload download method to be written perhaps.. Might be redundant error checking etc going on... Edited September 16, 2018 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted September 16, 2018 Share Posted September 16, 2018 Windowed protocols can get dicey with 4 k (fmodem packets etc.) since it can be almost 3 or more tcp packets to deliver, so an error w/retry can be a mess. This is why I go with Y-modem batch mostly. I hope the explanation of picking the protocol to match the transport makes sense.... I think for a software flow control solution to work (in text mode), we'd need small packets like 8-16 bytes and a status return byte of a CRC of that packet like XModem. Just sending XON / XOFF could get misinterpreted if an ATASCII animation is sent. Some of these ESP Modules have RTS / CTS exposed that we could use in a hardware flow solution. The R-Verter could accommodate this through the use of VPRCED ($202) and the Motor-Control lines. All through the SIO Port only just needing an additional transistor circuit. The Motor-Control line would be dual purpose in this application. 2 Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted September 16, 2018 Share Posted September 16, 2018 I have a question: For those who have added RVerter logic to their modules, ESP-1 or nodeMCU/lolin/wemos dev board, have you confirmed that the wifi modem that you created plays nice with real drives? -SteveS 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 17, 2018 Share Posted September 17, 2018 (edited) remember x on x off generally only affects client to local modem and remote host if the host supports it. only one side generally assert the control not the other... what does this mean? I call a bbs and select a break time movie, the movie will play just fine without pausing on my screen... it won't do a thing to me, and generally the application on the local machine should de assert flow stop on my pressing any key and pass that key when using a terminal, Some BBS programs do not send the echo of characters after control S is sent, but will still get all typed characters including the control s and output them on control q or terminal protocol sending the go code.. knowing this If I send control s in a movie or graphic message in my post on a bbs, I simply send the control s type control q and the delete the control q and replace it with the rest of whatever I wish to send... It will not harm anything but is an extra step.... When using a u/l d/l protocol... most are aware of soft flow on both end and will perform binary transfer passing the flow control characters without acting on them... only the client of a transfer can pause anything. not the sender of the data using a protocol. the protocol generally will not echo anything the receiver of the file sends. Even in ascii mode that is suppose to be the behavior... so when my computer sends control s during a download..perhaps to save part of what is coming in.. it can tell my device to stop... it can tell the host sending to stop... it will not be added to the returning stream. when I send control q it all comes to me... if there is a control s in the file I am downloading... the protocol knows this and since it's incoming my device will pass it right on through... nothing added nothing lost nothing stopped. he who is feeding generally can be stopped, the eater holds his hand up, and food stops coming, he swallows (save to disk et) and can put his hand down for more. The host sending the file does not have to tell the eater to stop eating.... he simply doesn't give any more food.... got it? some people didn't quite get the hang of it so the additional step was taken later to do a break (timed pause in data) followed by x on x off... making this a different animal all together *Edit *- I called the BBS to veriy my remembery.. it worked exactly as I outlined... A deadlock can happen if both sides assert software flow control at their local device. This also why most BBS systems and hosts do not used software flow control on their devices but rather none... or hardware flow for their devices. The software should be intelligent enough to handle flow control in different ways based on what it's doing. As if both sides are trying to use software flow control to their local device.. they can end up stopping themselves on echo, especially if there is no soft control pass though. As a client your safe to use software flow control... as a server or host... not so much. Edited September 17, 2018 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted September 17, 2018 Share Posted September 17, 2018 Yeah, that's how it's supposed to work, but I do remember a situation in the past where it interfered in comms... Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 17, 2018 Share Posted September 17, 2018 (edited) yep, bad things happen when something gets missed... that's why you have to use good software or choose hardware flow control as your first choice.... If a bbs. server host deadlocks... and you don't have hardware... you can select local only soft control... but it will kill your ability to type control s and q in in a message.... etc. if they were silly enough to have software flow as a /host /bbs/ server and wish to send atascii movies or posts with control s in them, they must end the movie with or message with control Q..... some old time BBS would send a control Q end of many sent things....just to be sure. Edited September 17, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted September 17, 2018 Share Posted September 17, 2018 remember x on x off generally only affects client to local modem and remote host if the host supports it. only one side generally assert the control not the other... what does this mean? I call a bbs and select a break time movie, the movie will play just fine without pausing on my screen... it won't do a thing to me, and generally the application on the local machine should de assert flow stop on my pressing any key and pass that key when using a terminal, Some BBS programs do not send the echo of characters after control S is sent, but will still get all typed characters including the control s and output them on control q or terminal protocol sending the go code.. knowing this If I send control s in a movie or graphic message in my post on a bbs, I simply send the control s type control q and the delete the control q and replace it with the rest of whatever I wish to send... It will not harm anything but is an extra step.... When using a u/l d/l protocol... most are aware of soft flow on both end and will perform binary transfer passing the flow control characters without acting on them... only the client of a transfer can pause anything. not the sender of the data using a protocol. the protocol generally will not echo anything the receiver of the file sends. Even in ascii mode that is suppose to be the behavior... so when my computer sends control s during a download..perhaps to save part of what is coming in.. it can tell my device to stop... it can tell the host sending to stop... it will not be added to the returning stream. when I send control q it all comes to me... if there is a control s in the file I am downloading... the protocol knows this and since it's incoming my device will pass it right on through... nothing added nothing lost nothing stopped. he who is feeding generally can be stopped, the eater holds his hand up, and food stops coming, he swallows (save to disk et) and can put his hand down for more. The host sending the file does not have to tell the eater to stop eating.... he simply doesn't give any more food.... got it? some people didn't quite get the hang of it so the additional step was taken later to do a break (timed pause in data) followed by x on x off... making this a different animal all together *Edit *- I called the BBS to veriy my remembery.. it worked exactly as I outlined... A deadlock can happen if both sides assert software flow control at their local device. This also why most BBS systems and hosts do not used software flow control on their devices but rather none... or hardware flow for their devices. The software should be intelligent enough to handle flow control in different ways based on what it's doing. As if both sides are trying to use software flow control to their local device.. they can end up stopping themselves on echo, especially if there is no soft control pass though. As a client your safe to use software flow control... as a server or host... not so much. I personally witnessed this today. Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted September 17, 2018 Share Posted September 17, 2018 (edited) I have a question: For those who have added RVerter logic to their modules, ESP-1 or nodeMCU/lolin/wemos dev board, have you confirmed that the wifi modem that you created plays nice with real drives? -SteveS Add a Diode. Edit: No, it's more than a diode for you guys that used that WRONG schematic. You must tri-state your device off of SIO during transactions un-related to the R: device. This requires a chip to get your device on / off the SIO Buss as required.. Edited September 17, 2018 by Kyle22 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted September 17, 2018 Share Posted September 17, 2018 I'm now suspecting it the Rverter driver that's limiting me. The board itself breezes through the ASCII animation at 38.4 when connected to my laptop (running minicom terminal emulator). Animation runs at higher speeds without scrambling but it does become hurky-jerky. I don't own any wired devices for connecting to the internet. -SteveS R:Verter is, I think the best solution. It is Pure PoKey performing at its finest. It will go fast, but we MUST get some kind of hardware flow control going. This should be an easy project. Use SIO + a JoyPort for the control lines. I have been saying this for a long time. This is CHEAP, EASY, and I know it will work. Prove me wrong? Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted September 17, 2018 Share Posted September 17, 2018 (edited) Add a Diode. Edit: No, it's more than a diode for you guys that used that WRONG schematic. You must tri-state your device off of SIO during transactions un-related to the R: device. This requires a chip to get your device on / off the SIO Buss as required.. Other than my early schematics when I was going back and forth with Both on his initial design I'm not sure what WRONG schematics you are referring too. I did post some schematics much later on wanting verification when I was having trouble getting things to work, but I was quite clear then that I wasn't sure and wanted conformation. I didn't get any. I have proved both Rverter II, Both's final and AtariGeezer's v2.0 schematics work. Please tell us what schematics are WRONG. And if you have a schematic that is the cat's meow, then please post that. It would make it easier on all of us. Edited September 17, 2018 by Dropcheck Quote Link to comment Share on other sites More sharing options...
mr-atari Posted September 18, 2018 Share Posted September 18, 2018 Small change of my layout. Thanks for the tips. :-) Added a 4050 that is controlled by Motor_GO to switch the 4050 (buffer) on/off. The ESP is on when the atari is on, so it keeps it's connection, when set. Motor_GO only controls the flow of data. Enable/Disable. Cheap way to include a buffer and I have 4050's enough.... Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 18, 2018 Share Posted September 18, 2018 According to the data sheet for the ESP-01, there are two GPIO pins exposed from the 8266, GPIO0 and GPIO2...those could be wired to a joystick connector. -Thom 1 Quote Link to comment Share on other sites More sharing options...
manterola Posted September 18, 2018 Share Posted September 18, 2018 According to the data sheet for the ESP-01, there are two GPIO pins exposed from the 8266, GPIO0 and GPIO2...those could be wired to a joystick connector. -Thom Yep, I am using gpio2 to turn the led on/off of the atari 1030. The only thing is to be careful since there are also used to put esp-01 in run mode and in programming mode, so gpio2 for example need to be pulled up during booting to make the esp-01 start, after that can be used as input or output.Another simpler option is to get a esp12 or adafuit or similar with all the gpios exposed. A third, poor man option, is to solder very thin wires to the esp-01 main chip to get additional gpios that are not currently used. There are particularly 2 of them which are located at corners of the IC that are easier to wire. I've seen videos on YouTube of people doing that an adding those gpios to additional header pins. Quote Link to comment Share on other sites More sharing options...
manterola Posted September 18, 2018 Share Posted September 18, 2018 Btw, and sorry for asking probably something obvious. What's the reason of not using proceed or some other signal of the SIO bus to do hardware flow control? Isn't sx202 modem implemented flow control using those? Please educate me Quote Link to comment Share on other sites More sharing options...
+mytek Posted September 18, 2018 Share Posted September 18, 2018 According to the data sheet for the ESP-01, there are two GPIO pins exposed from the 8266, GPIO0 and GPIO2...those could be wired to a joystick connector. -Thom I would suggest if you are willing to incorporate the joystick as part of the interface, thus taking it out of an SIO only connection strategy, that the Motor-On signal be taken out of the equation if at all possible. Reason being, as many of you are certainly aware, there is an existing MIDI interface that also utilizes the Motor-On signal. Since it's existence predates the ESP-01 concept, and has several software packages that support it (with more to certainly follow), it would be a good way to avoid potential conflict. Of course I realize that it's nearly impossible to not have some incompatibilities with other hardware that also utilizes the joystick ports, but with careful consideration and weighing all the pros and cons this may be a small price to pay in order to gain WiFi connectivity. Btw, and sorry for asking probably something obvious. What's the reason of not using proceed or some other signal of the SIO bus to do hardware flow control? Isn't sx202 modem implemented flow control using those? Please educate me I would also be curious about that as well . 1 Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted September 18, 2018 Share Posted September 18, 2018 The Atari SX212 Modem also incorporates a R-Verter circuit. It uses PROCEED or INTERRUPT as a Carrier Detect, but not flow control... 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.