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