Re: Developing PLATOTerm64, Flow Control woes.

From: Thom Cherryhomes <thom.cherryhomes_at_gmail.com>
Date: Sun, 1 Jul 2018 16:15:14 -0500
Message-ID: <CAPQyuQJ_2RJK2U4d01n9ur4StkSC1GSu=s_LUuhDqMRCKN5Ppw@mail.gmail.com>
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.