you could increase the buffer size to something larger than the expected maximum packet length.... not sure if that is an option in practise. or perhaps modify the code so that a) you only send an XON when the buffer is completely empty and b) send an XOFF immediatly when something was recieved. with some luck that makes packet fragmentation kick in that said... what you could also do is use RTS/CTS also (ie hardware handshake). then the buffering in the modem and the automatic resending in the ip stack should kick in Am Sonntag, 1. Juli 2018, 21:50:05 CEST schrieb Thom Cherryhomes: > Seeing as I am either using wifi modem emulators based on ESP8266, or > ethernet cartridges running under IP65, what do I do? > > -Thom > > On Sun, Jul 1, 2018 at 2:47 PM Mike Stein <mhs.stein@gmail.com> wrote: > > Keep in mind that XON/XOFF expects a fairly immediate response; a common > > issue using it these days is that you're not necessarily receiving single > > characters but packets and you could receive quite a few characters before > > XOFF has any effect. > > > > m > > > > ----- Original Message ----- > > From: <groepaz@gmx.net> > > To: <cbm-hackers@musoftware.de> > > Cc: "Thom Cherryhomes" <thom.cherryhomes@gmail.com> > > Sent: Sunday, July 01, 2018 1:55 PM > > Subject: Re: Developing PLATOTerm64, Flow Control woes. > > > > > > uh, its like 5 lines of code. thats kinda the point - take your plato > > stuff > > out of the equation and test *only* the rs232 driver. when this works, > > then > > the problem is in your code, not the driver. (i'd even test against some > > terminal program on the other end, not the plato server - because who > > knows) > > > > Am Sonntag, 1. Juli 2018, 19:46:17 CEST schrieb Thom Cherryhomes: > > > there is no simple text mode in PLATO. can't do that. > > > > > > -Thom > > > > > > On Sun, Jul 1, 2018 at 12:43 PM <groepaz@gmx.net> wrote: > > > > i'd try those routines with a very simple text terminal implementation > > > > first, > > > > and see if the flow control works right. XON/OFF is always a bit > > > > tricky, > > > > > > so it > > > > might just be the thresholds that need tweaking. > > > > > > > > Am Sonntag, 1. Juli 2018, 19:32:04 CEST schrieb Thom Cherryhomes: > > > > > great, now if only I can figure out wtf to do... I'm not a skilled > > > > C64 > > > > > > > programmer, am only passing through to write this terminal. > > > > > > > > > > -Thom > > > > > > > > > > On Sun, Jul 1, 2018 at 12:30 PM David Roberts <daver21145@gmail.com> > > > > > > > > wrote: > > > > > > I have never used cc65 - but I know programmers who have been > > > > caught > > > > > > out > > > > > > > > > > on other platforms. > > > > > > > > > > > > NMI routines need to make sure that all CPU registers are > > > > > > > > saved/restored > > > > > > > > > > and that data structures remain intact. If the NMI routine changes > > > > > > anything > > > > > > that is relied on outside of it (without the appropriate > > > > protection) > > > > > > you > > > > > > > > > > are in trouble... > > > > > > > > > > > > Interrupts can be inhibited during critical processing outside of > > > > the > > > > > > > > interrupt service routine. An NMI requires special treatment. We > > > > use > > > > > > NMI > > > > > > > > > > as > > > > > > a critical error and real-time clock handler (in preference to an > > > > > > interrupt) in a piece of communications hardware we use; but the > > > > > > > > hardware > > > > > > > > > > contains a mechanism for (very briefly) disabling the NMI around > > > > very > > > > > > > > critical data structures that absolutely must not be modified > > > > should a > > > > > > > > critical error (such as a bus timeout on the MULTIBUS) occur. > > > > > > > > > > > > Not sure how much of this is relevant to your problem, but it fits > > > > the > > > > > > > > symptoms you have... > > > > > > > > > > > > Dave > > > > > > > > > > > > On Sunday, 1 July 2018, Thom Cherryhomes < > > > > thom.cherryhomes@gmail.com> > > > > > > > > wrote: > > > > > >> The up2400 routines use the NMI to do all the shifting and > > > > filling of > > > > > > the > > > > > > > > > >> buffers. > > > > > >> > > > > > >> I'm not entirely sure volatile has any meaningful consequence in > > > > > >> cc65. > > > > > >> > > > > > >> -Thom > > > > > >> > > > > > >> On Sun, Jul 1, 2018 at 11:54 AM David Roberts < > > > > daver21145@gmail.com> > > > > > > > >> wrote: > > > > > >>> I have only just had a cursory look at the sources, but does > > > > > >>> anything > > > > > >>> use interrupts? Usually interrupts cause unexpected results. > > > > > >>> > > > > > >>> The other thing to be wary of (with C code) is the ability of > > > > > >>> the > > > > > >>> hardware to change stuff 'under' the compiler's feet... If C > > > > code is > > > > > > > >>> mapped > > > > > >>> onto hardware anywhere - you need to use the 'volatile' keyword > > > > to > > > > > > force > > > > > > > > > >>> the compiler to re-read the data before use as opposed to using > > > > its > > > > > > own > > > > > > > > > >>> cached value. > > > > > >>> > > > > > >>> Just a couple of thoughts... > > > > > >>> > > > > > >>> Dave > > > > > >>> > > > > > >>> > > > > > >>> On Sunday, 1 July 2018, Thom Cherryhomes < > > > > thom.cherryhomes@gmail.com > > > > > > > >>> wrote: > > > > > >>>> Hello, everyone. > > > > > >>>> > > > > > >>>> My name is Thom Cherryhomes, and I am both the systems operator > > > > of > > > > > > > >>>> IRATA.ONLINE, and developing a series of terminal programs for > > > > > >>>> different > > > > > >>>> machines that can connect to the currently running PLATO > > > > systems en > > > > > > > >>>> extant: > > > > > >>>> IRATA.ONLINE, and CYBER1.ORG. > > > > > >>>> > > > > > >>>> I've gotten the vast majority of the terminal written, using > > > > CC65, > > > > > > and > > > > > > > > > >>>> appropriating some bits of code from other places, namely: > > > > > >>>> > > > > > >>>> * up2400 for cc65 based on George Hug's user-port 2400 driver. > > > > > >>>> https://github.com/nanoflite/c64-up2400-cc65 > > > > > > > >>>> * The swiftlink driver for cc65: > > https://github.com/gilligan/snesdev/blob/master/tools/cc65-2.13.2/libsr > > > > > > > >>>> c/c64/c64-swlink.s > > > > > >>>> > > > > > >>>> * ip65 for ethernet support > > > > https://github.com/oliverschmidt/ip65 > > > > > > > >>>> As I said, the terminal is mostly functioning, but I am having > > > > > > > > problems > > > > > > > > > >>>> when flow control needs to assert itself, The type of flow > > > > control > > > > > > that > > > > > > > > > >>>> PLATO supports is XON/XOFF, so I've implemented a threshold > > > > model > > > > > > that > > > > > > > > > >>>> sends XON/XOFF based on threshold values: > > https://github.com/tschak909/platoterm64/blob/master/src/io.c#L20 > > > > > > > >>>> #define XOFF_THRESHOLD 250 > > > > > >>>> #define XON_THRESHOLD 100 > > > > > >>>> And this is asserted during the io_recv_serial() which gets > > > > called > > > > > > > >>>> every pass through the main loop: > > https://github.com/tschak909/platoterm64/blob/master/src/io.c#L20 > > > > > > > >>>> I understand that the code as is only works with user-port > > > > devices > > > > > > > >>>> (because up2400 re-uses the kernal structures), these are the > > > > > > > > devices > > > > > > > > > >>>> that > > > > > >>>> need it most, and I am trying to get these devices working, > > > > before > > > > > > > >>>> I > > > > > >>>> refine > > > > > >>>> things for the swiftlink cartridge. > > > > > >>>> > > > > > >>>> However, what happens, is something like this: > > > > > >>>> https://www.youtube.com/watch?v=K9VgIigaJzw > > > > > >>>> > > > > > >>>> and this: > > > > > >>>> https://www.youtube.com/watch?v=xjSlCOPXYRk > > > > > >>>> > > > > > >>>> I'm not entirely sure what's happening here, as the buffer is > > > > > > > > filling > > > > > > > > > >>>> up, and draining, and the amount of glitching is directly > > > > > > > > proportional > > > > > > > > > >>>> to > > > > > >>>> the tiniest bits of changes in my drawing routines. The one > > > > biggest > > > > > > > >>>> cause > > > > > >>>> of glitch is the block erase routine (which given a set of > > > > > >>>> pixel > > > > > >>>> coordinates, erases an area of the screen...the cc65 > > > > implementation > > > > > > > >>>> draws > > > > > >>>> horizontal lines until the bottom of the bounding box is > > > > reached... > > > > > > I > > > > > > > > > >>>> would > > > > > >>>> think this would simply cause the buffer to fill up, which > > > > > >>>> would > > > > > > > > cause > > > > > > > > > >>>> xoff > > > > > >>>> to trip, stuff would stop being sent, and the buffer would > > > > > > > > subsequently > > > > > > > > > >>>> be > > > > > >>>> drained until the buffer is empty...but something very subtly > > > > wrong > > > > > > is > > > > > > > > > >>>> happening. > > > > > >>>> > > > > > >>>> I have already spent days messing with the threshold values, as > > > > > > > > well as > > > > > > > > > >>>> trying to shuffle code around to try and alleviate the problem, > > > > but > > > > > > I > > > > > > > > > >>>> seem > > > > > >>>> to just keep getting the short end of the stick on this one. > > > > > >>>> > > > > > >>>> Could really use some help, any insights? > > > > > >>>> > > > > > >>>> Code is here btw: http://github.com/tschak909/platoterm64 > > > > > >>>> > > > > > >>>> -Thom > > > > > > > > -- > > > > > > > > http://hitmen.eu http://ar.pokefinder.org > > > > http://vice-emu.sourceforge.net http://magicdisk.untergrund.net > > > > > > > > Habe ich schon erwähnt, daß mir HDTV/Blueray/HD-DVD völlig am > > > > Allerwertesten > > > > vorbeigehen? Das derzeitige Programm noch hochauflösender zu sehen, > > > > empfinde > > > > ich als Drohung. > > > > -- > > > > http://hitmen.eu http://ar.pokefinder.org > > http://vice-emu.sourceforge.net http://magicdisk.untergrund.net > > > > Wer im Glashaus sitzt hat immer frische Gurken. -- http://hitmen.eu http://ar.pokefinder.org http://vice-emu.sourceforge.net http://magicdisk.untergrund.net The weirder you are going to behave, the more normal you should look... When I see a kid with three or four rings in his nose, I know there is absolutely nothing extraordinary about that person. <P.J. O'Rourke>Received on 2018-07-02 00:00:05
Archive generated by hypermail 2.2.0.