great, now if only I can figure out wtf to do... I'm not a skilled C64 programmer, am only passing through to write this terminal. -Thom On Sun, Jul 1, 2018 at 12:30 PM David Roberts <daver21145@gmail.com> wrote: > 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:01:46
Archive generated by hypermail 2.2.0.