[Coco] noob question

[Randy Weaver]

Thank you for taking the time to respond in such detail.  I assure you, I am not trying to make the CoCo programming paradigm fit what I know.  I mention C# to let folks know where my head is so they might be able to help me understand (from that perspective) a different approach to achieving similar results.  And you have done that.  I know there are tons of ways to achieve the same goals in programming.  I just don't want to reinvent the wheel.  Perhaps I'll invent a better wheel later when I learn the lay of the land and what tools are available.

Again, REALLY appreciate the time you took.  It's a great start for me.

-Randy

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of William Astle
Sent: Tuesday, November 7, 2017 5:57 PM
To: coco at maltedmedia.com
Subject: Re: [Coco] noob question

Your main question can be surprisingly complex (which I think you already know based on your other comments). The only reason languages like C# can do event driven behaviour so "cleanly" or "simply" is because *something* is polling for events somewhere and managing wait queues for those events.

That means you have to have an event poller of some kind. Whether it's interrupt driven or a main loop that just busywaits until an event is detected doesn't matter. Or some frankenhybrid.

I can describe one way I've seen an event driven scheme implemented on the coco. That is the way Daggorath does it.

Daggorath uses the IRQ as a timer to "schedule" event processing. During the IRQ, if a "process" becomes ready by whatever timer criteria was sepcified, it is moved to a run queue. It is then up to that handler if it wants to re-schedule for later. The only thing the IRQ handler does is update timer counts and move things from the wait queues (different queues per timer tick length) to the run queue.

Then, the main game loop running outside of the IRQ handler checks the run queue. If there is nothing in it, it just waits for an interrupt and checks again. Otherwise, it removes the first item from the run queue and executes it. Later, rinse, repeat ad infinitum.

Now, Daggorath is entirely timer tick driven, but there's no reason you couldn't have other queues working on other sources. It can get arbitrarily complicated depending what you need to work with. (It also doesn't need all that much code. You just need to make sure you handle the concurrency issues correctly which is fairly straight forward on a single CPU system.)

(If you want to see how Daggorath actually does it, I have a disassembly at http://dod.projects.l-w.ca/ in the "hg" folder  which is a mercurial
repository.)

There are, of course, many ways to accomplish the same thing. One thing to consider is that you may not actually want an event driven structure even if you think you do. Make sure you're not trying to do event driven simply because that's what you're familiar with. Often times on a machine like the coco, you're better off with simple procedural stuff that just waits for the event that matters at the time (like a key press during a line input loop). I'm not saying your particular case is such a situation. Just that it is something to carefully consider since an event driver loop adds complexity.

Also, to answer your question on what happens if your IRQ processing overflows the "tick" length: it depends. The IRQ is level driven so as long as the signal is still present when your service routine exits, you will get an immediate re-entry to your service routine (not even a single instruction will execute between). Depending what you do in that IRQ service, other things could happen, including interrupts being missed or the IRQ service routine itself being interrupted by the next interrupt. Regardless, it's better not to do anything slow during an IRQ service routine so you don't have that problem in the first place. 
That's probably why Daggorath uses a run queue that the main loop processes but there are other strategies, too, depending on just what the use case is.

On 2017-11-07 02:23 PM, Randy Weaver wrote:
> I'm used to coding in c#... an event driven language.
> 
>   
> 
> Actions are hooked to events that "raise" a function I wrote to do 
> something.
> 
>   
> 
> I'm trying to wrap my head around how you would achieve similar 
> behavior on a coco.
> 
>   
> 
> I suppose a loop that kept polling for statuses that I'm interested in.
> 
>   
> 
> IRQs are interesting too but do they fire 60 times a second?  And what 
> happens when my check doesn't complete in 1/60th of a second. does it 
> fire again?
> 
>   
> 
> Guess I'm trying to get the basics here.
> 
>   
> 
> Thanks!
> 
> Randy
> 
> 


--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco