https://github.com/cc65/cc65/blob/master/asminc/ser-kernel.inc and https://github.com/cc65/cc65/blob/master/include/serial.h -Thom On Sun, Jul 1, 2018 at 2:15 PM David Roberts <daver21145@gmail.com> wrote: > That's what I partially assumed. > > The problem is that this function in turn calls the kernal routines CHKOUT > and BSOUT. I am trying to work out the code path from the user code to the > serial handler itself witinn the NMI handler. > > For example, if a keyboard character is detected (that calls ser_put > within keyboard.c) and an incoming serial character arrives at the same > time (resulting in another call of ser_put from io.c) will they interfere > with each other? If the NMI handler is already processing a transmit > character, and an XOFF/XON is required before the previous character has > been transmitted, will this cause problems? > > This is my current thinking. > > Dave > > On Sunday, 1 July 2018, Thom Cherryhomes <thom.cherryhomes@gmail.com> > wrote: > >> The ser_kernel ultimately jumps to this: >> >> https://github.com/nanoflite/c64-up2400-cc65/blob/master/driver/c64-up2400.s#L163 >> >> -Thom >> >> >> >> On Sun, Jul 1, 2018 at 1:03 PM David Roberts <daver21145@gmail.com> >> wrote: >> >>> Where is the source code for ser_put()? >>> >>> Dave >>> >>> >>> On Sunday, 1 July 2018, <groepaz@gmx.net> wrote: >>> >>>> uh, its like 5 lines of code. thats kinda the point - take your plato >>>> stuff >>>> out of the equation and test *only* the rs232 driver. when this works, >>>> then >>>> the problem is in your code, not the driver. (i'd even test against >>>> some >>>> terminal program on the other end, not the plato server - because who >>>> knows) >>>> >>>> >>>> Am Sonntag, 1. Juli 2018, 19:46:17 CEST schrieb Thom Cherryhomes: >>>> > there is no simple text mode in PLATO. can't do that. >>>> > >>>> > -Thom >>>> > >>>> > On Sun, Jul 1, 2018 at 12:43 PM <groepaz@gmx.net> wrote: >>>> > > i'd try those routines with a very simple text terminal >>>> implementation >>>> > > first, >>>> > > and see if the flow control works right. XON/OFF is always a bit >>>> tricky, >>>> > > so it >>>> > > might just be the thresholds that need tweaking. >>>> > > >>>> > > Am Sonntag, 1. Juli 2018, 19:32:04 CEST schrieb Thom Cherryhomes: >>>> > > > 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/libsr >>>> > > >>>> > > > >>>> c/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 >>>> > > >>>> > > -- >>>> > > >>>> > > http://hitmen.eu http://ar.pokefinder.org >>>> > > http://vice-emu.sourceforge.net http://magicdisk.untergrund.net >>>> > > >>>> > > Habe ich schon erwähnt, daß mir HDTV/Blueray/HD-DVD völlig am >>>> > > Allerwertesten >>>> > > vorbeigehen? Das derzeitige Programm noch hochauflösender zu sehen, >>>> > > empfinde >>>> > > ich als Drohung. >>>> >>>> >>>> -- >>>> >>>> http://hitmen.eu http://ar.pokefinder.org >>>> http://vice-emu.sourceforge.net http://magicdisk.untergrund.net >>>> >>>> Wer im Glashaus sitzt hat immer frische Gurken. >>>> >>>> >>>> >>>> >>>> >>>>Received on 2018-07-01 22:02:19
Archive generated by hypermail 2.2.0.