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