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.