Newsgroups: comp.sys.hp48

SORRY!!!!!!!!!!!!
Obviously I did not make things very clear.
Thanks Joe Ervin for explaining about the interrupts.
These interrupts are what I was (or thought I was ) 
talking about.
These interrupts not olny affect machine language programs,
but can be heard in "user" RPL music programs and also 
interfere with high speed data transfer.
(try TSEND with the clock on and notice the retrys0)

When running a music program it is recommended that you 
turn the clock off first. Doing so in a program by clearing
flag -40 does not stop the interrupts until the program
stops and all other keypresses are caught up. So the
clock must be turned off before the program starts or
the program must be paused after it clears flag -40 and
then restarted.

ClrDA!IsStat will NOT stop these interrupts.
That is what the PMC at $?? #CEEAh does./

If the clock is turned on ( flag -40 is set ),
#CEEAh will stop the interrupts.
but (BUT!!!0)
BUT, #CEEAh will olny stop the interrups until there
is a pause.
So if it is used in a program that pauses, then the 
clock will come back on (the interrupts will start again )
unless flag -40 is cleared ( then the operating system will
turn the clock off and stop the interrupts ).

My question was:
Does anyone know if it is safe to use #CEEAh in a program
without any checks ( to check for interrupts ).
For example 
should it be used only when the clock ( and interrupts )
are active or can it be used any time.

Checking flag -40 does not work because the flag could
be set ( or cleared ) , but the clock will not start
( or stop ) until the HP48 is at a rest state ( paused
or at the end of the program and all the keypresses are
caught up ).

For example:
program 1 checks flag -40 and if it is set uses #CEEAh
to turn the interrupts off.

program 2 sets flag -40 and then cl?? calls program 1.

If the clock is off when program 2 is ran, then program 1
would use #CEEAh to stop the interrupts even though the
clock ( and the interrupts ) ahave not been started yet!!

This may be unessary?? unes?? (let me try agin0)

this may be unnecessary as, 
I have been using #cEEa??? #CEEAh without any check for
a couple of weeks without any problems.

It seems that #CEEAh is a location that has not been 
documented before.

It is called by "system" RPL programs in the ROM at
#48A9h and #DCDBh.

#$*
#48A9h does some checks and then cl?? calls either
#39AD8h (?SHOWTIME) or #CEEAh using "system" RPL
ITE.

#DCDBh seems to use #CEEAh without any checks.

I have traced #48A9h back to #42159 (GETKEY).
#42159h calls #4890h
#4890  calls #48A9h
and #48A9h calls #CEEAh

I have traced #DCDBh back to #42113h (ALARMxcp).
(This is better because #DCDBh does not seem to
use any checks when it calls #CEEAh0)
#42113 (ALARMxcp) calls #DC3Bh
#DC3Bh calls D?? #DCDBh
and #DCDBh calls #CEEAh

I hope this information is useful to someone out there.
I also hope you can follow what I have said.

sorry for the bad writing.

Any quistions???

Any questions or comments??
please send emial ( woops I must be getting tires?? tired )
please send e-mail to:
                     kirkland@ee.utah.edu

thanks

dan k

From: akcs.kirkland@hpcvbbs.cv.hp.com (Daniel B. Kirkland)
Date: Fri, 8 Jan 1993 04:40:01 GMT
Subject: Re: XOFF ??
Message-ID: <2b4d0199.2588.1comp.sys.hp48.1@hpcvbbs.cv.hp.com>