Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 541
INFO-ATARI16 Digest Mon, 14 May 90 Volume 90 : Issue 541
Today's Topics:
(none) really problems with memory upgrade **FLAME**
8086 C Cross Compiler ???
Arcgsh: New Version 3.0
CALL FOR VOTES: comp.sys.atari.st.tech
changing directory with a program??
Determining Own Name - Major BooBoo
getting argv[0]
MMU on Atari ST
PRO GEM 13+
Uniterm/Tektronix 4100 terminal emulator
wanted, 68000 filled polygon code
WHERE IS PINHEAD????????
----------------------------------------------------------------------
Date: 14 May 90 07:22:53 GMT
From: eagle.wesleyan.edu!ncastellano@CS.YALE.EDU
Subject: (none) really problems with memory upgrade **FLAME**
Message-ID: <23013@eagle.wesleyan.edu>
In article <398@van-bc.UUCP>, johna@van-bc.UUCP (John Altstadt) writes:
> In article <22828@eagle.wesleyan.edu> ncastellano@eagle.wesleyan.edu writes:
> >In article <9005130650.AA28761@Sunburn.Stanford.EDU>, FTJLH@ALASKA.BITNET
("Prinz_Arcturus") writes:
> >> ZRAM video flicker
> >> as I was saying... the left and right borders of what I see on a mono
> >> monitor jump back and forth several chars worth. The rightmost char gets
> >> wrapped around to the next line. All this on a 1040 taken to 2.5, with
> >> all the rf shields left off. The ZRAM sits right on top of the video
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > This is probably the source of the problem.
> >
> >> shifter.
> >> Any help appreciated.... I'll try to get in there again and shield
> >> what I can.... but, right now, the jitter has stopped and I'm merely
> >
> >What do you want help with? You've already indicated the problem and the
> >most likely solution, so what can we say?
> >
> >> right shifted several chars. Thanks for any comments.
> >> J Harris Fairbanks/Alaska
> >--
> > ncastellano@eagle.wesleyan.edu ncastellano@wesleyan.bitnet
> > Sinkhole!dEADHEAd@mast.citadel.moundst.mn.org
> > "We are happy. (_silence._) What do we do now, now that we are happy?"
> > -Estragon, _waiting for godot_ by samuel beckett
>
> Wow, you read it here first on usenet: removing the shielding (that is
> wrapped around the OUTSIDE of all the circuit boards) that was designed to
> reduce radio and television reception interference, will make electrical
> signals take several milliseconds longer to propagate through wires. In
> fact, the wires become storage devices capable of storing several clock
> pulses along their lengths. RAM prices should drop dramatically now
> that the secret is out, otherwise everybody will replace their RAMs
> with loops of wire. Anybody want to continue this thread on alt.urbane.
> legends?
>
WARNING: ***FLAME ON***
Electronic propagation delays are not the only source of monitor
flickering. Pardon me for living, but it sounded to me like a safe
assumption that removing the RF shield could cause RF leakage which
could interfere with a monitor. So I suggested that he try to put it
back on. Is that any reason for you to be snide and flame me? The
purpose of this newsgroup is to provide information, not to prove who
is the biggest hotshot know-it-all who can make everyone else look
stupid. Well, my friend, the only one who looks stupid here is you.
Read on...
> What sort of a school is this "wesleyan" anyways? Judging by the
> ..signature it must be either philosophy or theatre. It's certainly
> "creative".
>
What the HELL does my school have to do with anything? Yes, they
teach philosophy here, and yes, we have quite a large theatre
department. We also have a math department and a physics department.
Are students at liberal arts institutions not allowed to post on
matters of a technical nature? Sorry, I must have missed the sign on
the door that said "Only engineering students allowed." My signature
is there because I like it, it has nothing to do with my school, my
major, or what my interests besides literature are. I am a COMPUTER
SCIENCE major. Should I have put some really brilliant quote from
Niklaus Wirth in my .signature? The only thing that makes someone
more qualified than me to post on a subject is if they know more about
it than I do, which has nothing to do with my school, my .sig, or
whether or not you think you're god's gift to the world of
electronics. Grow up.
> From my own experience with memory upgrades, I would say that the problem
> is that there are two different physical banks of RAM being accessed as
> the same logical bank. I upgraded my 520 to a 1040 a long time ago.
> When the price of 1M chips dropped low enough last year, I popped in
> a set and had results much the same as those described above. The
> problems went away when I removed the 256K DRAMs that were part of
> the initial upgrade.
Gee, look at that...actual information. Why couldn't you have just
posted that without being a total asshole about my message?
>
> My upper RF shield was recyled long ago (it's probably part of a Buick
> now) because the RAM + shield wouldn't let me put the keyboard back in.
>
> Cheers
> John
> --
> John Altstadt, 6135 Carson St., Burnaby B.C., CANADA, V5J 2Z8
> ...!ubc-cs!van-bc!johna || ..!uunet!van-bc!johna || johna@wimsey.bc.ca
> There may, or there may not have been some :-)s up there. There should
> probably have been a few more for the humorless, lost souls out there.
There were none. And for those who think your sense of humor sucks,
it wouldn't have done a damn bit of good. Get a clue.
*** FLAME OFF ***
--
ncastellano@eagle.wesleyan.edu ncastellano@wesleyan.bitnet
Sinkhole!dEADHEAd@mast.citadel.moundst.mn.org
"We are happy. (_silence._) What do we do now, now that we are happy?"
-Estragon, _waiting for godot_ by samuel beckett
------------------------------
Date: 14 May 90 12:37:40 GMT
From: maytag!mks.com!ant@iuvax.cs.indiana.edu (Anthony Howe)
Subject: 8086 C Cross Compiler ???
Message-ID: <1990May14.123740.5288@mks.com>
I was wondering if there was a cross-compiler that produced 8086 code or
maybe a 68000->8086 translating assembler. I'm hoping that such a beast
might exist which would solve my need to get any expensive PC emulators.
- ant
--
__ "A thousan li journey begins
_ . .-|- / _\ . . |_ _. _ _ . . with just one step."
(_\ |\| | |(_/ |\/| |\ _\ o (_ (_) |\/|
------------------------------
Date: 14 May 90 07:20:31 GMT
From: mcsun!unido!laura!heike!klute@uunet.uu.net (Rainer Klute)
Subject: Arcgsh: New Version 3.0
Message-ID: <2157@laura.UUCP>
I would like to announce version 3.0 of Arcgsh.
Arcgsh is a GEM based shell for the popular archivers Zoo, Arc, and
LHarc. Besides that you can call the not-so-popular-anymore Shar. A GEM
interface to Uud and Uue eases decoding of articles you grabbed from the
net resp. encoding files for distribution via net or e-mail.
Main improvements over Arcgsh V2.1c:
- Support of Arc V6.02.
- Support of LHarc V1.13 (posted in comp.binaries.atari.st some weeks
ago). I am not quite happy with LHarc because there are several formats
of LHarc archive files floating around and still no English
documentation is available. Consequently you might not be able to
extract every .LZH file but only those LHarc V1.13 can decode. (For
other .LZH files Unlzh may be helpful.) Due to the lack of documentation
the Arcgsh GEM interface relies on some guesses I made and some options
are not (directly) available. Hopefully the situation will get stable some day.
I am still working on the Arcgsh documentation which will be more
detailed than the former one. It will be distributed in LaTex format.
For those poor souls without TeX an ugly looking ASCII version will be
included.
Arcgsh V3.0 will appear in comp.binaries.atari.st within the next few weeks.
Dipl.-Inform. Rainer Klute klute@heike.informatik.uni-dortmund.de
Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet
Postfach 500500 |)|/ ...uunet!mcvax!unido!klute
D-4600 Dortmund 50 |\|\ Tel.: +49 231 755-4663
------------------------------
Date: 14 May 90 01:21:18 GMT
From:
usc!zaphod.mps.ohio-state.edu!uwm.edu!bionet!turbo.bio.net!wam.umd.edu@ucsd.edu
(David M. Baggett)
Subject: CALL FOR VOTES: comp.sys.atari.st.tech
Message-ID: <1990May7.024120.19065@wam.umd.edu>
[I did not receive a call for discussion for this group.-eliot]
*** PLEASE READ THIS ENTIRE MESSAGE BEFORE REPLYING ***
This is the first call for votes for creation of a new group
comp.sys.atari.st.tech
The voting period will last until 11:59 PM on June 4, 1990.
*** DON'T VOTE UNTIL YOU READ THE WHOLE MESSAGE! ***
The charter of the group, if created, will be as follows:
Charter for comp.sys.atari.st.tech
----------------------------------
comp.sys.atari.st.tech is devoted to technical discussion
regarding Atari ST software and hardware. Examples of topics to
be discussed in this newsgroup include:
"What are the pinouts for the ___ port on the ST?"
"Has anyone managed to hook up a ___ successfully?"
(Assuming this is a nontrivial task)
"Which system vector controls ____?"
"What is the official, Atari-sanctioned method of doing ___?"
"What are the specs for ___ file format?"
"How does ___ manage to get 20 million colors on the screen?"
"What is the best way to do fine scrolling?"
Examples of topics NOT to be discussed in this newsgroup include:
"How do you get past the dragon in ___ game?"
"For sale: ___"
"New product announcement: ___"
"My ST is better than your ___ because"
"My ___ is better than your ST because..."
"Atari's financial situation is ___"
-----------------------------------------------------------------------------
comp.sys.atari.st.tech, if created, will be unmoderated.
HOW TO VOTE
-----------
To cast a vote, send a mail message to dmb@wam.umd.edu with either of
the following subject lines:
Subject: Vote YES for comp.sys.atari.st.tech
Subject: Vote NO for comp.sys.atari.st.tech
THE BODY OF THE MESSAGE WILL BE IGNORED. Nothing placed in the body will
be used in counting votes.
No vote with an incorrect subject line will be counted!
ONLY votes MAILED to dmb@wam.umd.edu will count. Votes posted to the net
for any reason (including inability to get mail to dmb@wam.umd.edu) and
proxy votes (such as having a mailing list maintainer claim a vote for
each member of the list) will not be counted.
Voting deadline: 11:59PM June 4, 1990
Dave Baggett
dmb@wam.umd.edu
------------------------------
Date: 14 May 90 09:43:34 GMT
From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!tukki!suhonen@ucsd.edu
(Timo Suhonen)
Subject: changing directory with a program??
Message-ID: <4528@tukki.jyu.fi>
Hi!
Is there a way to change directory with a program so that the change
can be seen after the program in desktop (or in a shell; I use gulam)???
I'm writing a program that changes directory with a TOS call (migh be
3F; can't remember). The call returns a 0 (success), but when the program
exits I am again in the same directory where I started the program. This
happens both with gulam shell or with desktop.
I have good old 520ST with 1M RAM and TOS dated 85 (or 86) and I use
Sozobon C version 1.1(?).
Timo
--
Timo Suhonen suhonen@tukki.jyu.fi
I am logged in, therefore I am
------------------------------
Date: 14 May 90 10:58:31 GMT
From: mcsun!hp4nl!phigate!ehviea!leo@uunet.uu.net (Leo de Wit)
Subject: Determining Own Name - Major BooBoo
Message-ID: <784@ehviea.ine.philips.nl>
In article <888@ncs.dnd.ca> balkwill@ncs.dnd.ca (R. J. Balkwill) writes:
[]
|A general solution to the problem that doesn't break any rules or make
|assumptions about future TOS's is unknown to me. True, that if one
|has a shell that uses ARGV and if one's compiler inserts
|ARGV-compatible startup code, all is fine. Not all shells and
|compilers cooperate.
|
|Dlibs uses a method (with uncooperative shells) based on accessing the
|stack of the parent process (assuming there is one) to see what name
|it supplied to the Pexec(). It works but it looks kind of fragile
|unless Atari has sworn not to alter the key components.
This does not work with Pexec(4,...), since that call doesn't even
_use_ a program name. It seems to prevent any fundamental solution to
the problem (other than to fix GEMDOS, but that is a fundamental one).
|
|There does appear to be a reserved slot in the basepage at offset 40.
|Perhaps this was originally intended to point to prog name. It would
|have been nice.
|
|P.S. I tested my 'procedure' and got a nice virgin-looking dta - all
|zeros.
Of course; the initial dta starts at the same address as your program's
argument string! That's why your assumption about the dta was wrong in
the first place (Fgetdta() gives the process' own disk transfer address
- initialized by GEMDOS to point to the same address as the program's
argument string -, not that of the parent).
|
|Bob (iq--)
~~~~ braindamage? 8-)
Leo.
------------------------------
Date: 14 May 90 08:34:57 GMT
From: hpcc01!hpbbn!hpbbi4!stefan@hplabs.hp.com (#Stefan Bachert)
Subject: getting argv[0]
Message-ID: <510006@hpbbi4.HP.COM>
/ hpbbi4:comp.sys.atari.st / silvert@cs.dal.ca (Bill Silvert) / 3:16 pm May
12, 1990 /
> Huh? How do things like FOLDRXXX.PRG get their name then?
What is about reading the directory for foldr*.prg ?
Stefan
------------------------------
Date: 14 May 90 08:17:40 GMT
From: hpcc01!hpbbn!hpbbi4!stefan@hplabs.hp.com (#Stefan Bachert)
Subject: MMU on Atari ST
Message-ID: <510005@hpbbi4.HP.COM>
/ hpbbi4:comp.sys.atari.st / rcb@netcom.uucp (Roy Bixler) / 4:15 am May 11,
1990 /
> I'm wondering if there are any possibilities of replacing the MMU on the
> ST with one that gives memory protection. I'd like to upgrade to Unix
> and not have to buy an expensive new machine. I realize there are
> people out there interested in this idea, so has anyone had any luck?
>
> Roy Bixler
> rcb@netcom.uucp
> ----------
There is an other pit fall. The 68000 is not able to continue
an aborted bus cycle. So you cannot implement demand paging
easily. If you omit demand paging you need a lot of memory.
And for UNIX 4 MB is really less.
So you have to wait for the day ATARI will offer the TT under UNIX.
(hopefully this day will come and hopefully ATARI will support UNIX unlike
GEM/TOS)
By the way what is about MINIX on ST?
Stefan
------------------------------
Date: Mon, 14 May 90 13:45:40
From: "Simon Chappell"
<S61304%PRIME-A.POLY-SOUTH-WEST.AC.UK@CORNELLC.cit.cornell.edu>
Subject: PRO GEM 13+
Does anyone know how to get hold of the PRO GEM articles after number
thirteen? I have the first thirteen but I have heard that there are
others! I have no FTP access outside of the UK, so if you have these
articles could you mail me them, using either UUE or ordinary text
(No binary mailings please!)
Regards,
Simon
| Simon Chappell, B.Sc(Hons) Computing and Informatics (Final Year)
| 51 Amherst Road, Penny-Come-Quick, Plymouth, Devon, PL3 4HJ, UK.
| JANET: s61304@uk.ac.psw.pa (Until the end of June 1990)
|
| Holder of the ST Penpals list. Join now and beat the Christmas rush!!
|
| "The box said nothing, only this time louder!" - Terry Pratchett
------------------------------
Date: 12 May 90 17:17:52 GMT
From:
zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!gopnbg!tmpmbx!e
inoed!utopia!neon!woju@tut.cis.ohio-state.edu (Wolfgang Jung)
Subject: Uniterm/Tektronix 4100 terminal emulator
Message-ID: <1087@neon.UUCP>
ashwin@gatech.edu (Ashwin Ram) writes:
>Hi... I'm a long-time user of UNITERM but I've been a little behind on
>upgrades. What is the latest version available?
So far i think the latest version is UNITERM V20E 011
If' there is a newer Version off Uniterm, it would be nice, if
the one post it to the binaries...
CU
--
===================================================================
# Wolfgang Jung Email:woju@neon.UUCP #
# Germany #
===================================================================
------------------------------
Date: 14 May 90 19:01:41 GMT
From: usc!samsung!munnari.oz.au!murtoa.cs.mu.oz.au!viccol!gjocc@ucsd.edu
Subject: wanted, 68000 filled polygon code
Message-ID: <6203.264eba46@csv.viccol.edu.au>
I am currently writing a game in compiled STOS BASIC (yuck why
didn't they write STOS 'C' or STOS Pascal?).
I find that the STOS polygon instruction is too slow for
my needs (It probably just uses LINE A?).
Does anyone out there have a fast 68000 assembler routine for
drawing filled polygons?
I dont even need a general routine, just low res, solid fill, four vertices,
and blinding speed.
Help, I haven't written any 68000 assembler before.
(although I did write some Z-80 assembly code years ago :-).)
Greg O'Sullivan (gjocc@csv.viccol.edu.au)
------------------------------
Date: 14 May 90 13:55:59 GMT
From:
usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!watserv1!watcgl!electro!ig
nac@ucsd.edu (Ignac Kolenko)
Subject: WHERE IS PINHEAD????????
Message-ID: <1786@electro.UUCP>
In article <9005092019.AA06214@Argus.Stanford.EDU> SA44@liverpool.ac.UK (Kevin
Maguire) writes:
>It seems that GEMDOS doesn't clear the memory if a program has no
>relocation data (last word in GEMDOS header == FFFF)
this is because in writing a $FFFF into the last word of the header, you
are toggling the TOS 1.4 fast file load bit, which ends up doing
EXACTLY the same thing like PINHEAD, but with less problems since this is
an actual feature of TOS 1.4, rather than a patch program like pinhead.
(correct me if i'm wrong - with a 1040, you can't really notice any
difference, although people with 520's claim that pinhead speeds things
up enormously - more a placebo effect than anything else i think!)
--
=====Ignac A. Kolenko (The Ig)=====watmath!watcgl!electro!brasoft!ignac======
co-author of QuickST, and the entire line of Quick Software!!!!
Branch Always Software Box 2624, Station B, Kitchener, Ont. CANADA N2H 6N2
=============================================================================
------------------------------
End of INFO-ATARI16 Digest V90 Issue #541
*****************************************
