[Coco] Os9 Intercept

Bill Pierce ooogalapasooo at aol.com
Tue Oct 30 10:47:48 EDT 2012


I was reading old Delphi and CIS posts as well as notes on Bro. Jeremy's upgrade disks and there's lots of metions of the CWArea routines having problems. On the upgrade disks, Kvein Darling claims he fixed this in the Level 3 upgrades.
What I want to know is what modules handles the CWArea? Is it grfdrv? Or is it the SCF drivers cowin, covdg and cogrf?
I just checked the Ident on the grfdrv on Bro Jeremy upgrade and it's different from any other I have. I may try using it and see what happens. I don't know how much was added to grfdrv since then, but I think it's been more optimization and bug fix. I don't think things were move in or out of grfdrv... anyone confirm this?

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




-----Original Message-----
From: Retro Canada <retrocanada76 at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Tue, Oct 30, 2012 10:35 am
Subject: Re: [Coco] Os9 Intercept


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.


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!



-- 
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

 



More information about the Coco mailing list