UH2@PSUVM.BITNET (Lee Sailer) (02/08/89)
I have an ill-specified problem concerning the Director and WB 1.3.
I wanted to talk a little. My first approach was to
open rc, "speak:"
if rc = 0 etc etc etc
and then later
write "Hi. This is what the Amiga will say."
Now, there may be other causes, but I am having trouble with memory
fragmentation and out of memory errors with this approach. Also, it
seems to lose about 8K every time it runs. (No, I don't have any
overlapping blits.)
As an experiment, I also tried this approach:
execute rc, "echo >speak: Say this stuff, instead."
This works, but with other problems. (1) Even though echo, run,
and execute are "resident", a brief access to SYS: occurs for each
execute. (Addbuffers solves that problem, but what is it getting
from disk??) No more memory loss, and no more fragmentation, however.
(2) This is ARP echo. After several iterations of the debug cycle,
something really surprising happens. When the Director gets to the
statement
execute rc, "echo >speak: Welcome to the vissitor"
the trace output (opt t) shows that statement, but the Amiga voice
says, "You need ARP library vs. 33"
Bizarre, no? I'm sure you all can explain it, but I am mystified.
PS--This is an old version of Director (12/87), and I've sent in
for an upgrade, but the Director wizards offered no explanations.
THEY DID TALK TO ME about it, though, which was pretty nice of them.
leecmcmanis%pepper@Sun.COM (Chuck McManis) (02/09/89)
In article <70402UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: > execute rc, "echo >speak: Say this stuff, instead." > > This works, but with other problems. (1) Even though echo, run, > and execute are "resident", a brief access to SYS: occurs for each > execute. (Addbuffers solves that problem, but what is it getting > from disk??) No more memory loss, and no more fragmentation, however. For this to work, several things happen. The speak handler gets loaded from l:, the translator.library gets loaded from libs: and the narrator.device gets loaded from devs:. Additionally, execute uses C:RUN to kick off the process so if you don't have c: assigned to ram: it may cause a disk access. It is unclear to me at this time if Execute really cares if RUN is resident. >(2) This is ARP echo. After several iterations of the debug cycle, > something really surprising happens. When the Director gets to the > statement > execute rc, "echo >speak: Welcome to the vissitor" >the trace output (opt t) shows that statement, but the Amiga voice >says, "You need ARP library vs. 33" The echo command (ARP echo) will print the "You need..." message if the arp.library gets expunged from memory and either a) it can't load it from the current libs: directory, or b) there isn't enough contiguous memory to load it so the OpenLibrary() fails. Personally, I suspect the latter. Sounds like you are running right on the edge of memory availability in your system. Run perfmon (or what ever it is called, the one with the rabbit icon) and watch your memory usage to see if it drops way down. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
UH2@PSUVM.BITNET (Lee Sailer) (02/09/89)
In article <88923@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) says: >>(2) This is ARP echo. After several iterations of the debug cycle, >> something really surprising happens. When the Director gets to the >> statement >> execute rc, "echo >speak: Welcome to the vissitor" >>the trace output (opt t) shows that statement, but the Amiga voice >>says, "You need ARP library vs. 33" > >The echo command (ARP echo) will print the "You need..." message if >the arp.library gets expunged from memory and either a) it can't load >it from the current libs: directory, or b) there isn't enough contiguous >memory to load it so the OpenLibrary() fails. Personally, I suspect the >latter. Sounds like you are running right on the edge of memory availability >in your system. Run perfmon (or what ever it is called, the one with the Quite right, I am on the edge of my meager 512K, and that is the cause of most of my difficulties. However, the thing I found CURIOUS was that the ARP error message doesn't get *printed*, it gets *spoken*.