If that's the case, then I'm going to need some help to shove in a user port modem driver that can handle hardware handshaking into CC65's ser framework. I am not an assembler programmer. -Thom On Sun, Jul 1, 2018 at 4:13 PM <groepaz@gmx.net> wrote: > 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:01:31
Archive generated by hypermail 2.2.0.