[Coco] noob question

[William Astle]

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
> 
>