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. > > > > > >Received on 2018-07-01 20:02:26
Archive generated by hypermail 2.2.0.