Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-106.txt

Text File | 1994-12-08 | 41.2 KB | 1,052 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 08 Jun 92       Volume 1 : Issue 106

Today's Topics:

    Writing a DRIVER (for inter-app comm)
    Console Emulation
    Phase2 zone setting
    Macsbug - Novice questions
    Marksman/AppMaker comments?
    Sampled sound buffers & Sound Muncher
    Good language and debugger for Mac
    Finding out if the debugger is installed


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Jim Cathey)
Subject: Writing a DRIVER (for inter-app comm)
Date: 23 Apr 92 16:59:18 GMT
Organization: ISC-Bunker Ramo, Spokane, WA

Perhaps some guru can help me.  I'm trying to do 'clean' inter-
application communications for a pair of my programs.  For System 7,
I will look into (and probably use) whatever is there for this.  For
System 3.2-6.X, I am trying to use a dummy driver for this purpose.
The idea is to avoid burning time spent polling by having the server
application post an asynchronous read to the driver.  (Just one more
async read up of the many it's already set up to handle.)  Then,
whenever the client wishes to trigger the server it just does an
immediate write to the driver (it has to be immediate otherwise the
write will just be queued behind the read that is already there.)

The problem is that the Device Manger documentation is almost opaque
when it comes to _actually_ writing a driver!  I can't figure out how
to have the Prime routine complete more than one request at a time
(both the current, immediate one and the queued asynchronous one).  It
implies that you can do either one or the other, but not both.  I've
tried JSR-ing to JIODone (instead of jumping to it) to complete the
queued routine, and then returning to the DM to complete the immediate
write, but this doesn't seem to work.  Disassembly (via MacsBug) of
the IODone routine didn't really help, it's what led me to try the
double-return trick.

I really don't want to have to try to play games with dNeedTime, nor
do I want to put in a VBL task to poll the driver.  We're back to
burning machine time again this way, and it would probably be simpler
(and a lot less clean) to search the heap zones for the server and
poke around in a memory mailbox.  I _don't_ want to do this, any more
than I want to patch traps (or vote for Duke :-).

This should be a simple event-driven driver.  The only thing that
changes the driver's state is the various incoming requests, so these
requests should be able to trigger all required action right then and
there, without leaving messages for various timers and pollers to find
later (which besides being ugly and complex slows down the whole
process).

I suppose I could de-queue the PB's myself and call their completion
routines, and figure out how to make the DM like this (using that
MacsBug disassembly), but this is also ugly, and shouldn't be necessary.

What am I missing?

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc ([e-mail])
! II      CCCCCC !  [phone]
+----------------+
            "PC's --- the junk bonds of the computer industry"

+++++++++++++++++++++++++++

From: [e-mail] (Aaron Wohl)
Date: 23 Apr 92 19:17:48 GMT
Organization: Special Projects, Carnegie Mellon, Pittsburgh, PA

For an exmaple device driver see host akutaktak.andrew.cmu.edu
[128.2.35.1] path /aw0g/mailcheck.sit.hqx.  It is a driver I wrote that
checks your unix mail.  It is dynamicly installed into a free unit table
slot.

For a discussionof the JIODone business see the think c user reference
manual.  IO request can only compleat in order.  The drivers like MacTCP
that allow multiple async request do this by removing the request from
the queue and simulating the done routine themselfs.  The JIODone
business works by putting the right stuff in register and jumping to
JIODone which compleats the front item in that drivers queue.  There
isn't a way to directly compleat more than one request or a request
other than front one.   If you are doing this kind of stuff I highly
recommend Nosy/THE debugger from Jasik designs.  With them you can
browse through other drivers and the ROM and see what is going on.

Aaron

+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Date: 23 Apr 92 20:50:24 GMT
Organization: University of Illinois at Urbana

[e-mail] (Jim Cathey) writes:

>The problem is that the Device Manger documentation is almost opaque
>when it comes to _actually_ writing a driver!  I can't figure out how
>to have the Prime routine complete more than one request at a time
>(both the current, immediate one and the queued asynchronous one).  It
>implies that you can do either one or the other, but not both.  I've
>tried JSR-ing to JIODone (instead of jumping to it) to complete the
>queued routine, and then returning to the DM to complete the immediate
>write, but this doesn't seem to work.  Disassembly (via MacsBug) of
>the IODone routine didn't really help, it's what led me to try the
>double-return trick.

I think JSR-ing to IODone should do it. This should remove the request
from the queue, call the completion routine, set ioResult, and move
the next thing to the head of the queue and wait for the next
SystemTask. Then it should return to where you JSR-ed from, at which
point you can RTS directly to the immediate call. Re-entrancy *might*
be a problem, but I don't really see how.

One other possibility if this doesn't work is to have two device
drivers, one for the read and one for the write. The one you write to
can JMP to IODone for the one you read from. This seems pretty silly
and I think your original solution should probably work.

PS: The other person who followed up to this mentioned seeing the
THINK C manual for info about IODone. Don't bother. THINK C does not
in the least take care of calling IODone after you have returned
inProgress from the driver; it is all up to you after that.

If you need more help, feel free to e-mail.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Andy Peterman)
Date: 25 Apr 92 18:33:00 GMT
Organization: The Treehouse

In article <[e-mail]-> [e-mail] (Pete Resnick) writes:
- ->[e-mail] (Jim Cathey) writes:
- ->
- ->->The problem is that the Device Manger documentation is almost opaque
- ->->.....
- ->
- ->I think JSR-ing to IODone should do it. This should remove the request
- ->from the queue, call the completion routine, set ioResult, and move
- ->the next thing to the head of the queue and wait for the next
- ->SystemTask. Then it should return to where you JSR-ed from, at which
- ->point you can RTS directly to the immediate call. Re-entrancy *might*
- ->be a problem, but I don't really see how.
- ->
- ->One other possibility if this doesn't work is to have two device
- ->drivers, one for the read and one for the write. The one you write to
- ->can JMP to IODone for the one you read from. This seems pretty silly
- ->and I think your original solution should probably work.
- ->

I ran across a similar problem writing a driver and ended up with two
drivers, one for write and one for read.  I believe this is the only way
to have asynchronous reads and writes.  One problem with this is that
they have to share common memory - I ended up using the same storage for
dCtlStorage.  Also, it would be tricky communicating between them.

An easier solution might be to use a Control call instead of a Write.  A
Control call should make it through to a driver with a pending Read or Write.

- --
Andy Peterman
treehouse![e-mail]
[phone]

+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Sat, 25 Apr 1992 20:32:56 GMT

[e-mail] (Andy Peterman) writes:

[Regarding device driver calls]

>An easier solution might be to use a Control call instead of a Write.  A
>Control call should make it through to a driver with a pending Read or Write.

That won't work. There is only one queue. Only immediate calls will
get through. Remember that's *immediate*, not just synchronous. The
Device Manager headers (at least in MPW C and THINK C) do not have
prototypes for immediate calls, only asynchronous and synchrounous.
Those will be queued.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 26 Apr 92 02:42:18 GMT

In <[e-mail]> [e-mail] (Pete Resnick) writes:

>PS: The other person who followed up to this mentioned seeing the
>THINK C manual for info about IODone. Don't bother. THINK C does not
>in the least take care of calling IODone after you have returned
>inProgress from the driver; it is all up to you after that.


In the section in the THINK C manual (version 4 or 5 -- they both have
it) describing the THINK DA glue (to allow the writing of a DA without
using even one line of assembly), it gives a moderately detailed
description of how the glue resolves the RTS/IODone question.  This is
the best discussion I've seen on this problem.

Note that this is described in the section on DAs, not DRVRs.  Sorry,
I can't supply page numbers as my manual is at home.

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 24 Apr 92 21:32:55 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Jim Cathey) wrote:
>
> I will look into (and probably use) whatever is there for this.  For
> System 3.2-6.X, I am trying to use a dummy driver for this purpose.

Issue 3 of develop has an article about writing a driver in C++ that implements
exactly this.
- -----
Larry Rosenstein
Taligent, Inc.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 24 Apr 92 21:36:15 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Larry Rosenstein) wrote:
>
> Issue 3 of develop

I made a mistake.  It's issue 4.

+++++++++++++++++++++++++++

From: [e-mail] (Jim Cathey)
Date: 27 Apr 92 22:45:05 GMT
Organization: ISC-Bunker Ramo, An Olivetti Company

In article <[e-mail]> [e-mail] (Pete Resnick) writes:
>>The problem is that the Device Manger documentation is almost opaque
>>when it comes to _actually_ writing a driver!  I can't figure out how
>>to have the Prime routine complete more than one request at a time
>>(both the current, immediate one and the queued asynchronous one).  It
>>implies that you can do either one or the other, but not both.  I've
>>tried JSR-ing to JIODone (instead of jumping to it) to complete the
>>queued routine, and then returning to the DM to complete the immediate
>>write, but this doesn't seem to work.  Disassembly (via MacsBug) of
>>the IODone routine didn't really help, it's what led me to try the
>>double-return trick.
>
>I think JSR-ing to IODone should do it. This should remove the request
>from the queue, call the completion routine, set ioResult, and move
>the next thing to the head of the queue and wait for the next
>SystemTask. Then it should return to where you JSR-ed from, at which
>point you can RTS directly to the immediate call. Re-entrancy *might*
>be a problem, but I don't really see how.

Well, I got things to work finally.  I had to simplify what I was
trying to do (and fix some bugs too), but I think I will be able
to make everything work that I need to.  I end up posting a single
ASYNC read from my server.  The client program then can do an
IMMEDIATE write, which will kick things loose.  I only have one
pending read up, so JSR'ing to IODone and then returning from the
Prime routine seems to be adequate.  All other requests are done
as IMMEDIATE PBControl calls so they don't get queued.  They're
ugly, in that they use ioBuffer (and other I/O fields that aren't
formally defined in the control versions of the structures) in
order to do READs and WRITEs that don't disturb the asynchronous
I/O queue.  Ick.

>One other possibility if this doesn't work is to have two device
>drivers, one for the read and one for the write. The one you write to
>can JMP to IODone for the one you read from. This seems pretty silly
>and I think your original solution should probably work.

Now _that's_ ugly!  One of these bletcherous beasts is bad enough!

I had to put the driver in the system heap, even though I didn't
want to, because it seems to disappear from the unit table on a
major switch (sometimes, anyhow) and can't be found by my client
application if the driver's in the server's heap.

I've got another problem:  After all that work to split off the
connection initiation action into another application (so there
can be 'documents' to open), the damned connections end up opening
in the non-frontmost layer!  The trigger application comes and goes,
and the _Finder_ is what ends up in front when the server is finally
able to establish the connection.  Some months it doesn't pay to
get out of bed...

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc ([e-mail])
! II      CCCCCC !  [phone]
+----------------+
            "PC's --- the junk bonds of the computer industry"

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 4 May 92 21:58:04 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Larry Rosenstein) writes:
>
> In article <[e-mail]>, [e-mail] (Jim Cathey)
wrote:
> >
> > I will look into (and probably use) whatever is there for this.  For
> > System 3.2-6.X, I am trying to use a dummy driver for this purpose.
>
> Issue 3 of develop has an article about writing a driver in C++ that
implements
> exactly this.

Unfortunately the example is broken under MPW 3.2. What we do
inside DTS is to send a PD package - found at CompuServe for instance -
that shows how to create a fake app, and then a special tool (part
of this distribution) moves the jump table entries and any other
global data back to the one and only segment. As for an Apple solution,
don't ask me when we will get this one. I do know that we have
reinvented the same tools inside engineering a couple of times, but
it takes a lot of energy to get those tools supported and released.

Cheers,
Kent Sandvik/DTS
..but not speaking for DTS...
Born Again Dynamic Language Programmer

---------------------------

From: [e-mail] (Sting)
Subject: Console Emulation
Date: 27 Apr 92 13:26:30 GMT
Organization: Dartmouth College, Hanover, NH

Greetings!

I'm trying to figure out how to emulate a glass terminal using THINK C and
the Macintosh ROM toolbox.  I know the THINK package contains a console and
an ANSI package that emulate that sort of thing, but according to the specifi-
cations, these packages can't be used for input, and that's not good.

My thoughts are that I could use the toolbox TextEdit stuff to maintain the
text window itself, and get command lines by reading the last line in the
buffer whenever the user hits return or enter.  Actually parsing the command
line is easy, as long as I can get the line into its own data structure.

Finding the number of the last line is easy enough (it would be the value of
the hte.teNLines field), and I can get the linestart from the teLines array,
but does anyone have any idea as to how I could then copy that line into a
C-string somewhere?

Also, does anyone know a good way to add lines from a separate buffer to the
end of a TextEdit record without having to make copies of the entire text
block?

Thanks!
- -Mike

P.S.-  Please email any responses you post in addition to posting them.
       Thank you!




- --
Michael J. Fromberger            | With every prison blown to dust
Composer, Guitarist            | My enemies walk free
[e-mail]                     | I'm mad about you,
Kiewit Computation Ctr. Student Asst.    | I'm mad about you ... (Sting)

+++++++++++++++++++++++++++

From: [e-mail] (Brent)
Organization: Texas A&M Univ., Inc.
Date: Wed, 6 May 1992 16:24:31 GMT

[e-mail] (Sting) writes:
| [tty emulation...], but according to the specifi-
|cations, these packages can't be used for input, and that's not good.

What kind of input are you talking about?  Sure you can.  You can get
lines read by using the familiar scanf().

But anyway, read on; I'm doing something similar...

|My thoughts are that I could use the toolbox TextEdit stuff to maintain the
|text window itself, and get command lines by reading the last line in the
|buffer whenever the user hits return or enter.

That's what I did.  I created a normal window with a scroll bar and a text
area.  Initially, a prompt is printed (length of prompt string is known).
I have checks in there so that when the user presses backspace, and if the
current insertion position is not within the [0 - (prompt_length-1)] range,
then I delete the character (this makes the prompt unchangeable).  The user
may enter characters/text as usual, copy/paste, etc and then when the user
presses <enter>, that's when I read what was written.  After I would process
their entered stuff, a new prompt is printed and the cycle continues.

|Finding the number of the last line is easy enough (it would be the value of
|the hte.teNLines field), and I can get the linestart from the teLines array,
|but does anyone have any idea as to how I could then copy that line into a
|C-string somewhere?

Whenever you want to get text out of a textEdit record without munging with
the record yourself, you have to do some text editing from within your app.
Ex:    Text = "The cow jumped over the moon"
               0123456789012345678901234567  (character positions)

If you wanted the string "jumped over", you would call:
  TESetSelect( te_handle, 8,18);      /* check the parameter order here */
  s = TEGetText( te_handle);          /* this copies the selected text; again,
                                         lookup the params on this.         */
  TESetSelect( te_handle, 32767, 32767);  /* moves cursor back to end of TE */

|Also, does anyone know a good way to add lines from a separate buffer to the
|end of a TextEdit record without having to make copies of the entire text
|block?

Yep.
  char buf[]="This is added to the end.";
  TESetSelect( te_handle, 32767,32767);  /* move to end; changes insert. pt. */
  TEInsert( te_handle, buf, strlen(buf)); /* add text at insertion point */


Please don't flame me if my TE function names/parameters are not exactly
right - it's hard coding macs by memory (ever try Xlib? ;-).  Look up the
similarly-named calls in Inside Mac for the real details.

The code I have written that implements this "console" will be freely
available.  It's done and is working, and it is stable.  Unfortunately,
today is the last day of classes and finals start Friday.  I'll try to get
this out asap, however.

- -Brent
- --
- ------------------------------------------------------------------------------
Brent P. Burton, N5VMG                                    Computer Sci/Physics
[e-mail]                                   Texas A&M University
- ------------------------------------------------------------------------------

---------------------------

From: [e-mail] (David R. McGee)
Subject: Phase2 zone setting
Date: 1 May 92 02:16:20 GMT
Organization: Pacific Northwest Laboratory

What we need one of you excellent network mangement software developers or
freeware developers to do is write some code that will remotely set an
ethernet connected Macintosh in a certain phase2 zone.

David R. McGee
Network Manager
Pacific Northwest Laboratory
Battelle Boulevard, M/S K1-88
Richland, WA 99352
[phone]
ALINK drmcgee
internet [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Throop Wilder)
Date: 5 May 92 17:40:08 GMT
Organization: Wilder Systems/Trik Product Group

In article <[e-mail]> [e-mail] (David R. McGee) writes:
>What we need one of you excellent network mangement software developers or
>freeware developers to do is write some code that will remotely set an
>ethernet connected Macintosh in a certain phase2 zone.
>
>David R. McGee
>internet [e-mail]

Our NetDistributor 2.0 product (still in beta) can do this right
now. If you're interested in this kind of functionality, drop
me a line.

Throop

PS. NetDistributor lets you install/update software remotely on
local/ether/tokentalk nets.

---------------------------

From: [e-mail] (Bradley Green )
Subject: Macsbug - Novice questions
Date: 6 May 92 00:08:32 GMT
Organization: University of Pennsylvania

I just ftp'ed Macsbug from the apple site, and found no information
included on how use use/run it.  Furthermore, when I uncompressed the
files, I found nothing resembling an executible application or a
system extension.  So how does one go about using this thing?  Is there
a free manual avaliable, and I just missed it.

Thanks for your response.

- --
*----------------------------------------------------------------------------*
* Bradley S. Green                University of Pennsylvania   *
* [e-mail]            Dept. Of Systems Engineering *
*----------------------------------------------------------------------------*

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Hall)
Date: 6 May 92 20:51:58 GMT
Organization: Oberlin College Computer Science

In article <[e-mail]> [e-mail] (Bradley Green ) writes:


>   I just ftp'ed Macsbug from the apple site, and found no information
>   included on how use use/run it.  Furthermore, when I uncompressed the
>   files, I found nothing resembling an executible application or a
>   system extension.  So how does one go about using this thing?  Is there
>   a free manual avaliable, and I just missed it.
>
>   Thanks for your response.

Well, there is no free manual.  Sorry.  You can buy it at your local
software etc. for around $16.

Macsbug is not an extension, it's a debugger.  To install it, drag it
into your system folder (for all systems) and reboot.  The message
"Macsbug installed" or "Debugger installed" should then appear under
the "Welcome to Macintosh" message in the opening alert.
    To enter it, hit the programmers switch (little plastic tab on
some macs, or
control-command-funny-key-that-looks-like-a-backward-triangle-aka-power-key
if you don't have the programmers switch.  Type ? for a little help.

- -matt hall
- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


---------------------------

From: [e-mail] (Chris Silverberg)
Subject: Marksman/AppMaker comments?
Date: 6 May 92 03:49:07 GMT
Organization: Worcester Polytechnic Institute

Greetings.

I am looking for some feedback on either Marksman or AppMaker from the
people who are using them... I currently program with THINK C 5.0, and
although I'm just using regular C, I may start working with the TCL later
on.  I'm also looking for comments from people who use both... like, if
I were trapped on a desert island, and I could only have one... which one
should I choose? ;-)

Thanks... please email.
- - Chris
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   Chris Silverberg                     INTERNET: [e-mail]
   Worcester Polytechnic Institute      WMUG BBS  508-832-5844 (TeleFinder)
   America Online: TfChris              FIDONET:  1:322/115.1

+++++++++++++++++++++++++++

From: [e-mail] (Mr. Neb)
Date: 6 May 92 16:38:17 GMT
Organization: Bowling Green State University B.G., Oh.

[e-mail] (Chris Silverberg) writes:
> I am looking for some feedback on either Marksman or AppMaker from the
> people who are using them... I currently program with THINK C 5.0, and
> although I'm just using regular C, I may start working with the TCL later
> on.  I'm also looking for comments from people who use both... like, if
> I were trapped on a desert island, and I could only have one... which one
> should I choose? ;-)

    I have used Marksman, as well as it's predecessor called
Prototyper.  It's a very nice package, overall.  You set up your program
visually, creating menus and windows etc.  You can even run the "program"
to see how things will work together.  You can test the way that things
link together to get a basic idea of how your finished program will run.

    The only thing that I don't care for about either of these programs
is the large amount of repetitive code that these programs can generate.  In
most cases this is hard to run into, but if you have a large window stuffed
with textedit items, both Prototyper and Marksman generate a lot of
repetitive code instead of using a single procedure that could be called
over and over.

    Generating code with the comments is just horrid.  I comment a good
bit of the time to let myself know what's going on, but these programs
comment every line.  And if you turn the commenting off, sometimes it is
hard to understand just where the code is going.  I am not trying to say that
it is not good code, but it is like trying to read someone elses code and
understand just what they were thinking when they wrote it.

    Enough of the Marksman and Prototyper bashing though.  They are two
very good programs that can take a lot of time out of the development cycle.
The code that is generated is (most of the time) very good and
understandable.  I would recommend them to anyone.

    Just my $0.02,

    Dave Nebinger
    [e-mail]

---------------------------

From: kelly@clio (Kelly Fitz)
Subject: Sampled sound buffers & Sound Muncher
Date: 6 May 92 19:03:16 GMT
Organization: University of Illinois at Urbana


How can I make the Mac Sound Manager play sample buffers? I'm reading up
sixteen bit sample files, converting them to eight bit samples, putting them
in a buffer, and trying to play them through the Mac speaker.
I have tried creating SoundHeaders and passing them with the SoundCmd
bufferCmd, but I get no sound. When I check the Sound Channel Status, I
find that the channel is busy, but the StartTime, EndTime, and CurrentTime
are all zero. I allocated the Sound Channel ahead of time with no errors.
Moreover, when I procede to dispose of the Sound Channel, the Mac loses
its lunch.

Has anyone gotten this stuff to work? The documentation and error reporting
are so complete that I can't figure out why it's not making any noise.
(My sarcasm bit is set)

The most useful thing for me would be a working code fragment which plays
buffers on the sampledSoundSynth.

- -Kelly Fitz
CERL Sound Group
University of Illinois, Urbana
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Wed, 6 May 1992 20:30:23 GMT

kelly@clio (Kelly Fitz) writes:
>
>How can I make the Mac Sound Manager play sample buffers?
>I have tried creating SoundHeaders and passing them with the SoundCmd
>bufferCmd, but I get no sound. When I check the Sound Channel Status, I
>find that the channel is busy, but the StartTime, EndTime, and CurrentTime
>are all zero. I allocated the Sound Channel ahead of time with no errors.
>Moreover, when I procede to dispose of the Sound Channel, the Mac loses
>its lunch.

It's very hard to figure out what's going on here, without a snippet of
the actual code.  My guesses would be, roughly in order of probability:

Your qLength is zero.
Your header is bad.  Check the sampleRate and baseFrequency fields
especially.
Your callback routine is crashing silently.
Your SndChannel is relocatable.  Like GrafPorts, SndChannels can't move
around, or the system loses track of them.
Cosmic rays.

>Has anyone gotten this stuff to work?

Three or four people.  Two are presently in institutions, one has
renounced computers and taken a vow of silence, and one vanished under
mysterious circumstances in November of 1989.

>The most useful thing for me would be a working code fragment which plays
>buffers on the sampledSoundSynth.

I'm planning on really, truly finishing up a Think C 5 class that
handles sound well, sometime in the next week or so.  I'll keep you
posted.

In the meantime...hmmm...well, OK, let's try this.  (None of the
following code was tested.  If it doesn't work, email me and I'll try to
figure out what's going on.)

void playSound(short sndRsrcID)
{
    SndChannelPtr mySndChannelPtr;
    SndCommand mySndCommand;
    Handle mySndRsrc;
    long theOffset;
    OSErr myOSErr;

    mySndChannelPtr = NewPtrClear( sizeof(SndChannel) );
    FailNIL(mySndChannelPtr);
    mySndChannelPtr->qLength = 128;
    FailOSErr(SndNewChannel(&mySndChannel, sampledSynth,
        initMono, NULL);

        /* Try a 'snd ' from the System file first, to make sure
         * it isn't bad data.  I like "Quack."
         */
    mySndRsrc = GetResource('snd ', sndRsrcID);
    FailNIL(mySndRsrc);
    HLock(mySndRsrc);

        /* This function defined later... */
    theOffset = offsetToSoundHeader(mySndRsrc);

    mySndCommand.cmd = bufferCmd;
    mySndCommand.param1 = 0;
    mySndCommand.param2 = *mySndRsrc + theOffset;

        /* Passing TRUE for "noWait" is somewhat trickier. */
    FailOSErr(SndDoCommand(mySndChannelPtr, &mySndCommand, FALSE));

    FailOSErr(SndDisposeChannel(mySndChannelPtr, TRUE));

    DisposPtr(mySndChannelPtr);
}

    /* Here's an abridged version of my "offsetToSoundHeader"
     * function.  It's not too bright, so don't give it strange
     * sounds, especially non-sampledSynth sounds.  Only format
     * 1 'snd 's are supported.
     */
long offsetToSoundHeader(Handle sndRsrcHndl)
{
    SndListPtr theSndListPtr;
    long theOffset;
    short nSndCommands;

    theSndListPtr = (SndListPtr) *sndRsrcHndl;
       /* Start the offset off pointing just past the "format" word. */
    theOffset = 2;
    if (theSndListPtr->format == firstSoundFormat) {
          /* Skip past the "number of synths/modifiers" word. */
       theOffset += 2;
          /* Skip past all the synths and modifiers. */
       theOffset += sizeof(ModRef) * theSndListPtr->numModifiers;
    } else {
          /* Skip past the reference count. */
       theOffset += 2;
    }
       /* Get the number of sound commands. */
    nSndCommands = *((short *) (*sndRsrcHndl + theOffset));
       /* Skip past the "number of sound commands" word. */
    theOffset += 2;
       /* Skip past all the sound commands. */
    theOffset += sizeof(SndCommand) * nSndCommands;
    return theOffset;
}
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "A common way to answer a question about C is to 'see what the compiler
  does.'  Clearly C has suffered from being partly defined, then
  implemented." - High C language reference manual, 1987

---------------------------

From: [e-mail] (Matthew Seitz)
Subject: Good language and debugger for Mac
Date: 7 May 92 05:12:00 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Hello all.  My company is getting into Mac software development.  As one of
programmers, I'm looking for a good development language.  Currently I have
a lot of experience with DOS and Windows programming, especially with
assembly language and C.  The debugger I'm most familiar with in the DOS
world is Soft-ICE.  Since I will be starting to do work on the Mac, I was
wondering if some suggestions could be dropped my way as to the best language
and debugger for use on the Mac.  The applications I will be working on
will be primarily low-level stuff (we do local area networks), something
that will allow me good access to the internals of the Mac and allow me
to view these same internals from the debugger.  I would really prefer a
good assembler to C, but I don't know of any assemblers for the Mac at all.
The only good C compiler I've seen referenced so far is Think C.

    Any suggestions?

    Thank you,

- --
                    Matthew Seitz
                    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Eric Brunson)
Date: 7 May 92 13:39:06 GMT
Organization: Vista-Chrome, Incorporated

In article <[e-mail]> [e-mail] (Matthew Seitz) writes:
>Hello all.  My company is getting into Mac software development.  As one of
>programmers, I'm looking for a good development language.  Currently I have
>a lot of experience with DOS and Windows programming, especially with
>assembly language and C.  The debugger I'm most familiar with in the DOS
>world is Soft-ICE.  Since I will be starting to do work on the Mac, I was
>wondering if some suggestions could be dropped my way as to the best language
>and debugger for use on the Mac.  The applications I will be working on
>will be primarily low-level stuff (we do local area networks), something
>that will allow me good access to the internals of the Mac and allow me
>to view these same internals from the debugger.  I would really prefer a
>good assembler to C, but I don't know of any assemblers for the Mac at all.
>The only good C compiler I've seen referenced so far is Think C.
>
>    Any suggestions?
>
>    Thank you,
>
>--
>                    Matthew Seitz
>                    [e-mail]

Symantec 'Think C' for straight C.  Undecided for Object Oriented, probably
MacApp if they ever stop changing their class libs.

- ---
Eric Brunson               These opinions are mine alone,
[e-mail]        but they could be yours for a low monthly fee!
- --
Eric Brunson               These opinions are mine alone,
[e-mail]        but they could be yours for a low monthly fee!

---------------------------

From: [e-mail] (marco piovanelli)
Subject: Finding out if the debugger is installed
Organization: Computer Science Dep. - Milan University
Date: Thu, 30 Apr 1992 14:14:35 GMT

I have MacsBug 6.2.1 and I want to write an FKEY to drop me into MacsBug
with one simple keystroke.  At first, I thought the obvious solution
was to simply stuff these 4 bytes
 0xA9FF  _Debugger
 0x4E75  rts
into the FKEY resource and stash the FKEY into the system resource fork.
In fact, it works pretty fine, but listen: now comes the pain.
I sometimes have to boot with extensions disabled, so MacsBug doesn't get
loaded, but after a while I forget it and I hit the command+shift
combination, thus crashing the machine with an Unimplemented Trap DS error.
  Well, I though, just check for the existence of the _Debugger trap by
checking its address against that of the _Unimplemented trap.
But that doesn't work, because the two addresses always coincide.
The _Debugger trap is *ALWAYS* unimplemented, so to say.  I guess
MacsBug patches directly the trap dispatcher, so it doesn't need to
set a new trap address.
  Now, has anyone any idea as to determining whether MacsBug is installed?
I would love a CLEAN method, like using _Gestalt or checking some
low-memory global.
  Thanks in advance for any suggestions.

Marco Piovanelli - Computer Science Department - Milano University

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Date: 1 May 92 00:47:12 GMT
Organization: The University of Western Australia

In article <[e-mail]>, [e-mail] (marco piovanelli) writes:
>
>   Well, I though, just check for the existence of the _Debugger trap by
> checking its address against that of the _Unimplemented trap.

Much too obvious.  The Mac is laughing at you (-:

> But that doesn't work, because the two addresses always coincide.
> The _Debugger trap is *ALWAYS* unimplemented, so to say.  I guess
> MacsBug patches directly the trap dispatcher, so it doesn't need to
> set a new trap address.

That's right.

>   Now, has anyone any idea as to determining whether MacsBug is installed?
> I would love a CLEAN method, like using _Gestalt or checking some
> low-memory global.

MacsBug 6.1 manual, Appendix C "MacsBug Internals", page 105...

{$push}
{$setc quoting=true}

Beginning with the 128k ROM, support for debuggers is provided.  When a
system error or 68000 exception occurs, the ROM code examines the global
variable MacJmp to see if a debugger is installed.  The high-order byte
of MacJmp is used to contain the following information.

Bit Meaning
7   Set if debugger is running
6   Set if debugger can handle system errors
5   Set if debugger is installed
4   Set if debugger can support the Extended Discipline utility

{$pop}

>   Thanks in advance for any suggestions.

Share and Enjoy.

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Who's very thankful for his copy of ETO.

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 1 May 92 19:17:46 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Quinn "The Eskimo!") writes:
>
> In article <[e-mail]>,
[e-mail] (marco piovanelli) writes:
> >
> >   Now, has anyone any idea as to determining whether MacsBug is installed?
> > I would love a CLEAN method, like using _Gestalt or checking some
> > low-memory global.
>
> MacsBug 6.1 manual, Appendix C "MacsBug Internals", page 105...
>
> {$push}
> {$setc quoting=true}
>
> Beginning with the 128k ROM, support for debuggers is provided.  When a
> system error or 68000 exception occurs, the ROM code examines the global
> variable MacJmp to see if a debugger is installed.  The high-order byte
> of MacJmp is used to contain the following information.
>
> Bit Meaning
> 7   Set if debugger is running
> 6   Set if debugger can handle system errors
> 5   Set if debugger is installed
> 4   Set if debugger can support the Extended Discipline utility
>
> {$pop}

This is only true on 24-bit machines. If you have 32-bit clean ROMs, the bits
quoted above are moved to BFF. This is because on 24-bit ROMs, those bits are in
the upper byte of the pointer to the Macsbug entry point. In 32-bit mode, those
bits have to be moved elsewhere in order to keep the pointer 32-bit clean.

if (On32BitMachine())
    debuggerBits = *(char*) MacJmp;
else
    debuggerBits = *(char*) 0x0BFF;

Boolean debuggerRunning = (debuggerBits & 0x20 != 0);

I think that the Macsbug 6.2 manual can help you write the On32BitMachine()
function.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (marco piovanelli)
Organization: Computer Science Dep. - Milan University
Date: Thu, 7 May 1992 14:33:27 GMT

Well, I posted this some time ago, but I couldn't get an answer.
The question is: how do you find out if a debugger (I'm using
MacsBug 6.2.1) is currently installed?  Is there a Gestalt selector
for this piece of information?  Some low-mem global to check?
The obvious way, that is: checking the address of the _Debugger trap
(0xA9FF) against that of _Unimplemented doesn't seem to work, because
the two addresses ALWAYS match, even if MacsBug IS installed.
Maybe MacsBug doesn't need to implement the _Debugger trap because it
traps the trap dispatcher directly (?)

The reason why I am interested in this is that an FKEY I wrote to drop
me into MacsBug with one keystroke {0xA9FF, 0x4E75} crashes my Mac if
I happen to boot it with Extensions Disasbled (debugger doesn't load)
and I simply don't want this to happen.

Thanks in advance for any hints.
Please e-mail me, because I am seldom able to access this newsgroup.

---------------------------

End of C.S.M.P. Digest
**********************