mr-atari Posted September 14, 2018 Share Posted September 14, 2018 I think we are not on the same line, don't get me wrong. I am talking about the connection with internet, not what the terminal software says. So I am talking low-level, Operating System style. The data that flows between the server and ESP8266 over the WIFI-connection. My driver is just like any other R-driver. Status tells you how many bytes there are in the buffer. Get byte gives you a byte from the buffer. Put byte sends a byte out. And then you have Open, Close and Special. That is what the Atari-OS supports. My driver maintains a buffer and I want to use Xoff and Xon to shut up the server from sending me data. But some how this does not work. When the ESP send $13, the server does not stop talking. It $13 not the correct byte to send? Do I need to send other bytes? If so, what byte do I send to start talking again? Quote Link to comment Share on other sites More sharing options...
mr-atari Posted September 14, 2018 Share Posted September 14, 2018 (edited) -deleted- posted twice... Edited September 14, 2018 by mr-atari Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 14, 2018 Share Posted September 14, 2018 no, you absolutely must stop the data while it's in a buffer at your house, the speed and amount of data on modern internet can be 12 Megabyte to 95 Megabyte a second at a persons home... and if you had servers on the backbone like I did... even more. If you are calling a lantronix box it spreads the data out and regulates packets to slow this down, and that allows for buffering on both sides (my house/your house) with only pass thru flow control a page and a half or more of data with fly by your screen at 9600. With local flow control, you can stop on a dime and it sits in your modem replacements devices buffer but if I keeps sending I will over flow the devices buffer. If you invoke local flow with pass thru, you can stop on a dime and prevent me from overflowing your devices buffer. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 14, 2018 Share Posted September 14, 2018 Your r driver is better than most, it is fast and even if you didn't intend to it controls rts and dtr hardware lines when used with bobterm and a mio using whatever you provided on your disk unless bobterm 1.23 does that on it's own... not sure about that because 1.23 always failed to work for me with the MIO until I used your driver .... I didn't notice the software flow control kicking in at lower baud rates. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 14, 2018 Author Share Posted September 14, 2018 @mr-atari, ok, so two out of three... I can't do anything about clearing of page 6 yet, as this is done in the underlying C runtime. Perhaps Chris may have an idea for a patch? But, I found out why CR wasn't sending LF with my last set of work, and that's because i had to handle the Atari keyboard scanning directly, it wasn't using my default routines (which work for e.g. the Apple II and other ASCII based keyboard scanning) So now when in TTY mode, CR will send CR and LF, and send # $ & straight through (which require special ACCESS keypresses in PLATO), so this should be enough to send commands to the modem. And config and driver filenames now explicitly have a filespec beginning with D:, which should use the default drive. This works on SpartaDOS X and DOS 2.5, so... Build attached, plato-20180914-crlf-really-default-d.atr -Thom 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 14, 2018 Author Share Posted September 14, 2018 I've released a public build on github, 20180914: https://github.com/tschak909/platoterm64/releases/tag/ATARI_20180914 Folding in all the fixes that have been coming across this thread, as well as adding in documentation and license programs to read or print those files. The disk format has been extended to 1050 format (1040 sectors) to accommodate the additional files. -Thom 2 Quote Link to comment Share on other sites More sharing options...
sanny Posted September 14, 2018 Share Posted September 14, 2018 I can't do anything about clearing of page 6 yet, as this is done in the underlying C runtime. Perhaps Chris may have an idea for a patch? Page6 is used for the mouse cursor P/M by default. You can change that by recompiling the cc65 Runtime lib, see libsrc/atari/mcbpm.s and libsrc/atari/Makefile.inc. It's already some time since I implemented the mouse support. I don't remember how good non page6 was tested, especially when using graphics 8. Please contact me in case of problems. What's the problem with clearing page 6? And config and driver filenames now explicitly have a filespec beginning with D:, which should use the default drive. This works on SpartaDOS X and DOS 2.5, so... It happened that I changed the cc65 runtime lib yesterday to have a better "default device" in DOS 2 and 2.5. It now is generated from DUNIT and should point to the drive the EXE file was loaded. "default device" for SD-X is in since long. Could it be that you also used latest cc65 for your new build? This would explain that it works better now. Prepending "D:" shouldn't matter, since if the filename didn't have a "x:" at the front, the default device was prepended. regards, chris 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 14, 2018 Author Share Posted September 14, 2018 Page6 is used for the mouse cursor P/M by default. You can change that by recompiling the cc65 Runtime lib, see libsrc/atari/mcbpm.s and libsrc/atari/Makefile.inc. It's already some time since I implemented the mouse support. I don't remember how good non page6 was tested, especially when using graphics 8. Please contact me in case of problems. What's the problem with clearing page 6? It happened that I changed the cc65 runtime lib yesterday to have a better "default device" in DOS 2 and 2.5. It now is generated from DUNIT and should point to the drive the EXE file was loaded. "default device" for SD-X is in since long. Could it be that you also used latest cc65 for your new build? This would explain that it works better now. Prepending "D:" shouldn't matter, since if the filename didn't have a "x:" at the front, the default device was prepended. regards, chris Sijmen uses page 6 for the buffers for his R-Verter device driver. Finding the required memory space elsewhere might be a bit of a challenge. @mr-atari: PLATOTerm has support for a variety of input devices to simulate the touch screen: joystick, trackballs, touch tablet (koala or Atari), and Amiga or ST mice. The mouse driver uses P/M graphics to display the cursor. -Thom Quote Link to comment Share on other sites More sharing options...
FifthPlayer Posted September 15, 2018 Share Posted September 15, 2018 Finding the required memory space elsewhere might be a bit of a challenge. Page 4, which normally holds the cassette buffer? 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 15, 2018 Author Share Posted September 15, 2018 For anyone testing. At any menu, you can press 'G' for go, to specify a specific lesson. One very useful lesson is 'diag' for all sorts of interesting diagnostics. -Thom Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 15, 2018 Share Posted September 15, 2018 (edited) Not that you are going to implement microcode games but what was the memory for the microcode section of the terminal? next question, 1k boundaries... does it affect you program and would it cripple things including buffer performance when crossing them... last crazy question... I am going to try for 9600 (jibberish screen folks keep showing) for that I think get more from buffer should be 0 and stop might be 46 or 48 with buffer as big as 512 or 1024 or get at 46 or 48 stop at 64 or 96 with buffer at 512 or 1024 with some fiddly and frustration experimentation we might get it to handle 9600. is larger the buffer the slower it parses an axiom here or will it be fine? Can we know what the largest stream plato sends for font character data (I think there is a limit to how much is sent at one full set swap) and does it pull from the standard buffer we've been adjusting (want to make sure it doesn't do a bypass) Edited September 15, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 15, 2018 Share Posted September 15, 2018 (edited) for some idea on where that set of number would come from 1024 buffer minus 960 = 64 so if we stop data at 64 there would be room for 960 overflow, and since we know plato likes 0 16 24 32 46 48 as a get point trying these to get a window for 9600 might work out. with how fast ethernet was pushing the rose draw I think we should be able to tune this and get it humming... I understand you want the same coding on everything, at some point It just may require optimization for each machine though. Mostly the same code Edited September 15, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 15, 2018 Author Share Posted September 15, 2018 full character set is 2048 bytes. (that's for memories m0 and m1), but only the changed character data is sent, so it's less. As for code differentiation: my intent was to get this running and working on each target platform. this has long since been accomplished. After which, things can be improved. Jon's fast text output was one example. As for crossing boundaries, the only performance penalty that I know for sure is the classic 256 byte page boundary crossing, which incurs an additional cycle. I will add a feature to set the thresholds via user input tomorrow, after the presentation. I have a presentation at VCF MW that I have been getting ready for, all week (stopping to do improvements and spin builds for this thread) It can then be tweaked as necessary. In any case, these values may very well be specific to the particular interface you are using, as none of these values have worked on my 850 at 2400bps. The RVerter interface that I do have, is an SIO2PC cable, basically. -Thom Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 15, 2018 Share Posted September 15, 2018 (edited) ? sio to pc rverter as in to ape or respeqt or tcpser? the 46get 127stop 384buffer we've been using on the mio has been working with xon xoff to the lantronix set to soft flow with soft flow pass though... so it works instantly at the device as it should.... a straight connection to a serial port with no buffer or flow control will yield garbage... it's almost like plato server does not act on flow control during char set loads etc... so it's likely I am buffering enough of it in the lantronix and the xon xoff lets it sip just what it needs as such a device should. giving the ability to adjust for xon xoff and buffer size would be a great help... I will have to find what works for each device, and go from there I wouldn't expect to have to go beyond 1023 or 1024 for buffer size.... I guess we could then make it part of the config, if they select rhnd850 - it will set the buffer size and high lower water marks from our findings. It could also set the device up I suppose... just like the modem string or init string every terminal had back in the day... Edited September 15, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 15, 2018 Author Share Posted September 15, 2018 i've got three setups here: (1) an 850 to rs232 to an rpi 0 running tcpser (using less than .002% of i/o bandwidth on the pi). The 850's use at 2400 is marginal (2) an SIO2PC cable that I can flip over to r-verter mode, onto my windows pc running tcpser. It works well at 2400, save for the occasional glitch from the checkers title screen. (3) the same SIO2PC using APE's serial handler. This thing sends data way too fast for PLATOTerm to process, and altering the metering and/or response latency values do little to help. Rather frustrating. As for MIO, I should be able to implement RTS/CTS flow control for it, and the black box (which both have ACIA's, just at different base addresses) -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 15, 2018 Author Share Posted September 15, 2018 Also worth noting that Len Spencer's hyperspeed drivers for MIO and Blackbox ARE on the distribution disk. -Thom Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 15, 2018 Share Posted September 15, 2018 (edited) yes that is what I have been using with the mio len's accelerator, in any event we'll get the numbers nailed down for software control, and adding the hardware control in should be as easy as replacing the color poke with the hardware poke..which the config program yet again would have to modify based on device chosen... Edited September 15, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
mr-atari Posted September 15, 2018 Share Posted September 15, 2018 (edited) I will move my driver and buffer out of page 6, no problem. Perhaps I need to increase my buffer to 1K, don't know yet. About the fixed D1: Your init-routine can read DUNIT and thus see were plato is loaded from. This is what I normally do and copy this value on the spot where now the "1" is stored. So D1: CONFIG is changed to Dx:CONFIG on the fly. I am going back to the drawing board and see what I do not right. Somehow Xon and Xoff are not working and I need to dig into this, before I can go further. Now I send Xoff when I have 8 bytes in the R:buffer and Xon when it is drained. But has no effect, data still is coming from the internet for ever and ever, it does not/never stop... Yes, I can set/reset RTS/DTR, no problem. Do you want a version that does this? I have to dig in the manual to see what lines to use, but that shouldn't be an issue. Edited September 15, 2018 by mr-atari Quote Link to comment Share on other sites More sharing options...
mr-atari Posted September 15, 2018 Share Posted September 15, 2018 New build appears not working... Altirra encounters a BRK and stops, no idea why. The "plato-diet-fixed-keys" works just fine. Standard configuration, no fancy pansy, 800xl+rverter+2400baudmodem. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 15, 2018 Author Share Posted September 15, 2018 are you loading from the DOS on the disk? -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 15, 2018 Author Share Posted September 15, 2018 @mr-atari. sorry, I tracked down the problem. I accidentally put a config file which had touch enabled, onto the distribution disk that was uploaded. (touch drivers and r-verter have problems together atm) https://github.com/tschak909/platoterm64/releases/tag/ATARI_20180914 updated to 0915. -Thom 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 16, 2018 Author Share Posted September 16, 2018 Added code for screen_beep() so now the beeper is working. I have a new-found respect for that little squawking speaker, trying to get anything out of it when you have ANTIC and POKEY stealing cycles, that doesn't sound like an enraged wasp is an achievement -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 16, 2018 Author Share Posted September 16, 2018 so now that fast text has been folded in, and the feature set is pretty much solid, now I am going to try and find ways to shrink platoterm, with a goal to either improving the scaling calculations, or to be able to re-instate the scaling table to get rendering accuracy back up. -Thom 2 Quote Link to comment Share on other sites More sharing options...
funkheld Posted September 16, 2018 Share Posted September 16, 2018 Hi good afternoon. what do you do with the program please? how can you use it today? Thank you. greeting Quote Link to comment Share on other sites More sharing options...
mr-atari Posted September 16, 2018 Share Posted September 16, 2018 Not had the time for testing, yet. My ESP has gone belly up, some weird baud-rate is set. Currently bit-banging to get it back for normal communication...... Termite can't be set to this weird-o-rate (about 140kbit). So back on the atari, using the joysticks-port to create a serial-out. In the meantime: Where can I find the transmission protocol for plato? To get my driver to work properly, I need to know the meaning of the bytes that are coming in. Thanks ! Quote Link to comment Share on other sites More sharing options...
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.