Developing PLATOTerm64, Flow Control woes.

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Developing PLATOTerm64, Flow Control woes.

Thom Cherryhomes
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:

and this:

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?


-Thom

Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

daver2nab
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 <[hidden email]> 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:

and this:

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?


-Thom

Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Thom Cherryhomes
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 <[hidden email]> 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 <[hidden email]> 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:

and this:

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?


-Thom

Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

daver2nab
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:

and this:

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?


-Thom

Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:

and this:

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?


-Thom

Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Groepaz
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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> >>
> >> 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 <[hidden email]>
> >>>
> >>> 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.





Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Thom Cherryhomes
there is no simple text mode in PLATO. can't do that.

-Thom

On Sun, Jul 1, 2018 at 12:43 PM <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> >>
> >> 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 <[hidden email]>
> >>>
> >>> 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.





Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Thom Cherryhomes
...and I have spent, a week, trying every XON/XOFF threshold value I can think of, it doesn't make much of a difference in the output. Greg King suggested this, as well.

-Thom

On Sun, Jul 1, 2018 at 12:46 PM Thom Cherryhomes <[hidden email]> wrote:
there is no simple text mode in PLATO. can't do that.

-Thom

On Sun, Jul 1, 2018 at 12:43 PM <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> >>
> >> 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 <[hidden email]>
> >>>
> >>> 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.





Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Groepaz
In reply to this post by Thom Cherryhomes
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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> > > >
> > > > 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 <[hidden email]>
> > > >>
> > > >> 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 <[hidden email]
> > > >>>
> > > >>> 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.





Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

daver2nab
Where is the source code for ser_put()?

Dave

On Sunday, 1 July 2018, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> > > >
> > > > 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 <[hidden email]>
> > > >>
> > > >> 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 <[hidden email]
> > > >>>
> > > >>> 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.





Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Thom Cherryhomes
The ser_kernel ultimately jumps to this: 

-Thom



On Sun, Jul 1, 2018 at 1:03 PM David Roberts <[hidden email]> wrote:
Where is the source code for ser_put()?

Dave


On Sunday, 1 July 2018, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> > > >
> > > > 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 <[hidden email]>
> > > >>
> > > >> 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 <[hidden email]
> > > >>>
> > > >>> 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.





Reply | Threaded
Open this post in threaded view
|

Developing PLATOTerm64, Flow Control woes.

daver2nab
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 <[hidden email]> wrote:
The ser_kernel ultimately jumps to this: 

-Thom



On Sun, Jul 1, 2018 at 1:03 PM David Roberts <[hidden email]> wrote:
Where is the source code for ser_put()?

Dave


On Sunday, 1 July 2018, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> > > >
> > > > 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 <[hidden email]>
> > > >>
> > > >> 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 <[hidden email]
> > > >>>
> > > >>> 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.





Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Thom Cherryhomes

On Sun, Jul 1, 2018 at 2:15 PM David Roberts <[hidden email]> 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 <[hidden email]> wrote:
The ser_kernel ultimately jumps to this: 

-Thom



On Sun, Jul 1, 2018 at 1:03 PM David Roberts <[hidden email]> wrote:
Where is the source code for ser_put()?

Dave


On Sunday, 1 July 2018, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> > > >
> > > > 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 <[hidden email]>
> > > >>
> > > >> 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 <[hidden email]
> > > >>>
> > > >>> 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.





Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Mike Stein
In reply to this post by Groepaz
Keep in mind that XON/XOFF expects a fairly immediate response; a common issue using it these days is that you're not necessarily receiving single characters but packets and you could receive quite a few characters before XOFF has any effect.

m

----- Original Message -----
From: <[hidden email]>
To: <[hidden email]>
Cc: "Thom Cherryhomes" <[hidden email]>
Sent: Sunday, July 01, 2018 1:55 PM
Subject: Re: Developing PLATOTerm64, Flow Control woes.


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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> > > >
> > > > 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 <[hidden email]>
> > > >>
> > > >> 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 <[hidden email]
> > > >>>
> > > >>> 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.






Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Thom Cherryhomes
Seeing as I am either using wifi modem emulators based on ESP8266, or ethernet cartridges running under IP65, what do I do?

-Thom

On Sun, Jul 1, 2018 at 2:47 PM Mike Stein <[hidden email]> wrote:
Keep in mind that XON/XOFF expects a fairly immediate response; a common issue using it these days is that you're not necessarily receiving single characters but packets and you could receive quite a few characters before XOFF has any effect.

m

----- Original Message -----
From: <[hidden email]>
To: <[hidden email]>
Cc: "Thom Cherryhomes" <[hidden email]>
Sent: Sunday, July 01, 2018 1:55 PM
Subject: Re: Developing PLATOTerm64, Flow Control woes.


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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> > > >
> > > > 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 <[hidden email]>
> > > >>
> > > >> 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 <[hidden email]
> > > >>>
> > > >>> 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.






Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Groepaz
you could increase the buffer size to something larger than the expected
maximum packet length.... not sure if that is an option in practise.

or perhaps modify the code so that a) you only send an XON when the buffer is
completely empty and b) send an XOFF immediatly when something was recieved.
with some luck that makes packet fragmentation kick in

that said... what you could also do is use RTS/CTS also (ie hardware
handshake). then the buffering in the modem and the automatic resending in the
ip stack should kick in

Am Sonntag, 1. Juli 2018, 21:50:05 CEST schrieb Thom Cherryhomes:

> Seeing as I am either using wifi modem emulators based on ESP8266, or
> ethernet cartridges running under IP65, what do I do?
>
> -Thom
>
> On Sun, Jul 1, 2018 at 2:47 PM Mike Stein <[hidden email]> wrote:
> > Keep in mind that XON/XOFF expects a fairly immediate response; a common
> > issue using it these days is that you're not necessarily receiving single
> > characters but packets and you could receive quite a few characters before
> > XOFF has any effect.
> >
> > m
> >
> > ----- Original Message -----
> > From: <[hidden email]>
> > To: <[hidden email]>
> > Cc: "Thom Cherryhomes" <[hidden email]>
> > Sent: Sunday, July 01, 2018 1:55 PM
> > Subject: Re: Developing PLATOTerm64, Flow Control woes.
> >
> >
> > 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 <[hidden email]> 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 <[hidden email]>
> > > >
> > > > 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 <
> >
> > [hidden email]>
> >
> > > > > > 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 <
> >
> > [hidden email]>
> >
> > > > > >> 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 <
> >
> > [hidden email]
> >
> > > > > >>> 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.


--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

The weirder you are going to behave, the more normal you should look... When I
see a kid with three or four rings in his nose, I know there is absolutely
nothing extraordinary about that person.
<P.J. O'Rourke>





Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Thom Cherryhomes
If that's the case, then I'm going to need some help to shove in a user port modem driver that can handle hardware handshaking into CC65's ser framework. I am not an assembler programmer.

-Thom

On Sun, Jul 1, 2018 at 4:13 PM <[hidden email]> wrote:
you could increase the buffer size to something larger than the expected
maximum packet length.... not sure if that is an option in practise.

or perhaps modify the code so that a) you only send an XON when the buffer is
completely empty and b) send an XOFF immediatly when something was recieved.
with some luck that makes packet fragmentation kick in

that said... what you could also do is use RTS/CTS also (ie hardware
handshake). then the buffering in the modem and the automatic resending in the
ip stack should kick in

Am Sonntag, 1. Juli 2018, 21:50:05 CEST schrieb Thom Cherryhomes:
> Seeing as I am either using wifi modem emulators based on ESP8266, or
> ethernet cartridges running under IP65, what do I do?
>
> -Thom
>
> On Sun, Jul 1, 2018 at 2:47 PM Mike Stein <[hidden email]> wrote:
> > Keep in mind that XON/XOFF expects a fairly immediate response; a common
> > issue using it these days is that you're not necessarily receiving single
> > characters but packets and you could receive quite a few characters before
> > XOFF has any effect.
> >
> > m
> >
> > ----- Original Message -----
> > From: <[hidden email]>
> > To: <[hidden email]>
> > Cc: "Thom Cherryhomes" <[hidden email]>
> > Sent: Sunday, July 01, 2018 1:55 PM
> > Subject: Re: Developing PLATOTerm64, Flow Control woes.
> >
> >
> > 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 <[hidden email]> 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 <[hidden email]>
> > > >
> > > > 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 <
> >
> > [hidden email]>
> >
> > > > > > 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 <
> >
> > [hidden email]>
> >
> > > > > >> 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 <
> >
> > [hidden email]
> >
> > > > > >>> 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.


--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

The weirder you are going to behave, the more normal you should look... When I
see a kid with three or four rings in his nose, I know there is absolutely
nothing extraordinary about that person.
<P.J. O'Rourke>





Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Mike Stein
In reply to this post by Thom Cherryhomes

When we ran into this issue on the Radio Shack M100 with its tiny fixed 64 byte buffer and no native hardware handshaking we went the other way from what groepaz suggested.
 
We couldn't easily increase the buffer size or implement HW HS, so we used USB and ethernet adapters that allowed setting the packet size to a very small number; they would then buffer the remaining packets until the XON released them and allowed more incoming packets.
 
m
 
 
----- Original Message -----
Sent: Sunday, July 01, 2018 3:50 PM
Subject: Re: Developing PLATOTerm64, Flow Control woes.

Seeing as I am either using wifi modem emulators based on ESP8266, or ethernet cartridges running under IP65, what do I do?

-Thom

On Sun, Jul 1, 2018 at 2:47 PM Mike Stein <[hidden email]> wrote:
Keep in mind that XON/XOFF expects a fairly immediate response; a common issue using it these days is that you're not necessarily receiving single characters but packets and you could receive quite a few characters before XOFF has any effect.

m

----- Original Message -----
From: <[hidden email]>
To: <[hidden email]>
Cc: "Thom Cherryhomes" <[hidden email]>
Sent: Sunday, July 01, 2018 1:55 PM
Subject: Re: Developing PLATOTerm64, Flow Control woes.


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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> > > >
> > > > 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 <[hidden email]>
> > > >>
> > > >> 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 <[hidden email]
> > > >>>
> > > >>> 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.






smf
Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

smf
In reply to this post by Mike Stein
On 01/07/2018 20:22, Mike Stein wrote:
> Keep in mind that XON/XOFF expects a fairly immediate response; a common issue using it these days is that you're not necessarily receiving single characters but packets and you could receive quite a few characters before XOFF has any effect.

The problem is large transmit fifo's and the uart neither understands
the concept of flow control, nor allows the driver to pause
transmission. If you also have a large dumb transmit fifo, then it may
be a while before you can tell the other end to stop sending (and if the
other end has sent an xoff then someone is going to be losing data).
This affects you whether you're using packets or an ascii terminal.

xon/xoff also shouldn't be used as an end to end flow control over a
modem/the internet as the transmit fifos in those will certainly swamp you.

sending xoff as soon as you start receiving and only sending xon once
all the data has been processed is as extreme as you can get, if that
doesn't work then the problem you're trying to solve is actually elsewhere.


Reply | Threaded
Open this post in threaded view
|

Re: Developing PLATOTerm64, Flow Control woes.

Mike Stein
I'm a little confused and don't quite understand what you're saying:

"The problem is large transmit fifo's "... "If you also have a large dumb transmit fifo"..."

Did you mean 'receive'?

"This affects you whether you're using packets or an ascii terminal"

Aren't we talking apples and oranges here? An ASCII terminal communicates with whatever it's connected to, whether that's a packet 'modem' of some kind, a 'normal' modem or a direct connection.

The bottom line IMO is that if it's available then RTS handshaking is the way to go; if not, and you can live with the 'no binary' restriction then end-to-end XON/XOFF flow control can work just fine over the internet.

With properly configured hard- and soft-ware, effective flow control is quite possible. Most of these devices are intended to transparently replace an RS-232 connection, so if it works over copper wire it should work just as well over USB, Ethernet, WiFi, whatever.

m

----- Original Message -----
From: "smf" <[hidden email]>
To: <[hidden email]>
Sent: Monday, July 02, 2018 4:10 AM
Subject: Re: Developing PLATOTerm64, Flow Control woes.


> On 01/07/2018 20:22, Mike Stein wrote:
>> Keep in mind that XON/XOFF expects a fairly immediate response; a common issue using it these days is that you're not necessarily receiving single characters but packets and you could receive quite a few characters before XOFF has any effect.
>
> The problem is large transmit fifo's and the uart neither understands
> the concept of flow control, nor allows the driver to pause
> transmission. If you also have a large dumb transmit fifo, then it may
> be a while before you can tell the other end to stop sending (and if the
> other end has sent an xoff then someone is going to be losing data).
> This affects you whether you're using packets or an ascii terminal.
>
> xon/xoff also shouldn't be used as an end to end flow control over a
> modem/the internet as the transmit fifos in those will certainly swamp you.
>
> sending xoff as soon as you start receiving and only sending xon once
> all the data has been processed is as extreme as you can get, if that
> doesn't work then the problem you're trying to solve is actually elsewhere.
>
>

12