Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 083
=========================================================================
INFO-ATARI16 Digest Mon, 22 Jan 90 Volume 90 : Issue 83
Today's Topics:
Bob Dobbs character set??
dissassembly (2 msgs)
GNU/Sozobon C question
Hello
Questions! (FTP'ing from VAX)
Spectre 2.5 Newsletter advisory
ST S/ware Rental Places
TURBO-C Question!
----------------------------------------------------------------------
Date: 23 Jan 90 01:55:48 GMT
From:
pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ap
lcen!jhunix!rick@tut.cis.ohio-state.edu (Eric Ruck)
Subject: Bob Dobbs character set??
Message-ID: <4031@jhunix.HCF.JHU.EDU>
I don't know about this Bob character, but I do seem to recall that either
one or both of the Tramiels were Auschwitz survivors, hence the Hebrew.
Eric
------------------------------
Date: 22 Jan 90 15:53:34 GMT
From: sgi!shinobu!odin!odin.corp.sgi.com!portuesi@ucbvax.Berkeley.EDU (Michael
Portuesi)
Subject: dissassembly
Message-ID: <PORTUESI.90Jan22155334@tweezers.esd.sgi.com>
>>>>> On 16 Jan 90 02:58:17 GMT, kbad@atari.UUCP (Ken Badertscher) said:
ken> Believe me, Arion, it's very very tempting at times. Especially when
ken> you see some of the really silly things that some developers do to
ken> break the rules. You want to punish them. But in fact, the end users
ken> are punished worse if Atari breaks programs which break the rules.
I disagree. In the end, the users are punished worse if Atari
*doesn't* break programs which break the rules. Those programs keep
Atari from adding bug fixes and enhancements to their operating
system, which hurts everyone in the end -- not just those people who
depend on broken software.
ken> All
ken> a user knows is that his favorite program doesn't work any more. If
ken> the company that made it is no longer in business, that user is really
ken> up the creek.
True. But in many cases, the user may be able to switch to an
alternative which didn't break the rules. And if I had some very
important piece of software I depended on for my livelihood, I would
think long and hard about migrating to something else if the company
that produced it went out of business.
--M
--
__
\/ Michael Portuesi Silicon Graphics Computer Systems, Inc.
portuesi@SGI.COM Entry Systems Division -- Engineering
------------------------------
Date: 22 Jan 90 18:02:02 GMT
From: per2!dag@speedy.wisc.edu (Daniel A. Glasser)
Subject: dissassembly
Message-ID: <893@per2.UUCP>
Being the person who wrote most of the MWC examples (other than most of the
GEM examples, which were mostly written by a non-programmer), I would like
to defend the MWC manual/examples a little here.
In article <1540@cs.rit.edu>, ajy2208%ritcv@cs.rit.edu writes:
> In article <10665@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu)
writes:
> [...informative stuff deleted...]
> >As for the stray data at the top, perhaps you're not aligning the
> >screen memory correctly?
> This was a problem at first, as I am a beginning ST programmer and
> am not a registered developer (yet.. :-). Of course, the people
> who wrote the MWC documentation didn't bother mentioning the
> fact that the memory has to be ALIGNED.. But they provided a nice
> example, in which they aligned the memory, so that's how I learned..
Sorry about that... The decision to not put the restriction into the
main part of the documentation was made because it was unclear what
future products might offer. There was supposed to be a note that stated
that the current 520 and 1040ST machines had this restriction, but this
got left out by accident, and nobody seems to have noticed. The examples
had most of their comments stripped out so they could fit into the manual.
> >If you're writing code that you eventually hope for
> >other people to use, don't hard-code magic numbers like 32K into your
> >screen manipulation routines. [In fact, don't even use 32K. You only
> >need, at most, 32256, to get 32000 bytes on a 256 byte boundary, eh?]
> Kind of interesting, that the example in the MWC manual does have
> 32K hard wired in. Of course, it's only an example, but for someone
> learning how to do something for a first time, it's not setting a
> GOOD example.. sigh.. (at least it does have LOTS of examples)..
Well -- I had to use some value when I wrote the example. I could have
used a #define, but at the time it seemed like this would remain unchanged
for the immediate future, and we didn't want to go through all the extra
trouble (in the example) to calculate the memory needs of the new display.
(It was not a GEM example, and S.A.L.A.D. was not yet written, and even when
these two conditions are met, it is still more than a few lines of code
to figure this out in the general case for all possible future display
modes, if its possible at all. I don't know what happens when you use
a Moniterm.) These examples were supposed to be short and illustrate
proper use of the documented routine/function/feature, without adding
lots of extra stuff that might confuse or intimidate the novice ST programmer.
I might add that for a program like a picture viewer (as described in the
original posting) to work with the overscan modification a simple file
read / physbase change will not do the trick anyway. Most of these
bitmap graphics file formats assume the standard ST screen layout.
The fact is that at the time the MWC manual was written, there was very
little programming documentation available for the ST. We went above
and beyond the required material for just using our compiler and set a
standard for completness which far outstripped anything available to the
general public at the time, and which the competition took a long time
to catch up with. We did not just rehash the material in the developers
documentation, we wrote new documentation and provided examples for just
about every Atari specific function in the system. We gave notes on how
some BIOS/XBIOS/GEMDOS functions were documented to work in the developers
documentation but actually worked in some other way and warned that these
things may change. We went out of our way not to use any non-sanctioned
hooks into the OS to make our product work.
In my honest opinion, biased as it may be, the MWC manual is the single
best volume for programming the ST published to date. It needs revision,
bugfixing, and maybe some other tweeking (new GEM examples, etc.) and
the compiler should be updated, but it is still a very good package at a
good price.
I don't work for MWC anymore, and don't speak for them. I've just seen
a few people bash the MWC package recently and wanted to set the record
a little straighter. I know that the posting to which I've followed up
is not a bash, but it was a convenient place to put this.
Daniel A. Glasser
--
_____________________________________________________________________________
Daniel A. Glasser "Their brains were small and they died."
uwvax.cs.wisc.edu!per2.uucp!dag
---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------
------------------------------
Date: 22 Jan 90 18:27:48 GMT
From: per2!dag@speedy.wisc.edu (Daniel A. Glasser)
Subject: GNU/Sozobon C question
Message-ID: <894@per2.UUCP>
In article <1990Jan17.154602.19880@chinet.chi.il.us>, saj@chinet.chi.il.us
(Stephen Jacobs) writes:
> 2)I like Mark Williams C. The non machine-specific parts are pretty K&R
> compliant. The library is very UNIX-like. The support people are great if
> you phone (don't write--they answer in 3 months). The compiler is said to be
> derived from pcc. The source and machine language debuggers work well.
> Steve J.
The MWC compiler is not derived from PCC. It is derived from the Coherent
(A 7th-edition Unix compatible OS with NO unix source code involved) compiler
which had been ported from the PDP-11 to the 8086 and Z8001 before the 68000
port was done. The compiler base is similar to pcc in many respects, but
it is not a derivitive of that compiler.
A large part of the speed "problems" that the MWC compiler has is because of
this history. A version (built from the same sources) ran on a PDP-11 as
a cross compiler until version 3. The PDP-11 has only 64k of virtual
address space. The compiler, therefore, uses disk files to store intermediate
code and chains between programs to do various stages of compilation.
The advantage to this is that the MWC compiler can run effectively in systems
with limited memory (512k with DAs loaded) and can handle programs larger than
available memory. I've linked an 800k program on a 520 with MWC.
Daniel A. Glasser
--
_____________________________________________________________________________
Daniel A. Glasser "Their brains were small and they died."
uwvax.cs.wisc.edu!per2.uucp!dag
---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------
------------------------------
Date: 23 Jan 90 00:53:46 GMT
From: zephyr.ens.tek.com!orca.wv.tek.com!pogo!bluneski@beaver.cs.washington.edu
(Bob Luneski)
Subject: Hello
Message-ID: <8429@pogo.WV.TEK.COM>
Hello Everyone!!
I just wanted people to know that I just gained access to the network
and can be reached here for questions and comments on Diamond Back.
Thanks,
Bob Luneski
Author: Diamond Back
------------------------------
Date: 22 Jan 90 16:09:15 GMT
From: ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrwic!wsucsa!mwjester@ucsd.edu
Subject: Questions! (FTP'ing from VAX)
Message-ID: <11456@wsucsa.uucp>
In article <9001220804.AA20499@ucbvax.Berkeley.EDU>, FRACHEL@UMIAMI.MIAMI.EDU
writes:>
> I have a question about FTP'ing. It seems that I cannot login to most
> so called 'anonymous' ftp sites while using the VAX system, but my
> friend on a unix system can get in fine.
>
> Is there anything I can do about this?
I can't answer your question about UUCP, but I can speak from experience about
FTP'ing from a VAX/VMS system. Your system is converting everything to upper-
case (I dunno why it was set up that way), and the system you are trying to
connect to is case-sensitive (probably a Unix(TM) system). What works for me
is to put quotation marks around anything the remote system is going to see.
e.g. FTP some.site.name
status message from the FTP program here...it should eventually tell you
it connected, and give you the prompt.
FTP>login "anonymous"
message saying guest login OK, asking you for your user name as password
Password: your user name here (needn't be quoted)
If all goes well, it should tell you that you are logged in; it will probably
say that some access restrictions apply.
In general, you will have to quote filenames or directories; you _probably_
don't have to quote commands (cd,get,dir,set,etc.).
Hope this helps!
-Max J
------------------------------
Date: 21 Jan 90 07:58:13 GMT
From: tcr!gadgets!dsmall@boulder.colorado.edu (David M. Small )
Subject: Spectre 2.5 Newsletter advisory
Message-ID: <3@gadgets.UUCP>
Fairly soon, the next Gadgets by Small newsletter will be going
out. If you haven't registered your Spectre 128 or GCR with us,
now is the time; there's talk of even including a free 2.5 update
with the newsletter (can't guarentee that, though). Still, it's
fairly good stuff.
If you have registered, our last newsletter went out last
summer. If you missed it then, time to call and check. Or email
me; this net address is unstable sometimes, I recommend the Well.
(hplabs!well!dsmall, or dsmall@well.sf.ca.us).
Details of some of the good things upcoming are within, and
it's free, if you just let us know your address, to our owners that
register.
-- thanks, Dave / Gadgets by Small
p.s. I mention this because many people feel registration cards are
near worthless, and never hear anything from the companies that
they send them into; we're not that way. So far, we've given two free
software updates, three newsletters, and lots of good karma to people
who've sent in their cards.
.
------------------------------
Date: 22 Jan 90 22:53:18 GMT
From: nsc!pyramid!infmx!robert@hplabs.hpl.hp.com (Robert Coleman)
Subject: ST S/ware Rental Places
Message-ID: <3165@infmx.UUCP>
In article <25910@brunix.UUCP> rjd@cs.brown.edu (Rob Demillo) writes:
>In article <1990Jan17.065533.601@murdoch.acc.Virginia.EDU>
gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) writes:
>I agree completely. And don't believe I have insulted legitimate
>businesses. If you want to see a piece of software run, go to
>a store and ask the proprieter to start up a copy for you. I have
>never been refused this request.
>
I basically agree with your other statements, but I just wanted to
note that I *have* had requests to see software turned down in a number
of stores- B&C Computervisions in Sunnyvale as an example. One of the
reasons I don't shop there...I am lucky enough to have access to several
stores in the area, but other users aren't as lucky. Under those
circumstances, software rental places could serve a legitimate function.
Robert C.
--
"Helen's the only one who knows what scruples are, and she won't tell us"
John said. "Have we got scruples about it, Helen?"
"Not a trace," Helen affirmed. -The Reefs of Earth, R.A.Lafferty
------------------------------
Date: 19 Jan 90 07:37:34 GMT
From: mcsun!hp4nl!tnosoes!joep@uunet.uu.net (Joep Mathijssen)
Subject: TURBO-C Question!
Message-ID: <671@tnosoes.UUCP>
I'm trying to compile 'BISON' on my ST using the TURBO-C compiler. After
a few changes the compilation was successful, but the linker still gives
some weird errors.
On standard C-function like 'free' I get:
"16 bit PC relative overflow"
When I change the order of the linked files, some other functions
are listed. The linker is trying to call the function
using relative addressing and sometimes the function is simply
to far away.
How can I solve this problem without changing compiler? Is there
an option that I don't know.
Or SHOULD I use another compiler? The only one I'm prepared to use
is the GCC-compiler. But will this compiler work correct on an
1MB atari.
Joep,
===============================================================================
Joep Mathijssen
TNO Institute for Perception
P.O. Box 23 Phone : +31 34 63 562 11
3769 ZG Soesterberg E-mail: tnosoes!joep@mcvax.cwi.nl
The Netherlands or: uunet!mcvax!tnosoes!joep
===============================================================================
------------------------------
End of INFO-ATARI16 Digest V90 Issue #83
****************************************
