Developing PLATOTerm64, Flow Control woes.

From: Thom Cherryhomes <thom.cherryhomes_at_gmail.com>
Date: Sun, 1 Jul 2018 11:27:01 -0500
Message-ID: <CAPQyuQ+kOEKzHd9A03Yo856Cg-FxqmdaAV55vMxbOD5vyOgczA@mail.gmail.com>
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:00:05

Archive generated by hypermail 2.2.0.