tschak909 Posted August 18, 2018 Share Posted August 18, 2018 You know, I keep thinking, that this whole approach is a massive dead end. There just isn't a clean way to provide a handshaking signal, at all. Why don't we just cram an 8266 in the cartridge slot, decoded to Dxxx and be done with it? Write a CIO handler to deal with that? -Thom 1 Quote Link to comment Share on other sites More sharing options...
Stefan Both Posted August 18, 2018 Share Posted August 18, 2018 You're right. The point is, I'm not able to do this. So I'm happy with the solution so far. Stefan Quote Link to comment Share on other sites More sharing options...
manterola Posted August 19, 2018 Share Posted August 19, 2018 According to what I have read here, the concurrent mode of the 850 is basically the same as the Rverter or conceptually very similar. It might be even better, if the additional signals of the sx212 are added and the right driver with handshaking signal is used. According to the FAQ there are several sx212 handlers, at least one of them it has the handshaking signals implemented using proceed and other signal that I don't remember right now (maybe command or motor). I have never checked this possibility, but it might worth a try, adding a couple more level shifters and looking for the right handler and finally using additional GPIO for handshaking. It doesn't sound too complicated to at least try. 2 Quote Link to comment Share on other sites More sharing options...
Stefan Both Posted August 19, 2018 Share Posted August 19, 2018 (edited) I used the 'c64 firmware' which I adapted slightly for the atarians need Afaik, the handshake lines are already implemented. CTS / RTS https://1200baud.wordpress.com/2017/03/04/build-your-own-9600-baud-c64-wifi-modem-for-20/ Stefan Edited August 19, 2018 by Stefan Both Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 19, 2018 Share Posted August 19, 2018 (edited) Available on the Commodore C64 & 128. Software emulated. The signals does not have true RS232 levels. It's TTL level, and RXD/TXD is inverted. It's just the normal User port used as a RS232 port. It has flow control that is implemented in software using the User Expansion port... since this stuff always goes to the bus in some fashion on all the other machines... maybe that's the way to go on our Ataris as well... on the others it seems above 2400 they must use flow control or bad things happen... it all goes wrong. For most things on the Atari- 4800 and even 9600 works fine without flow control, unless software or attached device can't keep up... then the lines are needed, in the case of the heavy processing platoterm most definitely needs flow control.... Edited August 19, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Stefan Both Posted August 19, 2018 Share Posted August 19, 2018 Yes. Ist TTL level. No need for TWO RS232 chips. (but level shifters - >3.3V) Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 19, 2018 Share Posted August 19, 2018 At some point, you guys are going to realize I'm right. I'd love to get to that point,sooner, rather than later. -Thom 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 19, 2018 Share Posted August 19, 2018 (edited) huh? You're both 'right'..... the sx212 and related r verter do flow control just fine.... the modem has a small buffer.... the key here is the buffer on the handshaked device and the software/driver to control it either baked into the terminal itself or knowing where to hit it in the driver... since no one kept the control line access in exactly the same place (mio bb etc) it's made things slightly more work on the coder. I was thinking about something... why does plato need hardware control? I mean it didn't have it in the first place and the server never sends an x on x off in any of it's transmissions, unless there is an issue with a microcode upload... are you implementing microcode emulation? a sufficient sized buffer within the modem/lantonix using x on x off can work if configured to halt the data at the modem computer interface locally and would not or should not be a problem.... if the modem can use it both locally and pass it through to the server all is good... perhaps I should re visit the lantronix configs and see if it can perform software flow control in that dual mode.... Edited August 19, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 19, 2018 Share Posted August 19, 2018 someone should dig up that driver and install the esp into an sx212... just to see how it fairs..... I have at least 2 or so sx's if they didn't get them whe they got my hard drives and megas Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 19, 2018 Share Posted August 19, 2018 You are very incorrect. PLATO had XON and XOFF flow control as part of its ASCII protocol, from day one. READ THE DAMNED PROTOCOL SPECIFICATION, I provide it on the front page of my site. https://irata.online/assets/s0ascers-045c83081e9ada2008378c3ae6aa62564b213a71decf9fe04608909b91d20ad1.html The connection asymmetry is large enough, that implementing flow control in-band means that by the time you assert the flow control character, you've already overflowed your buffer many times over. I've been through all of this, this has been my last 6 months, literally in the lab, understanding this whole @#(%@# problem. If you think you have a solution that I haven't already tried, then do it, and prove me wrong. Otherwise, I have a TI 99/4A terminal to write. -Thom Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 19, 2018 Share Posted August 19, 2018 (edited) what are you saying, I said plato had software flow control from the start, not hardware! I've re read my post, maybe I am missing an error in my post? if you can make it work on one classic machine you can make it work on all of them.... since the transport over flow issue is the same no matter the computer... if the device can hold it all in it's buffer what is the issue when serving things a page at a time? The only issue might be play a real time game but key and joystick input shouldn't be an issue as they are slow the only problem might be trying to serve a full screen game realtime game that redraws to slow, in which case flow control is the least of our worries. as the game would probably be unplayable. Wasn't that the reason to send microcode in the first place.... to run such things instead of streaming them. Edited August 19, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 19, 2018 Share Posted August 19, 2018 (edited) I ran tlp using software flow control, at 2400 baud. If you have implemented it in your terminal properly, and the largest chunk of data won't overflow the lantronix local buffer, then so long as the stop is sent early enough, the Atari would not lose one bit of data, and as it says okay send more it would only pull from the lantronix... not the server.... I will reconfigure the lantronix console.... you provide an image that can do 2400 with software flow... I will try local on off and remote on off and both at same time if possible... when going from lantronix to lantronix they provide a back channel for flow control in certain modes, this won't work if you are just serving out a single ethernet port... you would need to use an ets16pr or greater to serve multiple people at the same time though... You can't run tru port on the Atari so you can't connect to a pc running tru port... and such a setup would not work for the average user. revisting this they updated the com port re-director, and it can monitor remote buffer status.. and need only be set up on one side... but may not be working with modem mode Edited August 19, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 19, 2018 Share Posted August 19, 2018 back on topic, how big of a buffer does your wifi modem have? Quote Link to comment Share on other sites More sharing options...
manterola Posted August 20, 2018 Share Posted August 20, 2018 I just want to report that the I have managed to turn the Atari 1030 "connect" LED on, when the esp-01 establish a connection (and turn it off when disconnected). I think it is very simple but cool! I will post the circuit. But it just a pn2222a transistor I got from the junk box, and a couple of resistors: one 3k3 as pull up (otherwise the esp-01 does not boot), and another one I don't remember now, to interface the GPIO with the base to put the transistor in "saturation mode" . Still the Atari 1030 is working and the original circuitry of the modem can turn on the LED, so this mod is a not destructive mod. 3 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 21, 2018 Share Posted August 21, 2018 (edited) You are very incorrect. PLATO had XON and XOFF flow control as part of its ASCII protocol, from day one. READ THE DAMNED PROTOCOL SPECIFICATION, I provide it on the front page of my site. https://irata.online/assets/s0ascers-045c83081e9ada2008378c3ae6aa62564b213a71decf9fe04608909b91d20ad1.html The connection asymmetry is large enough, that implementing flow control in-band means that by the time you assert the flow control character, you've already overflowed your buffer many times over. I've been through all of this, this has been my last 6 months, literally in the lab, understanding this whole @#(%@# problem. If you think you have a solution that I haven't already tried, then do it, and prove me wrong. Otherwise, I have a TI 99/4A terminal to write. -Thom perhaps you still don't get it! software flow control can shut off the flow right at the modem in the persons house just like hardware flow control, in band & shut it down remotely if the modem has local and remote pass thru, all data is held in the remote buffer and local buffer.....as the Atari off load the buffers, nothing else should be getting pushed into any buffer until a new choice is made.... but your modem or device must support it. these are configuration issue... if you are not serving using an actual console server or modem server then we lose half the buffering ability.... but you can solve it using the old school solutions that all this stuff ran on back in the day, that means console servers, modem emulation or (lol) modems.... You keep telling us there is no way for this to work in band. That's fine, then you need something to expedite this, that would be as I stated... using true port on lantronix boxes. In any event on the version you sent before last, I was snooping the serial data, and found the software flow control didn't appear to work as it should! This worked with the TLP 2400 baud hack you did.... but is failing on Platoterm... the reason could be down to speed of interpretation, requiring the stop to come sooner before it overflows.... Edited August 21, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 21, 2018 Share Posted August 21, 2018 (edited) unless interpretation speeds up, we need a decent buffer and earlier clamping with x on x off, hardware flow control won't solve this since the same thing happens in EITHER mode, and all 4 modes on the lantronix. there are solutions that meter the output by/per connection on the ethernet sockets... the only other thing that might help.... in this situation. Since X on X off works for me when calling telnet and when using IRC with the Atari. The must be some reason this isn't working other than what form of flow control is at play/in use... Edited August 21, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 21, 2018 Share Posted August 21, 2018 Yes, RTS/CTS hardware flow control solves this quite nicely on both the Apple and C64 targets, which both have solutions built on the 6551 ACIA, which have their RTS/CTS lines exposed. With hardware flow control enabled on the modem, I can use the exact same code and use baud rates of 19200 or above. You can see the difference in line and single dot drawing. Please dude, I understand that I need to get text routines optimized. Want to help with that? In the mean time hardware flow control is essential, and greatly improves reliability. xon/off only works if the local modem isn't only able to process these characters locally, but the buffer isn't being overwhelmed, as the characters are being transmitted in-band. Otherwise, in my case ,since I am transmitting from a very fast source, the connection speed is too asymmetrical for xon/xoff. -Thom Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 21, 2018 Share Posted August 21, 2018 (edited) can this be approached from another angle, such that you put hardware flow control routines in for the black box, and then the mio. two call them platob and platom.... since the lines were not standard across the interfaces. It's not 'automatic' as some people try to tell you... since plato has it's own buffer, adjust the high water mark down and assert control. The thing that strikes me, as I had mentioned before... I never saw the line change on the analyzer even after an overflow... it wasn't late, it just never occured at all.... Let's try to get flow control working on each device first, in some sort of test code only for each device... then we can incorporate it into your terminal. Trying to do it all at once is no doubt going mess with our stress levels. a simple make lines blink type of deal... if cc65 won't do it just call ml routine from within cc65... go around it Edited August 21, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
+mytek Posted August 21, 2018 Share Posted August 21, 2018 I am enjoying the discussions and where this is going, but it's also beginning to sound like people are getting pissed off at one another. I really don't understand the reason for this, and it certainly doesn't seem necessary as part of the development process. Must be a full moon or some other outer worldly influence going on, since this isn't the only thread with people getting pissed off lately . Anyway ignore me if you like and carry on (really wishing they had an eating popcorn emoji). More then one way to skin a cat 4 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 21, 2018 Share Posted August 21, 2018 how many connections can you handle at one time? If I enable every single entry in my site table, I can handle 300 simultaneous sessions. -Thom Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 21, 2018 Share Posted August 21, 2018 (edited) hmmm, okay, I was getting no connection for a bit and was thinking some one was on... I'm going to ditch the MIO for a few minutes and try the black box instead and see if the control lines do anything on there. Who knows, maybe we need to give the serial port itself a buffer.... and by the way you made me dig one out... MicroFazer 16k rs232 buffer in my very hands Edited August 21, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 21, 2018 Share Posted August 21, 2018 I currently have 6 users on. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 21, 2018 Share Posted August 21, 2018 (edited) as for working on hardware flow control, am currently trying to resolve the memory map issue (some systems currently can't run PLATOTerm because of how the cc65 linker is placing the IRQ handler caller in memory, if you have more than 128K of memory, and it's enabled, e.g. in SpartaDOS X with USE BANKED, the program crashes.) I'll experiment with adding flow control for the BB and MIO soon. (I just have to figure out where the internal receive buffers and their pointers are kept, and I can write code to tickle the handshake line) (Oh yeah, and am in the middle of bringing up PLATOTerm on the ST) -Thom Edited August 21, 2018 by tschak909 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 21, 2018 Share Posted August 21, 2018 (edited) the good news is it powers up, the bad news, I have to buy cables and wire up three new cords... to connect it up to the black box, mio, and 850 and it still won't be of use until we have some control going on. Are any of the platoterm versions in theory performing hardware flow control for the Atari? if there are more than one, zip them up and I'll try them one at a time with each interface.... *edit* posted at the same time.... while most people should already know it, you might have to put a blurb in about using high speed serial patch on the ST's as well... it would seem they muffed the routines for that fully capable hardware so i had to be patched later. Everyone should already know but it does re appear from time to time someone forgets or is new. Edited August 21, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
BillC Posted August 21, 2018 Share Posted August 21, 2018 the good news is it powers up, the bad news, I have to buy cables and wire up three new cords... to connect it up to the black box, mio, and 850 and it still won't be of use until we have some control going on. Are any of the platoterm versions in theory performing hardware flow control for the Atari? if there are more than one, zip them up and I'll try them one at a time with each interface.... *edit* posted at the same time.... while most people should already know it, you might have to put a blurb in about using high speed serial patch on the ST's as well... it would seem they muffed the routines for that fully capable hardware so i had to be patched later. Everyone should already know but it does re appear from time to time someone forgets or is new. The 850 modem/printer cables are compatible with the original ICD MIO, the reproduction MIO by Metalguy66 uses PC compatible cables. IIRC the cables for the Blackbox are just ribbon cable with the correct IDC connectors crimped on each end. 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.