INFO-ATARI16 Digest         Wed,  6 Dec 89       Volume 89 : Issue 761
 
Today's Topics:
                         1040st sound problem
                      Atracting new Club members
                              C question
                              Form Doc's
                       LYNX Development System
                        Shareware MAC (3 msgs)
                  Sozobon C, PageStream, Magic, NRPS
----------------------------------------------------------------------
 
Date: 6 Dec 89 01:25:57 GMT
From:
 usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!peregrine!ccicpg!cci632!rit!ultb!drp9
 500@ucsd.edu  (D.R. Paradis)
Subject: 1040st sound problem
Message-ID: <1698@ultb.isc.rit.edu>
 
  I forget the part number but it is the General Instruments sound chip
from Radio Shack.
 
   how do I know this......I had to replace mine and used this chip and
it's been working like a champ for over a year!
 
  The chip is about $10 (standard 40 pin size) but they do have it.
 
------------------------------
 
Date: 6 Dec 89 17:54:42 GMT
From: texbell!wuarchive!kuhub.cc.ukans.edu!shawl@rutgers.edu
Subject: Atracting new Club members
Message-ID: <19367@kuhub.cc.ukans.edu>
 
The Lawrence Atari Computer Club (Lawrence, Kansas) meets in the
public library.  I would recommend trying that since it is
centrally located, and FREE!!
 
Steve Shawl
bitnet:  Shawl@kuhub.cc.ukans.edu
 
------------------------------
 
Date: 6 Dec 89 17:45:24 GMT
From: galaxy.rutgers.edu!argus!ron@rutgers.edu  (Ron DeBlock)
Subject: C question
Message-ID: <1381@argus.UUCP>
 
Someone asked why
        main()
        ?
                char fred[] = "hello";
                ....
won't work, and a bunch of answers followed.  Some made no sense, others
were close, but I haven't seen the complete answere yet.  So here it is:
 
 
The error from the compiler on this line is probably something like:
        "No initialization of automatic agragate."
 
This means that an aggragate structure (an arry, struct or union) that is
automatically allocat cannot be pre-initialized.  Automatics are any
variables declared INSIDE of a function (this excludes the functions
arguments).  For non-aggragate variables, (int, *, cha the compiler
will generate storage and code to initialize.  It does not do so for
aggragates.
 
The solution is to make the variable non-automatic.  Someone mentioned
declaring the array as
        static char fred[]
which will work just fine.  Global variables are also not automatic,
so moving the declaration outside of main() will also work.
 
C provides the keyword "auto" to make variables automatic.  I've
never seen it used, since it is only valid within functi (or block)
scope and it is the default.
 
The "static" keyword has an interesting side effect: a global symbol
declared as static only has file scope.  This allows you to create
global vaiables and functions which are visible only within a file:
 
        static int foo;
        int bar;
 
        static int bas()
        ?
                ...
        ?
 
        int baf()
        ?
                ...
        ?
 
 
 
baf() and bar may be declareas extern in other files and used normally.
However, foo and bas() CANNOT be referenced outside of the file!  This is
sometimes useful if you want to be sure that certain variables or functions
cannot be accessed from other code.
--
Ron DeBlock     N2JSO
Net: ...!rutgers!galaxy!argus
US Mail: 42 Davis Street, Phillibsburg, NJ 08865 USA
 
------------------------------
 
Date: 6 Dec 89 05:11:21 GMT
From: att!chinet!saj@ucbvax.Berkeley.EDU  (Stephen Jacobs)
Subject: Form Doc's
Message-ID: <1989Dec6.051121.21994@chinet.chi.il.us>
 
I can whine with the best of them (and do, often enough).  The point that .dvi
isn't the most accessible form seems made.  For those who can do nothing else,
i suggest using either a strings program or a dump utility on the dvi: enough
of the text is recoverable to let you know what the program is about.
                                 Steve J.
 
------------------------------
 
Date: 5 Dec 89 13:10:41 GMT
From: sgi!shinobu!odin!odin.corp.sgi.com!portuesi@ucbvax.Berkeley.EDU  (Michael
 Portuesi)
Subject: LYNX Development System
Message-ID: <PORTUESI.89Dec5131041@tweezers.esd.sgi.com>
 
>>>>> On 5 Dec 89 17:44:45 GMT, 2FHDBEAK@kuhub.cc.ukans.edu said:
j> Here's an interesting tidbit for you LYNX fans:
 
j> The development system for the Atari LYNX is an AMIGA computer!
j> I wonder what it must be like to go into Atari's offices and see
j> all sorts of Amigas lying about.
 
 
That's not surprising, given that the Lynx was developed at Epyx, not
Atari, and all the Lynx designers also designed the Amiga.
 
                                --M
--
__
\/  Michael Portuesi    Silicon Graphics Computer Systems, Inc.
    portuesi@SGI.COM    Entry Systems Division -- Engineering
 
He says, "Take me to your leader" -- and I say, "Do you mean....George?"
 
------------------------------
 
Date: 5 Dec 89 16:15:15 GMT
From: att!drutx!druwy!dlm@ucbvax.Berkeley.EDU  (Dan Moore)
Subject: Shareware MAC
Message-ID: <4476@druwy.ATT.COM>
 
in article <3395@brazos.Rice.edu>, bro@titan.rice.edu (Douglas Monk) says:
> The suggestion was made that instead of using a cartridge, code that works
> like the MAC ROMs but doesn't violate Apple's copyright could be used. This
> is a great idea. No one has done it yet, which is one of the reasons why no
> Apple clones (other than STs :-) exist yet.
                ~~~~~~~~~~~~~~ not true, there is an Amiga Mac emulator.
 
> It is a technical difficulty, or a legal one? How does Phoenix et al. get
> away with IBM clone ROMs? Licensing? Work-alike?
 
        The problem is partly technical and partly legal (or at least
lots of money for lawyers).
 
        To "legally clone" a BIOS (or ToolBox in Mac'ese) you need to
teams of programmers and some lawyers.  The first team studies the code
to be duplicated and generates a highly detailed description of the
code.  The description would include statements about register
contents, data structures passed, etc. for the various routines in the
BIOS.  It then states what the routine does including any side effects
(eg. global variables that are changed).  It should also document any
bugs in the code (ie. deviations from the published specifications for
the BIOS). This description is then sent to the lawyers who save copies
of everything (documentation for any suits that come up) and then send
a copy to the second programmer team.  The second progammer team has to
be made up of people who have NEVER looked at the actual code to be
duplicated (ie. they never used a debugger to look at the Mac ROMs or
the IBM PC BIOS or whatever).  They also can NOT talk to the first
programmer team except by having the lawyers forward messages (which
are filed just like everything else.)  They then use the descriptions
to write routines that do the exact same thing as the original.  They
may even clone the bugs, some of the 3rd party EGA cards for PC's have
the same bugs as IBM's EGA card.
 
        When you get done you have what should be a legal duplicate of
the first program's functionality.  There may be problems due to
copyrights on the visual appearance (look & feel) or patents on
algorithims, etc.  Hopefully the documentation the lawyers have will be
enough to prove that you did things legally (Phoenix pulled it off with
BIOS ROMs for PC's).
 
        The technical problems are really just time problems.  The Mac
ROMs are very complex (much more complicated than the TOS ROMs for
instance).  Given the large number of functions contained in the ROMs
it will take quite a while to duplicate them. And while they are
working to duplicate a given release of ROMs (eg. the 256K ROMs in the
Mac II) Apple will be working on new, improved ROMs with new features.
So when you get done you may have something that is already obsolete.
This isn't a problem with cloning the BIOS ROMs in a PC, the functions
of those ROMs is pretty stable with very few changes over time.
 
 
        No company has decided that the time and expense (at least one
year, at least 10 or 20 programmers, plus lawyers, and Apple will
sue when you get done) is worth the expected return.
 
 
 
                                Dan Moore
                                AT&T Bell Labs
                                Denver
                                dlm@druwy.ATT.COM
 
------------------------------
 
Date: 4 Dec 89 15:34:59 GMT
From: sgi!shinobu!odin!odin.corp.sgi.com!portuesi@ucbvax.Berkeley.EDU  (Michael
 Portuesi)
Subject: Shareware MAC
Message-ID: <PORTUESI.89Dec4153459@tweezers.esd.sgi.com>
 
>>>>> On 29 Nov 89 14:30:00 GMT, greg.trice@canremote.uucp (GREG TRICE) said:
 
greg> Why does everybody assume that a Mac emulator has to use Mac ROMs or any
greg> Mac code at all? There are an infinite number of ways to do a given job
greg> and it is perfectly possible for somebody to carefully read all the Mac
greg> documentation and then sit down and write code that will do exactly the
greg> same job as the Mac roms, but have not a byte in common with them in
greg> code. This is the situation with most IBM compatible systems. Though
greg> they are functionally identical to the IBM product, their ROMs contain
greg> different, but functionally identical code.
greg>  It should be perfectly possible to produce a Mac emulator that used no
greg> ROMs at all, but was wholly disk based (given sufficient memory to hold
greg> the quondam ROM code in RAM).
 
 
Go ahead and try...I'll see you in a few years.
 
The Apple ROMS are the result of several hundred person-years of work,
and you expect one enterprising hacker to recode them, and do all
of the testing and revising to ensure even a reasonable amount of
compatibilty?  Obviously you've never developed software for a living.
 
                                --M
--
__
\/  Michael Portuesi    Silicon Graphics Computer Systems, Inc.
    portuesi@SGI.COM    Entry Systems Division -- Engineering
 
He says, "Take me to your leader" -- and I say, "Do you mean....George?"
 
------------------------------
 
Date: 6 Dec 89 17:35:00 GMT
From: apollo!rehrauer@eddie.mit.edu  (Steve Rehrauer)
Subject: Shareware MAC
Message-ID: <474461c0.20b6d@apollo.HP.COM>
 
In article <3395@brazos.Rice.edu> bro@titan.rice.edu (Douglas Monk) writes:
>The suggestion was made that instead of using a cartridge, code that works
>like the MAC ROMs but doesn't violate Apple's copyright could be used. This
>is a great idea. No one has done it yet, which is one of the reasons why no
>Apple clones (other than STs :-) exist yet.
>
>It is a technical difficulty, or a legal one?
 
Primarily the former, secondarily the latter.  To "do it right"; i.e.: to
avoid committing legal hari-kari, companies use what I've heard called a
"clean room" approach.  Two design teams work on the problem.  Team #1
looks at the *specifications* for what they're trying to clone.  It's
probably fair for this team to look at ROM images, but I'm sure it'd be
better if they didn't.  Team #1 generates their own specs for how to
functionally reproduce what is to be cloned.  Team #2 only sees this
spec, and can never look at the original materials team #1 used.  No
fair going to team #1 and saying, "Hey, we're having a hard time seeing
how to do 'bletch'; how did They do it?"  If the original specs were
accurate, and team #1 did a good job, and team #2 did a good job, the
clone works well.
 
And even after all that, if the opposition is sufficiently larger than
yourself, they may be able bleed you dry in court.  You may be perfectly
legal in what you've done, but proving it takes time and $$$.
 
> How does Phoenix et al. get
>away with IBM clone ROMs? Licensing? Work-alike?
 
What's in IBM ROM BIOS is surely an order of magnitude (or more) easier
to reverse-engineer than what's in Mac ROMs.  Not to mention that it's
(at least originally, and perhaps still) far more lucrative if you succeed
with IBM BIOS.
 
Don't hold your breath for Mac OS clones.  Apple has shown itself to be
quite willing to vigorously defend what it considers its turf, whether
"common sense" says they have a case or not.  The cost of developing a
Mac clone "done right", plus the possibility of locking horns with Apple
in court afterwards, is enough to scare away most of the cloners.  I'd
expect to see Apple license their ROMs before we see clones, and they
haven't been too receptive to that idea either.
 
--
>>"Aaiiyeeee!  Death from above!"<< | Steve Rehrauer, rehrauer@apollo.hp.com
   "Flee, lest we be trod upon!"    | The Apollo System Division of H.P.
 
------------------------------
 
Date: 5 Dec 89 11:00:00 GMT
From:
 ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!glk01126@iuvax.cs.indiana.ed
 u
Subject: Sozobon C, PageStream, Magic, NRPS
Message-ID: <111500076@uxa.cso.uiuc.edu>
 
        To the authors of Sozobon: great job on version 1.2, when
        is the final release coming?
 
        I have finally deceiphered the format of PageStream files
        and wrote (for a class) a magic (VLSI CAD SYSTEM) to PageStream
        file converter if anyone is interested.  This will allow
        you to work on VLSI in a PageStream Document and port it...
        (with limited error checking) or to include your VLSI documents
        in PageStream documents.
 
        I am going to start a graphing program that will output to
        PageStream format files.  I have not decided yet if I should
        try to contact SoftLogic for possible marketing (GraphStream)
        or release it as shareware... Anyone have any advice?
 
        Has anyone done any reviews on products and sent them in to
        a magazine?  I would like to review Sozobon C and get the
        message out that an excellent PD C is available.
 
        To the requesters of Neodesk Random Picture Selector... It
        is available at terminator (35.1.33.8) in atari/new/nrps.arc.
        Version 2.0 is coming soon that will extract a random picture
        from .zoo,.lzh or .arc files and use that. (getting sick of
        all the space required for the pictures)  If you can't access
        terminator, get your request to me or let me know how to post
        it to comp.binaries.atari.st.
 
 
        -Gregory Mathias Lemperle-Kerr
        "Ahhh the University of Illinois, what a joy..."
 
------------------------------
 
End of INFO-ATARI16 Digest V89 Issue #761
*****************************************
