NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/amiga/programm/17630

Internet Message Format | 1992-12-21 | 4.4 KB

Path: sparky!uunet!dtix!darwin.sura.net!spool.mu.edu!yale.edu!ira.uka.de!sol.ctr.columbia.edu!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!ami-cg!cg
From: [e-mail] (Chris Gray)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Big mistake - A compromise (of sorts)
Message-ID: <[e-mail]>
Date: 20 Dec 92 18:14:50 GMT
References: <[e-mail]>
Organization: Not an Organization
Lines: 67

In article <[e-mail]> [e-mail]
 (Thorne K. Kontos) writes:
>
>     Since I believe I started this thread, let me put forth a compromise
>solution. There are two classes of people who will continue to write
>software for the Amiga. The professional programmer who is attempting to
>create a piece of software that may become a viable commercial product
>is one of these. The other is the hardware hacker/demo coder who writes
>"demos" for fun. The obvious solution given that Commodore does not wish
>to release the AGA specs, is to release code that will allow the hacker
>to bang the hardware, yet return to the normal OS when the demo is
>finished. A generic piece of code that covers all Amigas (regardless of
>configuration) would be perfect. In this manner, the demo coders can happily
>bang the hardware all they want, but by using this snippet of code, the
>computer can be returned to its "normal" state, without having to do
>the three finger salute and reboot the machine which is so prevalent among
>the current demos that I have seen. So what do you think?
>     IMHO, this solution works well, and satisfies all. Commodore does not
>have to release the AGA specs. Demo coders will be able to continue to code
>demos, but they will be OS friendly demos. Professional programmers can and
>will continue to use the normal OS function calls.
>
>                              Thorne K. Kontos
>                              System Engineer
>                              Intergraph A.P.D.

I agree with your initial split of the folks concerned, but I don't agree that
your solution will work. First off, releasing the code in source or simple
object form would make it too easy for the hacker/demo folks to figure out
what the hardware really does. I'm also not convinced that anything short of
rebooting the system is a truly safe, reliable way to bring the OS back to
full functioning. What about the state of anything real-time dependent? What
about the zillions of background processes that might be running? For example,
my system here is a UUCP node, with Getty running all the time and with
connections coming in at random times. In the past I've run Amiga Empire games
on it as well as running test versions of AmigaMUD. I don't WANT to stop all
that stuff to run a game, so the only games on the system are a few that
multitask quite happily. I HAVE lots of arcade and role-playing games, which
I run on other systems (my A2000 is currently on loan, however).

I want to suggest something (perhaps mostly to CBM) that I think has a better
chance of working. Unfortunately, it won't solve the problem for a couple of
years.

CBM has said they are working on two new chip sets/architectures. One is low
end and one is high end. OK, so deliberately make the two sets as incompatible
as possible! Then, release the full specs on the low-end architecture, but
not for the high-end one. The hacker/demo folks can then hack away on the
low-end systems, and their stuff will be shared with and appreciated by all
the folks with such systems. Folks like me who want a very stable system for
software development will likely have a high-end system anyway (I'm typing
this on my A3000/25). If the two architectures are quite different, there is
much less chance of any hackers developing something for the high-end systems,
which appears to be one of the main concerns about releasing hardware specs.
Things like big role-playing games, which can make good use of extra memory
and hard disks, don't really need hardware access, and should run just fine
on the high-end machines by going through the OS for everything.

Folks with lots of money will buy one of each, and will have a stable system
on which to run BBS's, develop software, run WP's, spreadsheets, etc. and
will have a possibly highly unstable (boot all the time) system on which to
run arcade games, demos, mods, etc.

Aside from it not solving the problem for AGA, anyone see problems with this?

--
Chris Gray   [e-mail]