Re: Developing PLATOTerm64, Flow Control woes.

From: Thom Cherryhomes <thom.cherryhomes_at_gmail.com>
Date: Sun, 1 Jul 2018 12:49:08 -0500
Message-ID: <CAPQyuQKk1L7mG+w2UHfG8L6+PTBshWqG5DJ3T73tJ+9fVr_xsA@mail.gmail.com>
...and I have spent, a week, trying every XON/XOFF threshold value I can
think of, it doesn't make much of a difference in the output. Greg King
suggested this, as well.

-Thom

On Sun, Jul 1, 2018 at 12:46 PM Thom Cherryhomes <thom.cherryhomes@gmail.com>
wrote:

> 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.
>>
>>
>>
>>
>>
>>
Received on 2018-07-01 20:02:40

Archive generated by hypermail 2.2.0.