Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 525
Info-Atari16 Digest Sat, 5 Oct 91 Volume 91 : Issue 525
Today's Topics:
ARJ? (3 msgs)
For Sale :
Help!?!
Install an app for two diff filetype
KR2ANSI
lharc vs. zoo (my correction)
Need disk cat prog. to show disk files & sizes, ask comments
People dumping machines (was.. Atari Mega 2 system.. for sale) (3 msgs)
Railroad Tycoon Needs File
SOME (HOPEFULLY NOT REDUNDANT) INFO ON OTHER MAC EMULATOR (LONG!!
Spectre GCR/System 7/A/UX
Using gcc/g++ to cross compile for the ST
WANTED: Suggestions for ST color monitor purchase
Welcome to the Info-Atari16 Digest. The configuration for the automatic
cross-posting to/from Usenet is getting closer, but still getting thrashed
out. Please send notifications about broken digests or bogus messages
to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
Please send requests for un/subscription and other administrivia to
Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list
instead of the moderators are likely to be lost or ignored.
If you want to unsubscribe, and you're receiving the digest indirectly
from someplace (usually a BITNET host) that redistributes it, please
contact the redistributor, not us.
----------------------------------------------------------------------
Date: 2 Oct 91 20:45:04 GMT
From: mcsun!unido!mcshh!malihh!pfunk!blackbox@uunet.uu.net (Michael
Kistenmacher)
Subject: ARJ?
To: Info-Atari16@naucse.cse.nau.edu
In <1991Oct01.144917.1607@convex.com>, William Rosenkranz writes:
>sort of program. when i post code, i generally always post source. and i
>place no restrictions on its use at all. i generally don't even include
>a copyright. and the code i write ends up in some odd places (nroff became
I pay high respect to your attitude, above all if I look on the products,
you have added to the PD-section on the ATARI. But you have to realize that
some people have to pay their rent with that money. Thomas is a student
and his university demand a high contribution. I don't know anything
about your profession but some people must earn money with their products.
>
>requesting the source, in this case, will save me the time of disassembling
>it, correcting the disassembled source, reformatting it, and annotating
If all people would thing think like that and every part of software would
be free of charge, we would not have so much professional software for
our computer. This might sound a bit fancy, but if I make a list of
professional products for the ST, the amount of them from germany would
perhaps be higher.(please don't get that wrong)
>i would not disassemble a spreadsheet, database, or any other sort of program.
>but for me, archivers are different.
>
But where do you make the difference ? OK, some hours against some weeks.
Bye......Michael
--
/------------------------------------\
| Michael Kistenmacher / blackbox |
| 2000 Hamburg 61 / Schippelsweg 64 |
| West Germany / ++ 49 40 552 37 66 |
\------------------------------------/
------------------------------
Date: 3 Oct 91 07:52:17 GMT
From: mcsun!uknet!ukc!edcastle!hwcs!neil@uunet.uu.net (Neil Forsyth)
Subject: ARJ?
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Oct1.212652.15376@watdragon.waterloo.edu>
cjherborth@rose.waterloo.edu (Chris Herborth) writes:
>a) What's the problem with Malloc() inside an ACC? Beyond the possibility
> of fragmenting your memeory, I can't imagine anything going wrong...
Like I said, when you malloc memory from an acc, the memory belongs to the
current process not the accessory. So if you are in an application when you
malloc some memory, you'll lose it when that application terminates. The
desktop doesn't terminate so you should do your mallocing then.
I'm not sure about rez changes though. Perhaps the desktop 'quits' then.
I guess you'd have to catch that.
>The main point is, it's to be an EXTENSIBLE Screen Saver. You could have
>2M of modules sitting in your XScreen folder (well, if it caught on and
>lots of people wrote modules) and you wouldn't want to load them all when
>you booted. You'd just want to load the one that was going to be
>executed when the screen saver went off. When you were done (ie, work your
>ST back up), it'd get deallocated.
What I described was an EXTENSIBLE system. You might have to reserve memory
for saver slots in advance though.
>There's another problem --> I haven't got the assembler smarts to write
>any sort of code that'll relocate and execure a module the way you
>suggest, with a special header/whatnot. I can't even use XBRA without
>the routines somebody else wrote and uploaded to a.a...
Well you are going to have to learn about assembler anyway to write
the saver in the first place.
BTW I'm getting all this stuff in reverse so I'm replying without having
seen Ken's message yet. No doubt I've made some more screw-ups! :-)
+----------------------------------------------------------------------------+
! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
! !
! Neil Forsyth JANET: neil@uk.ac.hw.cs !
! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk !
! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil !
! Edinburgh, Scotland, UK "That was never 5 minutes!" !
+----------------------------------------------------------------------------+
------------------------------
Date: 2 Oct 91 23:01:35 GMT
From:
noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs
.ohio-state.edu!usenet.ins.cwru.edu!yfn.ysu.edu!ysub!psuvm!cunyvm!jokhc@arizona
.edu (Joshua Kronengold)
Subject: ARJ?
To: Info-Atari16@naucse.cse.nau.edu
You don't want to malloc in a desk acc inside a application, because once you
are closed, anyone else can use that memory.
A easy Idea, might be to make savers written in some type of
interpred language,or script. If you distribute an interpreter with it, litera
ly anyone can make up their own saver...
To be really simple, the 'language' could just be an animation format...
-------
< Joshua Kronengold<JOKHC@CUNYVM.cuny.edu> >
< "Oh Lord, what fools these mortals be!"-Robin Goodfellow >
< "Never underestimate man's potential for stupidity" >
< <I'm going to change this soon, > -Woodrow Wilson Smith >
<I promise... >
------------------------------
Date: 3 Oct 91 00:49:34 GMT
From:
noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ox.com!math.fu-berlin.de!fu
b!dobag.in-berlin.de!obh.in-berlin.de!tyrell@arizona.edu (Stefan Haack)
Subject: For Sale :
To: Info-Atari16@naucse.cse.nau.edu
For Sale : ATARI 'TETRA-TOWER'
-Atari Mega ST 4 Board 4MB
-AT-Speed C 16 (16Mhz) (MS-DOS Emulator)
-Hypercash 16Mhz
-Overscan
-all Tetra Tool's(Printer, I/O, SCSI, LAN)
-177 MB Seagate Harddisk (14ms 64KB Cache)
-44 MB Syquest SQ44
-3 1/2 Disk
-5 1/4 Disk
-NEC 3D Multisync
-ATARI SLM804
-Calamus DestopPub. Program and another Programs
VB 9500.- DM (Deutsche Mark) without Shipping !
------------------------------------------------------------------------
Voice Germany 030/3235284 Q Rigo Manikofski or Stefan Haack
or mail me ! tyrell@obh.in-berlin.de
------------------------------
Date: Sat, 05 Oct 91 16:19:13 MEZ
From: Wolfgang Ley <BWWL%DCZTU1.BITNET@CUNYVM.CUNY.EDU>
Subject: Help!?!
To: Atari ST users forum <Info-Atari16@naucse.cse.nau.edu>
On Fri, 4 Oct 1991 21:17:00 MST <ASMVF@ASUACVAX> said:
>Hello, folks!
>
>I am new to Bitnet and Internet, and need a little help, if you can spare
>it.
>
>I am interested in doing anonymous ftp to get some atari st software. I
>tried a couple of the addresses on the list that was sent out in
>yesterday's digest, but I couldn't get past the login. Is there some kind
>of universal guest account or something?
>
>Thanks in advance!
>
>*Mf*
Hi!
There is indeed a special account:
1) you should login as "anonymous" (most of the ftp-sites also understand
the userid "ftp", but "anonymous" is the best way...)
2) send your userid as password. Most server accept the name "guest", but
normally you should send your own userid. Some even want the complete
mailing address as password (like BWWL@ibm.rz.tu-clausthal.de)
This should work...
I hope this helps. Bye, Wolfgang.
(bye the way: the most important ftp-site for atari is
atari.archive.umich.edu (141.211.164.8) )
---------------------------------------------------------------------------
Wolfgang Ley e-mail:
Teichstrasse 9 from BITNET : BWWL@DCZTU1.BITNET
W-3392 Clausthal-Zellerfeld from Internet: BWWL@ibm.rz.tu-clausthal.de
(West Germany) or BWWL@sun.rz.tu-clausthal.de
Tel. 05323/82132 (voice)
---------------------------------------------------------------------------
------------------------------
Date: 2 Oct 91 19:55:04 GMT
From:
noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!van-bc!jon
h!jhenders@arizona.edu (John Henders)
Subject: Install an app for two diff filetype
To: Info-Atari16@naucse.cse.nau.edu
In <5551365@presto.ruhr.de>, David Channing writes:
>In article <6446.28e738d9@miavx1.acs.muohio.edu>
rlcollins@miavx1.acs.muohio.edu
>(Ryan 'Gozar' Collins) writes:
>>
>> 1. Is there anyway to install an application for more than one filetype?
>> filetype. Well, it won't let you do that under 1.4 :*( So I tried to
>> edit the desktop.inf file adding the required lines to install the
>> application for two filetypes. Well, my ST just crashed on boot up
>
>You must have messed up your desktop.inf file editing it. Here are the
>relevant lines from my desktop.inf which works with no problems:
>
>#F FF 04 C:\BIN\ARCLOAD.PRG@ *.ARC@
>#F FF 04 C:\BIN\ARCLOAD.PRG@ *.LZH@
>#F FF 04 C:\BIN\ARCLOAD.PRG@ *.ZOO@
>
This only works until the next time you save a desktop.inf
file from the desktop. The desktop seems to ignore the extra
lines when writing the file, at least when I tried it.
The best solution is Gemini, where you can do something
like *.[ALZ][RZO][CHO] in the instal application dialog. I'd
sure like to have Gemini run from a ROM cart.
--
John Henders jhenders@jonh.wimsey.bc.ca
Vancouver,B.C or ubc.cs!van-bc!jonh!jhenders
------------------------------
Date: 3 Oct 91 05:55:56 GMT
From: bu.edu!bucsf.bu.edu!harryk@uunet.uu.net (Harry Karayiannis)
Subject: KR2ANSI
To: Info-Atari16@naucse.cse.nau.edu
I just put kr2ansi.zoo on atari.archive. kr2ansi is a small utility that
generates ANSI prototypes from K&R-style C source files.
Using output redirection one can generate header files (the program puts
an "extern" in front of every prototype line) with prototypes of all the
functions present in the file read...with the appropriate #include lines in
the K&R source code old-fashioned programs can be compiled with an ANSI
compiler (thus taking advantage of the parameter-checking during compilation).
If there's enough interest I can also send it to c.b.a.s and c.s.a.s
have fun...
===============================================================================
Author of ATZENTA2 Harry Karayiannis ________E-Mail_________
15 N.Beacon, #316 Boston Univ. |INTERnet:
** || ATARI ** Allston, MA 02134 Computer Sc. | harryk@bucsf.bu.edu
** /||\ MegaST ** U.S.A. |BITnet:
=======================================================| cscrzcc@buacca.bu.edu
-----------------------
------------------------------
Date: 3 Oct 91 13:25:41 GMT
From:
noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!THD-News!news@ar
izona.edu (WALLMANN, GEORG)
Subject: lharc vs. zoo (my correction)
To: Info-Atari16@naucse.cse.nau.edu
As two people have pointed out I lost 'cause I oversaw the 'h' option
on Zoo 2.1. I ran the tests again and sure enough the results of ZOO
came very close to Lharc. Which makes conclusion wise ZOO as good
as Lharc really.
As to the fragmentation issue, I don't still quite see the problem (but
who cares ? (har)) since after erasing the produced files, the fragmen-
tation ought to be the same as before (the allocated blocks being freed).
BTW. Since all archivers ran on the same partition from the same /bin
directory I don't see this comparable to running one from a floppy and
one from a ramdisk, not even in a more transcendental sense.
Oh well
Nat!
------------------------------
Date: 3 Oct 91 04:19:17 GMT
From: noao!asuvax!cs.utexas.edu!samsung!mips!apple!netcomsv!bryanw@arizona.edu
(Bryan Woodworth)
Subject: Need disk cat prog. to show disk files & sizes, ask comments
To: Info-Atari16@naucse.cse.nau.edu
I am looking for a program that does the following:
o catalogs filenames and filesizes according to disk #s
o asks for comments
o stores output in !! ASCII !! format.
Any ideas?
--
Bryan Woodworth Mail: bryanw@netcom.COM
Netcom - Online Communication Services San Jose, CA
------------------------------
Date: 3 Oct 91 23:35:36 GMT
From:
noao!asuvax!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!bonnie.ics.uci.edu!jvanc
e@arizona.edu (Joachim Vance)
Subject: People dumping machines (was.. Atari Mega 2 system.. for sale)
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Sep27.143553.27920@magnus.acs.ohio-state.edu>
dhbutler@magnus.acs.ohio-state.edu (David Butler) writes:
> One thing I have noticed about the computer world is that there are
> a lot of real bone-heads in it, like as in thick skulls. Atari and
> Amiga users are the WORST of the lot. Get off your high-horses guys,
> you are arguing over a hunk of frigging silicone and some wires!
> That's right, go home, look at your ST, and think about what it really
> is, a lump of PLASTIC and METAL, and that is all, it has no
> importance. GET A LIFE!
Didn't you know? Computers are a bona fide social religion.
Just like cars, beer and music. Computers, for some people, have as much
to do with a person's self esteem and self image as clothing and
hairstyle (or more so).
What more to life is there anyway ;)
--
Joachim Vance
=====================================================================
I am antisesquipedalian--Opposed to the use of long words.
=====================================================================
------------------------------
Date: 3 Oct 91 23:45:15 GMT
From:
noao!asuvax!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!bonnie.ics.uci.edu!jvanc
e@arizona.edu (Joachim Vance)
Subject: People dumping machines (was.. Atari Mega 2 system.. for sale)
To: Info-Atari16@naucse.cse.nau.edu
> though, like I said, if the blitter can speed up bit-block transfers...
My understanding is that the TT has no blitter. The '030 was too fast
to justify one. Am I mistaken?
Joachim
--
Joachim Vance
=====================================================================
I am antisesquipedalian--Opposed to the use of long words.
=====================================================================
------------------------------
Date: 4 Oct 91 00:41:46 GMT
From: munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe!cs.uq.oz.au!warwick@uunet.uu.net
(Warwick Allison)
Subject: People dumping machines (was.. Atari Mega 2 system.. for sale)
To: Info-Atari16@naucse.cse.nau.edu
In <28EBAB8B.5952@ics.uci.edu> jvance@bonnie.ics.uci.edu (Joachim Vance) writes:
>> though, like I said, if the blitter can speed up bit-block transfers...
> My understanding is that the TT has no blitter. The '030 was too fast
>to justify one. Am I mistaken?
That was my guess, from seeing the "Blitter" option greyed out (ie. disabled)
on my friend's TT. It seems to me that if TurboST and QuickST can do better
than the blitter (though I'm still not convinced), then certainly even the
coders at Atari can do better with a 32MHz machine.
Warwick.
--
_-_|\ warwick@cs.uq.oz.au
/ * <-- Computer Science Department,
\_.-._/ University of Queensland,
v Brisbane, AUSTRALIA.
------------------------------
Date: 2 Oct 91 20:30:08 GMT
From:
noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!van-bc!jon
h!jhenders@arizona.edu (John Henders)
Subject: Railroad Tycoon Needs File
To: Info-Atari16@naucse.cse.nau.edu
In <4990@chalmers.se>, Per Anders Olausson writes:
>
> There is a lot of bugs present when you have lost a game etc but I still
> haven't found myself trapped when *in* the game.
>
> In other words I don't think the external bugs have any counterparts when
> running the game itself.
>
> It sure is the first buggy Microphrose game I've owned anyway and I don't
> like it at all, they used to produce stuff that were better tested than this.
>
F19, on North American TOS's had several annoying bugs, the worst
of which was that you'd suddenly find yourself flying inverted. Not
fun if you were 100 feet off the ground at 400 mph. ;-) After promising
to fix this for several months, Microprose announced that they didn't
consider North American sales significant enough to warrant the effort.
While the bugs may not be a major problem on European TOS's, the
early reports over here are that the game will barely run on most machines,
some only work if you don't touch the mouse, and 4 meg machines are
completely out of luck.
It's too bad, as this game's release for the ST was one reason I
put off purchasing a clone, as unlike Richard Covert, I consider the
386 boxes the current top games machine.
--
John Henders jhenders@jonh.wimsey.bc.ca
Vancouver,B.C or ubc.cs!van-bc!jonh!jhenders
------------------------------
Date: Sat, 05 Oct 91 03:02:45 SST
From: "S. Ssuthipuntha" <AKISUJAR%NUSVM.BITNET@CUNYVM.CUNY.EDU>
Subject: SOME (HOPEFULLY NOT REDUNDANT) INFO ON OTHER MAC EMULATOR (LONG!!
To: INFO-ATARI16@naucse.cse.nau.edu
Subject: Some (hopefully not redundant) Information
Greeting from Singapore,
* I am wondering why the mainframe here alway turns the Subject: line
into uppercase!
Contemplating to buy NeXT, I posted a message regarding the Mac
Emulator to NEXT-L@BROWNVM.BITNET without much expectation as I
so get use to getting zero response or help when I posted my queries
here. To my surprise I received 4 replies within 6 hours after
sending out my messages. Either the NeXT users are more enthusiastic
about their computer than us, Atarians, or they are to free as they
don't have to read the flaming which often occur in our discussion
group. Perhaps the Ferrari owners (is it really a Ferrari?) or those
who have an opportunity to drive/use without having to own one
themselves could not be bother to spend their time debating or
arguing whether the Toyota is better than Nissan.
Below is some parts of the reply which I felt might be of interest to
all who are using Spectre or waiting for Spectre 256 (a Color Mac
Emulator).
Suthipuntha, School of Architecture, National University of Singapore
AKISUJAR@NUSVM.BITNET
-------------------------------------------------------------------
Hello,
I received the following from Abascus, the people working on a
commercial Mac-emulator for the NeXT. The MIT effort has been halted
because they don't see any point in duplicating Abascus' effort.
Apparently, the MIT folks thought that Abascus is so far ahead of
them that it wouldn't be worth their while to try to catch up
anyways. Instead, they might try to work together.
===================================================================
Greetings,
Your presence at this conference implies an interest in open computing.
At Abacus Research and Development, ARDI, we too are interested in open
computing. Specifically we are interest in helping you run programs that
are currently available only on Apple's(r) Macintosh (r) computer. We
are a small start up with big goals.
Information that you have asked for that isn't contained in one of those
three missives is answered below.
Q: Performance?
A: Compute intensive applications blaze (the native 040 does all the work,
we just stand back and let it rip). Graphics are slowed down by two
things. ROMlib is written entirely in C so our graphics start out a
bit slower than Apple's, on top of that we go through NeXTstep and
that slows us down a bit more. I believe most people who have seen
a demo are happy with the graphics. Some of our graphics tests run
faster on a 040 NeXTstation than on a Mac IIci, some run slower.
Q: What special hardware is needed.
A: None. With the beta software you'll be able to stick 1.4M Mac formatted
floppies into your drive and have the contents transferred to your hard
disk for use under Executor.
Q: Has Apple seen your work?
A: At least one person from Apple stopped by at UNIX Open Solutions '91
(thanks to everyone who stopped by). I have also sent two demo copies
to people within Apple and am about to send a third to Apple Europe.
Q: Lawsuit?
A: Who knows? No word of one yet. We're prepared for one.
Q: Is the emulator at the source level or binary level?
A: What we will be releasing, Executor, is a binary compatible "solution."
We started this game with a source compatible solution, ROMlib. ROMlib
was briefly offered for sale on the Sun-3 line for $400.00 for a one
CPU copy. We sold a few but lost our shirts by spending much too much
time explaining its use. Source compatibility systems are complex and it
turns out there aren't a whole lot of people who are familiar with Mac
programming and UNIX programming. We will re-offer ROMlib for ISVs, but
the cost will be much greater and we can't do that until we've hired some
support people which in turn is predicated on getting some funding or
selling some copies of Executor.
Q: Can I pass information about Executor and ROMlib to other groups?
A: Please do. We've tried to keep a good balance between hype and reality;
I hope you do as well.
Today we do not have any shrink-wrapped products available for you to purchase.
We are just about to send beta copies of what will be our first product.
The "not quite beta" software can be shown running on a NeXTstation in our
booth. Because this is a conference dedicated to open solutions, we are also
running a in-house version that uses X-windows. The software that we are
demonstrating is known as Executor and it allows you to take shrink-wrapped
products originally written on a Macintosh and run them on non-Apple machines.
The product line we will support is the NeXT product line.
Emulating the Macintosh is no simple matter. When people clone IBM-PCs they
have the cooperation of Microsoft. Microsoft wrote the operating system that
runs on PCs and Microsoft is willing to sell copies to clone makers. Because
Apple wrote the operating system that runs on Macintoshes, in order to be able
to do what we do we had to rewrite the Macintosh operating system from scratch.
Because this is such an enormous task, our first product will have some
limitations. The first version will not support: Color, Sound, Printing,
Desk Accessories, System 7, or AppleTalk(r). As we grow we will get rid of
these limitations. We will also support other product lines. If you are
interested in our technology but you already buy UNIX machines from someone
other than NeXT, you may want to tell the company you deal with that you'd
like to see our software running on their platforms. We could use the
exposure.
<Stuff deleted >
For the technically curious, here's a brief description of how Executor is
put together. Executor is actually a very small program (approximately 3000
lines of C and assembly "glue") that uses a large library known as ROMlib.
As the name implies, ROMlib is a library of routines that replaces those
provided by the Macintosh ROMs. Although Executor has some assembly
language portions, ROMlib is written entirely in C and at various times ROMlib
has been brought up on a wide variety of machines, including: DECstations,
VAXstations, SPARCstations, the IBM-PC running Xenix, Data General's Aviion,
the IBM-RT as well as the machines we use in house, "Sun 3"s and NeXTstations.
We originally hoped independent software vendors would use ROMlib to port their
applications to the wide range of platforms that will support ROMlib, but there
were concerns that ROMlib wouldn't be robust enough to handle complex
applications. Executor was created both as a viable software product and as
proof that ROMlib will work with complex programs.
We hope you like what you see and that you'll pass on your knowledge of our
company and projects to your colleagues and to the manufacturer that supplies
you with open solutions. We welcome suggestions and are trying hard to grow as
a company so that we can act on them. Most suggestions so far have been
"Support Color," Support Printing." We will as soon as we can. When we
release our first product it will certainly be less powerful than what
everyone wants (a product that runs on all platforms, executes all programs
written on a Macintosh and has no limitations with respect to Color, Printing,
etc.). We humbly ask that you not buy our product until it does what you want.
We don't want to disappoint anyone and sincerely believe that some people will
benefit from our limited versions and it will be less of a hassle for each of
us if you wait until we release what you really want before you become a
customer.
ExecutorDemo is distributed on a floppy disk as a NeXT package.
You must be super-user to do the installation because ExecutorDemo
must be installed as a set-uid root program so it can load in kernel
<More Stuff deleted>
Once ExecutorDemo has been installed you should be able to run the
sample programs provided by starting up ExecutorDemo and selecting
the application you wish to run and then either completing a double
click or selecting the "OK" button. This document assumes you are
already familiar with the Macintosh paradigm.
<More stuff deleted>
The first release will run Microsoft Word 4.00D. Other programs
may work; but you are on your own. The Microsoft Word "only"
version will cost $80.00. When it is fully debugged, a version
that supports all major applications, Color, and Sound will cost
$700.00. The $80.00 version should be out in December 1991. It
is too early to predict when the full featured version will be
available. Qualification for other applications shall be forthcoming
as an interim solution.
<further more stuff deleted>
people wouldn't believe our code would hold up with the heavy use of a
major application. It does. 2) The legal implications. We'd get a better
reception if we were selling flammable children's nightwear.
I hope enough people were interested to justify this as a post rather than
e-mail. I hope some comp.sys.next readers will see us at UNIX Open even
though NeXT won't be there. Perhaps if enough show up we can go hit "Fondue
Fred" in Berkeley.
Thank you.
Sincerely,
Clifford T. Matthews
President and founder
Abacus Research and Development, Inc.
It sounds like they still have much work to do on it, but seems to be well
underway. I hope this helps.
Suthipuntha,
------------------------------
Date: 3 Oct 91 14:00:20 GMT
From:
noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs
.ohio-state.edu!dhbutler@arizona.edu (David Butler)
Subject: Spectre GCR/System 7/A/UX
To: Info-Atari16@naucse.cse.nau.edu
In article <"1028*.S=data3d.O=aahs.PRMD=uninett.ADMD=..C=no."@MHS> data3d@aahs.
no (Karl Anders 0ygard) writes:
>1 simple question: Does Spectre run System 7 and A/UX?
>
>Karl Anders Oygard - Karl A Oygard <data3d@aahs.no>
System 7 does not work as yet (and who wants it, have you used it? Man, talk
about slow. Also uses over a MEG or ram just for the basic OS, they probably
have Crays running on smaller operating systems. I have a theory the whole
thing was written in basic, and is actually just a huge pracitical joke
anyway). I don't know about A/UX. Dave Small will probably have system 7
working soon for those who want it. As for A/UX, since Dave is a UNIX wiz, if
it does not work at this time, I'm sure he is working on it, or can at least
let you know one way or the other.
- David Butler -
------------------------------
Date: 3 Oct 91 04:38:44 GMT
From:
news-server.csri.toronto.edu!generic.physics.utoronto.ca!julian!julian.uwo.ca!e
rsmith@uunet.uu.net (Eric Smith)
Subject: Using gcc/g++ to cross compile for the ST
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Oct2.215945.25204@elroy.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov
(Howard Chu) writes:
>I'm a little hazy on the MiNT support in the current version of gcc.
>It causes the mint libraries to be loaded before the regular libraries,
>but the mint library docs say "use this instead of the regular gnu
>libraries." Some agreement/clarification would be nice.
The mint library docs were written before gcc 1.40 was available and
before the gcc include files were adapted for MiNT (you can check the
latter by grep'ing for __MINT__ in the include directory), so the
confusion is understandable. Some clarification, then:
(1) You can keep the original gcc include files and libraries, and
name the MiNT libraries as mint.olb and mint16.olb, and then use the
"-mint" switch to gcc to use the MiNT libraries (e.g. gcc -mint
foo.c). If you do this, the MiNT library will be searched first, and
then the "normal" gcc library; it is highly unlikely that anything
will actually be linked from the normal library, since the MiNT one is
complete, so that second search does nothing. (Also: use the gcc
library crt0.o).
You can use this set up if you want to use different libraries for
different programs.
(2) Alternatively, you can throw out (or put on a backup disk) the old
gcc libraries and use the MiNT ones (in this case, call them gnu.olb
and gnu16.olb) and the MiNT crt0.o. In this case, you'll probably want
to use the MiNT include files instead of the gcc ones, since they're
smaller.
This is the setup I use, and it's the only one I can absolutely
guarantee; on the other hand, I strongly suspect that (1) works as it
should, since I trust bammi to get it right. Personally, I can see no
reason *not* to use the MiNT library alone, so I see no reason to keep
the "normal" one. However, mileage may vary.
(Do I see a reason not to use the normal library? Yes: UNIXMODE is a
horrible abomination that causes code bloat and aggravation if you're
trying to use a non-TOS file system (like minix) under MiNT. It was
probably one of my worst ideas (or, if the idea wasn't bad, the
implementation certainly was). MiNT is my penance for UNIXMODE :-) ).
--
Eric R. Smith ersmith@julian.uwo.ca eric.smith@uwo.ca
create a sensible (non-TOS) file system. It was my worst mistake, and
believe me, I've done penance for it
------------------------------
Date: 3 Oct 91 04:58:32 GMT
From: pro-smof.cts.com!bgodot@ucbvax.berkeley.edu (Buck Godot)
Subject: WANTED: Suggestions for ST color monitor purchase
To: Info-Atari16@naucse.cse.nau.edu
I'm tired of using Video Key with a composite monitor. It was an
inexpensive option at the time, but I would like to get the real thing
now.
Does anyone have any suggestions for a color monitor purchase? Any
warnings?
BTW, this is for a 1040 STf.....
------------------------------
End of Info-Atari16 Digest
******************************
