[Coco] Program won't stay loaded under NitrOS9/OS9
K. Pruitt
pruittk at roadrunner.com
Sun Jan 3 13:40:03 EST 2016
Hi Bill,
Sure, that'd be great. I'll toss it up on dropbox in a bit and send you an
email.
Thanks
----- Original Message -----
From: "Bill Pierce via Coco" <coco at maltedmedia.com>
To: <coco at maltedmedia.com>
Cc: "Bill Pierce" <ooogalapasooo at aol.com>
Sent: Saturday, January 02, 2016 12:46 PM
Subject: Re: [Coco] Program won't stay loaded under NitrOS9/OS9
> Kelly, do you mind if I take a look at the code? I may see an easy way
> around it.
>
>
>
>
>
> Bill Pierce
> "Charlie stole the handle, and the train it won't stop going, no way to
> slow down!" - Ian Anderson - Jethro Tull
>
>
>
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> Global Moderator for TRS-80/Tandy Color Computer Forums
> http://www.tandycoco.com/forum/
>
> E-Mail: ooogalapasooo at aol.com
>
>
>
>
>
>
> -----Original Message-----
> From: K. Pruitt <pruittk at roadrunner.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Sat, Jan 2, 2016 2:38 pm
> Subject: Re: [Coco] Program won't stay loaded under NitrOS9/OS9
>
> Thanks Bill. That was helpful to me.I've been avoiding using the sleep
> call as I figured it best not to attempt any system calls while interrupts
> are turned off. I initially had to turn off the interrupts or I was
> getting nothing from the S/SP cart when they were on. Now it works with
> the interrupts turned on but the speech is terminated prematurely.
> Utilizing an user interrupt sounds like a plan.There is a byte on the
> Speech/Sound Cartridge to monitor to see if the cart is still busy or not,
> so that is the delay in the program. Once it isn't busy then the program
> exits. If it takes 30 seconds for the thing to finish talking the computer
> is halted for that entire time with the interrupts disabled.. Highly
> unacceptable in a time-slice sharing OS, of course.----- Original
> Message ----- From: "Bill Pierce via Coco" <coco at maltedmedia.com>To:
> <coco at maltedmedia.com>Cc: "Bill Pierce" <ooogalapasooo at aol.com>Sent:
> Saturday, January 02, 2016 10:45 AMSubject: Re: [Coco] Program won't stay
> loaded under NitrOS9/OS9> Camillus, using the SWI in os9 would be
> disasterous. That instruction is > reserved for OS9 system calls and any
> SWI you insert manually would make > an unwanted system call.> The better
> solution would be to use a user interrupt and/or sleep calls. > The system
> definately should not be halted while waiting on sound to > play..> A good
> example of this is Ultimuse3. When using the serial port as a MIDI >
> output, Ultimuse3 has to block interrupts briefly for the data to be sent
> > through the port without interrupts (comm programs do the same), then >
> turns interrupts back on even though data is being sent at a pretty fast >
> rate (think playing 128th note runs). The program then waits until the >
> next needed clock tick (timed MIDI event) to occur before taking another >
> action, so what was done is after sending data, interrupts are turned back
> > on and the program sleeps for a small ammount of time (milliseconds)
> thus > halting program execution, then checks the clock to see if it's
> time to > wake up, if not, it loops and sleeps again until it's time.
> There's even a > clock "compensation routine" in the serial port routine
> that, based on the > number of bytes sent, adds milliseconds to the
> software clock tick count > to make up for the time the interrupts were
> off. It's pretty ingenious.> This method allows any other processes
> running in OS9 to continue working > until the the program needs to send
> more data.> You base the sleep time on the estimated length of time until
> the next > note (a known value). So Kelly could disable interrupts, send
> his data, > enable interrupts (the SS pak should not need interrupts
> blocked while > actually playing), then when the time is up, wake up and
> do it again..> Another thing is giving the program higher priority so that
> it gets bigger > and more frequent time slices on the interrupt polling
> table.> Ya gotta luv OS9 :-)>>>>> Bill Pierce> "Charlie stole the handle,
> and the train it won't stop going, no way to > slow down!" - Ian
> Anderson - Jethro Tull>>>> My Music from the Tandy/Radio Shack Color
> Computer 2 & 3> https://sites.google.com/site/dabarnstudio/>
> Co-Contributor, Co-Editor for CocoPedia>
> http://www.cocopedia.com/wiki/index.php/Main_Page> Global Moderator for
> TRS-80/Tandy Color Computer Forums> http://www.tandycoco.com/forum/>>
> E-Mail: ooogalapasooo at aol.com>>>>>>> -----Original Message-----> From:
> Camillus <camillus.b.58 at gmail.com>> To: Bill Pierce via Coco
> <coco at maltedmedia.com>> Sent: Sat, Jan 2, 2016 12:42 pm> Subject: Re:
> [Coco] Program won't stay loaded under NitrOS9/OS9>> Hi K.Just my $0.02
> worth. Would it not easier to divide the clock to 1/2 > system clock on
> your sound chip card. I presume the clock is from the > cartridge clock
> out? Then it would not be that difficult to half the clock > rate with
> some discrete logic. That gives you the freedom of NOT have to > mess with
> the HALT* interrupt. On the other hand if you really draw the > card of
> using interrupts, then why not write a good interrupt handler, and > using
> SWI for example? That code would store the system state on stack, >
> transfer the data to the sound ship and then resume normal operation. I'm
> > just not feel comfortable with using the *HALT, which to me is just
> needed > to do what it said, HALT. I also do not understand very well why
> you wait > to have the chip done making the noise you want, ( wait
> states ), because > I would presume that the processing in the chip is
> pretty fast. Well, just > some more things to think about...lol Success
> with your future > endeavors.cb Sent from Mailbird >
> [http://www.getmailbird.com/?utm_source=Mailbird&utm_medium=email&utm_campaign=sent-from-mailbird]On
> > 1/2/2016 10:37:20 AM, K. Pruitt <pruittk at roadrunner.com> wrote:Hi >
> Bill,Executing it from the command line works fine. It's just when it is >
> loadedit won't say in memory after execution. There are no external calls
> > fromthis program. I've created a little sandbox so to speak by shutting
> > offinterrupts. I have tried not turning off interrupts but then the
> speech > getsterminated prematurely when I do so. Ultimately to be at all
> useful it > willhave to work with interrupts enabled - but that's
> something for down > theroad a bit.I'm just screwing around with the
> speech and sound cartridge > here and tryingto learn some more about
> hardware programming. I've pretty > much crashed myCoCo every which way
> imaginable in the process. I am > learning in the processthough.Here is
> what I am doing...The code loads the > parameter in to a buffer, turns off
> the interrupts anddrops the Coco down > to 0.89Mhz.. Passes the parameter
> to the Speech./Soundcartridge a byte at > a time, wastes some time while
> the cartridge is speakingand then returns > the CoCo to 1.79Mhz, turns the
> interrupts back on and exitsthe > program.Thanks for the info on the link
> and load stuff. I will explore > that area.Thank you Bill.----- Original
> Message -----From: "Bill Pierce > via Coco"To:Cc: "Bill Pierce"Sent:
> Saturday, January 02, 2016 8:10 > AMSubject: Re: [Coco] Program won't stay
> loaded under NitrOS9/OS9> Did you > "load" the file before executing it?
> or just 'run' the file?> Even calling > another module from within a
> program, it must be loaded first> to keep it > residing in memory and
> unloaded when finished or it stays in> memory even > after you exit your
> program.> There is also another 'undocumented" method > of loading that
> allows you to> load a module without it's data space being > assigned and
> it will only use> up the amount of memory equal to the size > of the
> module (as opposed to the> 8k OS9 assigns on 'load'). It uses the >
> "NMLoad" call which is used the> same as load. This actually a low level >
> call and has been there for a long> time, but was never documented in any
> > of the docs. A sister call of> "NMLoad" is "NMLink" which does the same,
> > but links the file, again, using> less memory.> I also have "external" >
> versions of these commands "NMLoad" & "NMLink"> which are used like "Load"
> > & "Link" from the command line.>>>>>>> Bill Pierce> "Charlie stole the >
> handle, and the train it won't stop going, no way to> slow down!" - Ian >
> Anderson - Jethro Tull>>>> My Music from the Tandy/Radio Shack Color >
> Computer 2 & 3> https://sites.google.com/site/dabarnstudio/> >
> Co-Contributor, Co-Editor for CocoPedia> >
> http://www.cocopedia.com/wiki/index.php/Main_Page> Global Moderator for >
> TRS-80/Tandy Color Computer Forums> http://www.tandycoco.com/forum/>> >
> E-Mail: ooogalapasooo at aol.com>>>>>>> -----Original Message-----> From: K.
> > Pruitt> To: Coco> Sent: Sat, Jan 2, 2016 10:59 am> Subject: [Coco]
> Program > won't stay loaded under NitrOS9/OS9>> What conditions would
> cause a module > to not stay loaded but remove itself> from memory after
> it is executed one > time? I'm not generating an error of> any sort and
> the system does not > destabilize.In my code I am halting the> interrupts
> and turning them back > on when I am done. Would that cause such> a
> scenario to occur? -- Coco > mailing> >
> listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco>>
> > --> Coco mailing list> Coco at maltedmedia.com> >
> https://pairlist5.pair.net/mailman/listinfo/coco>--Coco mailing >
> listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco--
> > Coco mailing >
> listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco>>
> -- > Coco mailing list> Coco at maltedmedia.com>
> https://pairlist5.pair.net/mailman/listinfo/coco> -- Coco mailing
> listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
More information about the Coco
mailing list