[Coco] OS9 Programming question

[Bill Pierce]

Actually, I think I answered my problem by reading my own question (as usual). I noted in the previous response to Robert Gault that the signals were being sent to the keyin routine and being processed as a key read. As a temporary fix until I figure out why the chars are being sent to start with, I've added a filter to my input routine to filter any character below chr$(8) as the characters seem to be between 1-4 anyway. This way the arrow keys will still come through and it seems to have solved the problem.
This is only a temp fix. The real problem needs to be resolved in the player programs where the chars are being generated.

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: Bill Pierce <ooogalapasooo at aol.com>
To: coco <coco at maltedmedia.com>
Sent: Fri, Jan 18, 2013 1:07 pm
Subject: Re: [Coco] OS9 Programming question



Mr Gault,
First, the program is my Sound Chaser program. The forked programs are the 
players. 
If I didn't use the intercept, the <break> key would just terminate the players 
leaving midi notes hanging without sending a midi noteoff to the midi device 
which is an external device. The notes will then just play until the external 
midi device is reset. The intercept has to be there to direct the program to 
turn all notes off before exiting.
The overlay windows are created by the players and also removed on exit (either 
on end or break terminated).
Also, the calling program sets the "wait(0)" state after the fork to suspend 
operation until the forked program is terminated.
I'm beginning to think the problem is that the players being intercepted are 
returning ERROR #2 since the break key was pressed (according to the manual). 
Either that or the signal is being returned as well, but if it's a signal, it 
should be caught by the initial program's intercept. 
Also, in one of the player intercepts, there was a function that would print a 
warning if there is a "odd" signal (not 2 or 3). It was printing signal 4. 
According to the manual, signal 4 is S$Window - Window change. At this point, 
the process is still running and the overlay window is open. 

I never noticed this when playing individual songs. Now I have a selection 
routine that allows the user to select a list of songs and play them in order of 
selection. After playing a list of 20 songs, you get  20 screen "blips" when 
they're done. It's odd that it waits till all the songs are over and returns to 
the menu loop as the loop returns to the main program before calling the next 
player. Then it seems accept the errors/signals as keystrokes on the keyin loop. 
This is where the "blip" is occuring. I may need a way to clear the input 
buffer. fflush(STDIN/STDOUT/STDERR) does nothing (I tried all three). Which this 
would just throw them all out at one time anyway.

The calling routine looks something like:

for(sngnum = 0; sngnum <= numsng; sngnum++) {
    fname = selection[sngnum];
    args = parms[sngnum];
    os9fork(fname,len,args,1,1,80);
    wait(0);
}

any ideas?
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: Robert Gault <robert.gault at att.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Fri, Jan 18, 2013 12:16 pm
Subject: Re: [Coco] OS9 Programming question


Bill Pierce wrote:
>
> Hi guys,
> I have an OS9 program that runs a loop that forks several other programs in 
succession in overlay windows. Each program sets an intercept that catches the 
break key and terminates on break and goes to the next program until the loop is 

finished. When the loop exits and returns to the main window, all the "break" 
keys that were pressed in the other programs all echo to the main window. The 
screen redraws for each break key that was pressed for each of the programs that 

was run.
> Is there some way to clear those signals so they don't come back to the main 
program? The main program has it's own intercept which is reset on return, but 
it doesn't seem to do any good in this case. If I don't "break" the other 
programs and let them finish, the program runs fine on return.
> All the program are written in C and Asm.
>
> Any suggestions?
> Bill P
>

The OS-9 manual says an intercept routine prevents a process from terminating on 


a signal but you say you want the process to be killed. Do you also want the 
overlay windows to be removed? What happens if the forked programs do not have 
intercept routines?


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