[Coco] Os9 Intercept

William Astle lost at l-w.ca
Tue Oct 30 17:27:46 EDT 2012 

On 12-10-30 03:19 PM, Bob Devries wrote:
> Hi all,
>
> Regarding the use of fflush() in C, it would be good to study pages 4-11
> and 4-12 of the C manual. I seem to remember also being able to set a
> bit to make the output unbuffered, but I'll need to study some of my
> code to see what I did.

Supposed to be "setbuf(stream, NULL);" to make a stream unbuffered. I 
just looked it up. (One is not supposed to twiddle with a FILE * directly.)

>
> Regards, Bob Devries
> Dalby, QLD, Australia
>
> ----- Original Message ----- From: "Retro Canada" <retrocanada76 at gmail.com>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Wednesday, October 31, 2012 12:33 AM
> Subject: Re: [Coco] Os9 Intercept
>
>
>> 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!
>>
>> --
>> 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

More information about the Coco mailing list