News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Arnaud

[cpctelera] Interrupts example

Started by Arnaud, 19:08, 29 October 15

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Arnaud

Hello,

in this example the border color are flickering, is there a way to exactly change the color at the right moment ?

I tried to use cpct_waitVSYNC() just before launching the interruption in order to synchronize it with the VSync, but it doesn't work.

Arnaud.


ronaldo

Are you referring to CPCtelera's interrupt example? I don't see colors fickering: I see them fixed, with a minimal timing variation on changing one of them due to branch logic used in the interrupt handler.

What does it mean that you "use cpct_waitVSYNC() just before launching the interruption"? Do you mean you wait for VSYNC before setting the interrupt handler?

Arnaud

#2
Sorry, i really misspoke, i have used your example in my code and the color border are moving as not synchronised. And sometime order color change.

Quote from: ronaldo on 20:49, 29 October 15
What does it mean that you "use cpct_waitVSYNC() just before launching the interruption"? Do you mean you wait for VSYNC before setting the interrupt handler?

Yes exactly, i try something to force synchronisation.

ronaldo

Then that may be due to 2 possible circumstances:

       
  • Your interrupt handler being too large (or too large sometimes). Larger enough to run up till the next interrupt.
  • Part of your code disables interrupts and you are loosing some of them.
In CPCtelera, drawChar/drawString functions do disable interrupts when drawing.

Arnaud

#4
Quote from: ronaldo on 21:46, 29 October 15

       
  • Your interrupt handler being too large (or too large sometimes). Larger enough to run up till the next interrupt.
I have copy / paste the example code and i increase a timer variable.

Quote from: ronaldo on 21:46, 29 October 15

       
  • Part of your code disables interrupts and you are loosing some of them.
I don't use drawChar/drawString, and if the interrupts was disabled i shouldn't see the border color changes ? But they are always visible.


Is my main loop can be the problem ? i do a lot of things.

ronaldo

Quote from: Arnaud on 22:01, 29 October 15
I don't use drawChar/drawString, and if the interrupts was disabled i shouldn't see the border color changes ? But they are always visible.

Not exactly. You may be using functions that disable and reenable interrupts (like cpct_drawString does). Some firmware functions may do this, or some part of your code (may be some of your assembly functions). The problem you are describing clearly points to interrupts being lost, and that only happens if an interrupt comes when they are disabled.

Arnaud

Effectively i found functions in my code, cpct_scanKeyboard for example, that disable and reenable interrupts and make my border color not stable.

But how i can handle this problem ?

I try to put :

cpct_waitVSYNC();
cpct_setInterruptHandler(interruptHandler);

after each call of the functions that disable interrupts, but i'm sure it's not the good solution.

I also try to disable interrupts with the function cpct_removeInterruptHandler, but it's not in cpctelera firmware.h (it's internal function ?) and it crashes my program when i call it.

Maybe the current line to be drawn can be known in my interrupt function in order to set the right border color ?

ronaldo

Yes, you are right. If cpct_scanKeyboard is called and an interrupt comes in the middle, that interrupt gets lost.

At the present momment, you've got 2 solutions:

       
  • Ensure that cpct_scanKeyboard will be called at an interrupt-safe time. Depending on your code, you may be able to call it earlier or latter and ensure this.
  • Call cpct_scanKeyboard at the end of an interrupt. If you do this, be sure that interrupt's code is small enough not to take into the next interrupt or it may explode. This may happen because cpct_scanKeyboard enables interrupts at the end.
I'm adding a new scanKeyboard function to the task list: one specially designed to be used on interrupts, for cases like yours :).

arnoldemu

Quote from: ronaldo on 22:58, 16 November 15
Yes, you are right. If cpct_scanKeyboard is called and an interrupt comes in the middle, that interrupt gets lost.
I thought it would be delayed and trigger after the scan is done?
The CPC holds the interrupt until it is acknowledged.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

AMSDOS

Quote from: arnoldemu on 10:04, 17 November 15
I thought it would be delayed and trigger after the scan is done?
The CPC holds the interrupt until it is acknowledged.


Unsure if this relates to some BASIC programs I entered recently, which had the sort of Key Scanning Routines which weren't detecting Key press immediately. One of those programs (at least) I think was Looping back on itself until it found one of those keys had been pressed. Though wasn't sure if that's a case of an Interrupt being Lost?
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Powered by SMFPacks Menu Editor Mod