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/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:19
Archive generated by hypermail 2.2.0.