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 20:02:54
Archive generated by hypermail 2.2.0.