Re: A86: TI-86 interrupts, Part 2


[Prev][Next][Index][Thread]

Re: A86: TI-86 interrupts, Part 2




> Sorry pal, the interrupt (the real one at 38h) loads the
> keypresses to RAM, the call, _getkey, returns that keypress ....

Thank you for simply telling me a lot of stuff I already knew but
did not include in my last letter due to it's irrelevancy to the
question.  Simply stated, there are 2 routines.  One on an
interrupt that saves the last keypress.  Another that gets/clears
that keypress when called.  I simply used _getkey to refer to
both of them to avoid making my letter unnecessarily
complicated.  All he asked was how the interrupt was related
to _getkey.  He didn't ask what else the interrupt and _getkey
did.  That was totally irrelevant.  I was just explaining why
disabling the interrupt disabled _getkey.  Do you follow me?

> A final necessary (though eshful) comment:
> If nothing else, I hope you have learned a little about how the
> calc works.  Next time (again, I don't mean to sound like an
> asshole :-), try doing a little disassembly rather than guesswork.

Your letter sounded very much like a personal flame.  There's
no place for things like this on the list.  I definitely was not
guessing, just answering the question in the most basic
accurate way possible.  I would hope that you could avoid being
so quick to flame people, especially when they aren't wrong, PAL.

Another copy of the thread (just so that you can verify what I am saying):
>>> I don't mean to be an ass, but if _getkey is an interrupt, what isn't?
You
>>> call it when you want to, not when the CPU wants to.
>> 
>> _Getkey is actually running all the time.  When you call _getkey, it just
>> gives you what it has.  If _getkey were not running all the time, it would
not
>> be able to grab keypresses except when you called it (and that could
>> cost you the quick keypresses, even in keyloops).  As an interrupt, it's
>> able to give you the last key pressed, regardless of how long ago that
>> was, upon your request.

Note: reread the above paragraph keeping in mind _getkey refers to
both the interrupt and the routine.
 
> Sorry pal, the interrupt (the real one at 38h) loads the keypresses to RAM,
the
> call, _getkey, returns that keypress along with doing these other things:
load and
> run [sqrt]KEY if the appropriate flags are set, shut off the calc if the APD
timer
> is run out (APD timer / sub timer is decremented every interrupt), reset the
APD
> timer after a keypress, blink the cursor if _curTime is 0 (_curTime is
decremented
> once every interrupt and the cursor toggles once every 70 interrupts),
control
> cursor / flags for 2nd and alpha key presses, adjust the contrast if up or
down is
> pressed while the 2nd shift falg is set, read from the linkport and return a
> linkport value in a, load / send variables / send free memory if on the home
> screen and then force out (_jforce) once successful.
> 
> You can see how _getkey depends on the interrupt, but still, none of this
will
> happen unless _getkey is called.  Even if the APD timers time out, the calc
will
> not shut off unless you call _getkey.  If the interrupts are disabled, the
calc
> will not shut off when you call _getkey because the timers haven't been
> decremented.
> 
> But let me stress this: the link port is not checked unless _getkey is
called
> explicity (in your code).
> You have complete control as an asm programmer; nothing is running that you
didn't
> tell to run.
> 
> Try this: run a program that infintely loops around _getkey; when you plug
in a
> link and upload a variable, it will force out after loading the variable or
after
> reading the free memory.  Try it again on a program where _getkey isn't
called but
> where the interrupts are still running.  Result: error message telling you
to put
> the calc on the home screen.
> 
> A final necessary (though eshful) comment:
> This is a ridiculuous thread.  If nothing else, I hope you have learned a
little
> about how the calc works.  Next time (again, I don't mean to sound like an
asshole
> :-), try doing a little disassembly rather than guesswork.


Follow-Ups: