Re: Developing PLATOTerm64, Flow Control woes.

From: Thom Cherryhomes <thom.cherryhomes_at_gmail.com>
Date: Sun, 1 Jul 2018 14:18:27 -0500
Message-ID: <CAPQyuQLRjJ43XZGLqbwWTYXNk_ddfg7SCP-qasZ=5WpbPj80jg@mail.gmail.com>
https://github.com/cc65/cc65/blob/master/asminc/ser-kernel.inc
and
https://github.com/cc65/cc65/blob/master/include/serial.h

-Thom

On Sun, Jul 1, 2018 at 2:15 PM David Roberts <daver21145@gmail.com> wrote:

> That's what I partially assumed.
>
> The problem is that this function in turn calls the kernal routines CHKOUT
> and BSOUT. I am trying to work out the code path from the user code to the
> serial handler itself witinn the NMI handler.
>
> For example, if a keyboard character is detected (that calls ser_put
> within keyboard.c) and an incoming serial character arrives at the same
> time (resulting in another call of ser_put from io.c) will they interfere
> with each other? If the NMI handler is already processing a transmit
> character, and an XOFF/XON is required before the previous character has
> been transmitted, will this cause problems?
>
> This is my current thinking.
>
> Dave
>
> On Sunday, 1 July 2018, Thom Cherryhomes <thom.cherryhomes@gmail.com>
> wrote:
>
>> The ser_kernel ultimately jumps to this:
>>
>> https://github.com/nanoflite/c64-up2400-cc65/blob/master/driver/c64-up2400.s#L163
>>
>> -Thom
>>
>>
>>
>> On Sun, Jul 1, 2018 at 1:03 PM David Roberts <daver21145@gmail.com>
>> wrote:
>>
>>> Where is the source code for ser_put()?
>>>
>>> Dave
>>>
>>>
>>> On Sunday, 1 July 2018, <groepaz@gmx.net> wrote:
>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
Received on 2018-07-01 22:02:19

Archive generated by hypermail 2.2.0.