Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 540
=========================================================================
INFO-ATARI16 Digest Sun, 13 May 90 Volume 90 : Issue 540
Today's Topics:
(none) really problems with memory upgrade
Determining Own Name
Determining Own Name - Major BooBoo
floppy b: continues to spin on hard disk autoboot
Floppy drive for sale.
----------------------------------------------------------------------
Date: 14 May 90 00:01:37 GMT
From: van-bc!johna@ucbvax.Berkeley.EDU (John Altstadt)
Subject: (none) really problems with memory upgrade
Message-ID: <398@van-bc.UUCP>
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?
What sort of a school is this "wesleyan" anyways? Judging by the
.signature it must be either philosophy or theatre. It's certainly
"creative".
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.
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.
------------------------------
Date: 14 May 90 01:05:12 GMT
From:
usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!watserv1!ria!uwovax!7103_2
622@ucsd.edu (Eric Smith)
Subject: Determining Own Name
Message-ID: <6001.264dcc08@uwovax.uwo.ca>
In article <886@ncs.dnd.ca>, balkwill@ncs.dnd.ca (R. J. Balkwill) writes:
> Ref question on how a program knows its own name. Since there is no
> provision for a pointer to prog name in the basepage (surely an
> oversight) programs like cachexxx determine their names as follows:
>
> a. Do an Fgetdta() to determine the dta location.
>
> b. The prog name (just the name, not the path) is at offset 30.
>
> Notes:
>
> 1. This is left over from the Fsfirst/Fsnext call that located the
> program so the name is in directory format - i.e. 8 + 3 + null byte.
>
> 2. Get it quick before the dta is used for other things.
I thought cachexxx.prg and similar (Atari) programs used Fsfirst/Fsnext
to look for programs named cache*.prg (or whatever). I'd be very surprised
indeed if Atari has guaranteed that a program's initial dta will contain
its name. If they haven't, then you can bet that programs that rely on
this undocumented feature will break under future versions of TOS (or
under MicroRTX or similar multi-tasking operating systems). In other words,
*don't do it*.
If a program really needs to know its own name, it should be started from
a shell that supports the (Atari standard) ARGV= mechanism for passing
arguments; argv[0] will be the program's name.
--
Eric R. Smith email:
Dept. of Mathematics ERSMITH@uwovax.uwo.ca
University of Western Ontario ERSMITH@uwovax.bitnet
London, Ont. Canada N6A 5B7
ph: (519) 661-3638
------------------------------
Date: 14 May 90 03:11:06 GMT
From: ncs.dnd.ca!balkwill@rutgers.edu (R. J. Balkwill)
Subject: Determining Own Name - Major BooBoo
Message-ID: <888@ncs.dnd.ca>
Eric Smith is absolutely right in pointing out the error of my
previous posting about how a program can determine its own name. I
was looking at a disassembly of cachennn when I wrote it but
apparently not with both eyes. In short, I missed the Fsfirst() call.
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.
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.
Bob (iq--)
------------------------------
Date: 14 May 90 02:06:10 GMT
From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!rodan!ggreenbe@ucsd.edu (Gerald
Greenberg)
Subject: floppy b: continues to spin on hard disk autoboot
Message-ID: <3275@rodan.acs.syr.edu>
Now I know why I took so long to get a hard drive! There is a
lot to keep track of! Here's the latest: I've got a 1meg 520
with tos 1.0, an ICD hard drive kit, two external floppies.
When autobooting from the hard disk, the busy light in floppy
a: comes on, then goes off, then the busy light in floppy b:
goes on and stays on...floppy a: continues to spin, but it
seems that floppy b: is not spinning. When I open floppy a:,
the light on b: goes off and everything is back to normal. I
seem to remember there was a similar problem for the Megas, so
I located a little program that, when added to an auto folder,
would access drive a: so that it would then stop spinning. I
tried out this fix, and it worked. As I was trying to see if
there was some other program in the auto folder that was
causing the problem, I found that if I booted from the hard
drive AND there was an actual floppy disk in drive b: upon
bootup, there was no problem...somehow, once drive b: saw that
there was a disk in it, the light would go off and drive a:
would stop spinning. So, I guess I'm just wondering if there
is something in my setup that is causing this? or if this is
normal, and I should just keep a floppy disk in drive b: at
all times?
Thanks in advance for any suggestions. As usual, you can
email me directly, or post to the net.
--Gerry
ggreenbe@rodan.acs.syr.edu
maxg@suvm
------------------------------
Date: 14 May 90 03:28:53 GMT
From: brunix!pgs@uunet.uu.net (Peter Sarrett)
Subject: Floppy drive for sale.
Message-ID: <39741@brunix.UUCP>
For sale: 1 Atari SF354 SS DD disk drive. In perfect working condition,
this drive has never given me a problem. Comes complete with cables and
power supply.
Interested? Please contact me through E-Mail.
===============================================================================
Peter Sarrett | PO Box 439 | "So much time and so little to
pgs@cs.brown.edu | Brown University | do. Stop. Strike that.
uunet!brunix!pgs | Providence, RI 02912 | Reverse it."
pgs@browncs.bitnet | (401)863-6977 | - W. Wonka
===============================================================================
Peter Sarrett | PO Box 439 | "So much time and so little to
pgs@cs.brown.edu | Brown University | do. Stop. Strike that.
uunet!brunix!pgs | Providence, RI 02912 | Reverse it."
pgs@browncs.bitnet | (401)863-6977 | - W. Wonka
------------------------------
End of INFO-ATARI16 Digest V90 Issue #540
*****************************************
