[Coco] Os9 Intercept

Gene Heskett gheskett at wdtv.com
Tue Oct 30 10:49:03 EDT 2012


On Tuesday 30 October 2012 10:44:27 Retro Canada did opine:

> also writing to stdout is awfully slow. I wonder how apps like
> dynacalc manage to write fast both in level 1 and level 2 terms.
> 
That might be a little faster if you move the curser to the upper left 
corner of the cwarea first, then 'puts' the string(s).  printf in C tries 
to be all things to all people, so a printf(stdout,"Hello World") is 
something over 10k when built.

> On Tue, Oct 30, 2012 at 10:33 AM, Retro Canada <retrocanada76 at gmail.com> 
wrote:
> > I'm am using I$Write on stdout path in C with no luck either. I have
> > to fflush every time too. So I believe is not a C problem.
> > 
> > #define _IWRITE(a,x,y) { reg.rg_a = a;reg.rg_x = x;reg.rg_y =
> > y;_os9(I_WRITE,&reg); }
> > 
> > On Tue, Oct 30, 2012 at 10:16 AM, Bill Pierce <ooogalapasooo at aol.com> 
wrote:
> >> Thanx guys
> >> I just set my intercept back to the break catcher on return from the
> >> sub and that seems to get me out of a loop I was getting into.
> >> 
> >> Now if I can just convince "C" that I want everything I send to
> >> stdout printed on the screen without flush after every printf, I
> >> would be happy. The "C" print routines really suck. The CWArea
> >> prints are really screwed. As long as I stay in one area, I'm fine.
> >> As soon as I start to change areas, print, change again  and print
> >> again, "C" seems to buffer everything and dump it in the 2nd area.
> >> Flush seems to do no good. It's worse when the area is only 2-3
> >> lines long and I don't want CRs scrolling it. CRs seem to make it
> >> flush, but when you're dealing with a 2 line work area and have 2
> >> lines of info, you don't want to scroll it off the screen.
> >> Everything seems to work fine in overlays, it's just the cwarea that
> >> seems to not want to flush.
> >> 
> >> Bill P
> >> 
> >> Music from the Tandy/Radio Shack Color Computer 2 & 3
> >> https://sites.google.com/site/dabarnstudio/
> >> Bill Pierce
> >> ooogalapasooo at aol.com
> >> 
> >> 
> >> 
> >> 
> >> -----Original Message-----
> >> From: Gene Heskett <gheskett at wdtv.com>
> >> To: coco <coco at maltedmedia.com>
> >> Sent: Tue, Oct 30, 2012 9:45 am
> >> Subject: Re: [Coco] Os9 Intercept
> >> 
> >> On Tuesday 30 October 2012 09:38:48 Bill Pierce did opine:
> >>> Thanks Aaron, I think that's what I need. The real problem is
> >>> there's already an intercept running on the program that catches
> >>> the BREAK key. Then my ML sub to connect to DW (inline, same
> >>> program) sets up the intercept when it runs. I need to be able to
> >>> read the intercept & vector data address BEFORE it makes the call,
> >>> then I can restore it afterwards.
> >>> 
> >>> New question.. when you set the intercept.. do the calls stack, or
> >>> does it just wipe the old intercept and create a new one? Example:
> >>> 
> >>> set intercept 1...
> >>> program code..
> >>> 
> >>> set intercept 2
> >>> program code..
> >>> 
> >>> signal
> >>> jmp intercept 2..
> >>> jmp intercept 1..
> >>> return (RTI)
> >>> 
> >>> If it doesn't stack like this, then I can just reset the first
> >>> intercept and it should be fine.
> >>> 
> >>> thnx
> >>> Bill P
> >> 
> >> Since the size of the PD area is fixed, its my understanding that
> >> only the last intercept set by the F$Icpt call will be executed when
> >> the signal comes in.  IOW they do not stack.  OTOH, since they don't
> >> stack, I also don't believe there is a limit other than your
> >> imagination. :)
> >> 
> >>> Music from the Tandy/Radio Shack Color Computer 2 & 3
> >>> https://sites.google.com/site/dabarnstudio/
> >>> Bill Pierce
> >>> ooogalapasooo at aol.com
> >>> 
> >>> 
> >>> 
> >>> 
> >>> -----Original Message-----
> >>> From: Aaron Wolfe <aawolfe at gmail.com>
> >>> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> >>> Sent: Tue, Oct 30, 2012 4:47 am
> >>> Subject: Re: [Coco] Os9 Intercept
> >>> 
> >>> 
> >>> You can get the current intercept settings for a process from it's
> >>> process descriptor.  F$GPrDsc is one way, I think that works in user
> >>> mode.  There may be others, I am no OS9 expert.  In the PD your
> >>> intercept info is at +$36 but if you're using os9 defs you can use
> >>> the pretty names:
> >>> 
> >>> P$Signal       RMB       1                   Signal Code $36
> >>> P$SigVec       RMB       2                   Signal Intercept Vector
> >>> P$SigDat       RMB       2                   Signal Intercept Data
> >>> Address
> >>> 
> >>> hth
> >>> -Aaron
> >>> 
> >>> On Tue, Oct 30, 2012 at 12:42 AM, Bill Pierce
> >>> <ooogalapasooo at aol.com>
> >> 
> >> wrote:
> >>> > Hi Guys,
> >>> > In OS9, how do you reset an Intercept back to default after a
> >>> > program has set
> >>> 
> >>> it?
> >>> 
> >>> > I have a program that runs a function that uses a signal
> >>> > intercept. When the
> >>> 
> >>> function is called, the F$Icpt is set. The program will be
> >>> continuously running, but the intercept will no longer be needed
> >>> until the same function is called again. The lines that set the
> >>> intercept can be jumped over each time, but the intercept itself
> >>> does not need to in operation unless within that function, as it
> >>> interferes with the rest of the program. So, how would I go about
> >>> resetting the intercept address to what it was before the change. I
> >>> searched through both the "C" User's guide and the OS9 Tech
> >>> Reference manual and only found reference to setting the intercept.
> >>> 
> >>> > So, is there some way to call before the intercept is set to get
> >>> > the current
> >>> 
> >>> intercept address saved before I set the intercept?
> >>> 
> >>> > Thnx
> >>> > Bill P
> >>> > 
> >>> > Music from the Tandy/Radio Shack Color Computer 2 & 3
> >>> > https://sites.google.com/site/dabarnstudio/
> >>> > Bill Pierce
> >>> > ooogalapasooo at aol.com
> >>> > 
> >>> > 
> >>> > --
> >>> > Coco mailing list
> >>> > Coco at maltedmedia.com
> >>> > http://five.pairlist.net/mailman/listinfo/coco
> >>> 
> >>> --
> >>> Coco mailing list
> >>> Coco at maltedmedia.com
> >>> http://five.pairlist.net/mailman/listinfo/coco
> >>> 
> >>> 
> >>> 
> >>> --
> >>> Coco mailing list
> >>> Coco at maltedmedia.com
> >>> http://five.pairlist.net/mailman/listinfo/coco
> >> 
> >> Cheers, Gene
> >> --
> >> 
> >> "There are four boxes to be used in defense of liberty:
> >>  soap, ballot, jury, and ammo. Please use in that order."
> >> 
> >> -Ed Howdershelt (Author)
> >> My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
> >> The word "Windows" is a word out of an old dialect of the Apaches. 
> >> It means: "White man staring through glass-screen onto an
> >> hourglass..."
> >> 
> >> --
> >> Coco mailing list
> >> Coco at maltedmedia.com
> >> http://five.pairlist.net/mailman/listinfo/coco
> >> 
> >> 
> >> 
> >> --
> >> Coco mailing list
> >> Coco at maltedmedia.com
> >> http://five.pairlist.net/mailman/listinfo/coco
> > 
> > --
> > Panasonic FSA1-WSX
> > Commodore 64
> > Commodore 64C
> > Commodore 128
> > Apple //c
> > TRS-Color Computer 3
> > TI-99/4A
> > ..and more coming!


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
The world really isn't any worse.  It's just that the news coverage
is so much better.



More information about the Coco mailing list