Re: Developing PLATOTerm64, Flow Control woes.

From: David Roberts <daver21145_at_gmail.com>
Date: Sun, 1 Jul 2018 17:54:10 +0100
Message-ID: <CAC5emFEYAhaiR-WPv8vjt4GE39_w4N1SEOn3jGSSmop=O9M16Q@mail.gmail.com>
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/libsrc/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
>
>
Received on 2018-07-01 19:02:05

Archive generated by hypermail 2.2.0.