Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II » Stopping Interrupts, inside of an interrupt.
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Stopping Interrupts, inside of an interrupt. [message #371487] Wed, 01 August 2018 10:33 Go to next message
Anonymous
Karma:
Originally posted by: Tom Porter

Suppose you have a need to setup and run an interrupt, but after that job is completed, you no longer want the CPU tax of checking constantly for interrupts, so you decide to shut it off... however the only way to know the task is done, is of course inside an interrupt itself. Seems trivial, but is it?

So of course you do the normal (SEI) statement, to shut off interrupts, and then it must exit its routine by...

NOW ENDINT
LDA #127
STA 50189
PLA
RTI

....for some reason it doesn't shut off the interrupt, and keeps going.

So experiment no2 is... a different ending routine... based upon task ending conditions.

NOW END.TASK
SEI
REM RING BELL
JSR 65338
PLA
TAX
PLA
TAX
PLA
RTI

this still keeps interrupts occurring. Its been confirmed by a beep this is the routine it takes once 'its job' is finished.

The only alternative is to place a marker in memory, and have the program constantly check it (occasional)... then do an SEI outside of the interrupt.... but that is VERY unpractical for this application.

Any obvious errors to the logic? -Tom
Re: Stopping Interrupts, inside of an interrupt. [message #371488 is a reply to message #371487] Wed, 01 August 2018 11:10 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
Tom Porter <laseractiveguy@gmail.com> wrote:
> Suppose you have a need to setup and run an interrupt, but after that job
> is completed, you no longer want the CPU tax of checking constantly for
> interrupts, so you decide to shut it off... however the only way to know
> the task is done, is of course inside an interrupt itself. Seems trivial, but is it?
>
> So of course you do the normal (SEI) statement, to shut off interrupts,
> and then it must exit its routine by...
>
> NOW ENDINT
> LDA #127
> STA 50189
> PLA
> RTI
>
> ...for some reason it doesn't shut off the interrupt, and keeps going.
>
> So experiment no2 is... a different ending routine... based upon task ending conditions.
>
> NOW END.TASK
> SEI
> REM RING BELL
> JSR 65338
> PLA
> TAX
> PLA
> TAX
> PLA
> RTI
>
> this still keeps interrupts occurring. Its been confirmed by a beep this
> is the routine it takes once 'its job' is finished.
>
> The only alternative is to place a marker in memory, and have the program
> constantly check it (occasional)... then do an SEI outside of the
> interrupt... but that is VERY unpractical for this application.
>
> Any obvious errors to the logic? -Tom
>

The status word loaded by the RTI re-enables interrupts. You need to modify
it on the stack prior to the RTI.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: Stopping Interrupts, inside of an interrupt. [message #371489 is a reply to message #371488] Wed, 01 August 2018 12:05 Go to previous messageGo to next message
qkumba is currently offline  qkumba
Messages: 1584
Registered: March 2013
Karma: 0
Senior Member
Something like this:

PHA
TXA
PHA
TSX
INX
INX
INX ;point to saved flags, accounting for the two PHAs, will need more adjustment if you saved Y, too
LDA $100,X ;it's unsafe to try LDA $00FD,X to avoid the INXs, in case X was < 3 at the time.
ORA #4 ;SEI
STA $100,X
PLA
TAX
PLA
RTI
Re: Stopping Interrupts, inside of an interrupt. [message #371495 is a reply to message #371487] Wed, 01 August 2018 13:42 Go to previous messageGo to next message
D Finnigan is currently offline  D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
Senior Member
Tom Porter wrote:
> Suppose you have a need to setup and run an interrupt, but after that job
> is completed, you no longer want the CPU tax of checking constantly for
> interrupts, so you decide to shut it off...

What? There's no CPU tax of checking for interrupts. The whole point of
interrupts is that the CPU *doesn't* have to check for anything. It just
happens.

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/
Re: Stopping Interrupts, inside of an interrupt. [message #371503 is a reply to message #371495] Wed, 01 August 2018 15:47 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Tom Porter

Thank you, the great Mahon and Qkumba!

As for this comment...
What? There's no CPU tax of checking for interrupts,

Everytime an interrupt goes off, the CPU has to stop what its doing, save pointers on the stack then jump to the interrupt code. Even if you could get by saving the A REG, check to see if (operation) was completed and exit, it still takes several hundred cpu cycles (at minimum)... once or twice isn't bad, but when interrupts are going like a couple hundred a second, you can easily eat up 20 to 30% of the cpu time. In the application this is headed, they need all the CPU they can get!

Thanks for the replies, i'm going to try this right now!- Tom
Re: Stopping Interrupts, inside of an interrupt. [message #371505 is a reply to message #371503] Wed, 01 August 2018 18:36 Go to previous messageGo to next message
D Finnigan is currently offline  D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
Senior Member
Tom Porter wrote:
> Thank you, the great Mahon and Qkumba!
>
> As for this comment...
> What? There's no CPU tax of checking for interrupts,
>
> Everytime an interrupt goes off, the CPU has to stop what its doing, save
> pointers on the stack then jump to the interrupt code. Even if you could
> get by saving the A REG, check to see if (operation) was completed and
> exit, it still takes several hundred cpu cycles (at minimum)... once or
> twice isn't bad, but when interrupts are going like a couple hundred a
> second, you can easily eat up 20 to 30% of the cpu time. In the
> application this is headed, they need all the CPU they can get!
>

That's called servicing an IRQ. I think you meant to say you wanted to avoid
the CPU overhead of servicing IRQs. The CPU doesn't check for IRQs, they
"just happen."

Which is why I didn't understand your initial remark.

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/
Re: Stopping Interrupts, inside of an interrupt. [message #371506 is a reply to message #371505] Wed, 01 August 2018 18:37 Go to previous messageGo to next message
D Finnigan is currently offline  D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
Senior Member
D Finnigan wrote:
> Tom Porter wrote:
>> Thank you, the great Mahon and Qkumba!
>>
>> As for this comment...
>> What? There's no CPU tax of checking for interrupts,
>>
>> Everytime an interrupt goes off, the CPU has to stop what its doing, save
>> pointers on the stack then jump to the interrupt code. Even if you could
>> get by saving the A REG, check to see if (operation) was completed and
>> exit, it still takes several hundred cpu cycles (at minimum)... once or
>> twice isn't bad, but when interrupts are going like a couple hundred a
>> second, you can easily eat up 20 to 30% of the cpu time. In the
>> application this is headed, they need all the CPU they can get!
>>
>
> That's called servicing an IRQ. I think you meant to say you wanted to
> avoid
> the CPU overhead of servicing IRQs. The CPU doesn't check for IRQs, they
> "just happen."
>
> Which is why I didn't understand your initial remark.
>

But what would Usenet be without helpful, pedantic posts like mine? ;-)

:-P
Re: Stopping Interrupts, inside of an interrupt. [message #371507 is a reply to message #371506] Wed, 01 August 2018 19:19 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Tom Porter

People can become confused with misinterpreted terms, so I forgive you, no harm done. I am having difficulty implementing the procedure above, its not shutting off interrupts, but I know exactly how the procedure works. Its odd, because I save the stack pointer to (6) and again to (7) after the ORA #4 but yet its still the same in both memory locations.... a bit strange. I'll figure it out, its gotta be really close.


>> That's called servicing an IRQ. I think you meant to say you wanted to
>> avoid
>> the CPU overhead of servicing IRQs. The CPU doesn't check for IRQs, they
>> "just happen."
>> Which is why I didn't understand your initial remark.
Re: Stopping Interrupts, inside of an interrupt. [message #371510 is a reply to message #371503] Wed, 01 August 2018 19:44 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
Tom Porter <laseractiveguy@gmail.com> wrote:
> Thank you, the great Mahon and Qkumba!
>
> As for this comment...
> What? There's no CPU tax of checking for interrupts,
>
> Everytime an interrupt goes off, the CPU has to stop what its doing, save
> pointers on the stack then jump to the interrupt code. Even if you could
> get by saving the A REG, check to see if (operation) was completed and
> exit, it still takes several hundred cpu cycles (at minimum)... once or
> twice isn't bad, but when interrupts are going like a couple hundred a
> second, you can easily eat up 20 to 30% of the cpu time. In the
> application this is headed, they need all the CPU they can get!
>
> Thanks for the replies, i'm going to try this right now!- Tom
>

If you just patch the first byte of the interrupt routine with an RTI,
you’re done in about a dozen cycles—but maybe you need to get precise
timings that interrupts would disturb.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: Stopping Interrupts, inside of an interrupt. [message #371515 is a reply to message #371510] Wed, 01 August 2018 21:57 Go to previous message
Anonymous
Karma:
Originally posted by: Tom Porter

What about the
LDA 69 thing?

> If you just patch the first byte of the interrupt routine with an RTI,
> you’re done in about a dozen cycles—but maybe you need to get precise
> timings that interrupts would disturb.
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Bit banging a serial port to simulate the IIC recorder on a IIC?
Next Topic: Jameco JE868 Manual
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 21:39:54 EDT 2024

Total time taken to generate the page: 0.06438 seconds